Когато докоснете „Инсталиране“ на APK файл или изтеглите приложение от Play Store, зад кулисите започва сложна последователност от операции. Това, което изглежда като обикновена лента за напредъка, всъщност представлява десетки стъпки, включващи анализиране на пакети, криптографска проверка, управление на разрешения, извличане на файлове и оптимизиране на кода. Разбирането на този процес помага да се обясни защо инсталациите понякога се провалят и какво можете да направите по въпроса.
В тази статия ще преминем през всяка основна стъпка от инсталационния процес на Android, от момента, в който системата получи APK до момента, в който приложението е готово за стартиране.
Стъпка 1: Започване на инсталацията
Процесът на инсталиране започва по различен начин в зависимост от източника:
- Play Store: Приложението Play Store изтегля APK (или разделени APK файлове) и извиква инсталатора на системния пакет със специални привилегии, които заобикалят някои потребителски потвърждения.
- Странично зареждане: Когато отворите APK файл, Android стартира дейността за инсталиране на пакети. В Android 8.0 и по-нови версии инсталиращото приложение трябва да има разрешение „Инсталиране на неизвестни приложения“ за своя конкретен източник.
- ADB: Командата adb install комуникира директно с услугата за управление на пакети през USB, заобикаляйки изцяло графичния инсталатор.
Независимо от източника, всички инсталации в крайна сметка достигат до една и съща системна услуга: PackageManagerService (PMS). Това е централният орган за всички операции с пакети на Android.
Стъпка 2: Анализ на пакета
Преди всичко друго, системата трябва да разбере какво ще инсталира. PackageManagerService извиква PackageParser, за да прочете 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 (завъртане на ключове)
Предлага се от Android 9.0, V3 разширява V2 с поддръжка за ротация на клавишите. Той включва структура за доказване на ротация, която свързва стари и нови ключове за подписване, позволявайки на разработчиците да променят своя ключ за подписване, като същевременно поддържат съвместимостта на актуализацията.
Подпис V4 (инкрементален)
Android 11 представи V4 за инкрементални инсталации. Той осигурява подпис, базиран на дърво на Merkle, който позволява проверка на отделни блокове, докато се предават поточно към устройството.
Ако проверката на подписа е неуспешна по някаква причина, инсталацията незабавно се прекъсва. Можете да проверите подписа на 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]/ на многопотребителски устройства). Тази директория се притежава от уникален Linux UID, присвоен на приложението, което гарантира, че никое друго приложение няма достъп до нея без root права.
Стъпка 7: Оптимизация на DEX
Тази стъпка е мястото, където Android трансформира байт кода на приложението във формат, оптимизиран за специфичния хардуер на устройството. Процесът се е развил значително през историята на Android:
Ерата Dalvik (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 и странично заредени версии.
- Понижаването на версията е блокирано: По подразбиране Android предотвратява инсталирането на по-стара версия върху по-нова. ADB може да отмени това с adb install -d.
Разделена инсталация на APK
Когато инсталирате разделени APK файлове (от App Bundles), процесът е малко по-различен. Системата използва базирана на сесия инсталация API:
- Създава се нова инсталационна сесия
- Всеки разделен APK се записва в сесията
- Сесията е ангажирана, задействайки конвейера за пълна проверка
- Всички разделяния трябва да имат съвпадащи имена на пакети, кодове на версии и сертификати за подписване
Това е механизмът, използван от инсталаторите на XAPK и инструменти като нашия APKS към APK сливане за обработка на многофайлови инсталации.
Инсталиране чрез ADB
Когато използвате adb install, процесът заобикаля графичния инсталатор, но следва същия вътрешен конвейер. ADB комуникира с услугата за управление на пакети чрез сокет връзка. Той поддържа допълнителни флагове, които не са достъпни чрез GUI:
- -r: Замяна на съществуващо приложение (разрешаване на повторно инсталиране)
- -d: Разрешаване на понижаване на версията
- -g: Предоставете незабавно всички разрешения за изпълнение
- -t: Позволява инсталирането на APK файлове само за тестване
- --install-multiple: Инсталирайте разделени APK файлове в една сесия
Какво се случва по време на деинсталиране
За пълнота, ето какво се случва, когато приложение бъде премахнато:
- Процесите на приложението са убити
- APK и извлечените библиотеки се изтриват от /data/app/
- Директорията с лични данни на приложението се премахва (освен ако потребителят не е избрал да запази данните)
- Компилираните DEX кеш файлове се изтриват
- Базата данни на пакетите се актуализира
- Изпраща се PACKAGE_REMOVED излъчване
- Стартовият панел премахва иконата на приложението
Обърнете внимание, че специфичните за приложението файлове във външно хранилище (/Android/data/[package]/ и /Android/obb/[package]/ също се изтриват на Android 10 и по-нови версии, благодарение на принудителното прилагане на хранилището с обхват).
Защо разбирането на PackageManager спестява време за отстраняване на грешки
Процесът на инсталиране на Android е внимателно организирана последователност от проверки за сигурност, файлови операции и системни интеграции. Всяка стъпка служи на определена цел, от защита на потребителите срещу манипулирани приложения до оптимизиране на производителността за конкретния хардуер. Когато инсталациите са неуспешни, грешката обикновено сочи към конкретна стъпка в този конвейер и разбирането на процеса ви помага да диагностицирате и разрешавате проблемите бързо.
Инсталиране от Play Store, странично зареждане на APK на ръка и прокарване на компилация с ADB през цялата фуния през един и същ основен конвейер, този, който гарантира, че всяко приложение на вашето устройство е проверено, поставено правилно и оптимизирано за вашия хардуер.