APEX v Androidu Q: Největší věc od Project Treble?

Implementace APEX je pravděpodobně největší bolestí, které Google čelil od představení Project Treble. Co je APEX a jak jeho zavedení změní Android?

Myšlenka APEX sama o sobě je poměrně běžná v každodenních distribucích GNU/Linux: aktualizace balíčků zaměřené na konkrétní části sady knihoven Linuxu. Ale o to se Google nikdy nepokusil, protože Android používá oddíl RO (pouze pro čtení), kde jsou všechny systémové knihovny a frameworky jsou uloženy oproti obvyklým oddílům RW (čtení-zápis) používaným ve většině distribucí Linuxu, což umožňuje standardní proces upgradu nevhodný.

Knihovny jsou předkompilovaný kód, který lze použít v jiných programech. Z běžně používaných metod lze vytvořit knihovny pro volání aplikací pro Android, čímž se sníží velikost souborů APK, protože stejný kód nebude nutné znovu implementovat ve více aplikacích. Mnoho předinstalovaných systémových knihoven můžete najít v adresářích /system/lib a /system/lib64. Systémové knihovny Android se obvykle neaktualizují jednotlivě – spíše se aktualizují jako součást upgradů platforem Android prostřednictvím aktualizace OTA. Na druhou stranu lze knihovny v distribucích Linuxu aktualizovat individuálně. Se zavedením APEX lze systémové knihovny v systému Android aktualizovat individuálně jako aplikace pro Android. Hlavní výhodou toho je, že vývojáři aplikací budou moci využívat výhody aktualizovaných knihoven, aniž by museli čekat, až OEM zavede úplnou aktualizaci systému. Pojďme se ponořit do více technických podrobností o tom, jak APEX funguje.

Jak APEX změní způsob aktualizace knihoven?

APEX je ekosystém, který donutil (nebo spíše nutí) Google přehodnotit způsob, jakým Android načítá všechny knihovny a soubory z nestandardního oddílu odlišného od /system.

Nejprve musíme specifikovat rozdíl mezi sdílenou knihovnou a statickou knihovnou. Sdílená knihovna je knihovna (obvykle soubor s názvem libkind.so), která sama o sobě neobsahuje veškerý kód potřebný ke spuštění, ale je „propojena“ s jinými knihovnami. poskytuje kód, zatímco statická knihovna je, jak můžete hádat, knihovna, která nezávisí na žádných jiných knihovnách a má vše staticky zahrnuto v soubor.

Android historicky konfiguroval cestu ke knihovně (ve světě Linuxu známou jako LD_LIBRARY_PATH) pomocí jediného souboru s názvem ld.config.txt [0] pro konfiguraci povolených vyhledávacích cest pro sdílené knihovny potřebné pro binární nebo jiné knihovna. Tyto cesty jsou pevně zakódovány v konfiguraci a nelze je rozšířit. Toto rozložení, včetně systémového oddílu pouze pro čtení, vede k neaktualizovatelným knihovnám, pokud si uživatel nenainstaluje aktualizaci OTA pro Android. Google vyřešil tento problém umožňující rozšířit cestu vyhledávání tím, že nechal jednotlivé balíčky APEX poskytovat svůj vlastní soubor ld.config.txt, který obsahoval další (a aktualizované) cesty knihoven v nich obsažené.

I když tento krok vyřešil jeden z hlavních problémů, stále bylo potřeba překonat několik vážných problémů. Za prvé: stabilita ABI (aplikační binární rozhraní). Knihovny by měly vždy exportovat stabilní sadu rozhraní, aby umožnily dalším aplikacím a knihovnám nadále pracovat se stejným protokolem i s upgradovanou knihovnou. Google na tom aktivně pracuje a snaží se vytvořit stabilní C rozhraní mezi APEXed knihovnami.

APEX se však neomezuje pouze na knihovny a binární soubory. Ve skutečnosti může obsahovat konfigurační soubory, aktualizace časového pásma a některé frameworky Java (conscrypt v době psaní).

Zde je několik příkladů aktuálních balíčků APEX poskytovaných AOSP:

• com.android.runtime: ART a bionické běhové prostředí (binární soubory a knihovny)
• com.android.tzdata: Časové pásmo a data ICU (knihovny a konfigurační data)
• com.android.resolv: Knihovna používaná systémem Android k řešení požadavků souvisejících se sítí (knihovny)
• com.android.conscrypt: Poskytovatel zabezpečení Java (rámec Java)

Jak je nainstalován a strukturován balíček APEX?

Balíček APEX je jednoduchý zip archiv (jako APK), který lze nainstalovat pomocí našeho praktického ADB (v tomto bodě vývoje) a později samotným uživatelem prostřednictvím správce balíčků (jako je Google Play nebo ručně prostřednictvím balíčku Android instalační program).

Rozložení ZIP je následující:

Pojďme se do toho ponořit.

Apex_manifest.json určuje název a verzi balíčku.

Apex_payload.img je obraz mikrosouborového systému (formátovaný jako EXT4).

Ostatní soubory jsou součástí ověřovacího procesu použitého k instalaci balíčku. Pojďme se podívat.

Přítomnost někoho AndroidManifest.xml, i když se používá hlavně v aplikacích, pomáhá nám pochopit, že většina implementace používané pro standardní instalaci APK je znovu použita i pro tyto balíčky. Ve skutečnosti se kontroluje pouze rozšíření, aby se mezi nimi rozlišilo.

The META-INF/ adresář má certifikát balíčku a používá stejný mechanismus jako normální soubory APK. Takže tyto balíčky jsou ověřeny párem soukromých/veřejných klíčů za běhu, než je uživateli povoleno nainstalovat aktualizaci. To ale Googlu nestačilo, a tak přidali další 2 vrstvy zabezpečení. Používají dm-verity ke kontrole integrity obrazu a ověřování AVB (Android Verified Boot), aby se ujistili, že obraz pochází z důvěryhodného zdroje. V nejhorším případě bude balíček APEX odmítnut.

Pokud jsou všechny kroky ověření úspěšné, bude obraz označen jako platný a při příštím restartu nahradí systémovou variantu.

Jak se instaluje obraz při bootování?

Začněme tím, že se podíváme na APEX aktuálně nainstalované v mém zařízení (emulátor)

Jak můžete vidět, předinstalované balíčky jsou uloženy v /system/apex/ a všechny jsou aktuálně na verzi číslo 1. Ale co se stane, když je aktivován APEX? Jako příklad opět použijeme com.android.tzdata.

Restartujeme zařízení a analyzujeme logcat.

První 2 řádky poskytují dostatek informací k pochopení původu balíčku a toho, kde bude nainstalován: /apex/, nový adresář představený v Android Q, který bude použit k ukládání aktivovaných balíčky.

Poté, co byl balíček úspěšně ověřen pomocí AVB a shodu veřejného klíče, je APEX připojen pomocí smyčkového zařízení do /dev/block/loop0, čímž se souborový systém EXT4 zpřístupní systému. Zařízení smyčky je pseudozařízení, které zpřístupňuje soubor jako blokové zařízení a zpřístupňuje obsah tohoto souboru jako bod připojení.

V tomto okamžiku se APEX stále nepoužívá kvůli příponě @1 (která označuje verzi balíčku). Aby systém konečně věděl, že náš balíček byl úspěšně aktivován, bude připojen k /apex/com.android.tzdata, kde Android aktivně očekává existenci tzdata. Připojení vazby překryje existující adresář nebo soubor pod jiným bodem. [1]

Implementace APEX je zcela obsažena v jediném úložišti pod AOSP. [2] V adresáři apexd (APEX daemon) je kód spuštěný na Androidu. Adresář apexer obsahuje kód používaný systémem sestavení k vytvoření balíčků APEX.

Jaký je účel?

V tuto chvíli mohu jen spekulovat. Můj nejlepší odhad je, že Google se snaží vytvořit základní sadu balíčků APEX, které může Google aktualizovat a případně vytvořit sjednocené základní jádro Androidu sdílené mezi dodavateli, které umožňuje pouze aktualizace „systému“, ale pomocí jediného balíčku aktualizace.

Budou všechna zařízení podporovat APEX?

Ne. Například apexd vyžaduje, aby byl /data/apex k dispozici hned po spuštění, aby se aktualizovaly všechny moduly Android. S FDE (Full-disk Encryption) je /data/apex zašifrováno, dokud uživatel zařízení neodemkne, takže APEX je v podstatě k ničemu, protože při bootu budou načteny pouze systémové varianty APEX. Kromě toho by všechna zařízení měla podporovat APEX, ale potřebují několik záplat jádra (mnoho z nich jsou opravy nalezené Googlem při hraní se smyčkovými zařízeními). [3] [4]

---

Prameny [0], [1], [2], [3], [4]