Как подписать apk файл на компьютере

Обновлено: 04.07.2024

Тема этого урока не относится непосредственно к программированию. И вполне себе можно кодить без этих знаний. Но для общего развития, думаю, об этом все-таки стоит поговорить. Данные знания пригодятся вам, например, когда будете делать приложение с гугл-картой, или когда будете выкладывать свое творение на маркет.

Подпись приложения

Вообще, в процессе подписи и верификации участвуют закрытый/открытый ключи и сертификат. Если кому интересно, то можете погуглить эти понятия и почитать подробнее. Я же, чтобы не усложнять урок, буду просто называть все это ключом. Для понимания темы урока этого будет достаточно.

Вы создали приложение и хотите его протестировать на реальном устройстве или эмуляторе. Для того, чтобы установить и запустить приложение, оно должно быть подписано. Если вы еще не публиковали на маркете свои приложения, то, скорее всего, про то, что приложение надо подписывать, вы слышите первый раз. И точно помните, что ни с какими подписями не возились. Создавали проект, кодили все, что нужно, сохраняли и запускали и все прекрасно работало. Так происходило, потому что Eclipse сам создавал ключ и сам подписывал приложение этим ключом, чтобы вам на первых порах не приходилось думать об этом. И когда ваше приложение устанавливалось, оно было уже подписанным. А если попытаться установить неподписанное приложение, то получим ошибку.

Итак, приложение обязательно должно быть подписанным, и Eclipse любезно берет это на себя. Он подписывает их debug-ключом. Раньше срок его действия был всего один год. Android проверяет срок действия ключа только при установке. Т.е. если вы установили приложение и срок действия ключа истек, вы все равно сможете использовать установленное приложение. А вот установить или обновить приложение, подписанное истекшим ключом, не получится. Система выдаст ошибку.

Сейчас срок debug-ключа равен 30 лет. Но приложение, подписанное debug-ключом, не получится опубликовать на маркете. А значит, нам надо будет создавать свой ключ и подписывать им приложение.

keytool

Для создания ключа нам понадобится утилита keytool. Ее можно найти по адресу <папка с Java>\bin. Она умеет создавать новые ключи и показывать информацию о уже существующих. Давайте сначала попробуем посмотреть информацию о существующем ключе. Для этого возьмем тот самый debug-ключ, который используется для подписи приложений по умолчанию. Узнать где он находится можно в настройках Eclipse: Window > Preferences >Android > Build.


Файл debug.keystore имеет расширение keystore. Это можно перевести как хранилище ключей. Это действительно так, один такой файл может содержать в себе несколько ключей. Для того чтобы обратится к конкретному ключу внутри хранилища используется alias (алиас, можно рассматривать его как имя ключа).

Посмотрим, какие ключи есть в хранилище debug.keystore. Используем команду list. С помощью параметров keystore и storepass укажем имя файла хранилища и пароль к хранилищу:

keytool -list -keystore debug.keystore -storepass android


Мы видим, что здесь хранится один ключ с алиасом androiddebugkey, и создан он был 26.08.2012. Этот ключ и используется Eclipse-ом для подписи вашего приложения по умолчанию. Хранилище и ключ имеют одинаковый пароль - android.

Давайте создадим свой ключ. Для этого используем команду genkey и к ней идет куча параметров.

keytool -genkey -keystore mykeys.keystore -storepass spassword -alias mykey1 -keypass kpassword1 -dname “CN=Dmitry Vinogradov O=StartAndroid C=RU” -validity 10000


Выглядит страшно, но на самом деле все несложно. Просто надо понимать следующее:
хранилище - это файл и оно защищено паролем
ключ в хранилище имеет алиас и свой пароль
также ключ содержит информацию о владельце и имеет ограниченный срок действия

Именно эти вышеперечисленные параметры мы и задали в скрипте.

keystore - имя файла хранилища
storepass - пароль к хранилищу
alias - алиас создаваемого ключа
keypass - пароль к ключу
dname - информация о владельце ключа
validity - срок действия ключа (в днях)

dname задается в определенном формате. Я указал только имя, организацию и страну.

После выполнения этой команды в хранилище mykeys.keystore создался ключ с вышеуказанными параметрами. Если указанное хранилище не существует, то оно будет создано.

Теперь давайте снова используем команду list и поглядим на только что созданный ключ

keytool -list -keystore mykeys.keystore -storepass spassword


Видим, что внутри все так, как мы и создавали - один ключ с алиасом mykey1.

Туда же можно поместить второй ключ. Но теперь запишем скрипт создания ключа в несколько урезанном виде. Мы не будем указывать пароли к хранилищу и ключу, и информацию о владельце.

keytool -genkey -keystore mykeys.keystore -alias mykey2 -validity 10000


и программа спросит нас о недостающих данных. Сначала пароль к хранилищу, затем данные о владельце ключа (я заполнял не все требуемые значения), затем пароль для создаваемого ключа и подтверждение пароля.

Функционально разницы нет, но при таком способе вам не надо знать формат ввода параметра dname (утилита все спросит сама), и посторонним не видны пароли, которые вы вводили.

Теперь в хранилище два ключа. Выполним list и убедимся.

keytool -list -keystore mykeys.keystore

Обратите внимание, что я не ввел пароль от хранилища (например, чтобы не «светить» его). Утилита спросит меня:


Видно, что был запрошен пароль и в хранилище сейчас два ключа.

Команду list можно еще выполнить с параметром v. Этот параметр добавляет информативности.


Теперь для каждого ключа виден не только алиас и дата создания, но и инфа о владельце, срок действия и пр.

Параметр v также можно использовать и с командой genkey. После создания ключа будет выведено немного информации о нем в консоль.

jarsigner

Итак, разобрались с keytool. Знаем, как создавать хранилище с ключами и как посмотреть инфу о существующих. Осталось узнать, как подписать приложение ключом. Для этого используется другая утилита - jarsigner.

Скрипт подписи выглядит так:

jarsigner -keystore mykeys.keystore -storepass spassword -keypass kpassword1 Package1.apk mykey1

Имена параметров нам знакомы по keytool: хранилище (keystore), пароль (storepass) к нему и пароль (keypass) к ключу. А последние два параметра – это имя APK-файла, который вы хотите подписать и алиас ключа из указанного хранилища, который вы хотите использовать для подписи.

После этого приложение будет подписано и система примет его к установке.


Попробуем установить приложение на эмулятор с помощью adb. Получаем ошибку Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]:


Система обнаружила, что приложение не подписано.


Визард

Eclipse предоставляет визард, который позволяет реализовать все вышеописанные шаги по подготовке приложения к установке. Для этого надо на проекте в Eclipse щелкнуть правой кнопкой и выбрать Android tools > Export Signed Application Package.

Визард на всякий случай уточнит проект


Затем надо выбрать: использовать существующее хранилище или создавать новое. Если используем существующее, то выбираем его и вводим пароль к этому хранилищу.


Жмем Next, и визард спрашивает, какой из существующих ключей использовать, либо дает возможность создать новый.


Выбираем существующий ключ, вводим пароль к нему


Осталось указать путь и имя файла, куда Eclipse сохранит готовое, подписанное и сжатое приложение. Заодно он сразу показывает срок действия сертификата.


Жмем Finish и получаем готовое приложение, которое можно публиковать на маркете.

Если же у вас пока нет ключа, то визард поможет вам его создать, чтобы не надо было возиться с консолью и keytool.

В этом случае вы указываете, что хотите создать хранилище


Далее надо создать ключ


Здесь вы указываете алиас, пароль, срок действия (в годах) и инфу о владельце.

Ну и остается указать путь к создаваемому файлу


По идее, я мог бы сразу показать вам этот визард, который за вас все сделает, но я думаю, что вы не понимали бы значение всех его экранов и полей. А это не очень хорошая практика – пользоваться тем, чего не понимаешь. Поэтому я подробно расписал механизм ключей и подписи приложений, чтобы вы представляли себе, как устроен этот процесс и что делает визард.

По поводу срока действия ключа, в хелпе пишут, что рекомендуется ставить 25 лет. И что при публикации приложения на маркете, проверяется, что срок действия закончится позднее, чем 22 октября 2033. Думаю, эта дата будет периодически сдвигаться.

На следующем уроке:

- разбираемся, что такое Package для приложения

- в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

- ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

- новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так — всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?

Введение

В этой статье мы поговорим о том, как разобрать пакет APK с приложением, рассмотрим его внутреннюю структуру, дизассемблируем и декомпилируем байт-код, а также попробуем внести в приложения несколько изменений, которые могут принести нам ту или иную выгоду.

Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно — от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.

Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?

Декомпиляция приложений

В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:

Использовать их следует так. Сначала запускаем dex2jar, указывая в качестве аргумента путь до apk-пакета:

В результате в текущем каталоге появится Java-пакет mail.jar, который уже можно открыть в jd-gui для просмотра Java-кода.

Устройство APK-пакетов и их получение

Пакет приложения Android, по сути, является обычным ZIP-файлом, для просмотра содержимого и распаковки которого никаких специальных инструментов не требуется. Достаточно иметь архиватор — 7zip для Windows или консольный unzip в Linux. Но это что касается обертки. А что внутри? Внутри же у нас в общем случае такая структура:

  • META-INF/ — содержит цифровой сертификат приложения, удостоверяющий его создателя, и контрольные суммы файлов пакета;
  • res/ — различные ресурсы, которые приложение использует в своей работе, например изображения, декларативное описание интерфейса, а также другие данные;
  • AndroidManifest.xml — описание приложения. Сюда входит, например, список требуемых разрешений, требуемая версия Android и необходимое разрешение экрана;
  • classes.dex — компилированный байт-код приложения для виртуальной машины Dalvik;
  • resources.arsc — тоже ресурсы, но другого рода — в частности, строки (да-да, этот файл можно использовать для русификации!).

Перечисленные файлы и каталоги есть если не во всех, то, пожалуй, в абсолютном большинстве APK. Однако стоит упомянуть еще несколько не столь распространенных файлов/каталогов:

  • assets — аналог ресурсов. Основное отличие — для доступа к ресурсу необходимо знать его идентификатор, список asset’ов же можно получать динамически, используя метод AssetManager.list() в коде приложения;
  • lib — нативные Linux-библиотеки, написанные с помощью NDK (Native Development Kit).

Этот каталог используют производители игр, помещая туда движок игры, написанный на C/C++, а также создатели высокопроизводительных приложений (например, Google Chrome). С устройством разобрались. Но как же получить сам файл пакета интересующего приложения? Поскольку без рута с устройства забрать файлы APK не представляется возможным (они лежат в каталоге /data/app), а рутить не всегда целесообразно, имеется как минимум три способа получить файл приложения на компьютер:

  • расширение APK Downloader для Chrome;
  • приложение Real APK Leecher;
  • различные файлообменники и варезники.

Какой из них использовать — дело вкуса; мы предпочитаем использовать отдельные приложения, поэтому опишем использование Real APK Leecher, тем более что написан он на Java и, соответственно, работать будет хоть в винде, хоть в никсах.

Настройка Real APK Leecher

Настройка Real APK Leecher

Просмотр и модификация

Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь XML-файла с удивлением обнаружил, что файл не текстовый. Чем же его декомпилировать и как вообще работать с пакетами? Неужели необходимо ставить SDK? Нет, SDK ставить вовсе не обязательно. На самом деле для всех шагов по распаковке, модификации и упаковке пакетов APK нужны следующие инструменты:

Использовать все эти инструменты можно и по отдельности, но это неудобно, поэтому лучше воспользоваться более высокоуровневым софтом, построенным на их основе. Если ты работаешь в Linux или Mac OS X, то тут есть инструмент под названием apktool. Он позволяет распаковывать ресурсы в оригинальный вид (в том числе бинарные XML- и arsc-файлы), пересобирать пакет с измененными ресурсами, но не умеет подписывать пакеты, так что запускать утилиту signer придется вручную. Несмотря на то что утилита написана на Java, ее установка достаточно нестандартна. Сначала следует получить сам jar-файл:

Далее нам понадобится скрипт-обвязка для запуска apktool (он, кстати, доступен и для Windows), включающий в себя еще и утилиту aapt, которая понадобится для запаковки пакета:

Далее просто сваливаем содержимое обоих архивов в каталог

/bin и добавляем его в $PATH:

Если же ты работаешь в Windows, то для нее есть превосходный инструмент под названиемVirtuous Ten Studio, который также аккумулирует в себе все эти инструменты (включая сам apktool), но вместо CLI-интерфейса предоставляет пользователю интуитивно понятный графический интерфейс, с помощью которого можно выполнять операции по распаковке, дизассемблированию и декомпиляции в несколько кликов. Инструмент этот Donation-ware, то есть иногда появляются окошки с предложением получить лицензию, но это, в конце концов, можно и потерпеть. Описывать его не имеет никакого смысла, потому что разобраться в интерфейсе можно за несколько минут. А вот apktool, вследствие его консольной природы, следует обсудить подробнее.

Импорт APK в Virtuous Ten Studio

Импорт APK в Virtuous Ten Studio

Рассмотрим опции apktool. Если вкратце, то имеются три основные команды: d (decode), b (build) и if (install framework). Если с первыми двумя командами все понятно, то что делает третья, условный оператор? Она распаковывает указанный UI-фреймворк, который необходим в тех случаях, когда ты препарируешь какой-либо системный пакет.

Рассмотрим наиболее интересные опции первой команды:

  • -s — не дизассемблировать файлы dex;
  • -r — не распаковывать ресурсы;
  • -b — не вставлять отладочную информацию в результаты дизассемблирования файла dex;
  • --frame-path — использовать указанный UI-фреймворк вместо встроенного в apktool. Теперь рассмотрим пару опций для команды b:
  • -f — форсированная сборка без проверки изменений;
  • -a — указываем путь к aapt (средство для сборки APK-архива), если ты по какой-то причине хочешь использовать его из другого источника.

Пользоваться apktool очень просто, для этого достаточно указать одну из команд и путь до APK, например:

После этого в каталоге mail появятся все извлеченные и дизассемблированные файлы пакета.

Препарирование. Отключаем рекламу

Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет Virtual Torch — виртуальный факел. Для нас эта софтина подойдет идеально, потому что она под завязку набита раздражающей рекламой и к тому же достаточно проста, чтобы не потеряться в дебрях кода.

Поиск кода рекламы в jd-gui

Поиск кода рекламы в jd-gui

Итак, с помощью одного из приведенных способов скачай приложение из маркета. Если ты решил использовать Virtuous Ten Studio, просто открой APK-файл в приложении и распакуй его, для чего создай проект (File -> New project), затем в контекстном меню проекта выбери Import File. Если же твой выбор пал на apktool, то достаточно выполнить одну команду:

После этого в каталоге com.kauf.particle.virtualtorch появится файловое дерево, похожее на описанное в предыдущем разделе, но с дополнительным каталогом smali вместо dex-файлов и файлом apktool.yml. Первый содержит дизассемблированный код исполняемого dex-файла приложения, второй — служебную информацию, необходимую apktool для сборки пакета обратно.

Первое место, куда мы должны заглянуть, — это, конечно же, AndroidManifest.xml. И здесь мы сразу встречаем следующую строку:

Нетрудно догадаться, что она отвечает за предоставление приложению полномочий на использование интернет-соединения. По сути, если мы хотим просто избавиться от рекламы, нам, скорее всего, достаточно будет запретить приложению интернет. Попытаемся это сделать. Удаляем указанную строку и пробуем собрать софтину с помощью apktool:

В каталоге com.kauf.particle.virtualtorch/build/ появится результирующий APK-файл. Однако установить его не получится, так как он не имеет цифровой подписи и контрольных сумм файлов (в нем просто нет каталога META-INF/). Мы должны подписать пакет с помощью утилиты apk-signer. Запустили. Интерфейс состоит из двух вкладок — на первой (Key Generator) создаем ключи, на второй (APK Signer) подписываем. Чтобы создать наш приватный ключ, заполняем следующие поля:

  • Target File — выходной файл хранилища ключей; в нем обычно хранится одна пара ключей;
  • Password и Confirm — пароль для хранилища;
  • Alias — имя ключа в хранилище;
  • Alias password и Confirm — пароль секретного ключа;
  • Validity — срок действия (в годах). Значение по умолчанию оптимально.

Остальные поля, в общем-то, необязательны — но необходимо заполнить хотя бы одно.

Создание ключа в apk-signer

Создание ключа в apk-signer

WARNING

Чтобы подписать приложение с помощью apk-signer, ты должен установить Android SDK и указать полный путь до него в настройках приложения.

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Теперь этим ключом можно подписать APK. На вкладке APK Signer выбираем только что сгенерированный файл, вводим пароль, алиас ключа и пароль к нему, затем находим файл APK и смело жмем кнопку «Sign». Если все пройдет нормально, пакет будет подписан.

Так как мы подписали пакет нашим собственным ключом, он будет конфликтовать с оригинальным приложением, а это значит, что при попытке обновить софтину через маркет мы получим ошибку.

Цифровая подпись необходима только стороннему софту, поэтому если ты занимаешься модификацией системных приложений, которые устанавливаются копированием в каталог /system/app/, то подписывать их не нужно.

Обычно авторы приложений создают специальные классы для вывода рекламы и вызывают методы этих классов во время запуска приложения или одной из его «активностей» (упрощенно говоря, экранов приложения). Попробуем найти эти классы. Идем в каталог smali, далее com (в org лежит только открытая графическая библиотека cocos2d), далее kauf (именно туда, потому что это имя разработчика и там лежит весь его код) — и вот он, каталог marketing. Внутри находим кучу файлов с расширением smali. Это классы, и наиболее примечателен из них класс Ad.smali, по названию которого нетрудно догадаться, что именно он выводит рекламу.

Мы могли бы изменить логику его работы, но гораздо проще будет тупо убрать вызовы любых его методов из самого приложения. Поэтому выходим из каталога marketing и идем в соседний каталог particle, а затем в virtualtorch. Особого внимания здесь заслуживает файл MainActivity.smali. Это стандартный для Android класс, который создается Android SDK и устанавливается в качестве точки входа в приложение (аналог функции main в Си). Открываем файл на редактирование.

Внутри находится код smali (местный ассемблер). Он довольно запутанный и трудный для чтения в силу своей низкоуровневой природы, поэтому мы не будем его изучать, а просто найдем все упоминания класса Ad в коде и закомментируем их. Вбиваем строку «Ad» в поиске и попадаем на строку 25:

Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 433, 435, 466, 468, 738, 740, 800 и 802 обращения к методам класса Ad. Комментируем. Вроде все. Сохраняем. Теперь пакет необходимо собрать обратно и проверить его работоспособность и наличие рекламы. Для чистоты эксперимента возвращаем удаленную из AndroidManifest.xml строку, собираем пакет, подписываем и устанавливаем.

Наш подопытный кролик. Видна реклама Он же, но уже без рекламы

Оп-па! Реклама пропала только во время работы приложения, но осталась в главном меню, которое мы видим, когда запускаем софтину. Так, подождите, но ведь точка входа — это класс MainActivity, а реклама пропала во время работы приложения, но осталась в главном меню, значит, точка входа другая? Чтобы выявить истинную точку входа, вновь открываем файл AndroidManifest.xml. И да, в нем есть следующие строки:

Они говорят нам (и, что важнее, андроиду) о том, что активность с именем Start должна быть запущена в ответ на генерацию интента (события) android.intent.action.MAIN из категории android.intent.category.LAUNCHER. Это событие генерируется при тапе на иконку приложения в ланчере, поэтому оно и определяет точку входа, а именно класс Start. Скорее всего, программист сначала написал приложение без главного меню, точкой входа в которое был стандартный класс MainActivity, а затем добавил новое окно (активность), содержащее меню и описанное в классе Start, и вручную сделал его точкой входа.

Открываем файл Start.smali и вновь ищем строку «Ad», находим в строках 153 и 155 упоминание класса FirstAd. Он тоже есть в исходниках и, судя по названию, как раз и отвечает за показ объявлений на главном экране. Смотрим дальше, идет создание экземпляра класса FirstAd и интента, по контексту имеющего отношение к этому экземпляру, а дальше метка cond_10, условный переход на которую осуществляется аккурат перед созданием экземпляра класса:

Скорее всего, программа каким-то случайном образом вычисляет, нужно ли показывать рекламу на главном экране, и, если нет, перескакивает сразу на cond_10. Ок, упростим ей задачу и заменим условный переход на безусловный:

Больше упоминаний FirstAd в коде нет, поэтому закрываем файл и вновь собираем наш виртуальный факел с помощью apktool. Копируем на смартфон, устанавливаем, запускаем. Вуаля, вся реклама исчезла, с чем нас всех и поздравляем.

  • Перевод приложений Android;
  • пример снятия триала с приложения.

Итоги

Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.

Тут вам покажем несколько способов инструментов, при помощи которых можно подписывать приложения Android перед публикацией их в Google App Play.

Вы можете использовать Android Studio для ручного создания подписанных APK, по одному за раз, или для нескольких вариантов сборки сразу. Вместо того, чтобы вручную подписывать APK, вы также можете настроить свои настройки сборки Gradle для автоматической обработки подписей во время процесса сборки. В этом разделе описывается процесс ручной подписи. Подробнее о подписании приложений как части процесса сборки см. В разделе Настройка процесса сборки для автоматической подписки APK.

Чтобы вручную подписать APK для выпуска в Android Studio, выполните следующие действия:

  1. Жмем Build > Generate Signed APK и откроется окно Generate Signed APK . (Как создать ключи подписи в Android Studio мы писали в прошлой статье)
  2. В окне Generate Signed APK Wizard выберите хранилище ключей, закрытый ключ и введите пароли для обоих. (Если вы только что создали хранилище ключей в предыдущем разделе, эти поля уже будут заполнены) Затем нажмите «Next»
  3. В следующем окне выберите пункт назначения для подписанных APK, выберите тип сборки (если применимо), выберите продукт (ы) и нажмите «Finish»

Когда процесс завершится, вы найдете свой подписанный APK в выбранной вами папке назначения. Теперь вы можете распространять подписанный APK через торговую площадку приложения, например, в Google Play Store, или использовать выбранный вами механизм распространения подписанного приложения конечным пользователям.

Чтобы пользователи могли успешно устанавливать обновления для вашего приложения, вам нужно будет подписать APK с тем же сертификатом на протяжении всего срока действия вашего приложения.

Подробнее об этом и других преимуществах подписания всех ваших приложений с помощью одного и того же ключа, по поводу безопасности и редактирования.

Есть сгенерированные ключи подписи или создаем?

Мы уже разбирали тут, как генерировать хранилище ключей с ключом подписи. Если кратко, то вы можете подписать свое приложение из командной строки с помощью инструмента apksigner или настроить Gradle для его подписки во время сборки. В любом случае вам нужно сначала сгенерировать закрытый ключ с помощью keytool. Например командой

Примечание: keytool находится в каталоге bin/ вашего JDK. Чтобы найти ваш JDK из Android Studio, выберите «File»> «Project Structure», а затем «SDK Location», и вы увидите местоположение JDK

В этом примере команды консоль еще запросит ввести пароли для хранилища ключей и ключа подписи и запросит заполнить поля Distinguished Name для вашего ключа. Затем он генерирует хранилище ключей в виде файла с именем my-release-key.jks, сохраняя его в текущем каталоге (вы можете перемещать его по своему усмотрению). Хранилище ключей содержит один ключ, действительный в течение 10 000 дней.

Теперь вы можете создать unsigned APK, т.е. построить конфигурацию release и подписать его вручную или вместо этого настроить Gradle для автоматического подписания APK.

Инструмент apksigner, доступный в версии 24.0.3 и выше для Android SDK Build Tools, позволяет вам подписывать APK и подтверждать, что подпись APK будет проверена успешно на всех версиях платформы Android, поддерживаемых этими APK. В этом подразделе представлено краткое руководство по использованию инструмента и служит ссылкой для различных параметров командной строки, которые поддерживает инструмент

Примечание 1. если вы подписываете APK с помощью apksigner и вносите дальнейшие изменения в APK, подпись APK становится недействительной. Поэтому перед подписанием APK вы должны использовать такие инструменты, как zipalign.

Примечание 2. Чтобы использовать инструмент apksigner, вы должны иметь версию 24.0.3 или выше установленных инструментов Android SDK Build Tools. Вы можете обновить этот пакет с помощью диспетчера SDK.

1). Открываем командную строку и перемещаемся в корневую директорию —из Android Studio, выбираем View > Tool Windows > Terminal. Затем вызываем команду assembleRelease :

2). Align the unsigned APK using zipalign:

zipalign гарантирует, что все несжатые данные начинаются с конкретного выравнивания байтов относительно начала файла, что может уменьшить объем оперативной памяти, потребляемой приложением.

3). Подписываем APK своим личным ключом с помощью apksigner:

В этом примере выводится подписанный APK на my-app-release.apk после его подписания с закрытым ключом и сертификатом, который хранится в одном файле хранилища ключей: my-release-key.jks.

Инструмент apksigner поддерживает другие параметры подписки, включая подписание файла APK с использованием отдельного закрытого ключа и файлов сертификатов и подписку APK с использованием нескольких подписчиков. Для получения дополнительной информации см. ссылку apksigner.

4). Убеждаемся, что ваш APK подписан:

Пример подписки средствами Android SDK

Если вышеописанное вызывает трудности, то давайте сделаем некоторый простой пример генерации ключа командой keytool, выполнения операции zipalign и подписи командой apksigner.

Сначала строим релиз средствами Cordova и Android SDK

Команда keytool генерации ключа в консоли:

Операция zipalign в консоли:

Обратите внимание, что zipalign мы выполняем по прямому пути версии приложения, которая соответствует версии нашего разрабатываемого приложения.

Операция подписи apksigner:

Обратите внимание, что apksigner мы выполняем по прямому пути версии приложения и указываем путь к сгенерированному ключу, которая соответствует версии нашего разрабатываемого приложения. Далее, после нажатия Enter, консоль запросит поочередно запросить пароль от хранилища ключей и от самого ключа.

Команда подписи с ее параметрами записывается так

Имена параметров нам знакомы по keytool:

  • хранилище (keystore),
  • пароль (storepass) к нему
  • пароль (keypass) к ключу.
  • А последние два параметра – это имя APK-файла, который вы хотите подписать и алиас ключа из указанного хранилища, который вы хотите использовать для подписи.

После данной команды приложение будет подписано и будет готово к установке на устройства или можно распространять через Google App Play.

Я пытаюсь подписать мой файл apk. Я не могу понять, как это сделать. Я не могу найти хорошие углубленные направления. У меня очень мало опыта программирования, поэтому любая помощь будет оценена.

  • откройте свой проект в eclipse
  • нажмите правую кнопку мыши - > инструменты (android tools?)- >экспорт подписанного приложения (АПК?)
  • пройдите через мастера:
  • сделать новый ключ-магазин. запомните этот пароль
  • подпишите свое приложение
  • сохранить и т. д.
  1. выберите проект в Проводнике пакетов и выберите Файл > Экспорт.
  2. откройте папку Android, выберите Экспорт приложения Android и нажмите Следующий.

    теперь запускается мастер экспорта приложений для Android, который будет направлять вас через процесс подписания ваше приложение, включая шаги для выбор закрытого ключа, с помощью которого к подписать .apk (или создание нового хранилище ключей и закрытый ключ).

  3. завершите работу мастера экспорта и ваше приложение будет скомпилировано, подписано, выровнено и готово к работе распределение.

вот руководство о том, как вручную подписать APK. Он включает в себя информацию о новом apk-signer представил в build-tools 24.0.3 (10/2016)

Шаг 1: создание хранилища ключей (только один раз)

вам нужно создать хранилище ключей один раз и использовать его для подписи вашего unsigned apk. Используйте keytool предоставлено JDK нашли в %JAVA_HOME%/bin/

Шаг 2 или 4: Zipalign

zipalign который является инструментом, предоставляемым Android SDK нашли, например, %ANDROID_HOME%/sdk/build-tools/24.0.2/ является обязательным шагом оптимизации, если вы хотите загрузить apk в игру Магазин.

Примечание: при использовании старых jarsigner вам нужно zipalign после подписание. При использовании нового apksigner способ вы делаете это до подпись (запутанная, я знаю). вызов zipalign перед apksigner работает нормально потому что apksigner сохраняет выравнивание APK и сжатие (в отличие от jarsigner).

вы можете проверка выравнивание с

Шаг 3: Знак & Проверить

использование build-tools 24.0.2 и старше

использовать jarsigner который, как и keytool,поставляется с дистрибутивом JDK нашли в %JAVA_HOME%/bin/ и использовать его вот так:

и может быть проверена с

использование build-tools 24.0.3 и новее

Android 7.0 представляет APK Signature Scheme v2, новую схему подписи приложений, которая обеспечивает более быстрое время установки приложений и большую защиту против несанкционированного изменения файлов APK (см. здесь и здесь для более подробной информации). Threfore Google реализовал их собственный apk signer называется apksigner (хм!) Файл скрипта можно найти в %ANDROID_HOME%/sdk/build-tools/24.0.3/ (the .jar находится в /lib папку). Используйте его вот так

и может быть проверена с

официальная документация находится здесь.

Он будет просить вас, чтобы обеспечить вашу пароль:: Введите пароль для хранилища ключей: Это будет знак вашей АПК.чтобы убедиться, что подписание прошло успешно, вы можете запустить:

утилита jarsigner -verify для c:\users\pir Фахим\рабочие столы\GoogleDriveApp.apk

Он должен вернуться с: баночка проверена.

Способ 2

Если вы используете eclipse с ADT, то просто скомпилировать, подписать, выровнять и подготовить файл для распространения.что вы должны сделать просто выполните следующие действия.

  • Файл > Экспорт.
  • экспорт приложения для android
  • обзор-->выбираем свой проект
  • Далее-->Далее

эти шаги будут скомпилированы, подписаны и zip выровнены ваш проект, и теперь вы готовы распространять свой проект или загружать в Google Play store.

Я столкнулся с этой проблемой и был решен путем проверки версии min sdk в манифесте. Он был установлен на 15 (ICS), но мой телефон работал 10(Gingerbread)

APK Signing Process

чтобы вручную подписать файл Android APK нам нужно ниже трех команд

1 создать файл хранилища ключей

2 подпишите файл APK с помощью Jarsigner

3 выровнять подписанный APK с помощью инструмента zipalign

Generate Keystore file

Example_

keystore пароль:yourApp@123 ключевой пароль:yourApp@123

CMD O / P-

Sign your app with your private keystore using jarsigner

jarsigner-verbose-sigalg SHA1withRSA -digestalg SHA1-keystore

Читайте также: