Google работает над APEX: обновление системных библиотек как в стандартном дистрибутиве Linux. Ожидаемый в Android Q, APEX может стать самым большим достижением со времен 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 (на момент написания использовалось conscrypt).
Вот несколько примеров текущих пакетов 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, используется повторно даже для этих пакетов. Фактически, чтобы различать их, проверяется только расширение.
МЕТА-ИНФ/ имеет сертификат пакета и использует тот же механизм, что и обычные APK. Итак, эти пакеты проверяются парой частного/открытого ключей во время выполнения, прежде чем пользователю будет разрешено установить обновление. Но Google этого оказалось недостаточно, поэтому они добавили еще два уровня безопасности. Они используют dm-verity для проверки целостности образа и проверки AVB (Android Verified Boot), чтобы убедиться, что образ получен из надежного источника. В худшем случае пакет APEX будет отклонен.
Если все этапы проверки пройдены успешно, образ будет помечен как действительный и заменит вариант системы при следующей перезагрузке.
Как устанавливается образ при загрузке?
Начнем с просмотра APEX, установленных на моем устройстве (эмуляторе).
Как видите, предустановленные пакеты хранятся в /system/apex/, и все они в настоящее время имеют версию номер 1. Но что происходит, когда APEX активируется? Мы снова будем использовать com.android.tzdata в качестве примера.
Перезагрузим устройство и проанализируем логкат.
Первые две строки предоставляют достаточно информации, чтобы понять происхождение пакета и его местонахождение. установлен: /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]