APEX az Androidban K: A legnagyobb dolog a Project Treble óta?

Az APEX megvalósítása valószínűleg a legnagyobb fejtörés, amellyel a Google szembesült a Project Treble bevezetése óta. Mi az APEX, és hogyan változtatja meg bevezetése az Androidot?

Az APEX mögött meghúzódó ötlet önmagában meglehetősen gyakori a mindennapi GNU/Linux disztribúciókban: a csomagfrissítések a Linux könyvtárkészlet bizonyos részeit célozzák meg. De ezt a Google soha nem próbálta megtenni, mivel az Android RO (csak olvasható) partíciót használt, ahol az összes rendszerkönyvtár és A keretrendszerek tárolása a legtöbb Linux disztribúcióban használt szokásos RW (írható-olvasó) partíciókkal szemben, a szabványos frissítési folyamatot eredményezve alkalmatlan.

A könyvtárak előre lefordított kódok, amelyek más programokban is használhatók. Az általánosan használt módszerek könyvtárakká alakíthatók az Android-alkalmazások meghívásához, csökkentve az APK-k méretét, mivel ugyanazt a kódot nem kell újra implementálni több alkalmazásban. Számos előre telepített rendszerkönyvtár található a /system/lib és a /system/lib64 könyvtárban. Az Android rendszerkönyvtárak általában nem egyenként frissülnek, hanem az Android platformok frissítésének részeként OTA frissítésen keresztül. Másrészt a Linux disztribúciók könyvtárai egyenként is frissíthetők. Az APEX bevezetésével az Android rendszerkönyvtárai egyenként frissíthetők, mint az Android-alkalmazások. Ennek fő előnye, hogy az alkalmazásfejlesztők kihasználhatják a frissített könyvtárak előnyeit anélkül, hogy megvárnák az OEM-től a teljes rendszerfrissítést. Merüljünk el részletesebben az APEX működéséről.

Hogyan változtatja meg az APEX a könyvtárak frissítésének módját?

Az APEX egy olyan ökoszisztéma, amely arra kényszerítette (vagy inkább kényszeríti) a Google-t, hogy újragondolja, hogyan tölti be az Android az összes könyvtárat és fájlt a /system partíciótól eltérő, nem szabványos partícióról.

Először is meg kell határoznunk a különbséget a megosztott könyvtár és a statikus könyvtár között. A megosztott könyvtár egy olyan könyvtár (általában egy libkind.so nevű fájl), amely önmagában nem tartalmazza a futtatáshoz szükséges összes kódot, de valójában más könyvtárakhoz van „kapcsolva”. megadja a kódot, míg a statikus könyvtár, ahogy sejthető, egy olyan könyvtár, amely nem függ semmilyen más könyvtártól, és mindent statikusan tartalmaz fájlt.

Az Android hagyományosan egyetlen fájllal konfigurálta a könyvtár elérési útját (a Linux világában LD_LIBRARY_PATH néven ismert) az ld.config.txt [0] nevű fájl a bináris vagy más könyvtárak számára szükséges megosztott könyvtárak engedélyezett keresési útvonalainak konfigurálásához könyvtár. Ezek az útvonalak a konfigurációban vannak kódolva, és nem bővíthetők. Ez az elrendezés, beleértve a csak olvasható rendszerpartíciót is, nem frissíthető könyvtárakat eredményez, hacsak a felhasználó nem telepít egy OTA Android-frissítést. A Google kijavította ezt a problémát, lehetővé téve a keresési útvonal kiterjesztését azáltal, hogy az egyes APEX-csomagok biztosítják a saját ld.config.txt fájljukat, amely tartalmazza a bennük lévő extra (és frissített) könyvtári útvonalakat.

Bár ez a lépés megoldotta az egyik fő problémát, még mindig volt néhány komoly probléma, amelyet le kellett küzdeni. Először is: ABI (application binary interface) stabilitás. A könyvtáraknak mindig stabil interfészkészletet kell exportálniuk, hogy más alkalmazások és könyvtárak továbbra is ugyanazzal a protokollal működhessenek, még a frissített könyvtár mellett is. A Google aktívan dolgozik ezen azáltal, hogy megpróbál egy stabil C interfészt létrehozni az APEX-alapú könyvtárak között.

De az APEX nem korlátozódik csak a könyvtárakra és a bináris fájlokra. Valójában konfigurációs fájlokat, időzóna-frissítéseket és néhány Java-keretrendszert (conscrypt az írás idején) tartalmazhat.

Íme néhány példa az AOSP által biztosított jelenlegi APEX csomagokra:

• com.android.runtime: ART és bionikus futtatókörnyezet (binárisok és könyvtárak)
• com.android.tzdata: TimeZone és ICU adatok (könyvtárak és konfigurációs adatok)
• com.android.resolv: Az Android által a hálózattal kapcsolatos kérések (könyvtárak) megoldására használt könyvtár
• com.android.conscrypt: Java biztonsági szolgáltató (Java keretrendszer)

Hogyan történik az APEX csomag telepítése és felépítése?

Az APEX-csomag egy egyszerű zip-archívum (mint egy APK), amelyet a praktikus ADB-nk telepíthet (a fejlesztés ezen pontján). később pedig maga a felhasználó egy csomagkezelőn keresztül (például a Google Playen vagy manuálisan az Android csomagon keresztül). telepítő).

A ZIP elrendezés a következő:

Merüljünk el ebbe.

Az apex_manifest.json a csomag nevét és verzióját határozza meg.

Az apex_payload.img egy mikrofájlrendszer-kép (EXT4 formátumban).

A többi fájl a csomag telepítéséhez használt ellenőrzési folyamat részét képezi. Nézzük meg.

Jelenléte AndroidManifest.xml, még ha főleg alkalmazásokban használják is, segít megértenünk, hogy a szabványos APK-telepítésekhez használt implementáció nagy részét még ezeknél a csomagoknál is újra felhasználjuk. Valójában csak a kiterjesztést ellenőrzik a különbségtétel érdekében.

A META-INF/ könyvtár rendelkezik a csomagtanúsítvánnyal, és ugyanazt a mechanizmust használja, mint a normál APK-k. Szóval ezek a csomagok egy privát/nyilvános kulcspár ellenőrzi futás közben, mielőtt a felhasználó telepíthetne egy frissítést. De ez nem volt elég a Google-nek, így további 2 biztonsági réteget adtak hozzá. A dm-verity segítségével ellenőrzik a kép integritását, és AVB (Android Verified Boot) ellenőrzéseket használnak, hogy megbizonyosodjanak arról, hogy a kép megbízható forrásból származik. A legrosszabb esetben az APEX csomag elutasításra kerül.

Ha az összes ellenőrzési lépés sikeres, a rendszer érvényesnek jelöli a képfájlt, és a következő újraindításkor lecseréli a rendszerváltozatot.

Hogyan történik a kép telepítése rendszerindításkor?

Kezdjük azzal, hogy vessünk egy pillantást az eszközömre (egy emulátorra) jelenleg telepített APEX-ekre.

Mint látható, az előre telepített csomagok a /system/apex/ könyvtárban vannak tárolva, és jelenleg mindegyik az 1-es verziószámú. De mi történik, ha egy APEX aktiválódik? Ismét a com.android.tzdata címet használjuk példaként.

Indítsuk újra az eszközt, és elemezzük a logcat-et.

Az első 2 sor elegendő információval szolgál a csomag eredetének és helyének megértéséhez telepítve: /apex/, az Android Q-ban bevezetett új könyvtár, amely az aktivált elemek tárolására szolgál csomagokat.

Miután a csomagot sikeresen ellenőrizték az AVB-vel, és a nyilvános kulcs megegyezik, az APEX egy hurokeszközzel felcsatolásra kerül a /dev/block/loop0 könyvtárba, így az EXT4 fájlrendszer elérhetővé válik a rendszer számára. A hurokeszköz egy pszeudoeszköz, amely blokkeszközként teszi elérhetővé a fájlt, így a fájl tartalma elérhetővé válik csatolási pontként.

Ezen a ponton az APEX még mindig nem használatos a @1 utótag miatt (ez a csomag verzióját jelzi). Hogy végre tudathassuk a rendszerrel, hogy csomagunkat sikeresen aktiváltuk, a /apex/com.android.tzdata fájlhoz kötéssel csatoljuk, ahol az Android aktívan várja a tzdata működését. A kötési beillesztés egy meglévő könyvtárat vagy fájlt fed le egy másik pont alatt. [1]

Az APEX megvalósítása teljes egészében egyetlen tárolóban található az AOSP alatt. [2] Az apexd (APEX démon) könyvtárban a kód fut Androidon. Az apexer könyvtár tartalmazza az összeállítási rendszer által az APEX csomagok létrehozásához használt kódot.

mi a célja?

Ezen a ponton nem tudok mást tenni, mint találgatni. A legjobb tippem az, hogy a Google megpróbál létrehozni egy alapvető APEX-csomagot, amelyet a Google frissíthet, hogy esetleg létrehozhasson a gyártók között megosztott Android egységes alapmag, amely csak a „rendszer” frissítését teszi lehetővé, de egyetlen csomag használatával frissítéseket.

Minden eszköz támogatni fogja az APEX-et?

Nem. Például az apexd megköveteli, hogy a /data/apex közvetlenül a rendszerindítás után elérhető legyen az összes Android-modul frissítéséhez. Az FDE (Full-disk Encryption) használatával a /data/apex mindaddig titkosítva van, amíg a felhasználó fel nem oldja az eszköz zárolását, ami gyakorlatilag használhatatlanná teszi az APEX-et, mivel rendszerindításkor csak a rendszer APEX-változatai töltődnek be. Ettől eltekintve minden eszköznek támogatnia kell az APEX-et, de szükségük van néhány kerneljavításra (amelyek közül sok olyan javítás, amelyet a Google talált, miközben hurokeszközökkel játszik). [3] [4]

---

Források [0], [1], [2], [3], [4]