APEX u Androidu P: Najveća stvar od Project Treble?

Implementacija APEX-a vjerojatno je najveća glavobolja s kojom se Google suočio od uvođenja Project Treble. Što je APEX i kako će njegovo uvođenje promijeniti Android?

Ideja koja stoji iza APEX-a sama po sebi prilično je uobičajena u svakodnevnim distribucijama GNU/Linuxa: ažuriranja paketa koja ciljaju na određene odjeljke skupa biblioteka Linuxa. Ali to je nešto što Google nikada nije pokušao učiniti s obzirom da je Android koristio RO (samo za čitanje) particiju gdje su sve sistemske biblioteke i okviri se pohranjuju u odnosu na uobičajene RW (čitanje i pisanje) particije koje se koriste u većini distribucija Linuxa, renderirajući standardni proces nadogradnje neprikladna.

Biblioteke su unaprijed kompilirani kod koji se može koristiti u drugim programima. Uobičajeno korištene metode mogu se pretvoriti u biblioteke za pozivanje Android aplikacija, čime se smanjuje veličina APK-ova jer se isti kôd neće morati ponovno implementirati u više aplikacija. Mnoge unaprijed instalirane sistemske biblioteke možete pronaći u direktorijima /system/lib i /system/lib64. Biblioteke sustava Android obično se ne ažuriraju pojedinačno—naprotiv, ažuriraju se kao dio nadogradnje Android platformi putem OTA ažuriranja. S druge strane, biblioteke u distribucijama Linuxa mogu se ažurirati pojedinačno. S uvođenjem APEX-a, sistemske biblioteke u Androidu mogu se ažurirati pojedinačno poput Android aplikacija. Glavna prednost ovoga je da će programeri aplikacija moći iskoristiti prednosti ažuriranih biblioteka bez čekanja da OEM uvede potpunu nadogradnju sustava. Uronimo u više tehničkih detalja o tome kako APEX radi.

Kako će APEX promijeniti način ažuriranja biblioteka?

APEX je ekosustav koji je prisilio (ili bolje rečeno, prisiljava) Google da preispita način na koji Android učitava sve biblioteke i datoteke s nestandardne particije različite od /system.

Prije svega, moramo navesti razliku između zajedničke knjižnice i statične knjižnice. Dijeljena biblioteka je biblioteka (obično datoteka imena libkind.so) koja ne uključuje sav kod potreban za pokretanje sama po sebi, ali je zapravo "povezana" s drugim bibliotekama pružajući kod, dok je statična biblioteka, kao što možete pretpostaviti, biblioteka koja ne ovisi o drugim bibliotekama i ima sve statički uključeno unutar datoteka.

Android je povijesno konfigurirao put knjižnice (poznat kao LD_LIBRARY_PATH u svijetu Linuxa) s jednom datotekom zove se ld.config.txt [0] za konfiguriranje dopuštenih staza pretraživanja za dijeljene biblioteke koje su potrebne bilo binarnom ili drugom knjižnica. Ove su staze tvrdo kodirane u konfiguraciji i ne mogu se proširiti. Ovaj raspored, uključujući sistemsku particiju samo za čitanje, vodi do biblioteka koje se ne mogu ažurirati osim ako korisnik ne instalira OTA Android ažuriranje. Google je riješio ovaj problem dopuštajući proširenje putanje pretraživanja dopuštajući pojedinačnim APEX paketima da daju vlastiti ld.config.txt koji uključuje dodatne (i ažurirane) staze knjižnica sadržane u njima.

Iako je ovaj potez riješio jedan od glavnih problema, bilo je još nekoliko ozbiljnih problema koje je trebalo prevladati. Prije svega: ABI (binarno sučelje aplikacije) stabilnost. Knjižnice bi uvijek trebale izvesti stabilan skup sučelja kako bi omogućile drugim aplikacijama i bibliotekama da nastave raditi s istim protokolom čak i s nadograđenom bibliotekom. Google aktivno radi na tome pokušavajući stvoriti stabilno C sučelje između APEXed biblioteka.

Ali APEX nije ograničen samo na biblioteke i binarne datoteke. Zapravo, može sadržavati konfiguracijske datoteke, ažuriranja vremenske zone i neke Java okvire (konskriptirati u vrijeme pisanja).

Evo nekoliko primjera trenutnih APEX paketa koje nudi AOSP:

• com.android.runtime: ART i bionic runtime (binarne datoteke i biblioteke)
• com.android.tzdata: Vremenska zona i ICU podaci (biblioteke i konfiguracijski podaci)
• com.android.resolv: Biblioteka koju koristi Android za rješavanje zahtjeva povezanih s mrežom (biblioteke)
• com.android.conscrypt: Java Security Provider (Java framework)

Kako se instalira i strukturira APEX paket?

APEX paket je jednostavna zip arhiva (poput APK-a) koju može instalirati naš praktični ADB (u ovoj fazi razvoja) a kasnije i sami korisnici putem upravitelja paketa (kao što je Google Play ili ručno putem Android paketa instalater).

ZIP izgled je sljedeći:

Zaronimo u to.

Apex_manifest.json navodi naziv i verziju paketa.

Apex_payload.img je slika mikro-datotečnog sustava (formatirana kao EXT4).

Ostale datoteke dio su postupka provjere koji se koristi za instalaciju paketa. Pogledajmo.

Prisutnost AndroidManifest.xml, čak i ako se koristi uglavnom u aplikacijama, pomaže nam shvatiti da se većina implementacije koja se koristi za standardnu ​​instalaciju APK-a ponovno koristi čak i za ove pakete. Zapravo, samo se ekstenzija provjerava kako bi se razlikovali.

The META-INF/ imenik ima certifikat paketa i koristi isti mehanizam kao normalni APK-ovi. Dakle, ovi paketi provjeravaju se parom privatnih/javnih ključeva tijekom izvođenja prije nego što korisniku bude dopušteno instalirati ažuriranje. Ali Googleu to nije bilo dovoljno, pa su dodali još 2 sloja sigurnosti. Koriste dm-verity za provjeru integriteta slike i AVB (Android Verified Boot) provjere kako bi bili sigurni da slika dolazi iz pouzdanog izvora. U najgorem slučaju, APEX paket će biti odbijen.

Ako su svi koraci provjere uspješni, slika će biti označena kao važeća i zamijenit će varijantu sustava pri sljedećem ponovnom pokretanju.

Kako se slika instalira pri pokretanju?

Započnimo s pogledom na APEX-ove koji su trenutno instalirani na mom uređaju (emulator)

Kao što vidite, unaprijed instalirani paketi pohranjeni su u /system/apex/ i svi su trenutno na verziji broj 1. Ali što se događa kada se aktivira APEX? Ponovno ćemo koristiti com.android.tzdata kao primjer.

Ponovno pokrenimo uređaj i analizirajmo logcat.

Prva 2 retka pružaju dovoljno informacija za razumijevanje podrijetla paketa i gdje će biti instalirano: /apex/, novi direktorij predstavljen u Androidu Q koji će se koristiti za pohranjivanje aktiviranih paketi.

Nakon što je paket uspješno provjeren s AVB-om i javni ključ se podudara, APEX se pomoću uređaja petlje montira na /dev/block/loop0, čineći EXT4 datotečni sustav dostupnim sustavu. Uređaj petlje je pseudo-uređaj koji datoteku čini dostupnom kao blok uređaj, čineći sadržaj te datoteke dostupnim kao točka montiranja.

U ovom se trenutku APEX još uvijek ne koristi zbog sufiksa @1 (koji označava verziju paketa). Kako bismo konačno obavijestili sustav da je naš paket uspješno aktiviran, bit će povezan na /apex/com.android.tzdata gdje Android aktivno očekuje da tzdata živi. Montiranje vezanja prekriva postojeći direktorij ili datoteku pod drugom točkom. [1]

Implementacija APEX-a u potpunosti je sadržana u jednom repozitoriju pod AOSP-om. [2] Apexd (APEX daemon) direktorij ima kod koji se izvodi na Androidu. Apexer direktorij ima kod koji koristi sustav za izradu za stvaranje APEX paketa.

Koja je svrha?

U ovom trenutku, sve što mogu učiniti je nagađati. Moja je najbolja pretpostavka da Google pokušava stvoriti temeljni skup APEX paketa koje Google može ažurirati kako bi mogao stvoriti unificirana osnovna jezgra Androida koju dijele dobavljači, čime su moguća samo ažuriranja "sustava", ali korištenjem jednog paketa nadopune.

Hoće li svi uređaji podržavati APEX?

Ne. Na primjer, apexd zahtijeva da /data/apex bude dostupan odmah nakon pokretanja za ažuriranje svih Android modula. Uz FDE (Full-disk Encryption), /data/apex je šifriran dok korisnik ne otključa uređaj, čineći APEX u osnovi beskorisnim jer će se samo varijante APEX-a sustava učitavati pri pokretanju. Osim toga, svi bi uređaji trebali podržavati APEX, ali trebaju nekoliko zakrpa kernela (od kojih su mnoge popravke koje je Google pronašao dok se igrao s uređajima u petlji). [3] [4]

---

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