Как установка приложений для Android работает под капотом

Когда вы нажимаете «Установить» для файла APK или скачиваете приложение из Play Store, за кулисами запускается сложная последовательность операций. То, что кажется простым индикатором выполнения, на самом деле представляет собой десятки шагов, включая анализ пакета, криптографическую проверку, управление разрешениями, извлечение файлов и оптимизацию кода. Понимание этого процесса помогает объяснить, почему установка иногда завершается сбоем и что с этим можно сделать.

В этой статье мы рассмотрим все основные этапы процесса установки Android: с момента получения системой APK до момента, когда приложение готово к запуску.

Шаг 1. Начало установки

Процесс установки начинается по-разному в зависимости от источника:

• Игровой магазин: Приложение Play Store загружает APK (или отдельные APK-файлы) и вызывает системный установщик пакетов со специальными привилегиями, которые обходят некоторые подтверждения пользователя.
• Неопубликованная загрузка: Когда вы открываете APK-файл, Android запускает установщик пакета. В Android 8.0 и более поздних версиях устанавливающее приложение должно иметь разрешение «Установка неизвестных приложений» для конкретного источника.
• АБР: Команда adb install напрямую взаимодействует со службой диспетчера пакетов через USB, полностью минуя графический установщик.

Независимо от источника, все установки в конечном итоге достигают одной и той же системной службы: PackageManagerService (PMS). Это центральный орган для всех операций с пакетами на Android.

Шаг 2. Анализ пакета

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

Анализатор считывает файл AndroidManifest.xml из APK. Этот двоичный XML-файл содержит важную информацию:

• Название пакета: Уникальный идентификатор приложения (например, com.example.myapp).
• Код и название версии: Используется для определения, является ли это обновлением или новой установкой.
• Минимальная и целевая версии SDK: Определяет совместимость с устройством
• Заявленные разрешения: Как разрешения, запрашиваемые приложением, так и пользовательские разрешения, которые оно определяет.
• Компоненты: Действия, услуги, приемники вещания и поставщики контента, которые регистрирует приложение
• Аппаратные и программные возможности: Требования, такие как камера, GPS или определенные версии OpenGL.

Если манифест имеет неверный формат или структура APK недействительна, на этом этапе установка завершается с ошибкой и появляется сообщение «Ошибка анализа». Это одна из наиболее распространенных причин, по которой неустановленные APK-файлы не устанавливаются.

Шаг 3. Проверка совместимости

После анализа манифеста система выполняет ряд проверок совместимости:

• Версия SDK: Если minSdkVersion приложения выше уровня API устройства, установка отклоняется.
• Совместимость с ABI: Если APK содержит собственные библиотеки, система проверяет, соответствуют ли они архитектуре ЦП устройства. APK, содержащий только библиотеки armeabi-v7a, не будет установлен на устройстве только с процессором x86.
• Требуемые функции: Если приложение заявляет о необходимых аппаратных функциях (например, android.hardware.telephony), система проверяет, поддерживает ли устройство их.
• Доступное хранилище: Система проверяет, достаточно ли свободного места для установки приложения, включая место для извлеченных собственных библиотек и оптимизированных файлов DEX.

Шаг 4. Проверка подписи

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

Процесс проверки зависит от того, какие схемы подписи присутствуют:

Подпись V1 (подпись JAR)

Система проверяет каталог META-INF/ на наличие файлов сигнатур (.SF, .RSA или .DSA). Каждый файл в APK проверяется на соответствие дайджестам, указанным в манифесте. Это медленно, поскольку каждый файл должен быть хеширован индивидуально.

Подпись V2 (Схема подписи APK v2)

Эта схема, представленная в Android 7.0, подписывает весь APK как двоичный объект. Блок подписи вставляется между центральным каталогом ZIP и записью конца центрального каталога. Проверка происходит намного быстрее, поскольку она работает с необработанными байтами без необходимости распаковки отдельных записей.

Подпись V3 (поворот ключей)

Версия V3, доступная начиная с Android 9.0, расширяет версию V2 поддержкой вращения клавиш. Он включает в себя структуру подтверждения ротации, которая связывает старые и новые ключи подписи, что позволяет разработчикам изменять свой ключ подписи, сохраняя при этом совместимость обновлений.

Подпись V4 (инкрементная)

В Android 11 представлена версия V4 для добавочной установки. Он предоставляет подпись на основе дерева Меркла, которая позволяет проверять отдельные блоки по мере их потоковой передачи на устройство.

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

Обновить сопоставление подписей

Если приложение с таким же названием пакета уже установлено, система выполняет дополнительную проверку: сертификат подписи нового APK должен совпадать с сертификатом существующей установки. Это не позволяет злоумышленнику заменить законное приложение подделанной версией. Если подписи не совпадают, вы увидите ошибку «Приложение не установлено: пакет конфликтует с существующим пакетом с тем же именем».

Шаг 5: Подтверждение пользователя

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

• Название и значок приложения (извлечены из ресурсов APK).
• Разрешения, запрашиваемые приложением (в старых версиях Android)
• Будь то новая установка или обновление
• Любые предупреждения об источнике приложения или потенциальных рисках.

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

Шаг 6: Извлечение и размещение файлов

Как только пользователь подтвердит (или автоматически при установке из Play Store), система начнет извлекать и размещать файлы:

Хранилище APK

Сам APK-файл копируется в /data/app/[package-name]-[random]/base.apk. При раздельных установках APK дополнительные файлы, такие как split_config.arm64_v8a.apk, размещаются рядом с базовым APK. Исходный APK в папке «Загрузки» не изменяется и не удаляется.

Извлечение родной библиотеки

Если APK содержит собственные библиотеки (в каталоге lib/, они извлекаются в /data/app/[package-name]-[random]/lib/[abi]/.) В более новых версиях Android приложения могут сохранять собственные библиотеки сжатыми в APK и загружать их напрямую с помощью android:extractNativeLibs="false", что экономит место для хранения.

Создание каталога данных

Система создает каталог личных данных приложения по адресу /data/data/[package-name]/ (или /data/user/0/[package-name]/ на многопользовательских устройствах). Этот каталог принадлежит уникальному UID Linux, назначенному приложению, что гарантирует, что никакое другое приложение не сможет получить к нему доступ без привилегий root.

Шаг 7: Оптимизация DEX

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

Эра Далвика (Android 4.4 и более ранние версии)

Исходная виртуальная машина Dalvik использовала компиляцию Just-In-Time (JIT). Во время установки файл classes.dex оптимизировался в файл ODEX, содержащий проверенный и оптимизированный байт-код. Это происходило относительно быстро, но означало, что приложение работало медленнее во время выполнения, поскольку большая часть кода по-прежнему интерпретировалась.

ART с AOT (Android 5.0–6.0)

Android Runtime (ART) заменил Dalvik и представил компиляцию Ahead-Of-Time (AOT). Во время установки весь байт-код DEX был скомпилирован в собственный машинный код. Это позволило приложениям работать быстрее, но значительно увеличило время установки и использование памяти. Установка некоторых приложений занимала несколько минут.

Компиляция по профилю (Android 7.0+)

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

Скомпилированный код хранится в /data/dalvik-cache/ или вместе с APK в виде файлов .odex, .vdex и .art. Файл .vdex содержит проверенный код DEX, файл .odex — скомпилированный собственный код, а файл .art — предварительно инициализированные образы кучи для более быстрого запуска.

Шаг 8: Регистрация разрешения

PackageManagerService регистрирует объявленные разрешения и компоненты приложения в системе:

• Разрешения во время установки (например, INTERNET или VIBRATE предоставляются автоматически без взаимодействия с пользователем).
• Разрешения во время выполнения (например, CAMERA или LOCATION зарегистрированы, но не предоставлены). Приложение должно запрашивать их во время выполнения.
• Фильтры намерений регистрируются, чтобы система знала, какие приложения могут выполнять какие действия (например, открытие URL-адреса или обмен контентом).
• Поставщики контента зарегистрированы в своих органах власти, поэтому другие приложения могут запрашивать их.

Шаг 9: Системная интеграция

Последние шаги интегрируют приложение в систему Android:

• Обновление базы данных пакетов: Системная база данных пакетов (/data/system/packages.xml) обновляется информацией о новом приложении, включая присвоенный ему UID, разрешения и объявления компонентов.
• Уведомление лаунчера: Средство запуска на главном экране уведомляется о новом приложении и может отображать значок приложения.
• Трансляция: Система отправляет широковещательное сообщение PACKAGE_ADDED, позволяя другим приложениям реагировать на новую установку (например, приложения резервного копирования могут запланировать резервное копирование).
• Контекст SELinux: Файлы приложения помечены соответствующим контекстом безопасности SELinux на основе целевой версии SDK и заявленных разрешений.

Почему установка не удалась

Понимание конвейера установки помогает диагностировать распространенные неисправности:

• «Ошибка анализа»: APK-файл поврежден, неполный или имеет неверный манифест. Такое часто случается при неполной загрузке или неправильно конвертированных файлах.
• «Приложение не установлено» (несоответствие подписи): Вы пытаетесь обновить приложение с помощью APK, подписанного другим ключом. Сначала необходимо удалить существующую версию.
• «Недостаточно места»: Недостаточно места для APK, извлеченных библиотек и результатов оптимизации DEX. Фактически необходимое пространство обычно в 2–3 раза превышает размер APK.
• «Пакет конфликтует с существующим пакетом»: То же имя пакета, но другая подпись. Часто встречается при переключении между Play Store и загруженными неопубликованными версиями.
• Понижение версии заблокировано: By default, Android prevents installing an older version over a newer one. ADB может отменить это с помощью adb install -d.

Разделенная установка APK

При установке разделенных APK-файлов (из App Bundles) процесс немного отличается. Система использует API установки на основе сеансов:

1. Создаётся новый сеанс установки.
2. Каждый разделенный APK записывается в сеанс.
3. Сеанс зафиксирован, что запускает полный конвейер проверки.
4. Все разделения должны иметь совпадающие имена пакетов, коды версий и сертификаты подписи.

Этот механизм используется установщиками XAPK и такими инструментами, как наш Объединение APKS и APK, для обработки многофайловых установок.

Установка через АБР

Когда вы используете команду adb install, процесс обходит графический установщик, но проходит по тому же внутреннему конвейеру. ADB взаимодействует со службой менеджера пакетов через сокет-соединение. Он поддерживает дополнительные флаги, недоступные через графический интерфейс:

• -r: заменить существующее приложение (разрешить переустановку).
• -d: Разрешить понижение версии.
• -g: немедленно предоставить все разрешения во время выполнения.
• -t: разрешить установку APK-файлов только для тестирования.
• --install-multiple: установка разделенных APK за один сеанс.

Что происходит во время удаления

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

1. Процессы приложения убиты
2. APK и извлеченные библиотеки удалены из /data/app/.
3. Каталог личных данных приложения удаляется (если пользователь не решил сохранить данные).
4. Скомпилированные файлы кэша DEX удаляются.
5. База данных пакетов обновлена.
6. Отправляется широковещательная рассылка PACKAGE_REMOVED.
7. Лаунчер удаляет значок приложения

Обратите внимание, что файлы приложений во внешнем хранилище (/Android/data/[package]/ и /Android/obb/[package]/ также удаляются в Android 10 и более поздних версиях благодаря принудительному использованию ограниченного хранилища).

Почему понимание PackageManager экономит время отладки

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

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