Dynamiske systemoppdateringer i Android Sp.: Hvordan Project Treble vil forbedre fremtidige Android-versjoner

Ved siden av utgivelsen av Android 8.0 Oreo, avduket Google Prosjekt diskant: en stor ombygging i måten Android OS-rammeverket og leverandørens HAL-er og Linux-kjernen kommuniserer på. Treble er et stort initiativ designet for å redusere Android-plattformversjonen og fragmentering av sikkerhetsoppdateringer, og alle Android-merkede enheter som lanseres med Android Pie må støtte Project Treble. OEM-er og leverandører tester diskantkompatibilitet ved å starte opp et generisk systembilde (GSI) – en ren lagerbygging av Android fra AOSP – og bestå Leverandør Test Suite (VTS) og Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). GSI har vist seg nyttig for ikke bare å la programvareingeniører som jobber for OEM-er teste diskantkompatibilitet, men den har også åpnet døren for en stort tilpasset ROM-fellesskap på XDA. For Android Q-utgivelsen ønsker Google å gjøre GSI-er nyttige for en annen gruppe: apputviklere.

Siden den første stabile utgivelsen og kildekoden for en gitt Android-plattformutgivelse vanligvis kommer i august, utviklere som ønsker å teste den neste Android-utgivelsen på en ekte enhet, trenger vanligvis tilgang til en Google-smarttelefon hvis de ikke vil vente på at oppdateringen skal nå sin egen maskinvare. Imidlertid jobbet Google med OEM-er for å bringe en Android P beta til flere enheter i fjor, og det har de fulgt opp i år med en Android Q beta. Ved siden av en offisiell Android Q-beta, ga Google i år også ut en offisiell Q beta GSI slik at enhver utvikler med en Project Treble-kompatibel enhet kan installere den nyeste Q-utgivelsen uten å måtte vente i måneder på at bygget skal nå enhetene deres. Denne nye måten å teste neste Android-utgivelse på gir utviklere flere muligheter, og dermed mer tid, til å teste appene sine mot store endringer i Android.

Dessverre er dagens metode for installere en GSI kan være vanskelig. Det krever å låse opp oppstartslasteren – noe som betyr å slette alle brukerdata og/eller annullere garantien – og blinke et bilde via fastboot-protokollen. Det er ikke en rask og enkel prosess for en apputvikler å gjøre, hvis enheten deres lar til og med låse opp bootloaderen. Det er derfor, for de siste månedene, har Google jobbet med en ny måte å starte opp GSI-er. Skriv inn en ny funksjon kalt Dynamic System Update, eller DSU.

(Denne funksjonen ble tidligere utviklet under navnene «Live Image», «Dynamic Android» og «Android on Tap», så ikke bli overrasket om Google kaller det noe annet om noen uker eller måneder.)

Dynamiske systemoppdateringer i Android Q

Målet med DSU-funksjonen er å la en utvikler starte opp i en GSI uten å forstyrre gjeldende installasjon. Det betyr at oppstartslasteren ikke trenger å låses opp og brukerdataene ikke trenger å bli slettet. Installasjonsprosessen er også sterkt forenklet ettersom Google har levert et kommandolinjegrensesnitt via ADB og en app som kan kontrolleres via intensjoner. Slik ser det ut å starte opp en GSI med DSU:

I denne videoen* starter en Google Pixel 3 XL som kjører Android Q beta 3 på nytt til en GSI. I dette miljøet kan en apputvikler installere og teste appen sin for Q API-kompatibilitet. Når de er ferdige med testingen, kan de ganske enkelt starte på nytt i den vanlige Q beta 3-programvaren på enheten. Du dobbeltstarter en GSI slik at du trygt kan teste appen din!

*Vi tok opp denne videoen på Google I/O 2019 da DSU ikke var offentlig tilgjengelig ennå, så Q beta 3-bygget på den filmede Pixel 3 XL ble litt modifisert av Google for å inkludere DSU-støtte. Enheter som kjører Q beta 4 og nyere er kvalifisert til å støtte DSU hvis de oppfyller kravene nedenfor.

Krav til dynamiske systemoppdateringer

Å få det som egentlig er dobbel oppstart var ikke en lett oppgave for Google. Store endringer måtte gjøres i måten partisjoner administreres på Pixel 3, Googles testbed for DSU. Dermed er det første store kravet for DSU-støtte at enheten støtter dynamiske partisjoner. Dynamiske partisjoner involverer en reell lagringspartisjon som er delt inn i logiske partisjoner som kan endres størrelse som system, leverandør, odm, oem, produkt, etc. Under installasjonen av en GSI reserveres plass for nye system- og brukerdatapartisjoner ved å ta ubrukte blokker fra den eksisterende brukerdatapartisjonen. Siden disse nye partisjonene kan være flere gigabyte store, gir DSU-støtte bare mening med logisk partisjoner ellers ville en enhet måtte reservere flere gigabyte med lagringsplass permanent for GSI installasjoner.

Andre krav inkluderer en ramdisk, som bestemmer om du vil starte opp til gjenoppretting, system eller en logisk partisjon, og en metadatapartisjon for å lagre metadataene til GSI. Generelt er byggeklossene for DSU-støtte Android Q lanseringskrav, ifølge Project Treble-leder Iliyan Malchev. Vi er ikke sikre på om alt som er nødvendig for å støtte DSU er et Android Q-lanseringskrav, men vi kan anta at de fleste om ikke alle enheter som starter med Android Q kan støtte DSU selv om Google for øyeblikket ikke krever det. Så langt er det bare Pixel 3, Pixel 3 XL, Pixel 3a og Pixel 3a XL som har dynamiske partisjoner, og av disse enhetene er det bare Pixel 3 og Pixel 3 XL som støtter DSU i Android Q beta 4. Selv om DSU-støtte ikke er nødvendig, håper Google at OEM-er aktiverer funksjonen uansett fordi det forenkler sikker testing for diskantkompatibilitet. For eksempel kan en OEM-programvareingeniør sette en GSI på et SD-kort slik at de raskt kan starte opp på flere enheter for å teste diskantkompatibilitet.

Sikkerhet for dynamiske systemoppdateringer

Siden DSU i hovedsak introduserer et andre operativsystem i blandingen, må Google sørge for at denne nye installasjonen ikke kan tukles med for å bryte enhetens integritet. Dermed samme grunnleggende sikkerhetsbeskyttelse for den originale installasjonen er på plass for GSI-installasjonen: Android Verified Boot og SELinux retningslinjer. Videre er det bare apper med INSTALL_DYNAMIC_SYSTEM-signaturen|privilegert tillatelse som kan starte en GSI installasjon, mens apper med signaturtillatelsen MANAGE_DYNAMIC_SYSTEM kan aktivere/deaktivere eller slette en GSI installasjon. Dette betyr at bare pålitelige apper på systemnivå kan fungere med DSU.

For å sikre at de opprinnelige brukerdataene er beskyttet, har Google lagt til en ekstra beskyttelsesmekanisme i Android Q. Kalt "Kontrollpunkt," funksjonen beskytter mot ødeleggelse av brukerdata ved å gjenopprette sjekkpunktpartisjoner til deres opprinnelige tilstand. Sjekkpunkter er imidlertid nyttige for ikke bare DSU. De brukes også for å beskytte mot feil Prosjekt hovedlinje APEX-modul og A/B OTA-oppdateringer. (Enheter med A/B-partisjoner har allerede tilbakeføringsbeskyttelse, men disse tilbakestillingene krever tilbakestilling av fabrikkdata mens brukerdatasjekkpunkter ikke gjør det.)

Installere en GSI

Hvis enheten din støtter DSU som Pixel 3-serien, er det enkelt å installere en GSI. Du må først sørge for at flagget for dynamisk system er aktivert på en av to måter:

1. Hvis du er på en userdebug build, aktiverer du flagget for settings_dynamic_android i Innstillinger > System > Utvikleralternativer > Funksjonsflagg.
2. Hvis du bruker en brukerbygging, kjør følgende adb-shell-kommando:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Last deretter ned den nyeste Android Q beta GSI fra Google eller enhetens OEM. (DSU tillater kun installasjon av GSI-er signert av Google eller en OEM.) Når den er lastet ned, bruk simg2img for å konvertere det sparsomme bildet til et råbilde. Bruk gzip til å pakke råbildet, og kopier deretter det resulterende arkivet til en plassering på enhetens ekstern lagring (f.eks. /data/media/0/Download) eller et faktisk eksternt lagringsmedium (som en fysisk SD kort). Til slutt, start DynamicSystemInstallationService-appen med riktig hensikt for å starte installasjonen:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Når du klikker på start på nytt, starter du opp i GSI. Brukbarheten til enheten i GSI avhenger av hvor godt enhetens OEM implementerte diskant (eller rettere sagt, hvor lite de krenket diskant kompatibilitet.) Noen enheter vil fungere bedre med GSI-er enn andre, men generelt sett, forvent ikke å bruke denne installasjonen som en daglig sjåfør. Det er meningen at du skal teste appen din og deretter komme deg ut ved å starte den på nytt. Hvis du ønsker å bli i GSI-installasjonen for videre testing, kan du bruke gsi_tool shell-kommando.

Du finner de fullstendige GSI-installasjonsinstruksjonene for DSU her. Feil kan arkiveres på Google Issue Tracker,Reddit, eller Stack Overflow.

Årsaken bak dynamiske systemoppdateringer

Da jeg snakket med Iliyan Malchev på Google I/O, gjentok han det Hung-ying Tyan fra Treble-teamet sa om tidlig GSI-tilgang kl. novembers Android Dev Summit. Google laget DSU til be om tilbakemeldinger fra et så bredt publikum som mulig. Målet er å forbedre kvaliteten på GSI, som igjen forbedrer kvaliteten på den fremtidige Android-utgivelsen siden en GSI er den reneste formen for Android. Google er for tiden det eneste selskapet som tester neste versjons GSI-kompatibilitet (for eksempel hvor godt Android Q-systembildet fungerer på toppen av Android P leverandørimplementering), men ettersom flere mennesker flasher GSI-er og gir tilbakemelding, kan OEM-er fikse brudd på diskantkompatibilitet slik at GSI-er vil fungere enda bedre i framtid. Iliyan sier at det er sterk interesse fra OEM-er og leverandører som Qualcomm for å gjenbruke leverandørbilder fra forrige Android-utgivelse med neste versjon av systembildet. Initiativer som DSU hjelper Google og OEM-er med å tette gapet i dekning fra automatiserte tester som VTS og CTS-on-GSI. Dermed får Google flere betatestere til å gi tilbakemelding på neste Android-utgivelse, samtidig som de hører om brudd på Treble-kompatibilitet slik at OEM-er kan forbedre arbeidet sitt.

Tillegget av dynamiske systemoppdateringer i Android Q er velkommen, men det kommer ikke til å være den dual boot-løsningen noen av dere håper på. Som nevnt tidligere, kan bare systembilder signert av Google eller OEM-er installeres. Da jeg spurte Iliyan om muligheten for å utvide DSU til å støtte et økosystem av alternativ Android systemer, sa han at det er teknisk mulig å gjøre det da DSU ganske enkelt er en kanal for å levere systemet Bilder. Enhver OEM kan bruke den slik de vil så lenge sluttresultatet er Android-kompatibelt. Google har ikke laget et alternativ til OTA-systemet her, og DSU er ikke ment å brukes til ekte dobbel oppstart. Uansett, arbeidet som Google har gjort på Treble gjør Android mer modulært, så jeg ville ikke bli overrasket om native dual booting blir realitet på veien.