APEX v sistemu Android Q: Največja stvar od Project Treble?

Implementacija APEX je verjetno največji glavobol, s katerim se Google sooča od uvedbe projekta Treble. Kaj je APEX in kako bo njegova uvedba spremenila Android?

Ideja za APEX je sama po sebi precej pogosta v vsakodnevnih distribucijah GNU/Linux: posodobitve paketov, ki ciljajo na določene odseke nabora knjižnic Linux. Toda Google tega ni nikoli poskušal narediti, saj je Android uporabljal particijo RO (samo za branje), kjer so vse sistemske knjižnice in okviri so shranjeni v primerjavi z običajnimi particijami RW (branje-pisanje), ki se uporabljajo v večini distribucij Linuxa, kar predstavlja standardni postopek nadgradnje neprimeren.

Knjižnice so vnaprej prevedena koda, ki jo je mogoče uporabiti v drugih programih. Pogosto uporabljene metode je mogoče spremeniti v knjižnice za klice aplikacij za Android, s čimer se zmanjša velikost APK-jev, saj iste kode ne bo treba znova implementirati v več aplikacijah. Veliko vnaprej nameščenih sistemskih knjižnic najdete v imenikih /system/lib in /system/lib64. Sistemske knjižnice Android se navadno ne posodabljajo posamično – namesto tega se posodobijo kot del nadgradenj platforme Android prek posodobitve OTA. Po drugi strani pa se lahko knjižnice v distribucijah Linuxa posodabljajo posamično. Z uvedbo APEX je mogoče sistemske knjižnice v Androidu posodabljati posamično, kot so aplikacije za Android. Glavna prednost tega je, da bodo razvijalci aplikacij lahko izkoristili posodobljene knjižnice, ne da bi čakali, da proizvajalec originalne opreme uvede celotno nadgradnjo sistema. Poglobimo se v več tehničnih podrobnosti o tem, kako deluje APEX.

Kako bo APEX spremenil način posodabljanja knjižnic?

APEX je ekosistem, ki je prisilil (ali bolje rečeno, sili) Google, da ponovno razmisli o tem, kako Android nalaga vse knjižnice in datoteke iz nestandardne particije, ki ni /system.

Najprej moramo določiti razliko med knjižnico v skupni rabi in statično knjižnico. Knjižnica v skupni rabi je knjižnica (običajno datoteka z imenom libkind.so), ki sama po sebi ne vključuje vse potrebne kode za izvajanje, ampak je dejansko »povezana« z drugimi knjižnicami zagotavlja kodo, medtem ko je statična knjižnica, kot lahko ugibate, knjižnica, ki ni odvisna od drugih knjižnic in ima vse, kar je statično vključeno v mapa.

Android je v preteklosti konfiguriral pot knjižnice (znano kot LD_LIBRARY_PATH v svetu Linuxa) z eno datoteko imenovan ld.config.txt [0] za konfiguracijo dovoljenih iskalnih poti za knjižnice v skupni rabi, ki jih potrebuje bodisi binarno ali drugo knjižnica. Te poti so v konfiguraciji trdo kodirane in jih ni mogoče razširiti. Ta postavitev, vključno s sistemsko particijo samo za branje, vodi do knjižnic, ki jih ni mogoče posodobiti, razen če uporabnik namesti posodobitev OTA za Android. Google je popravil to težavo in omogočil razširitev iskalne poti tako, da je posameznim paketom APEX dovolil, da zagotovijo lastno datoteko ld.config.txt, ki vključuje dodatne (in posodobljene) poti knjižnic, ki jih vsebujejo.

Čeprav je ta poteza odpravila eno od glavnih težav, je bilo še vedno nekaj resnih težav, ki jih je bilo treba premagati. Najprej: stabilnost ABI (binarni vmesnik aplikacije). Knjižnice morajo vedno izvoziti stabilen nabor vmesnikov, da omogočijo drugim aplikacijam in knjižnicam, da še naprej delujejo z istim protokolom tudi z nadgrajeno knjižnico. Google aktivno dela na tem, tako da poskuša ustvariti stabilen vmesnik C med knjižnicami APEX.

Vendar APEX ni omejen samo na knjižnice in binarne datoteke. Pravzaprav lahko vsebuje konfiguracijske datoteke, posodobitve časovnih pasov in nekatera ogrodja Java (skriptirano v času pisanja).

Tukaj je nekaj primerov trenutnih paketov APEX, ki jih ponuja AOSP:

• com.android.runtime: ART in bionic runtime (binarne datoteke in knjižnice)
• com.android.tzdata: TimeZone in podatki ICU (knjižnice in konfiguracijski podatki)
• com.android.resolv: Knjižnica, ki jo uporablja Android za reševanje zahtev, povezanih z omrežjem (knjižnice)
• com.android.conscrypt: Ponudnik varnosti Java (ogrodje Java)

Kako je nameščen in strukturiran paket APEX?

Paket APEX je preprost arhiv zip (kot APK), ki ga je mogoče namestiti z našim priročnim ADB (na tej točki v razvoju) kasneje pa uporabnik sam prek upravitelja paketov (kot je Google Play ali ročno prek paketa Android). namestitveni program).

Postavitev ZIP je naslednja:

Poglobimo se v to.

Apex_manifest.json določa ime in različico paketa.

Apex_payload.img je slika mikrodatotečnega sistema (formatirana kot EXT4).

Druge datoteke so del postopka preverjanja, ki se uporablja za namestitev paketa. Poglejmo.

Prisotnost AndroidManifest.xml, tudi če se uporablja predvsem v aplikacijah, nam pomaga razumeti, da se večina implementacije, ki se uporablja za standardno namestitev APK, ponovno uporabi tudi za te pakete. Pravzaprav se preverja samo razširitev, da se med njimi razlikuje.

The META-INF/ ima paketno potrdilo in uporablja enak mehanizem kot običajni APK-ji. Torej ti paketi se preverijo s parom zasebnih/javnih ključev med izvajanjem, preden je uporabniku dovoljeno namestiti posodobitev. Toda Googlu to ni bilo dovolj, zato so dodali še 2 ravni varnosti. Uporabljajo dm-verity za preverjanje celovitosti slike in preverjanja AVB (Android Verified Boot), da zagotovijo, da slika prihaja iz zaupanja vrednega vira. V najslabšem primeru bo paket APEX zavrnjen.

Če so vsi koraki preverjanja uspešni, bo slika označena kot veljavna in bo ob naslednjem ponovnem zagonu nadomestila sistemsko različico.

Kako se slika namesti ob zagonu?

Začnimo z ogledom APEX-ov, ki so trenutno nameščeni v moji napravi (emulator)

Kot lahko vidite, so vnaprej nameščeni paketi shranjeni v /system/apex/ in vsi so trenutno na različici številka 1. Toda kaj se zgodi, ko je APEX aktiviran? Kot primer bomo spet uporabili com.android.tzdata.

Ponovno zaženimo napravo in analizirajmo logcat.

Prvi 2 vrstici zagotavljata dovolj informacij, da razumemo izvor paketa in kje bo nameščeno: /apex/, nov imenik, predstavljen v sistemu Android Q, ki se bo uporabljal za shranjevanje aktiviranih paketi.

Ko je paket uspešno preverjen z AVB in se javni ključ ujema, je APEX nameščen z uporabo zanke v /dev/block/loop0, s čimer je datotečni sistem EXT4 dostopen sistemu. Naprava z zanko je psevdonaprava, ki naredi datoteko dostopno kot blokovno napravo, zaradi česar je vsebina te datoteke dostopna kot točka priklopa.

Na tej točki se APEX še vedno ne uporablja zaradi pripone @1 (ki označuje različico paketa). Da bi sistem končno obvestil, da je bil naš paket uspešno aktiviran, bo povezan z /apex/com.android.tzdata, kjer Android aktivno pričakuje, da bo tzdata živela. Pripenjanje povezovanja prekriva obstoječi imenik ali datoteko pod drugo točko. [1]

Izvedba APEX je v celoti v enem samem repozitoriju pod AOSP. [2] Imenik apexd (APEX daemon) ima kodo, ki se izvaja v sistemu Android. Imenik apexer vsebuje kodo, ki jo sistem gradnje uporablja za ustvarjanje paketov APEX.

Kaj je namen?

Na tej točki lahko samo špekuliram. Moja najboljša domneva je, da poskuša Google ustvariti osnovni nabor paketov APEX, ki jih lahko Google posodobi, da bi morda ustvaril poenoteno osnovno jedro Androida, ki si ga delijo prodajalci, kar omogoča samo »sistemske« posodobitve, vendar z uporabo enega paketa posodobitve.

Ali bodo vse naprave podpirale APEX?

Ne. Apexd na primer zahteva, da je /data/apex na voljo takoj po zagonu za posodobitev vseh modulov Android. S FDE (Full-disk Encryption) je /data/apex šifriran, dokler uporabnik ne odklene naprave, zaradi česar je APEX v bistvu neuporaben, saj bodo ob zagonu naložene samo različice sistema APEX. Razen tega bi morale vse naprave podpirati APEX, vendar potrebujejo nekaj popravkov jedra (mnogi so popravki, ki jih je našel Google med igranjem z napravami zanke). [3] [4]

---

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