APEX „Android“ Kl.: didžiausias dalykas po projekto „Treble“?

APEX diegimas yra bene didžiausias galvos skausmas, su kuriuo Google susidūrė nuo projekto Treble pristatymo. Kas yra APEX ir kaip jo įvedimas pakeis „Android“?

Pati APEX idėja yra gana įprasta kasdieniuose GNU/Linux platinimuose: paketų atnaujinimai, skirti konkrečioms Linux bibliotekos rinkinio sekcijoms. Tačiau to „Google“ niekada nebandė padaryti, nes „Android“ naudojo RO (tik skaitymo) skaidinį, kuriame visos sistemos bibliotekos ir Framos yra saugomos, palyginti su įprastais RW (skaitymo ir rašymo) skaidiniais, naudojamais daugumoje „Linux“ paskirstymų, todėl standartinis atnaujinimo procesas netinkamas.

Bibliotekos yra iš anksto sukompiliuotas kodas, kurį galima naudoti kitose programose. Įprastus metodus galima paversti bibliotekomis, kurias galima iškviesti „Android“ programoms, sumažinant APK dydį, nes to paties kodo nereikės iš naujo įdiegti keliose programose. Daugelį iš anksto įdiegtų sistemos bibliotekų galite rasti /system/lib ir /system/lib64 kataloguose. „Android“ sistemos bibliotekos paprastai nėra atnaujinamos atskirai – veikiau jos atnaujinamos atnaujinant „Android“ platformas naudojant OTA naujinimą. Kita vertus, bibliotekos Linux distribucijose gali būti atnaujinamos atskirai. Įdiegus APEX, sistemos bibliotekos „Android“ gali būti atnaujinamos atskirai, kaip ir „Android“ programos. Pagrindinis privalumas yra tas, kad programų kūrėjai galės pasinaudoti atnaujintų bibliotekų pranašumais nelaukdami, kol OĮG įdiegs visą sistemos naujinimą. Pasinerkime į daugiau techninės informacijos apie tai, kaip veikia APEX.

Kaip APEX pakeis bibliotekų atnaujinimo būdą?

APEX yra ekosistema, kuri privertė (tiksliau, verčia) „Google“ persvarstyti, kaip „Android“ įkelia visas bibliotekas ir failus iš nestandartinio skaidinio, kuris skiriasi nuo /system.

Visų pirma, turime nurodyti skirtumą tarp bendrinamos bibliotekos ir statinės bibliotekos. Bendrinama biblioteka yra biblioteka (dažniausiai failas, pavadintas libkind.so), kuri neapima viso kodo, reikalingo pačiam paleisti, bet yra „susieta“ su kitomis bibliotekomis. pateikiant kodą, o statinė biblioteka, kaip galite atspėti, yra biblioteka, kuri nepriklauso nuo jokių kitų bibliotekų ir kurioje viskas statiškai įtraukta į failą.

„Android“ istoriškai sukonfigūravo bibliotekos kelią (žinoma kaip LD_LIBRARY_PATH Linux pasaulyje) su vienu failu vadinamas ld.config.txt [0], kad sukonfigūruotų leistinus bendrinamų bibliotekų paieškos kelius, kurių reikia dvejetainei ar kitai biblioteka. Šie keliai yra užkoduoti konfigūracijoje ir jų negalima išplėsti. Šis išdėstymas, įskaitant tik skaitomą sistemos skaidinį, veda į bibliotekas, kurių negalima atnaujinti, nebent vartotojas įdiegtų OTA Android naujinimą. „Google“ ištaisė šią problemą, leisdama išplėsti paieškos kelią, leisdama atskiriems APEX paketams pateikti savo ld.config.txt failą, kuriame yra papildomų (ir atnaujintų) bibliotekų keliai.

Nors šiuo žingsniu buvo išspręsta viena iš pagrindinių problemų, vis tiek reikėjo įveikti keletą rimtų problemų. Visų pirma: ABI (application binary interface) stabilumas. Bibliotekos visada turėtų eksportuoti stabilų sąsajų rinkinį, kad kitos programos ir bibliotekos galėtų toliau dirbti su tuo pačiu protokolu net ir su atnaujinta biblioteka. „Google“ aktyviai dirba su tuo, bandydama sukurti stabilią C sąsają tarp APEX bibliotekų.

Tačiau APEX neapsiriboja vien bibliotekomis ir dvejetainiais failais. Tiesą sakant, jame gali būti konfigūracijos failų, laiko juostos atnaujinimų ir kai kurių „Java“ sistemų (sušifruoti rašant).

Štai keli dabartinių AOSP teikiamų APEX paketų pavyzdžiai:

• com.android.runtime: ART ir bionic runtime (dvejetainės ir bibliotekos)
• com.android.tzdata: laiko juostos ir ICU duomenys (bibliotekos ir konfigūracijos duomenys)
• com.android.resolv: biblioteka, kurią „Android“ naudoja su tinklu susijusioms užklausoms (bibliotekoms) išspręsti
• com.android.conscrypt: „Java“ saugos teikėjas („Java“ sistema)

Kaip įdiegiamas ir struktūrizuotas APEX paketas?

APEX paketas yra paprastas ZIP archyvas (kaip APK), kurį gali įdiegti mūsų patogus ADB (šiuo kūrimo momentu) o vėliau pats vartotojas per paketų tvarkyklę (pvz., „Google Play“ arba rankiniu būdu per „Android“ paketą). montuotojas).

ZIP išdėstymas yra toks:

Pasinerkime į tai.

Apex_manifest.json nurodo paketo pavadinimą ir versiją.

Apex_payload.img yra mikro failų sistemos vaizdas (suformatuotas kaip EXT4).

Kiti failai yra tikrinimo proceso, naudojamo paketui įdiegti, dalis. Pažiūrėkime.

Buvimas AndroidManifest.xml, net jei jis daugiausia naudojamas programose, padeda mums suprasti, kad dauguma standartiniam APK diegimui naudojamų diegimų yra pakartotinai naudojami net ir šiems paketams. Tiesą sakant, tikrinamas tik plėtinys, kad būtų galima juos atskirti.

The META-INF/ katalogas turi paketo sertifikatą ir naudoja tą patį mechanizmą kaip ir įprasti APK. Taigi šios pakuotės Prieš vartotojui leidžiant įdiegti naujinimą, juos patikrina privataus/viešojo raktų pora vykdymo metu. Tačiau „Google“ to nepakako, todėl jie pridėjo dar 2 saugumo lygius. Jie naudoja dm-verity, kad patikrintų vaizdo vientisumą ir AVB („Android Verified Boot“) patvirtinimus, kad įsitikintų, jog vaizdas yra iš patikimo šaltinio. Blogiausiu atveju APEX paketas bus atmestas.

Jei visi patvirtinimo veiksmai bus sėkmingi, vaizdas bus pažymėtas kaip galiojantis ir kitą kartą paleidžiant iš naujo pakeis sistemos variantą.

Kaip vaizdas įdiegiamas paleidžiant?

Pradėkime nuo APEX, šiuo metu įdiegtų mano įrenginyje (emuliatoriuje)

Kaip matote, iš anksto įdiegti paketai yra saugomi /system/apex/ ir šiuo metu jų visų versija yra 1. Bet kas atsitinka, kai suaktyvinamas APEX? Kaip pavyzdį vėl naudosime com.android.tzdata.

Perkraukite įrenginį ir išanalizuokime logcat.

Pirmosiose 2 eilutėse pateikiama pakankamai informacijos, kad suprastumėte pakuotės kilmę ir kur ji bus įdiegtas: /apex/, naujas „Android Q“ katalogas, kuris bus naudojamas aktyvuotam saugojimui paketus.

Kai paketas sėkmingai patikrintas naudojant AVB ir viešasis raktas sutampa, APEX sujungiamas naudojant kilpos įrenginį į /dev/block/loop0, todėl EXT4 failų sistema tampa prieinama sistemai. Ciklinis įrenginys yra pseudo įrenginys, leidžiantis failą pasiekti kaip blokinį įrenginį, todėl to failo turinys pasiekiamas kaip prijungimo taškas.

Šiuo metu APEX vis dar nenaudojamas dėl @1 priesagos (kuris nurodo paketo versiją). Kad pagaliau sistema žinotų, kad mūsų paketas buvo sėkmingai suaktyvintas, jis bus prijungtas prie /apex/com.android.tzdata, kuriame „Android“ aktyviai tikisi, kad „tzdata“ veiks. Susiejimo prijungimas perdengia esamą katalogą arba failą kitu tašku. [1]

APEX diegimas yra visiškai vienoje AOSP saugykloje. [2] Apexd (APEX demono) kataloge yra kodas, veikiantis „Android“. Apexer kataloge yra kodas, kurį naudoja kūrimo sistema APEX paketams kurti.

Koks tikslas?

Šiuo metu viskas, ką galiu padaryti, yra spėlioti. Mano geriausias spėjimas, kad „Google“ bando sukurti pagrindinį APEX paketų rinkinį, kurį „Google“ gali atnaujinti, kad galėtų sukurti vieningas bazinis „Android“ branduolys, dalijamas tarp pardavėjų, leidžiantis atnaujinti tik „sistemą“, tačiau naudojant vieną paketą atnaujinimus.

Ar visi įrenginiai palaikys APEX?

Ne. Pavyzdžiui, norint atnaujinti visus Android modulius, apexd reikalauja, kad /data/apex būtų pasiekiamas iškart po įkrovos. Naudojant FDE (viso disko šifravimą), / data/apex yra šifruojamas tol, kol vartotojas atrakina įrenginį, todėl APEX iš esmės tampa nenaudingas, nes paleidžiant bus įkeliami tik sistemos APEX variantai. Išskyrus tai, visi įrenginiai turėtų palaikyti APEX, tačiau jiems reikia kelių branduolio pataisų (daugelį jų pataisė „Google“ žaidžiant su kilpiniais įrenginiais). [3] [4]

---

Šaltiniai [0], [1], [2], [3], [4]