APEX в Android Q: Най-голямото нещо след Project Treble?

Внедряването на APEX е може би най-голямото главоболие, с което Google се сблъсква след въвеждането на Project Treble. Какво е APEX и как въвеждането му ще промени Android?

Идеята зад APEX сама по себе си е доста често срещана в ежедневните дистрибуции на GNU/Linux: актуализации на пакети, насочени към конкретни секции от набора от библиотеки на Linux. Но това е нещо, което Google никога не се е опитвал да направи, като се има предвид, че Android използва RO (само за четене) дял, където всички системни библиотеки и рамките се съхраняват в сравнение с обичайните RW (четене-запис) дялове, използвани в повечето Linux дистрибуции, изобразявайки стандартния процес на надграждане неподходящи.

Библиотеките са предварително компилиран код, който може да се използва в други програми. Често използваните методи могат да се превърнат в библиотеки за извикване на приложения за Android, като се намали размерът на APK файловете, тъй като един и същи код няма да трябва да се внедрява повторно в множество приложения. Можете да намерите много предварително инсталирани системни библиотеки в директориите /system/lib и /system/lib64. Системните библиотеки на Android обикновено не се актуализират индивидуално - по-скоро те се актуализират като част от надстройки на платформи на Android чрез OTA актуализация. От друга страна, библиотеките в Linux дистрибуции могат да се актуализират индивидуално. С въвеждането на APEX системните библиотеки в Android могат да се актуализират индивидуално като приложенията за Android. Основната полза от това е, че разработчиците на приложения ще могат да се възползват от актуализираните библиотеки, без да чакат OEM да пусне пълно надграждане на системата. Нека се потопим в повече технически подробности за това как работи APEX.

Как APEX ще промени начина, по който библиотеките се актуализират?

APEX е екосистема, която принуди (или по-скоро принуждава) Google да преразгледа начина, по който Android зарежда всички библиотеки и файлове от нестандартен дял, различен от /system.

На първо място, трябва да уточним разликата между споделена библиотека и статична библиотека. Споделената библиотека е библиотека (обикновено файл с име libkind.so), която не включва целия код, необходим за изпълнение, но всъщност е „свързана“ с други библиотеки предоставяйки кода, докато статичната библиотека е, както можете да предположите, библиотека, която не зависи от никакви други библиотеки и има всичко, включено статично в файл.

В миналото Android е конфигурирал пътя на библиотеката (известен като LD_LIBRARY_PATH в света на Linux) с един файл наречен ld.config.txt [0], за да конфигурирате разрешените пътища за търсене за споделените библиотеки, необходими или на двоичен, или на друг библиотека. Тези пътища са твърдо кодирани в конфигурацията и не могат да се разширяват. Това оформление, включително системния дял само за четене, води до неподлежащи на актуализиране библиотеки, освен ако потребителят не инсталира OTA актуализация на Android. Google поправи този проблем, позволявайки разширяване на пътя за търсене, като позволи на отделните APEX пакети да предоставят свой собствен ld.config.txt, който включва допълнителните (и актуализирани) пътеки на библиотеки, съдържащи се в тях.

Въпреки че този ход реши един от основните проблеми, все още имаше няколко сериозни проблема за преодоляване. На първо място: стабилност на ABI (двоичен интерфейс на приложението). Библиотеките винаги трябва да експортират стабилен набор от интерфейси, за да позволят на други приложения и библиотеки да продължат да работят със същия протокол дори с надстроената библиотека. Google работи активно върху това, като се опитва да създаде стабилен C интерфейс между APEXed библиотеки.

Но APEX не се ограничава само до библиотеки и двоични файлове. Всъщност той може да съдържа конфигурационни файлове, актуализации на часови зони и някои рамки на Java (консиптирани към момента на писане).

Ето няколко примера за текущите APEX пакети, предоставени от AOSP:

• com.android.runtime: ART и бионично време за изпълнение (двоични файлове и библиотеки)
• com.android.tzdata: TimeZone и данни за ICU (библиотеки и конфигурационни данни)
• com.android.resolv: Библиотека, използвана от Android за разрешаване на свързани с мрежата заявки (библиотеки)
• com.android.conscrypt: Доставчик на сигурност на Java (рамка на Java)

Как се инсталира и структурира пакет APEX?

APEX пакетът е прост zip архив (като APK), който може да бъде инсталиран от нашия удобен ADB (на този етап в процес на разработка) и по-късно от самия потребител чрез мениджър на пакети (като Google Play или ръчно чрез пакета за Android). инсталатор).

ZIP оформлението е както следва:

Нека се потопим в това.

Apex_manifest.json указва името и версията на пакета.

Apex_payload.img е изображение на микрофайлова система (форматирано като EXT4).

Другите файлове са част от процеса на проверка, използван за инсталиране на пакета. Нека погледнем.

Присъствието на AndroidManifest.xml, дори ако се използва главно в приложения, ни помага да разберем, че по-голямата част от внедряването, използвано за стандартна инсталация на APK, се използва повторно дори за тези пакети. Всъщност само разширението се проверява, за да се прави разлика между тях.

The МЕТА-ИНФ/ директорията има пакетен сертификат и използва същия механизъм като нормалните APK файлове. Така че тези пакети се проверяват от двойка частен/публичен ключ по време на изпълнение, преди на потребителя да бъде разрешено да инсталира актуализация. Но това не беше достатъчно за Google, така че те добавиха още 2 слоя за сигурност. Те използват dm-verity, за да проверят целостта на изображението и AVB (Android Verified Boot) проверки, за да се уверят, че изображението идва от доверен източник. В най-лошия случай пакетът APEX ще бъде отхвърлен.

Ако всички стъпки за проверка са успешни, изображението ще бъде маркирано като валидно и ще замени системния вариант при следващото рестартиране.

Как се инсталира изображение при зареждане?

Нека започнем, като разгледаме APEX-ите, инсталирани в момента на моето устройство (емулатор)

Както можете да видите, предварително инсталираните пакети се съхраняват в /system/apex/ и всички те в момента са на версия номер 1. Но какво се случва, когато APEX е активиран? Отново ще използваме com.android.tzdata като пример.

Нека рестартираме устройството и анализираме logcat.

Първите 2 реда предоставят достатъчно информация, за да разберете произхода на пакета и къде ще бъде инсталирано: /apex/, нова директория, въведена в Android Q, която ще се използва за съхраняване на активираните пакети.

След като пакетът е проверен успешно с AVB и публичният ключ съвпада, APEX се монтира с помощта на устройство за цикъл към /dev/block/loop0, което прави файловата система EXT4 достъпна за системата. Устройството за цикъл е псевдоустройство, което прави файл достъпен като блоково устройство, което прави съдържанието на този файл достъпно като точка на монтиране.

В този момент APEX все още не се използва поради суфикса @1 (който показва версията на пакета). За да уведомим най-накрая системата, че нашият пакет е успешно активиран, той ще бъде монтиран към /apex/com.android.tzdata, където Android активно очаква tzdata да живее. Монтирането на свързване наслагва съществуваща директория или файл под различна точка. [1]

Изпълнението на APEX се съдържа изцяло в едно хранилище под AOSP. [2] Директорията apexd (APEX демон) съдържа кода, работещ на Android. Директорията apexer съдържа кода, използван от системата за изграждане за създаване на пакетите APEX.

Каква е целта?

На този етап всичко, което мога да направя, е да спекулирам. Най-доброто ми предположение е, че Google се опитва да създаде основен набор от APEX пакети, които могат да бъдат актуализирани от Google за евентуално създаване унифицирано базово ядро ​​на Android, споделено между доставчици, което прави възможни само „системни“ актуализации, но с помощта на един пакет актуализации.

Всички устройства ли ще поддържат APEX?

Не. Например apexd изисква /data/apex да бъде достъпен веднага след зареждане, за да актуализира всички модули на Android. С FDE (пълно дисково криптиране) /data/apex се криптира, докато устройството не бъде отключено от потребителя, което прави APEX по същество безполезен, тъй като само вариантите на системния APEX ще бъдат заредени при зареждане. Освен това, всички устройства трябва да поддържат APEX, но се нуждаят от няколко кръпки на ядрото (много от които са корекции, открити от Google, докато играете с устройства за цикъл). [3] [4]

---

източници [0], [1], [2], [3], [4]