APEX Androidissa K: Suurin asia sitten Project Treblen?

APEXin käyttöönotto on luultavasti suurin päänsärky, jonka Google on kohdannut Treble-projektin käyttöönoton jälkeen. Mikä on APEX, ja miten sen käyttöönotto muuttaa Androidia?

APEXin taustalla oleva ajatus itsessään on melko yleinen jokapäiväisissä GNU/Linux-jakeluissa: pakettipäivitykset, jotka kohdistuvat Linux-kirjastojoukon tiettyihin osiin. Mutta sitä Google ei koskaan yrittänyt tehdä, koska Android on käyttänyt RO-osiota (vain luku), jossa kaikki järjestelmäkirjastot ja puitteet tallennetaan verrattuna tavallisiin RW-osioihin (read-write), joita käytetään useimmissa Linux-jakeluissa, mikä tekee tavallisesta päivitysprosessista sopimaton.

Kirjastot ovat esikäännettyä koodia, jota voidaan käyttää muissa ohjelmissa. Yleisesti käytetyistä menetelmistä voidaan tehdä kirjastoja, joita Android-sovellukset voivat kutsua, mikä pienentää APK: iden kokoa, koska samaa koodia ei tarvitse ottaa uudelleen käyttöön useissa sovelluksissa. Löydät monia esiasennettuja järjestelmäkirjastoja /system/lib- ja /system/lib64-hakemistoista. Android-järjestelmäkirjastoja ei yleensä päivitetä yksitellen, vaan ne päivitetään osana Android-alustojen päivityksiä OTA-päivityksen kautta. Toisaalta Linux-distrojen kirjastot voidaan päivittää yksitellen. APEXin käyttöönoton myötä Androidin järjestelmäkirjastoja voidaan päivittää yksitellen kuten Android-sovelluksia. Tämän tärkein etu on, että sovelluskehittäjät voivat hyödyntää päivitettyjä kirjastoja odottamatta OEM: n ottavan käyttöön täyden järjestelmäpäivityksen. Sukellaanpa teknisiin yksityiskohtiin APEXin toiminnasta.

Miten APEX muuttaa tapaa, jolla kirjastot päivitetään?

APEX on ekosysteemi, joka pakotti (tai pikemminkin pakottaa) Googlen harkitsemaan uudelleen tapaa, jolla Android lataa kaikki kirjastot ja tiedostot ei-standardista osiosta, joka eroaa /system-osiosta.

Ensinnäkin meidän on määritettävä ero jaetun kirjaston ja staattisen kirjaston välillä. Jaettu kirjasto on kirjasto (yleensä libkind.so-niminen tiedosto), joka ei sisällä kaikkea suorittamiseen tarvittavaa koodia itsessään, mutta joka on "linkitetty" muihin kirjastoihin. antaa koodin, kun taas staattinen kirjasto on, kuten voit arvata, kirjasto, joka ei ole riippuvainen muista kirjastoista ja joka sisältää kaiken staattisesti tiedosto.

Android on historiallisesti määrittänyt kirjastopolun (tunnetaan Linux-maailmassa nimellä LD_LIBRARY_PATH) yhdellä tiedostolla nimeltä ld.config.txt [0] määrittääkseen sallitut hakupolut jaetuille kirjastoille, joita binääri tai jokin muu tarvitsee kirjasto. Nämä polut on koodattu kokoonpanoon, eikä niitä voi laajentaa. Tämä asettelu, mukaan lukien vain luku -järjestelmäosio, johtaa kirjastoihin, joita ei voi päivittää, ellei käyttäjä asenna OTA Android -päivitystä. Google korjasi tämän ongelman mahdollistamalla hakupolun laajentamisen antamalla yksittäisten APEX-pakettien tarjota oman ld.config.txt-tiedoston, joka sisälsi niihin sisältyvät ylimääräiset (ja päivitetyt) kirjastopolut.

Vaikka tämä muutos korjasi yhden tärkeimmistä ongelmista, muutama vakava ongelma oli vielä ratkaistava. Ensinnäkin: ABI (Application binary interface) -vakaus. Kirjastojen tulee aina viedä vakaa joukko rajapintoja, jotta muut sovellukset ja kirjastot voivat jatkaa työskentelyä samalla protokollalla jopa päivitetyn kirjaston kanssa. Google työskentelee aktiivisesti tämän eteen yrittämällä luoda vakaan C-rajapinnan APEX-kirjastojen välille.

Mutta APEX ei rajoitu pelkästään kirjastoihin ja binääriin. Itse asiassa se voi sisältää määritystiedostoja, aikavyöhykepäivityksiä ja joitain Java-kehyksiä (conscrypt kirjoitushetkellä).

Tässä on muutamia esimerkkejä AOSP: n nykyisistä APEX-paketeista:

• com.android.runtime: ART ja bionic runtime (binäärit ja kirjastot)
• com.android.tzdata: Aikavyöhyke- ja ICU-tiedot (kirjastot ja määritystiedot)
• com.android.resolv: Androidin käyttämä kirjasto verkkoon liittyvien pyyntöjen (kirjastojen) ratkaisemiseen
• com.android.conscrypt: Java Security Provider (Java-kehys)

Miten APEX-paketti asennetaan ja rakennetaan?

APEX-paketti on yksinkertainen zip-arkisto (kuten APK), jonka kätevä ADB voi asentaa (tässä kehitysvaiheessa) ja myöhemmin käyttäjä itse paketinhallinnan kautta (kuten Google Play tai manuaalisesti Android-paketin kautta asennusohjelma).

ZIP-asettelu on seuraava:

Sukellaanpa siihen.

Apex_manifest.json määrittää paketin nimen ja version.

Apex_payload.img on mikrotiedostojärjestelmän kuva (muotoiltu muodossa EXT4).

Muut tiedostot ovat osa vahvistusprosessia, jota käytetään paketin asentamiseen. Katsotaan.

Läsnäolo AndroidManifest.xml, vaikka sitä käytetään pääasiassa sovelluksissa, auttaa meitä ymmärtämään, että suurin osa APK: n vakioasennuksessa käytetystä toteutuksesta käytetään uudelleen jopa näissä paketeissa. Itse asiassa vain laajennus tarkistetaan niiden erottamiseksi toisistaan.

The META-INF/ hakemistossa on pakettivarmenne ja se käyttää samaa mekanismia kuin tavalliset APK: t. Nämä paketit siis yksityisen/julkisen avainparin varmentaa ajon aikana ennen kuin käyttäjä saa asentaa päivityksen. Mutta se ei riittänyt Googlelle, joten he lisäsivät kaksi suojaustasoa. He käyttävät dm-verityä kuvan eheyden tarkistamiseen ja AVB (Android Verified Boot) -varmistuksia varmistaakseen, että kuva tulee luotettavasta lähteestä. Pahimmassa tapauksessa APEX-paketti hylätään.

Jos kaikki vahvistusvaiheet onnistuvat, kuva merkitään kelvolliseksi ja korvaa järjestelmäversion seuraavan uudelleenkäynnistyksen yhteydessä.

Miten kuva asennetaan käynnistyksen yhteydessä?

Aloitetaan katsomalla laitteelleni tällä hetkellä asennettuja APEX-tiedostoja (emulaattori).

Kuten näet, esiasennetut paketit on tallennettu kansioon /system/apex/ ja ne kaikki ovat tällä hetkellä versiossa 1. Mutta mitä tapahtuu, kun APEX aktivoidaan? Käytämme jälleen esimerkkinä tiedostoa com.android.tzdata.

Käynnistetään laite uudelleen ja analysoidaan logcat.

Ensimmäiset 2 riviä tarjoavat tarpeeksi tietoa paketin alkuperän ja sen sijainnin ymmärtämiseksi asennettu: /apex/, uusi Android Q: ssa esitelty hakemisto, jota käytetään aktivoitujen tallentamiseen paketteja.

Kun paketti on varmennettu onnistuneesti AVB: llä ja julkinen avain täsmää, APEX liitetään silmukkalaitteella hakemistoon /dev/block/loop0, jolloin EXT4-tiedostojärjestelmä on järjestelmän käytettävissä. Silmukkalaite on pseudolaite, joka mahdollistaa tiedoston käytön lohkolaitteena, jolloin tiedoston sisältö on käytettävissä liitoskohtana.

Tässä vaiheessa APEX-tunnusta ei vieläkään käytetä @1-liitteen vuoksi (joka ilmaisee paketin version). Jotta järjestelmä vihdoinkin tietäisi, että pakettimme on aktivoitu onnistuneesti, se liitetään tiedostoon /apex/com.android.tzdata, jossa Android odottaa aktiivisesti tzdatan toimivan. Sidosliitos peittää olemassa olevan hakemiston tai tiedoston eri pisteen alla. [1]

APEX-toteutus sisältyy kokonaan yhteen AOSP-tietovarastoon. [2] Apexd (APEX daemon) -hakemistossa koodi on käynnissä Androidissa. Apexer-hakemistossa on koodi, jota rakennusjärjestelmä käyttää APEX-pakettien luomiseen.

Mikä on tarkoitus?

Tässä vaiheessa en voi muuta kuin spekuloida. Paras arvaukseni on, että Google yrittää luoda ydinjoukon APEX-paketteja, jotka Google voi päivittää luodakseen Androidin yhtenäinen perusydin, joka jaetaan toimittajien kesken, mikä mahdollistaa vain "järjestelmän" päivitykset, mutta käyttämällä yhtä pakettia päivitykset.

Tukevatko kaikki laitteet APEXia?

Ei. Esimerkiksi apexd edellyttää, että /data/apex on käytettävissä heti käynnistyksen jälkeen, jotta kaikki Android-moduulit voidaan päivittää. FDE: llä (Full-disk Encryption) /data/apex salataan, kunnes käyttäjä avaa laitteen lukituksen, mikä tekee APEX: stä periaatteessa hyödyttömän, koska vain järjestelmän APEX-versiot ladataan käynnistyksen yhteydessä. Muuten kaikkien laitteiden pitäisi tukea APEX: iä, mutta ne tarvitsevat muutaman ytimen korjaustiedoston (joista monet ovat korjauksia, jotka Google löytää pelatessaan silmukkalaitteilla). [3] [4]

---

Lähteet [0], [1], [2], [3], [4]