APK — это формат, в котором распространяются и устанавливаются Android приложения. Задумывались что у них внутри? Почему мы уже давно в Google Play загружаем AAB файлы, а не APK? Эта статья является расшифровкой видео, в котором я рассказал что находится внутри APK, что такое App Bundle и зачем поменяли формат распространения приложений в Google Play.

Если вам интересно следить за самыми последними новостями Android разработки и получать подборку интересных статей по этой тематике, тогда вам стоит подписаться на Телеграм-канал Android Broadcast и мой YouTube канал "Android Broadcast"

Структура APK

APK файл — это обычный ZIP архив и любой инструмент, который умеет работать с этим форматом, сможет распаковать содержимое APK. Лучше всего его смотреть через Android Studio. Для этого там есть инструмент, который покажет, что находится внутри, а также размер каждого файла.

Первое что вы заметите внутри APK — это множество файлов classes.dex с номерам. dex файлы — это скомпилированный Java код, который позже трансформируется в специальный Android формат байт кода. Весь Java код из проекта и подключенных библиотек попадает сюда.

Файл AndroidManifest.xml — вся информация о вашем приложении: компоненты, разрешения, требования к устройству и другая информация для системы. Хоть библиотеки и модули в проекте могут содержать свои файлы манифеста, но в итоге он один и объединяется с помощью утилиты Manifest Merger. На канале есть отдельное видео про неё.

Android ресурсы представлены в нескольких местах: папка res, куда попадают файлы: картинки, ресурсы шрифтов, layout‑ы, сырые ресурсы (да‑да, в Android ресурсы можно положить любой файл), а также файл resources.arsc, который содержит ссылки на ресурсы, value ресурсы (строки, размеры и пр.)

Содержимое APK при открытии его в Android Studio

В папке libs кладут скомпилированные нативные библиотеки под различные архитектуры процессоров, обычно это ARM V7 и V8, а также x86 и x86–64. Этой папки может не быть, если вы сами или какая‑то из библиотек не содержит нативных библиотек т. е. попросту класть нечего

Папка assets — еще одно место, куда можно положить любые файлы, которые просто будут добавлены в финальное APK. Например, до появления ресурсов шрифтов разработчики складывали их именно туда! Зачем несколько мест? assets позволяют организовать любую структуру папок внутри директории, не накладывает никаких ограничений на имена файлов, а также позволяет работать внутри как с деревом файлов. В свою очередь raw ресурсы подчиняются всем ограничениям ресурсов

Папка META-INF содержит несколько важных файлов, которые содержат информацию и подписи файла, а также проверки, что это именно оригинальный файл от разработчика. За это отвечают 3 файла: CERT.RSA, CERT.SF и MANIFEST.MF

Вы можете увидеть и другие файлы в APK, а также странные файлы в папках, про которые рассказывал ранее. Дело в том, что всё содержимое подключаемых библиотек попадает и в финальный файл приложения. Многие Java библиотеки содержат кучу всего лишнего. Например, я встречал исходный код библиотеки на Java, а другая библиотека добавила README файл из GitHub репозитория.

Universal APK

Теперь давайте разберемся, как сборки доставляются пользователям и какие форматы есть для этого. Первое и самое универсальное решение — одна сборка под все поддерживаемые устройства. Такая сборка называется Universal APK. Её плюс очевиден — пользователю не надо ничего знать про его устройство, чтобы выбрать правильную APK, она всего одна. Минусы сборки — большой размер и хранение на устройстве множества неиспользуемых файлов. Например, нативные библиотеки под неподдерживаемую устройством архитектуру процессора.

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

Multi APK

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

Идея делать сборки меньшего размера, чтобы доставлять их быстрее и занимать на устройстве меньше места, возникла сразу после успеха Android устройств. В Google сразу начали анализировать, что можно убрать из APK. Если рассмотреть отдельное Android устройство, то мы четко знаем его размер экрана, плотность пикселей на экране, поддерживаемую архитектуру процессора (например, ARM‑v8a или x86 инструкции). Фактически, если оставить только нативные библиотеки под архитектуру процессора и графику только для необходимой плотности экрана, то мы уменьшим размер APK, но никак не повлияем на работу приложения.

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

Вот только остается вопрос: «Как доставлять APK под каждое устройство?». Собрать новую APK из Universal APK не представляется возможным т.к. нужно заново подписывать сборку, а механизм для этого у Google Play на заре Android не было.

В Google выбрали самое простое решение — делегировать разработчикам сборку и подпись нескольких APK. Механизм назвали Split APK. В Gradle вы указываете по каким критериям разбивать сборку и плагин соберет вам несколько APK

android {
    ...
    splits {
        density {
            isEnable = true
            exclude("ldpi", "mhdpi")
            compatibleScreens("normal", "large")
        }
    abi {
        isEnable = true
        isUniversalApk = false
        include("armeabi-v7a", "arm64-v8a")
    }
}

Проблема в одном — чтобы залить их в Google Play у каждой из них должен быть уникальный version code. Вот тут уже разработчикам приходилось все это делать ручками, Google давала рекомендации, но порой все уходили во что горазды.

// Пример расчета versionCode для нескольких сборок в рамках Split APKs
android {
  val abiCodes = mapOf("armeabi-v7a" to 1, "arm64-v8a" to 2)
  androidComponents {
    onVariants { variant ->
      variant.outputs.forEach { output ->
      val name = output.filters.find { it.filterType == ABI }?.identifier
      val baseAbiCode = abiCodes.getValue(name)
      if (baseAbiCode != null) {
            output.versionCode.set(baseAbiCode * 1000 + output.versionCode.get())
      }
    }
  }
}

App Bundle

Новой итерацией создания оптимизированных сборок для Android устройств стал формат App Bundle, который представили в 2018 году. App Bundle представляет из себя архив с кубиками для построения APK. Теперь разработчикам нужно было просто собрать AAB файл вместо APK и загрузить в магазин приложений. Также стало проще и с версионированием — у всех APK из одного App Bundle она теперь одна и та же.

Помимо всего того, что уже было в Multi APK нововведением App Bundle стала возможность скачивать ресурсы только для отдельных локалей на устройстве. Ведь они тоже все не нужны, зачастую мы используем только один язык, разве что с приходом Android 13 появилась возможность менять язык приложений независимо от системы. Эта возможность опциональна и если вы поддерживаете переключение локалей внутри своего приложения независимо от системы, то вам стоит отключить эту опцию:

bundle {
    language {
        enableSplit = false
    }
    density {
        enableSplit = true
    }
    abi {
        enableSplit = true
    }
    texture {
        enableSplit = false
    }
}

App Bundle не установить на устройство, потому что единственным форматом распространения приложений остается все также APK. Чтобы из AAB файла получить APK надо воспользоваться утилитой bundletoole от Google. На вход ей необходимо передать конфигурацию устройства. В результате вы получите несколько APK файлов. Почему так? Отдельная APK представляет базовую APK, где содержится вся основа приложения, отдельное APK для нативных библиотек под архитектуру процессора, APK с графическими ресурсами и строками и другие APK с различными компонентами. После этого все они устанавливаются на устройство. Подписывать полученные APK вам уже придется самостоятельно.

Установка нескольких APK проходит с помощью специального API PackageInstaller, которое представили в API Level 21. И это важный аспект — ощутить преимущества App Bundle не смогу устройства на Android 4.4 и ниже.

App Bundle — свободный формат с открытым исходным кодом. Любой из магазинов приложений может взять его себе на вооружение, но конечно полноценно сделали это только в Google Play. Поддержка также есть в Huawei App Gallery. Начиная с августа 2021 он является обязательным для всех новых приложение в Google Play и рекомендуй для остальных.

На основе App Bundle реализуется множество возможностей: расширенная проверка и верификация приложений, анализ зависимостей, доставка ассетов для игр и другие.

Google Play App Signing

Чтобы весь механизм заработал прозрачно через магазин приложений, нужно было решить вопрос с подписью приложений. Для этого появился механизм Google Play App Signing. Его суть заключается в том, что ключ для подписи вашего приложения, его называют Signing Key, хранится на защищенном сервере Google, чтобы магазин мог подписать приложение в любой момент. Для новых приложений ключ за вас сам сгенерирует магазин, а для существующих есть процесс передачи ключа и данных для доступа к нему.

Помимо этого вам надо сгенерировать еще один ключ для подписи — Upload Key. Он используется при передачи сборки от разработчика в магазин приложений, чтобы убедиться в том, что именно разработчик приложения загружает его в консоль. Если вы потеряете Upload Key или его украдут, то можно обратиться в Google Play и заменить его на новый.

Пример передачи сборок от разработчика к пользователю при использовании Google Play App Signing

С одной стороны, звучит все хорошо — Google упростила работу с получением APK из App Bundle. Но это не совсем так, фактически магазин может собрать и изменить финальные APK как ему угодно, добавив или убрав оттуда файлы. Официально заявляют, что они делают оптимизации на стороне Google Play. Так поступают для добавления метаинформации о том, чтобы убедится в подлинности сборке магазином приложений. Но что они могут добавлять еще известно только Google…

Google Play Feature Delivery

Структура APK файлов при использование Dynamic Feature модулей

Представьте, что у вас есть приложение карт. Вы в него вставили функцию AR навигации, но использует её лишь 5% аудитории. Почему так? Банально в устройстве может не быть камеры, либо не хватает мощности, а может фича и вовсе доступна только по подписке. Библиотеки, связанные с AR весят немало, и получается, что мы имеем функционал, который редко используется, но который качают все пользователи.

Почему бы не сделать так, чтобы мы могли какие‑то части приложения скачивать по запросу? Для этого сделали Google Play Feature Delivery. Вы можете доставлять части своего приложения по запросу либо при выполнение условий на устройстве. Сложность подхода заключается в том, что разработчикам нужно правильно организовать модули и связи их с основным API приложения.

apply plugin: 'com.android.application'

// В application модуле указываем все подключаемые dynamic feature приложе
android {
    dynamicFeatures = [':feature-navigation', ':feature-navigation-ar']
}

// Пример dynamic feature модул
apply plugin: 'com.android.dynamic-feature'

dependencies {
    // Указываем application модуль в который будет подключаться модуль
    implementation project(':app')
}

Dynamic Feature модули могут доставляться несколькими способами:

Установка вместе с приложением
Загрузка модуля по запросу
Установка по условию которыми могут быть требования к железу устройства, версия OpenGL ES, стране, версии Android
Instant Apps т.е. возможность запуска без установки приложения

Все подробности работы с Dynamic Feature и организации их архитектуры тянет на отдельное видео: архитектура, API, UI/UX. На самом деле я уверен, что такой функционал к себе интегрируют очень редко, но если в вашем приложение он есть, а может вы сами его реализовывали - оставьте комментарий!

Механизм доставки приложений в Google Play прошел огромный путь и продолжает развиваться, сократив размеры приложения и скорость их доставки. На момент написания статья ограничение на размер приложения, загружаемого в Google Play - 150 Мб. Для большинства контента в магазине этого объема хватает с головой, разве что супераппы выходят за его лимиты.

Проблема в текущих реалиях заключается в том, как прозрачно может работать этот механизм с альтернативными магазинами приложений, особенно те, что не имею системных прав. Сейчас пользователю нужно подтверждать установку и обновление каждого приложения вне Google Play, а в случае с App Bundle — это будет несколько отдельных APK. Также встает вопрос как динамически устанавливать модули. В общем, пока без дополнительных полномочий для магазинов приложений в Android, кроме Google Play никому не получится нормально работать с динамической доставкой сборок.

В Android 14 Dev Preview 2 представили новое API в Package Manager, которое позволит запрашивать у пользователя одобрение на установку приложений один раз и до тех пор пока разрешение не отзовует

Что внутри APK. App Bundle. Google Play Dynamic Feature