Google pracuje na APEX: aktualizácia systémových knižníc ako štandardná linuxová distribúcia. APEX, ktorý sa očakáva v systéme Android Q, môže byť najväčšou vecou od Project Treble.
Implementácia APEX je pravdepodobne najväčšou bolesťou hlavy, ktorej spoločnosť Google čelila od predstavenia Project Treble. Čo je APEX a ako jeho zavedenie zmení Android?
Myšlienka APEX sama o sebe je pomerne bežná v každodenných distribúciách GNU/Linux: aktualizácie balíkov zamerané na špecifické časti sady knižníc Linuxu. Ale to je niečo, o čo sa Google nikdy nepokúsil, pretože Android použil oblasť RO (len na čítanie), kde sú všetky systémové knižnice a rámce sú uložené v porovnaní so zvyčajnými oddielmi RW (čítanie a zápis), ktoré sa používajú vo väčšine distribúcií Linuxu, čo predstavuje štandardný proces aktualizácie nevhodné.
Knižnice sú predkompilovaný kód, ktorý možno použiť v iných programoch. Bežne používané metódy možno premeniť na knižnice pre aplikácie pre Android, ktoré môžu volať, čím sa zníži veľkosť súborov APK, pretože rovnaký kód nebude potrebné znova implementovať vo viacerých aplikáciách. Mnoho predinštalovaných systémových knižníc môžete nájsť v adresároch /system/lib a /system/lib64. Systémové knižnice Android sa zvyčajne neaktualizujú jednotlivo – skôr sa aktualizujú ako súčasť aktualizácií platforiem Android prostredníctvom aktualizácie OTA. Na druhej strane, knižnice v linuxových distribúciách môžu byť aktualizované individuálne. So zavedením APEX je možné systémové knižnice v systéme Android aktualizovať individuálne ako aplikácie pre Android. Hlavnou výhodou toho je, že vývojári aplikácií budú môcť využívať výhody aktualizovaných knižníc bez toho, aby museli čakať, kým OEM zavedie úplnú aktualizáciu systému. Poďme sa ponoriť do technických detailov o tom, ako APEX funguje.
Ako APEX zmení spôsob aktualizácie knižníc?
APEX je ekosystém, ktorý prinútil (alebo skôr núti) Google prehodnotiť spôsob, akým Android načítava všetky knižnice a súbory z neštandardného oddielu odlišného od /system.
V prvom rade musíme špecifikovať rozdiel medzi zdieľanou knižnicou a statickou knižnicou. Zdieľaná knižnica je knižnica (zvyčajne súbor s názvom libkind.so), ktorá neobsahuje všetok kód potrebný na spustenie, ale je „prepojená“ s inými knižnicami. poskytovanie kódu, zatiaľ čo statická knižnica je, ako môžete hádať, knižnica, ktorá nezávisí od žiadnych iných knižníc a má všetko staticky zahrnuté v súbor.
Android historicky nakonfiguroval cestu knižnice (známu ako LD_LIBRARY_PATH vo svete Linuxu) s jedným súborom s názvom ld.config.txt [0] na konfiguráciu povolených vyhľadávacích ciest pre zdieľané knižnice potrebné pre binárne alebo iné knižnica. Tieto cesty sú pevne zakódované v konfigurácii a nedajú sa rozšíriť. Toto rozloženie vrátane systémového oddielu iba na čítanie vedie k neaktualizovateľným knižniciam, pokiaľ si používateľ nenainštaluje aktualizáciu OTA pre Android. Spoločnosť Google vyriešila tento problém a umožnila rozšíriť cestu vyhľadávania tým, že umožnila jednotlivým balíkom APEX poskytovať svoj vlastný súbor ld.config.txt, ktorý zahŕňal ďalšie (a aktualizované) cesty knižníc, ktoré sa v nich nachádzajú.
Aj keď tento krok vyriešil jeden z hlavných problémov, stále bolo potrebné prekonať niekoľko vážnych problémov. Po prvé: stabilita ABI (aplikačné binárne rozhranie). Knižnice by mali vždy exportovať stabilnú sadu rozhraní, aby umožnili ostatným aplikáciám a knižniciam pokračovať v práci s rovnakým protokolom aj s inovovanou knižnicou. Google na tom aktívne pracuje a snaží sa vytvoriť stabilné C rozhranie medzi APEXed knižnicami.
APEX sa však neobmedzuje len na knižnice a binárne súbory. V skutočnosti môže obsahovať konfiguračné súbory, aktualizácie časového pásma a niektoré frameworky Java (conscrypt v čase písania).
Tu je niekoľko príkladov aktuálnych balíkov APEX poskytovaných AOSP:
- com.android.runtime: ART a bionický runtime (binárne súbory a knižnice)
- com.android.tzdata: Údaje o časovom pásme a jednotke intenzívnej starostlivosti (knižnice a konfiguračné údaje)
- com.android.resolv: Knižnica používaná systémom Android na riešenie požiadaviek súvisiacich so sieťou (knižnice)
- com.android.conscrypt: Poskytovateľ zabezpečenia Java (rámec Java)
Ako je nainštalovaný a štruktúrovaný balík APEX?
Balík APEX je jednoduchý archív zip (ako súbor APK), ktorý môže nainštalovať náš praktický ADB (v tomto štádiu vývoja) a neskôr samotným používateľom prostredníctvom správcu balíkov (napríklad Google Play alebo manuálne prostredníctvom balíka Android inštalatér).
Rozloženie ZIP je nasledovné:
Poďme sa do toho ponoriť.
Apex_manifest.json určuje názov balíka a verziu.
Apex_payload.img je obraz mikrosúborového systému (formátovaný ako EXT4).
Ostatné súbory sú súčasťou procesu overovania použitého na inštaláciu balíka. Pozrime sa na to.
Prítomnosť AndroidManifest.xml, aj keď sa používa hlavne v aplikáciách, pomáha nám pochopiť, že väčšina implementácie používanej pri štandardnej inštalácii APK sa opätovne používa aj pre tieto balíčky. V skutočnosti sa kontroluje iba rozšírenie, aby sa medzi nimi rozlíšilo.
The META-INF/ adresár má certifikát balíka a používa rovnaký mechanizmus ako bežné súbory APK. Takže tieto balíčky sú overené párom súkromných/verejných kľúčov za behu predtým, ako je používateľovi umožnené nainštalovať aktualizáciu. To však Googlu nestačilo, a tak pridali ďalšie 2 vrstvy zabezpečenia. Používajú dm-verity na kontrolu integrity obrázka a overenia AVB (Android Verified Boot), aby sa uistili, že obrázok pochádza z dôveryhodného zdroja. V najhoršom prípade bude balík APEX odmietnutý.
Ak sú všetky kroky overenia úspešné, obrázok sa označí ako platný a pri ďalšom reštarte nahradí variant systému.
Ako sa obraz nainštaluje pri štarte?
Začnime tým, že sa pozrieme na aktuálne nainštalované APEXy na mojom zariadení (emulátor)
Ako vidíte, predinštalované balíčky sú uložené v /system/apex/ a všetky sú momentálne na verzii číslo 1. Čo sa však stane, keď je aktivovaný APEX? Ako príklad opäť použijeme com.android.tzdata.
Reštartujeme zariadenie a analyzujeme logcat.
Prvé 2 riadky poskytujú dostatok informácií na pochopenie pôvodu balíka a toho, kde sa bude nachádzať nainštalovaný: /apex/, nový adresár predstavený v systéme Android Q, ktorý sa použije na ukladanie aktivovaných balíkov.
Po úspešnom overení balíka pomocou AVB a zhode verejných kľúčov sa APEX pripojí pomocou slučkového zariadenia do /dev/block/loop0, čím sa systém súborov sprístupní EXT4. Slučkové zariadenie je pseudozariadenie, ktoré sprístupňuje súbor ako blokové zariadenie, čím sprístupňuje obsah tohto súboru ako bod pripojenia.
V tomto bode sa APEX stále nepoužíva kvôli prípone @1 (ktorá označuje verziu balíka). Aby sme dali systému konečne vedieť, že náš balík bol úspešne aktivovaný, pripojíme ho k /apex/com.android.tzdata, kde Android aktívne očakáva existenciu tzdata. Pripojenie väzby prekryje existujúci adresár alebo súbor pod iným bodom. [1]
Implementácia APEX je úplne obsiahnutá v jedinom úložisku pod AOSP. [2] V adresári apexd (APEX daemon) je kód spustený v systéme Android. Adresár apexer obsahuje kód používaný zostavovacím systémom na vytvorenie balíkov APEX.
Aký je účel?
V tejto chvíli môžem len špekulovať. Môj najlepší odhad je, že Google sa snaží vytvoriť základnú sadu balíkov APEX, ktoré môže Google aktualizovať, aby zjednotené základné jadro Androidu zdieľané medzi dodávateľmi, vďaka čomu sú možné iba aktualizácie „systému“, ale pomocou jedného balíka aktualizácie.
Budú všetky zariadenia podporovať APEX?
Nie. Napríklad apexd vyžaduje, aby bol /data/apex dostupný hneď po spustení, aby sa aktualizovali všetky moduly systému Android. S FDE (Full-disk Encryption) je /data/apex zašifrovaný, kým používateľ neodomkne zariadenie, čím sa APEX stane v podstate zbytočným, pretože pri štarte sa načítajú iba systémové varianty APEX. Okrem toho by všetky zariadenia mali podporovať APEX, ale potrebujú niekoľko záplat jadra (mnohé z nich sú opravy, ktoré našiel Google pri hraní so slučkovými zariadeniami). [3] [4]
Zdroje [0], [1], [2], [3], [4]