Google werkt aan APEX: het updaten van systeembibliotheken zoals een standaard Linux-distributie. Verwacht in Android Q, APEX zou wel eens het grootste ding kunnen zijn sinds Project Treble.
Het implementeren van APEX is waarschijnlijk de grootste hoofdpijn waarmee Google te maken heeft gehad sinds de introductie van Project Treble. Wat is APEX en hoe zal de introductie Android veranderen?
Het idee achter APEX op zichzelf is vrij gebruikelijk in alledaagse GNU/Linux-distributies: pakketupdates die zich richten op specifieke secties van de Linux-bibliotheekset. Maar dat is iets wat Google nooit heeft geprobeerd, aangezien Android een RO-partitie (alleen-lezen) heeft gebruikt waar alle systeembibliotheken en frameworks worden opgeslagen versus de gebruikelijke RW-partities (lezen-schrijven) die in de meeste Linux-distributies worden gebruikt, waardoor het standaard upgradeproces wordt weergegeven ongeschikt.
Bibliotheken zijn vooraf gecompileerde code die in andere programma's kan worden gebruikt. Van veelgebruikte methoden kunnen bibliotheken worden gemaakt die Android-apps kunnen oproepen, waardoor de grootte van APK's wordt verkleind, omdat dezelfde code niet opnieuw in meerdere apps hoeft te worden geïmplementeerd. U kunt veel vooraf geïnstalleerde systeembibliotheken vinden in de mappen /system/lib en /system/lib64. Android-systeembibliotheken worden doorgaans niet afzonderlijk bijgewerkt, maar worden bijgewerkt als onderdeel van Android-platformupgrades via een OTA-update. Aan de andere kant kunnen bibliotheken in Linux-distributies afzonderlijk worden bijgewerkt. Met de introductie van APEX kunnen systeembibliotheken in Android individueel worden bijgewerkt, net als Android-apps. Het belangrijkste voordeel hiervan is dat app-ontwikkelaars kunnen profiteren van bijgewerkte bibliotheken zonder te hoeven wachten tot een OEM een volledige systeemupgrade heeft uitgerold. Laten we dieper ingaan op de technische details van hoe APEX werkt.
Hoe zal APEX de manier veranderen waarop bibliotheken worden bijgewerkt?
APEX is een ecosysteem dat Google dwong (of beter gezegd dwingt) om de manier te heroverwegen waarop Android alle bibliotheken en bestanden laadt van een niet-standaard partitie die verschilt van /system.
Allereerst moeten we het verschil specificeren tussen een gedeelde bibliotheek en een statische bibliotheek. Een gedeelde bibliotheek is een bibliotheek (meestal een bestand met de naam libkind.so) die niet alle code bevat die nodig is om op zichzelf te worden uitgevoerd, maar die feitelijk is “gekoppeld” aan andere bibliotheken het leveren van de code, terwijl een statische bibliotheek, zoals u kunt raden, een bibliotheek is die niet afhankelijk is van andere bibliotheken en alles statisch in de bibliotheek heeft opgenomen bestand.
Android heeft het bibliotheekpad (in de Linux-wereld bekend als LD_LIBRARY_PATH) historisch gezien geconfigureerd met één enkel bestand genaamd ld.config.txt [0] om de toegestane zoekpaden te configureren voor de gedeelde bibliotheken die nodig zijn voor binair of ander materiaal bibliotheek. Deze paden zijn hardgecodeerd in de configuratie en kunnen niet worden uitgebreid. Deze lay-out, inclusief de alleen-lezen systeempartitie, leidt tot niet-bijwerkbare bibliotheken, tenzij de gebruiker een OTA Android-update installeert. Google heeft dit probleem opgelost, waardoor het zoekpad kon worden uitgebreid door de afzonderlijke APEX-pakketten hun eigen ld.config.txt te laten leveren, inclusief de extra (en bijgewerkte) bibliothekenpaden die daarin zijn opgenomen.
Hoewel deze stap een van de belangrijkste problemen oploste, moesten er nog een aantal serieuze problemen worden overwonnen. Allereerst: ABI-stabiliteit (Application Binary Interface). Bibliotheken moeten altijd een stabiele set interfaces exporteren, zodat andere apps en bibliotheken met hetzelfde protocol kunnen blijven werken, zelfs met de geüpgradede bibliotheek. Google werkt daar actief aan door te proberen een stabiele C-interface tussen APEX-bibliotheken te creëren.
Maar een APEX beperkt zich niet alleen tot bibliotheken en binaire bestanden. Het kan zelfs configuratiebestanden, tijdzone-updates en sommige Java-frameworks bevatten (conscrypt op het moment van schrijven).
Hier zijn een paar voorbeelden van de huidige APEX-pakketten van AOSP:
- com.android.runtime: ART en bionische runtime (binaire bestanden en bibliotheken)
- com.android.tzdata: TimeZone- en ICU-gegevens (bibliotheken en configuratiegegevens)
- com.android.resolv: bibliotheek die door Android wordt gebruikt om netwerkgerelateerde verzoeken (bibliotheken) op te lossen
- com.android.conscrypt: een Java-beveiligingsprovider (Java-framework)
Hoe wordt een APEX-pakket geïnstalleerd en gestructureerd?
Een APEX-pakket is een eenvoudig zip-archief (zoals een APK) dat kan worden geïnstalleerd door onze handige ADB (op dit punt in ontwikkeling) en later door de gebruiker zelf via een pakketbeheerder (zoals Google Play of handmatig via het Android-pakket). installateur).
De ZIP-indeling is als volgt:
Laten we daar eens in duiken.
Apex_manifest.json specificeert de pakketnaam en -versie.
De apex_payload.img is een microbestandssysteemafbeelding (geformatteerd als EXT4).
De andere bestanden maken deel uit van het verificatieproces dat wordt gebruikt om het pakket te installeren. Laten we eens kijken.
De aanwezigheid van AndroidManifest.xml, ook al wordt het voornamelijk in applicaties gebruikt, helpt ons te begrijpen dat het grootste deel van de implementatie die voor een standaard APK-installatie wordt gebruikt, zelfs voor deze pakketten wordt hergebruikt. In feite wordt alleen de extensie gecontroleerd om onderscheid te maken tussen deze extensies.
De META-INF/ directory heeft het pakketcertificaat en gebruikt hetzelfde mechanisme als normale APK's. Deze pakketten dus worden tijdens runtime geverifieerd door een privé/openbaar sleutelpaar voordat de gebruiker een update mag installeren. Maar dat was niet genoeg voor Google, dus voegden ze nog twee beveiligingslagen toe. Ze gebruiken dm-verity om de integriteit van de afbeelding te controleren en AVB-verificaties (Android Verified Boot) om er zeker van te zijn dat de afbeelding afkomstig is van een vertrouwde bron. In het ergste geval zal het APEX-pakket worden afgewezen.
Als alle verificatiestappen succesvol zijn, wordt de afbeelding als geldig gemarkeerd en wordt de systeemvariant vervangen bij de volgende herstart.
Hoe wordt een image geïnstalleerd tijdens het opstarten?
Laten we beginnen met een kijkje te nemen naar de APEX’s die momenteel op mijn apparaat zijn geïnstalleerd (een emulator)
Zoals u kunt zien, zijn de vooraf geïnstalleerde pakketten opgeslagen in /system/apex/ en bevinden ze zich momenteel allemaal op versienummer 1. Maar wat gebeurt er als een APEX wordt geactiveerd? We zullen opnieuw com.android.tzdata als voorbeeld gebruiken.
Laten we het apparaat opnieuw opstarten en de logcat analyseren.
De eerste twee regels bieden voldoende informatie om te begrijpen waar het pakket vandaan komt en waar het naartoe gaat geïnstalleerd: /apex/, een nieuwe map geïntroduceerd in Android Q die zal worden gebruikt om de geactiveerde bestanden op te slaan pakketjes.
Nadat het pakket met succes is geverifieerd met AVB en de openbare sleutel overeenkomt, wordt de APEX met behulp van een lusapparaat aangekoppeld aan /dev/block/loop0, waardoor het EXT4-bestandssysteem toegankelijk wordt voor het systeem. Een loop device is een pseudo-apparaat dat een bestand toegankelijk maakt als blokapparaat, waardoor de inhoud van dat bestand toegankelijk wordt als koppelpunt.
Op dit moment wordt de APEX nog steeds niet gebruikt vanwege het achtervoegsel @1 (dat de pakketversie aangeeft). Om het systeem eindelijk te laten weten dat ons pakket met succes is geactiveerd, wordt het gekoppeld aan /apex/com.android.tzdata, waar Android actief verwacht dat tzdata zal leven. Een bind-mount overlapt een bestaande map of bestand onder een ander punt. [1]
De APEX-implementatie is volledig opgenomen in één enkele repository onder AOSP. [2] In de apexd-map (APEX-daemon) wordt de code op Android uitgevoerd. De apexer-map bevat de code die door het bouwsysteem wordt gebruikt om de APEX-pakketten te maken.
Wat is het doel?
Op dit moment kan ik alleen maar speculeren. Mijn beste gok is dat Google probeert een kernset van APEX-pakketten te maken die door Google kunnen worden bijgewerkt om mogelijk te maken een uniforme basiskern van Android die wordt gedeeld tussen leveranciers, waardoor alleen ‘systeem’-updates mogelijk zijn, maar met gebruik van één enkel pakket updates.
Gaan alle apparaten APEX ondersteunen?
Nee. Apexd vereist bijvoorbeeld dat /data/apex direct na het opstarten beschikbaar is om alle Android-modules bij te werken. Met FDE (Full-disk Encryption) wordt /data/apex gecodeerd totdat het apparaat door de gebruiker wordt ontgrendeld, waardoor APEX feitelijk onbruikbaar wordt omdat alleen de APEX-systeemvarianten bij het opstarten worden geladen. Verder zouden alle apparaten APEX moeten ondersteunen, maar ze hebben een paar kernelpatches nodig (waarvan vele oplossingen zijn die door Google zijn gevonden tijdens het spelen met loop-apparaten). [3] [4]
Bronnen [0], [1], [2], [3], [4]