Release-android-debuggable.md

Мы уже неоднократно рассказывали о взломе приложений для Android. Несколько раз мы вскрывали приложения практически голыми руками, имея только декомпилятор и дизассемблер, один раз прибегли к помощи фреймворка Frida, но есть и еще один, одновременно очевидный и неочевидный способ взлома — использовать отладчик.

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

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

Так что в целом алгоритм твоих действий будет выглядеть так:

1. Достаем подопытное приложение из устройства.
2. Дизассемблируем его, выставляем флаг отладки.
3. Собираем обратно и устанавливаем на устройство.
4. Импортируем декомпилированный или дизассемблированный код в Android Studio.
5. Запускаем отладку, будто это наше приложение.

WARNING

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

Флаг отладки

Android устроен таким образом, что не позволит подключиться с помощью отладчика к приложению, которое этого не хочет. А факт «хотения» определяется флагом отладки, который представляет собой простую строку в файле AndroidManifest.xml приложения.

Поэтому первое, что мы должны сделать, — это разобрать приложение, выставить флаг отладки в значение true и собрать обратно. Проще всего это сделать с помощью утилиты apktool. Просто натравливаем ее на подопытное приложение, и готово:

$ java -jar apktool.jar d app.apk

В текущем каталоге появится подкаталог app (ну или как назывался пакет с приложением).

Далее переходим в него и видим несколько файлов и каталогов. Нам они еще пригодятся, а пока открываем файл AndroidManifest.xml в текстовом редакторе и находим строку, начинающуюся с <application. Это тег application, который описывает приложение в целом. Именно к нему мы должны добавить атрибут android:debuggable="true". Просто вставь его сразу после application:

<application android:debuggable="true" ...

Теперь приложение необходимо запаковать и подписать:

$ java -jar apktool.jar b app
$ java -jar sign.jar app.apk

Утилиту sign можно найти на GitHub.

После этого приложение можно установить на устройство.

Декомпиляция и дизассемблирование

Дизассемблерный листинг приложения у нас уже есть, мы получили его, разобрав приложение с помощью apktool. Мы можем импортировать его в Android Studio и начать отладку. Но лучше все-таки попытаться получить исходники Java, гораздо более легкие в чтении.

Для этого приложение необходимо декомпилировать. Сделать это можно с помощью нескольких различных инструментов, но я предпочитаю использовать декомпилятор Jadx. Он хорошо переваривает код, имеет средства деобфускации и активно развивается.

Присоединяйся к сообществу «Xakep. ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку!
Подробнее

Содержание статьи

Существует множество инструментов для работы с подключенным с помощью USB-кабеля или Wi-Fi смартфоном. Особо развитые инструменты позволяют перемещать файлы, устанавливать и удалять софт, просматривать контакты, делать скриншоты экрана и даже отправлять СМС, однако ни один графический инструмент не сравнится с мощью, которую может дать консоль Android. В этой статье мы поговорим об ADB (Android Debug Bridge) — стандартном инструменте для отладки и работы с консолью Android с компа.

Описанные в статье команды можно выполнять непосредственно на устройстве, скачав из маркета эмулятор терминала, но удобнее это делать, конечно же, с компа через adb.

Основы работы с ADB

Для начала работы с ADB его следует активировать на устройстве и установить утилиту adb и драйверы на комп. Первая задача выполняется с помощью включения «Отладки по USB» в пункте настроек «Для разработчиков» (если этот пункт скрыт, нажми семь раз на номер сборки в меню «О телефоне»).

Для установки ADB на комп качаем Adb Kit и распаковываем в любую папку (рекомендую использовать названия папок без русских символов). Также скачиваем и устанавливаем драйверы ADB.

Работать с adb нужно из командной строки. Нажимаем Win + R и вводим cmd, далее переходим в папку, в которой лежит adb. Для моей папки команда будет следующей:

cd \android

Чтобы не проделывать все эти манипуляции каждый раз, можно добавить нужную папку в переменную Path. Для этого необходимо зайти в «Панель управления -> Система -> Дополнительные параметры системы -> Переменные среды», найти переменную Path и добавить в конец строки, через точку с запятой, путь до папки с adb. Теперь после запуска консоли можно сразу вводить необходимые команды.

Проверим наше подключение к телефону с помощью следующей команды (она должна вывести список подключенных устройств):

adb devices

adb connect IP-адрес

Далее работа с ADB ничем не отличается.

INFO

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

Установка программ

ADB можно использовать для установки приложений без необходимости копировать их на смартфон. Достаточно выполнить такую команду:

adb install d:/downloads/имя_файла.apk

В команду также можно добавить дополнительные ключи. Полезными будут -е — переустановить приложение с сохранением данных и -d — установить версию меньше текущей.

Программы можно и удалять, но для этого нужно знать название пакета (как узнать, расскажу чуть позже). На примере игры Angry Birds Seasons команда будет выглядеть так:

adb uninstall com.rovio.angrybirdsseasons

Бэкап приложений

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

adb backup [опции] <приложения>

• -f указывает имя создаваемого файла и его расположение на компе. При отсутствии ключа будет создан файл backup.ab в текущем каталоге;
• -apk|-noapk указывает, включать ли в бэкап только данные приложения или сам .apk тоже (по умолчанию не включает);
• -obb|-noobb указывает, включать ли в бэкап расширения .obb для приложений (по умолчанию не включает);
• -shared|-noshared указывает, включать ли в бэкап содержимое приложения на SD-карте (по умолчанию не включает);
• -all указывает на необходимость бэкапа всех установленных приложений;
• -system|-nosystem указывает, включать ли в бэкап системные приложения (по умолчанию включает);
• — перечень пакетов для бэкапа.

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

adb backup -f c:\android\backup.ab -apk -all -nosystem

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

adb restore c:\android\backup.ab

Консоль в консоли

Наряду с упомянутой консолью, которая является DOS-консолью под Windows, в Android существует и своя. Она вызывается через adb shell и представляет собой по сути стандартную Linux-консоль, но с неполным набором команд, расширить который можно, установив из маркета BusyBox. Использовать эту консоль можно двумя способами. В интерактивном режиме она запускается командой

adb shell

В консоли появляется знак $ (далее по тексту этот знак будет означать необходимость ввода предварительной команды adb shell), и после этого можно вводить серию команд, получая после каждой отклик. Второй способ — если необходимо ввести только одну команду, можно писать ее подряд за adb shell.

В шелле работают стандартные команды для копирования, перемещения и удаления файлов: cp, mv и rm. Можно менять каталоги (cd) и смотреть их содержимое (ls). Кроме стандартных Linux-команд, о которых можно узнать из любого справочника, в Android есть несколько своих специализированных инструментов, но, чтобы использовать некоторые из них, придется получить на смартфоне права root, а после запуска консоли выполнять команду su:

adb shell
su

Это нужно делать, если в ответ на какую-либо команду ты видишь строку, похожую на «access denied» или «are you root?». В случае успеха знак $ сменится на #.

Создание скриншота

Выполняется одной строчкой:

adb shell screencap /sdcard/screen.png

После этого картинку нужно выдернуть из устройства командой adb pull:

adb pull /sdcard/screen.png

В recovery скриншот можно сделать следующей командой:

adb pull /dev/graphics/fb0

ffmpeg -f rawvideo -pix_fmt rgb32 -s 1080x1920 -i fb0 fb0.png

Запись видео, происходящего на экране устройства

adb shell screenrecord --size 1280x720 --bit-rate 6000000 --time-limit 20 --verbose /sdcard/video.mp4

Данная команда начнет записывать видео с разрешением 1280 x 720 (если не указать, то будет использовано нативное разрешение экрана устройства), с битрейтом 6 Мбит/с, длиной 20 с (если не указать, то будет выставлено максимальное значение 180 с), с показом логов в консоли. Записанное видео будет находиться в /sdcard (файл video.mp4).

INFO

Все запущенные из консоли и в adb shell процессы, занимающие некоторое время для выполнения, можно прервать с помощью комбинации Ctrl + C. Выйти из шелла и вернуться к выполнению обычных команд adb — Ctrl + D.

Управление приложениями

Для управления приложениями используются две команды: pm (package manager) — менеджер пакетов и am (activity manager) — менеджер активностей. У данных команд есть немало ключей, которые можно посмотреть на портале разработчиков. Остановимся на некоторых.

Для начала получим список установленных на устройстве приложений в виде названий пакетов, которые пригодятся позже:

$ pm list packages

Добавив в конец -s, ты увидишь только системные приложения, -3 — только сторонние, -f покажет пути установки пакетов, а -d — отключенные приложения. Далее, зная названия пакетов, можно совершать над ними различные насильственные действия :). Например, отключить ненужный календарь:

$ pm disable com.google.android.calendar

$ pm clear com.dropbox.android

Ну а совсем удалить можно так:

$ pm uninstall com.dropbox.android

Для использования activity manager понадобятся более глубокие знания структуры Android и понимание того, что такое Avtivity и Intent. Это позволит тебе запускать различные приложения, например браузер или настройки:

$ am start -n com.android.browser/.BrowserActivity
$ am start -n com.android.settings/.Settings

Завершить работу приложения можно противоположной командой:

$ am kill com.android.browser

Ну а убить все запущенные приложения — такой командой:

$ am kill-all

Тот же activity manager поможет сделать звонок на нужный номер телефона:

$ am start -a android.intent.action.CALL tel:123

А так можно открыть страницу в браузере:

$ am start -a android.intent.action.VIEW 'http:/xakep.ru'

А с помощью вариации предыдущей команды можно отправить СМС:

$ am start -a android.intent.action.SENDTO -d sms:НОМЕР_ТЕЛЕФОНА --es sms_body "ТЕКСТ_СМС" --ez exit_on_sent true
$ input keyevent 22
$ input keyevent 66

В данной команде input keyevent эмулирует нажатие кнопок и может использоваться как для хардварных, так и для кнопок внутри приложения. В нашем примере 22 соответствует перевод фокуса вправо (джойстик вправо — dpad right), а 66 — Enter.

С помощью команды input можно, например, разблокировать телефон. Для этого необходимо ввести:

$ input keyevent 82

Погасит экран keyevent 26, что соответствует нажатию кнопки Power. Можно также поэкспериментировать с цифрами 3 — Home, 4 — Back, 24 — Volume Up, 25 — Volume Down, 27 — физическая кнопка Camera. Последнюю кнопку можно передать и через широковещательные сообщения (полный список широковещательных сообщений ты найдешь тут):

$ am broadcast -a android.intent.action.CAMERA_BUTTON

Другое широковещательное сообщение переведет телефон в режим самолета:

$ am broadcast -a android.intent.action.AIRPLANE_MODE --ez state true

Но данная команда не сработает на последних версиях Android. Для управления питанием и беспроводными коммуникациями там используется утилита svc. Например, включить передачу данных через мобильную сеть или управлять Wi-Fi можно через команды

$ svc data enable
$ svc wifi disable

Также можно заставить смартфон оставаться включенным при подключении к USB-порту/зарядке/Wi-Fi-сети или всегда:

$ svc power stayon usb
$ svc power stayon ac
$ svc power stayon wireless
$ svc power stayon true

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

$ input text "Текст для вставки"

Кроме опции text, у команды input есть и другие. Полная форма команды такова:

$ input [<source>] <command> [<arg>…]

В качестве источника можно указывать trackball, joystick, touchnavigation, mouse, keyboard, gamepad, touchpad, dpad, stylus, touchscreen. В качестве команд будут:

• text (Default: touchscreen) [delay]
• keyevent [–longpress] … (Default: keyboard)
• tap (Default: touchscreen)
• swipe [duration(ms)] (Default: touchscreen)
• press (Default: trackball)
• roll (Default: trackball)

Как видно из команд, можно, хотя и с трудом, управлять устройством через команды input touch и input swipe при разбитом экране, если не поддерживается работа мышки через USB-OTG. Например, вытянуть шторку с уведомлениями получится так (отсчет координат идет от левого верхнего угла):

$ input swipe 10 10 10 1000

А так можно узнать разрешение экрана:

$ dumpsys window | \sed -n '/mUnrestrictedScreen/ s/^.*) \([0-9][0-9]*\)x\([0-9][0-9]*\)/\1 \2/p'

Для Nexus 5 разрешение выдаст 1080 х 1920. Тогда нажать на кнопку «Меню приложений» стандартного лаунчера от Google, которая находится над кнопкой «Домой», можно так:

$ input touchscreen tap 500 1775

Скрипты

Выполнение всех описываемых в статье серий команд можно автоматизировать. Для этого вставляем их в текстовый файл (строки, следующие за adb shell), который имеет в начале строку #!/system/bin/sh, сохраняем с расширением sh и закидываем на устройство. После этого можно запускать скрипт через тот же adb:

adb shell sh /sdcard/имя_файла.sh

Системные утилиты

Кратко остановлюсь на нескольких полезных командах (работоспособность некоторых, однако, может зависеть от версии прошивки и модели телефона).

Изменение DPI. Не требует root и работает на Android 5.0+. Стандартное значение для Nexus 5 — 480. При значении 420 на рабочем столе стокового лаунчера помещается пять иконок в ряд вместо четырех:

$ wm density 420 && adb reboot

Подключение /system в режиме записи. Для части команд, которые меняют системные файлы, необходимо сначала перемонтировать раздел /system на запись. Это необходимо в том числе при удалении системных приложений. Перемонтирование выполняется следующей командой:

$ su
# mount -o rw,remount /system

$ setprop ctl.restart zygote

Перевод смартфона в режим энергосбережения Doze (Android M+):

$ dumpsys battery unplug
$ dumpsys deviceidle step

Батарейка в процентах (Android 4.4+):

$ content insert --uri content://settings/system --bind name:s:status_bar_show_battery_percent --bind value:i:1

Снятие логов

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

adb logcat > logcat.txt

Все события будут записываться непрерывно по мере работы устройства. Остановить запись можно стандартной комбинацией Ctrl + C. Однако в лог попадает вся информация, что сильно затрудняет поиск нужной. Поэтому для работы обычно используют набор ключей и фильтров, подходящих к конкретной ситуации. Существует семь приоритетов сообщений по мере возрастания: V — Verbose, D — Debug, I — Info, W — Warning, E — Error, F — Fatal, S — Silent. Например, для вывода всех сообщений с приоритетом Е и выше следует ввести:

adb logcat *:E

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

adb logcat -b events

Продвинутый уровень

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

$ cd /data/data/com.android.chrome
$ su
# sqlite3 app_chrome/Default/History
> .schema urls
> select * from urls where url like "%android%";

Также с помощью sqlite3 можно выдернуть все контакты с телефона. Для этого в консоли на компе должен использоваться шрифт Lucida Console и перед началом выполнения команд необходимо перевести кодировку на UTF-8. Иначе вместо русских букв будут отображаться непонятные символы. Сами команды выглядят так:

chcp 65001
adb shell
$ su
# cd /data/data/com.android.providers.contacts/databases
# sqlite3 contacts2.db
> select t1.raw_contact_id,t1.normalized_number,t2.display_name from phone_lookup as t1, raw_contacts as t2 where t1.raw_contact_id=t2._id Order by display_name;

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

Можно вывести данные не на экран, а сразу в текстовый файл. Для этого команды нужно изменить:

adb shell
$ su
# cd /data/data/com.android.providers.contacts/databases
# sqlite3 contacts2.db "select t1.raw_contact_id,t1.normalized_number,t2.display_name from phone_lookup as t1, raw_contacts as t2 where t1.raw_contact_id=t2._id;" > /sdcard/contacts.txt

Альтернативный способ вывода контактов в файл — команда, требующая установленного BusyBox:

content query --uri content://contacts/phones --projection number:name --sort "name ASC"| awk -F= '{gsub(/[-() name]/,"",$2);print $2" "$3}'| sed 's/,//g' >/sdcard/contacts.txt

Снятие графического ключа, PIN, facelock

adb shell
$ su
# cd /data/system
# rm *.key

Команда удалит все пароли и графические ключи. Сами файлы в зависимости от прошивки и модели устройства могут быть: gesture.key, password.key, cm_gesture.key, personalpattern.key, personalbackuppin.key. Также за блокировку отвечают файлы locksettings.db, locksettings.db-shm, locksettings.db-wal.

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

adb shell
$ cd /data/data/com.android.providers.settings/databases
$ sqlite3 settings.db
> update system set value=0 where name='lock_pattern_autolock';
> update system set value=0 where name='lockscreen.lockedoutpermanently';

Выводы

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

You can execute all the build tasks available to your Android project using
the Gradle wrapper command line tool. It’s
available as a batch file for Windows (gradlew.bat) and a shell
script for Linux and Mac (gradlew.sh), and it’s
accessible from the root of each project you create with Android Studio.

• On Windows:

  gradlew task-name

• On Mac or Linux:

  ./gradlew task-name

To see a list of all available build tasks for
your project, execute tasks:

gradlew tasks

If you’d prefer to use the Android Studio tools instead of the command line
tools, see Build and run your app.

About build types

If you want to build your app for release, it’s important that you also
sign your app with the appropriate signing key.
If you’re just getting started, however, you can quickly run your apps on an
emulator or a connected device by
building a debug APK.

Build and deploy an APK

Build a debug APK

For immediate app testing and debugging, you can build a debug APK.
The debug APK is signed with a debug key provided by the SDK tools and
allows debugging through adb.

To build a debug APK, open a command line and navigate to the root of your
project directory. To initiate a debug build, invoke the
assembleDebug task:

gradlew assembleDebug

This creates an APK named module_name-debug.apk in
project_name/module_name/build/outputs/apk/.
The file is already signed with the debug key and aligned with
zipalign, so you can
immediately install it on a device.

Or to build the APK and immediately install it on a running emulator or
connected device, instead invoke installDebug:

gradlew installDebug

The “Debug” part in the above task names is just a
camel-case version of the build variant name, so it can be replaced with whichever build type or
variant you want to assemble or install. For example, if you have a “demo”
product flavor, then you can build the debug version with the
assembleDemoDebug task.

To see all the build and install tasks available for each variant (including
uninstall tasks), run the tasks task.

Also see the section about how to run your app on the emulator and run your app on a device.

Build a release bundle or APK

Deploy your app to the emulator

To use the Android Emulator, you must create an Android Virtual
Device (AVD) using Android Studio.

1. In a command line, navigate to
   android_sdk/tools/ and start the emulator by
   specifying your AVD:

   emulator -avd avd_name

   If you’re unsure of the AVD name, execute
   emulator -list-avds.

2. Now you can install your app using either one of the Gradle install tasks
   mentioned in the section about how to build a debug APK
   or the
   adb tool.

   If the APK is built using a developer preview SDK (if the targetSdkVersion is
   a letter instead of a number), you must include the
   -t option
   with the install command to install a test APK.

   adb install path/to/your_app.apk
   

   All APKs you build are saved in
   project_name/module_name/build/outputs/apk/.

Deploy your app to a physical device

Before you can run your app on a device, you must enable USB
debugging on your device. You can find the option under
Settings > Developer options.

Note: On Android 4.2 and newer,
Developer options is hidden by default. To make it available,
go to Settings > About phone and tap Build
number seven times. Return to the previous screen to find
Developer options.

Once your device is set up and connected via USB, you can install your app
using either the Gradle install tasks mentioned
in the section about how to build a debug APK or the
adb tool:

adb -d install path/to/your_app.apk

All APKs you build are saved in
project_name/module_name/build/outputs/apk/.

Build an app bundle

The easiest way to build an app bundle is by
using Android Studio. However, if you need to build an
app bundle from the command line, you can do so by using either Gradle or
bundletool, as described in the sections below.

Build an app bundle with Gradle

./gradlew :base:bundleDebug

If you instead want to sign an app bundle as a separate step, you can use
jarsigner
to sign your app bundle from the command line.

Build an app bundle using bundletool

bundletool is a command line tool that Android Studio, the Android Gradle
plugin, and Google Play use to convert your app’s compiled code and
resources into app bundles, and generate deployable APKs from those bundles.

So, while it’s useful to
test app bundles with bundletool and locally recreate
how Google Play generates APKs, you typically won’t need to
invoke bundletool to build the app bundle itself—you should instead
use Android Studio or Gradle tasks, as described in previous sections.

However, if you don’t want to use Android Studio or Gradle tasks to build
bundles—for example, if you use a custom build toolchain—you can use bundletool
from the command line to build an app bundle from pre-compiled code and
resources. If you haven’t already done so,

download bundletool from the GitHub repository.

This section describes how to package your app’s compiled code and resources,
and how to use bundletool from the command line to convert them into an
Android App Bundle.

Generate the manifest and resources in proto format

bundletool requires certain information about your app project, such as the
app’s manifest and resources, to be in
Google’s Protocol Buffer format—which
is also known as “protobuf” and uses the *.pb file extension. Protobufs
provide a language-neutral, platform-neutral, and extensible mechanism
for serializing structured data—it’s similar to XML, but smaller, faster, and
simpler.

Download AAPT2

You can generate your app’s manifest file and resource table in
protobuf format using the latest version of AAPT2 from the
Google Maven repository.

1. Navigate to com.android.tools.build > aapt2 in the
   repository index.
2. Copy the name of the latest version of AAPT2.

3. For example, to download version 3.2.0-alpha18-4804415 for Windows, you
   would use:
   https://dl.google.com/dl/android/maven2/com/android/tools/build/aapt2/3.2.0-alpha18-4804415/aapt2-3.2.0-alpha18-4804415–windows.jar

4. Navigate to the URL in a browser—AAPT2 should begin downloading shortly.

5. Unpackage the JAR file you just downloaded.

Compile and link your app’s resources

aapt2 compile \
project_root/module_root/src/main/res/drawable/Image1.png \
project_root/module_root/src/main/res/drawable/Image2.png \
-o compiled_resources/

During the link phase, where AAPT2 links your various compiled resources into a
single APK, instruct AAPT2 to convert your app’s manifest and compiled resources
into the protobuf format by including the --proto-format flag, as shown below:

aapt2 link --proto-format -o output.apk \
-I android_sdk/platforms/android_version/android.jar \
--manifest project_root/module_root/src/main/AndroidManifest.xml \
-R compiled_resources/*.flat \
--auto-add-overlay

Package pre-compiled code and resources

Build your app bundle using bundletool

To build your app bundle, you use the bundletool build-bundle command, as
shown below:

bundletool build-bundle --modules=base.zip --output=mybundle.aab

Customize downstream APK generation

App bundles include a BundleConfig.pb file that provides metadata that app
stores, such as Google Play, require when generating APKs from the bundle.
Although bundletool creates this file for you, you can configure some aspects
of the metadata in a BundleConfig.json file and pass it to the
bundletool build-bundle command—bundletool later converts and merges this
file with the protobuf version included in each app bundle.

{
  "optimizations": {
    "splitsConfig": {
      "splitDimension": [{
        "value": "LANGUAGE",
        "negate": true
      }]
    }
  }
}

{
  "compression": {
    "uncompressedGlob": ["res/raw/**", "assets/**.uncompressed"]
  }
}

Keep in mind, by default, bundletool does not compress your app’s native
libraries (on Android 6.0 or higher) and resource
table (resources.arsc). For a full description of what you can configure in
your BundleConfig.json, inspect the bundletool config.proto
file,
which is written using Proto3
syntax.

Deploy your app from an app bundle

If you’ve built and signed an app bundle,
use bundletool to generate APKs and deploy them to
a device.

Sign your app from command line

You do not need Android Studio to sign your app. You can sign your app from
the command line, using apksigner for APKs or jarsigner for app bundles,
or configure Gradle to sign it for you during the build. Either way, you need to
first generate a private key using
keytool,
as shown below:

keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-alias

The example above prompts you for passwords for the keystore and key, and for
the “Distinguished Name” fields for your key. It then generates the
keystore as a file called my-release-key.jks, saving it in the
current directory (you can move it wherever you’d like). The keystore
contains a single key that is valid for 10,000 days.

Now you can sign you APK or app bundle manually, or configure Gradle to sign
your app during the build process, as described in the sections below.

Sign your app manually from the command line

If you want to sign an app bundle from the command line, you can use
jarsigner.
If instead you want to sign an APK, you need to use zipalign and apksigner
as described below.

1. Open a command line—from Android Studio, select View > Tool Windows
   > Terminal—and navigate to the directory where your unsigned APK is
   located.

2. Align the unsigned APK using zipalign:

   zipalign -v -p 4 my-app-unsigned.apk my-app-unsigned-aligned.apk
   

   zipalign ensures that all uncompressed data starts with a
   particular byte alignment relative to the start of the file, which may
   reduce the amount of RAM consumed by an app.

3. Sign your APK with your private key using apksigner:

   apksigner sign --ks my-release-key.jks --out my-app-release.apk my-app-unsigned-aligned.apk
   

   This example outputs the signed APK at my-app-release.apk
   after signing it with a private key and certificate that are stored in a
   single KeyStore file: my-release-key.jks.

   Note: To use the apksigner tool, you must
   have revision 24.0.3 or higher of the Android SDK Build Tools installed.
   You can update this package using the SDK Manager.

4. Verify that your APK is signed:

   apksigner verify my-app-release.apk
   

Configure Gradle to sign your app

android {
    ...
    defaultConfig { ... }
    signingConfigs {
        release {
            // You need to specify either an absolute path or include the
            // keystore file in the same directory as the build.gradle file.
            storeFile file("my-release-key.jks")
            storePassword "password"
            keyAlias "my-alias"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
            ...
        }
    }
}

android {
    ...
    defaultConfig { ... }
    signingConfigs {
        create("release") {
            // You need to specify either an absolute path or include the
            // keystore file in the same directory as the build.gradle file.
            storeFile = file("my-release-key.jks")
            storePassword = "password"
            keyAlias = "my-alias"
            keyPassword = "password"
        }
    }
    buildTypes {
        getByName("release") {
            signingConfig = signingConfigs.getByName("release")
            ...
        }
    }
}

Now, when you build your app by
invoking a Gradle task, Gradle signs your app (and runs zipalign) for you.

Additionally, because you’ve configured the release build with your signing key,
the “install” task is available for that build type. So you can build, align,
sign, and install the release APK on an emulator or device all with the
installRelease task.

To prepare your app for release, you need to configure, build, and test a release
version of your app. The configuration tasks involve basic code
cleanup and code modification tasks that help optimize your app. The build process is
similar to the debug build process and can be done using JDK and Android SDK tools.

Testing
tasks serve as a final check, helping ensure that your app performs as expected under real-world
conditions. Firebase offers a large set of both physical and virtual test devices
through Firebase Test Lab that you can
use to improve your app quality.

Note: As a best practice, make sure your app meets all of your
release criteria for functionality, performance, and stability before you perform the tasks outlined
on this page.

Figure 1. Preparing for release is a required development
task and is the first step in the publishing process.

Tasks to prepare for release

Figure 2. There are five main tasks to prepare your app for
release.

To prepare your app for release, you typically perform five main tasks, as shown in figure 2.
Each main task may include one or more smaller tasks, depending on how you are releasing your
app. For example, if you are releasing your app through Google Play, you may want
to add special filtering rules to your manifest while you are configuring your app for
release. Similarly, to meet Google Play publishing guidelines you may have to prepare screenshots
and create promotional text while you are gathering materials for release.

Gather materials and resources

Cryptographic keys

Android requires that all APKs are digitally signed with a certificate before they are installed
on a device or updated. For Google Play Store, all apps
created after August 2021 are required to use
Play App Signing. But uploading
your AAB to Play Console still requires you to sign it with your developer certificate. Older
apps can still self-sign, but whether you’re using Play App Signing or you’re
self-signing, you must sign your app before you can upload it.

To learn about certificate requirements, see Sign
your app.

Important: Your app must be signed with a cryptographic
key that has a validity period ending after October 22, 2033.

You might also have to obtain other release keys if your app accesses a service or uses a
third-party library that requires you to use a key that is based on your private key.

App icon

End-user license agreement

Miscellaneous materials

Configure your app for release

After you gather all of your supporting materials, you can start configuring your app
for release. This section provides a summary of the configuration changes we recommend that you make
to your source code, resource files, and app manifest prior to releasing your app.

Although most of the configuration changes listed in this section are optional, they are
considered good coding practices and we encourage you to implement them. In some cases,
you might already have made these configuration changes as part of your development process.

Choose a suitable application ID

Turn off debugging

To configure whether the APK is debuggable, use the debuggable flag for Groovy or
the isDebuggable flag for Kotlin script:

  android {
    ...
    buildTypes {
      release {
        isDebuggable = false
        ...
      }
      debug {
        isDebuggable = true
        ...
      }
    }
    ...
  }
  

  android {
    ...
    buildTypes {
      release {
        debuggable false
        ...
      }
      debug {
        debuggable true
        ...
      }
    }
    ...
  }

Enable and configure app shrinking

Turn off logging

Deactivate logging before you build your app for release. You can deactivate logging by removing
calls to Log methods in your source
files. Also, remove any log files or static test files that were created in your project.

Also, remove all Debug
tracing calls that you added to your code, such as startMethodTracing() and
stopMethodTracing()
method calls.

Clean up your project directories

• Review the contents of your cpp/, lib/, and src/
  directories. The cpp/ directory should contain only source files associated with the
  Android NDK, such as C or C++ source files, header files,
  or makefiles. The lib/ directory should contain only third-party library files or
  private library files, including prebuilt shared and static libraries. The src/
  directory should contain only the source files for your app (Java, Kotlin, and AIDL
  files). The src/ directory should not contain any JAR files.
• Check your project for private or proprietary data files that your app doesn’t use
  and remove them. For example, look in your project’s res/ directory for old
  drawable files, layout files, and values files that you are no longer using and delete them.
• Check your lib/ directory for test libraries and remove them if they are no
  longer being used by your app.
• Review the contents of your assets/ directory and your res/raw/
  directory for raw asset files and static files that you need to update or remove prior to
  release.

Review and update your manifest and Gradle build settings

• 
<uses-permission> element

  Specify only those permissions that are relevant and required for your
  app.

• android:icon and android:label attributes

  You must specify values for these attributes, which are located in the
  <application>
  element.

• versionCode and versionName properties

Address compatibility issues

Add support for multiple screen configurations.

Make sure you meet the best practices for

supporting multiple screens. By supporting multiple screen configurations,
you can create an app that functions properly and looks good on any of the screen sizes
supported by Android.

Optimize your app for larger displays.

You can optimize your app to work well on devices with large displays such as tablets and
foldables. For example,
list-detail
layouts can improve usability on larger screens.

Consider using Jetpack libraries.

Jetpack is a suite of libraries to help developers follow best practices, reduce boilerplate
code, and write code that works consistently across Android versions and devices.

Update URLs for servers and services

If your app accesses remote servers or services, make sure you are using the production
URL or path for the server or service and not a test URL or path.

Implement licensing for Google Play

Build your app for release

If you are using a continuous integration
system, you can configure a task to automate your release process. This is not limited to
building your release APK or AAB. You can also configure it to automatically upload the build
artifact(s) to Play Console.

Build with Android Studio

You can use the Gradle build system, integrated with Android Studio, to build a release-ready
APK file that is signed with your private key and optimized. To learn how to set up and
run builds from Android Studio, see
Build and run your app.

Prepare external servers and resources

If your app relies on a remote server, make sure the server is secure and that it is
configured for production use. This is particularly important if you are implementing in-app billing in your app and you are
performing the signature verification step on a remote server.

Also, if your app fetches content from a remote server or a real-time service (such as a
content feed), be sure the content you are providing is up to date and production ready.

The Android build system compiles app resources and source code and packages
them into APKs or Android App Bundles that you can test, deploy, sign, and
distribute.

Android Studio uses Gradle, an advanced build toolkit, to automate
and manage the build process while letting you define flexible, custom
build configurations. Each build configuration can define its own set of code
and resources while reusing the parts common to all versions of your app.
The Android Gradle plugin works with the build toolkit to provide
processes and configurable settings that are specific to building and testing
Android apps.

Gradle and the Android Gradle plugin run independent of Android Studio. This
means that you can build your Android apps from within Android Studio, the
command line on your machine, or on machines where Android Studio is not
installed, such as continuous integration servers.

If you aren’t using
Android Studio, you can learn how to build and run your app from
the command line. The output of the build is the same whether you are
building a project from the command line, on a remote machine, or using
Android Studio.

Note: Because Gradle and the Android Gradle plugin run
independently from Android Studio, you need to update the build tools
separately. Read the release notes to learn how to update Gradle
and the Android Gradle plugin.

The build process

The build process involves many tools and processes that convert your project
into an Android Application Package (APK) or Android App Bundle (AAB).

The Android Gradle plugin does much of the build process for you, but it can be
useful to understand certain aspects of the build process so you can adjust the
build to meet your requirements.

This page focuses on app development,
but many of the build steps and concepts are common to most build types.