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 між бібліотеками APEX.

Але APEX не обмежується лише бібліотеками та двійковими файлами. Фактично, він може містити конфігураційні файли, оновлення часового поясу та деякі фреймворки Java (conscript на момент написання).

Ось кілька прикладів поточних пакетів 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 daemon) містить код, що працює на 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]