Google töötab APEX-i kallal: süsteemiteekide värskendamine nagu tavaline Linuxi distributsioon. Android Q puhul võib APEX olla suurim asi pärast Project Treble'i.
APEXi juurutamine on ilmselt suurim peavalu, millega Google on pärast Project Treble'i kasutuselevõttu silmitsi seisnud. Mis on APEX ja kuidas selle kasutuselevõtt Androidi muudab?
APEX-i idee iseenesest on igapäevastes GNU/Linuxi distributsioonides üsna tavaline: paketivärskendused, mis sihivad Linuxi teegikomplekti kindlaid sektsioone. Kuid seda ei üritanud Google kunagi teha, kuna Android on kasutanud RO (ainult kirjutuskaitstud) partitsiooni, kus kõik süsteemiteegid ja raamistikud salvestatakse võrreldes tavaliste RW (lugemis-kirjutamise) partitsioonidega, mida kasutatakse enamikus Linuxi distributsioonides, mis muudab standardse uuendusprotsessi sobimatu.
Teegid on eelkompileeritud kood, mida saab kasutada teistes programmides. Tavaliselt kasutatavatest meetoditest saab teha Androidi rakenduste helistamiseks teeke, mis vähendab APK-de suurust, kuna sama koodi ei pea mitmes rakenduses uuesti rakendama. Paljusid eelinstallitud süsteemiteeke leiate kataloogidest /system/lib ja /system/lib64. Androidi süsteemiteeke ei värskendata tavaliselt eraldi – pigem värskendatakse neid Androidi platvormide täienduste osana OTA värskenduse kaudu. Teisest küljest saab Linuxi distributsioonide teeke värskendada individuaalselt. APEX-i kasutuselevõtuga saab Androidi süsteemiteeke värskendada individuaalselt nagu Androidi rakendusi. Selle peamiseks eeliseks on see, et rakenduste arendajad saavad värskendatud teeke ära kasutada, ootamata, kuni OEM võtab kasutusele täieliku süsteemiuuenduse. Sukeldume APEXi toimimise tehnilistesse üksikasjadesse.
Kuidas muudab APEX teekide värskendamise viisi?
APEX on ökosüsteem, mis sundis (või pigem sunnib) Google'it uuesti läbi vaatama viisi, kuidas Android laadib kõik teegid ja failid mittestandardsest partitsioonist, mis erineb /system.
Kõigepealt peame määrama erinevuse jagatud teegi ja staatilise teegi vahel. Jagatud teek on teek (tavaliselt fail nimega libkind.so), mis ei sisalda endas kogu käitamiseks vajalikku koodi, kuid mis on tegelikult „lingitud” teiste teekidega koodi andmine, samas kui staatiline teek on, nagu võite arvata, teek, mis ei sõltu ühestki teisest teegist ja sisaldab kõike staatiliselt faili.
Android on ajalooliselt konfigureerinud teegi tee (Linux-maailmas tuntud kui LD_LIBRARY_PATH) ühe failiga ld.config.txt [0], et konfigureerida lubatud otsinguteed jagatud teekide jaoks, mida vajavad kas binaar- või muu raamatukogu. Need teed on konfiguratsioonis kõvakoodiga ja neid ei saa laiendada. See paigutus, sealhulgas kirjutuskaitstud süsteemisektsioon, viib värskendamatute teekideni, välja arvatud juhul, kui kasutaja installib OTA Androidi värskendust. Google parandas selle probleemi, võimaldades otsinguteed laiendada, lastes üksikutel APEX-pakettidel esitada oma ld.config.txt, mis sisaldas neis sisalduvaid täiendavaid (ja värskendatud) teekide teid.
Kuigi see samm lahendas ühe peamistest probleemidest, jäi siiski ületada mõned tõsised probleemid. Esiteks: ABI (rakenduse binaarliidese) stabiilsus. Teegid peaksid alati eksportima stabiilse liideste komplekti, et teised rakendused ja teegid saaksid jätkata sama protokolliga tööd isegi täiendatud teegi korral. Google töötab selle nimel aktiivselt, püüdes luua APEX-teekide vahel stabiilset C-liidest.
Kuid APEX ei piirdu ainult teekide ja kahendfailidega. Tegelikult võib see sisaldada konfiguratsioonifaile, ajavööndi värskendusi ja mõnda Java-raamistikku (kirjutamise ajal konsrüpti).
Siin on mõned näited praegustest AOSP pakutavatest APEX-pakettidest:
- com.android.runtime: ART ja biooniline käitusaeg (binaarfailid ja teegid)
- com.android.tzdata: ajavööndi ja ICU andmed (teegid ja konfiguratsiooniandmed)
- com.android.resolv: teek, mida Android kasutab võrguga seotud päringute lahendamiseks (teegid)
- com.android.conscrypt: Java turvateenuse pakkuja (Java raamistik)
Kuidas on APEX-pakett installitud ja üles ehitatud?
APEX-pakett on lihtne zip-arhiiv (nagu APK), mille saab installida meie käepärane ADB (praegusel arenduse hetkel) ja hiljem kasutaja ise paketihalduri kaudu (nt Google Play või käsitsi Androidi paketi kaudu paigaldaja).
ZIP-paigutus on järgmine:
Sukeldume sellesse.
Apex_manifest.json määrab paketi nime ja versiooni.
Apex_payload.img on mikro-failisüsteemi kujutis (vormindatud kui EXT4).
Teised failid on osa paketi installimiseks kasutatavast kinnitusprotsessist. Vaatame.
Juuresolekul AndroidManifest.xml, isegi kui seda kasutatakse peamiselt rakendustes, aitab see meil mõista, et enamikku standardse APK installimiseks kasutatud juurutusest kasutatakse uuesti isegi nende pakettide jaoks. Tegelikult kontrollitakse nende eristamiseks ainult laiendit.
The META-INF/ kataloogil on paketisertifikaat ja see kasutab sama mehhanismi nagu tavalised APK-d. Nii need paketid enne, kui kasutajal lubatakse värskendust installida, kontrollib privaat-/avalik võtmepaar käitusajal. Kuid Google'ile sellest ei piisanud, nii et nad lisasid veel 2 turvakihti. Nad kasutavad pildi terviklikkuse kontrollimiseks funktsiooni dm-verity ja AVB (Android Verified Boot) kinnitusi, et veenduda, et pilt pärineb usaldusväärsest allikast. Halvimal juhul lükatakse APEXi pakett tagasi.
Kui kõik kinnitustoimingud on edukad, märgitakse pilt kehtivaks ja see asendab järgmisel taaskäivitamisel süsteemi variandi.
Kuidas pilt alglaadimisel installitakse?
Alustuseks vaatame minu seadmesse (emulaatorisse) praegu installitud APEX-e.
Nagu näete, on eelinstallitud paketid salvestatud kausta /system/apex/ ja kõik need on praegu versioonis 1. Aga mis juhtub, kui APEX on aktiveeritud? Näitena kasutame taas aadressi com.android.tzdata.
Taaskäivitame seadme ja analüüsime logcati.
Esimesed 2 rida annavad piisavalt teavet, et mõista paki päritolu ja selle asukohta installitud: /apex/, Android Q-s kasutusele võetud uus kataloog, mida kasutatakse aktiveeritud andmete salvestamiseks paketid.
Pärast paketi edukat kontrollimist AVB-ga ja avaliku võtme ühtimist ühendatakse APEX silmusseadme abil kausta /dev/block/loop0, muutes EXT4-failisüsteemi süsteemile juurdepääsetavaks. Silmusseade on pseudoseade, mis muudab faili juurdepääsetavaks plokkseadmena, muutes selle faili sisu juurdepääsetavaks ühenduspunktina.
Praegusel hetkel ei kasutata APEX-i ikka veel @1 järelliide tõttu (mis näitab paketi versiooni). Et anda süsteemile lõpuks teada, et meie pakett on edukalt aktiveeritud, ühendatakse see failiga /apex/com.android.tzdata, kus Android ootab aktiivselt tzdata toimimist. Sideühendus katab olemasoleva kataloogi või faili teise punkti all. [1]
APEX-i rakendamine sisaldub täielikult ühes AOSP-i hoidlas. [2] Apexd (APEX deemon) kataloogis on kood, mis töötab Androidis. Apexeri kataloogis on kood, mida ehitussüsteem kasutab APEX-pakettide loomiseks.
Mis on eesmärk?
Praegu ei jää muud üle, kui oletada. Minu parim oletus on, et Google üritab luua APEX-pakettide põhikomplekti, mida Google saab värskendada, et luua Androidi ühtne põhituum, mida jagavad tarnijad, mis teeb võimalikuks ainult süsteemivärskendused, kuid kasutab ühte paketti uuendused.
Kas kõik seadmed toetavad APEX-i?
Ei. Näiteks nõuab apexd, et kõigi Androidi moodulite värskendamiseks oleks /data/apex saadaval kohe pärast käivitamist. FDE (täisketta krüptimise) abil krüpteeritakse /data/apex, kuni kasutaja seadme lukustab, muutes APEXi põhimõtteliselt kasutuks, kuna alglaadimisel laaditakse ainult süsteemi APEX-i variandid. Peale selle peaksid kõik seadmed toetama APEX-i, kuid neil on vaja mõnda tuumaparandust (millest paljud on Google'i silmusseadmetega mängimise ajal leitud parandused). [3] [4]
Allikad [0], [1], [2], [3], [4]