Dynamiska systemuppdateringar i Android F: Hur Project Treble kommer att förbättra framtida Android-versioner

Vid sidan av lanseringen av Android 8.0 Oreo, presenterade Google Projekt Treble: en stor omarbetning av hur Android OS-ramverket och leverantörens HALs och Linux-kärnan kommunicerar. Treble är ett stort initiativ utformat för att minska Android-plattformsversionen och fragmentering av säkerhetskorrigeringar, och alla Android-märkta enheter som lanseras med Android Pie måste stödja Project Treble. OEM-tillverkare och leverantörer testar diskantkompatibilitet genom att starta upp en generisk systembild (GSI) – en ren lageruppbyggnad av Android från AOSP – och godkänna Leverantörstestsvit (VTS) och Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). GSI har visat sig användbar för att inte bara låta mjukvaruingenjörer som arbetar för OEM-tillverkare testa diskantkompatibilitet, utan den har också öppnat dörren för en stor anpassad ROM-gemenskap

på XDA. För Android Q-versionen vill Google göra GSI: er användbara för en annan grupp: apputvecklare.

Sedan den första stabila utgåvan och källkodssläppet för en given Android-plattformsversion vanligtvis kommer i Augusti, utvecklare som skulle vilja testa nästa Android-version på en riktig enhet behöver vanligtvis tillgång till en Google-smarttelefon om de inte vill vänta på att uppdateringen ska nå sin egen hårdvara. Google arbetade dock med OEM-tillverkare för att få en Android P beta till flera enheter förra året, och de har följt upp det i år med en Android Q beta. Vid sidan av en officiell Android Q-beta, släppte Google i år också en officiella Q beta GSI så alla utvecklare med en Project Treble-kompatibel enhet kan installera den senaste Q-utgåvan utan att behöva vänta månader på att bygget ska nå sina enheter. Detta nya sätt att testa nästa Android-version ger utvecklare fler möjligheter, och därmed mer tid, att testa sina appar mot stora förändringar i Android.

Tyvärr är den nuvarande metoden för installera en GSI kan vara svårt. Det kräver att man låser upp starthanteraren – vilket innebär att man torkar all användardata och/eller ogiltigförklarar garantin – och att en bild blinkar via fastboot-protokollet. Det är inte en snabb och enkel process för en apputvecklare att göra, om deras enhet tillåter till och med att låsa upp starthanteraren. Det är därför, för senaste månaderna, har Google arbetat på ett nytt sätt att starta GSI: er. Ange en ny funktion som heter Dynamic System Update, eller DSU.

(Den här funktionen utvecklades tidigare under namnen "Live Image", "Dynamic Android" och "Android on Tap", så bli inte förvånad om Google kallar det något annat om några veckor eller månader.)

Dynamiska systemuppdateringar i Android Q

Målet med DSU-funktionen är att tillåta en utvecklare att starta upp i en GSI utan att störa den aktuella installationen. Det betyder att starthanteraren inte behöver låsas upp och användardatan inte behöver raderas. Installationsprocessen är också mycket förenklad då Google har tillhandahållit ett kommandoradsgränssnitt via ADB och en app som kan styras via avsikter. Så här ser det ut att starta upp en GSI med DSU:

I den här videon* startar en Google Pixel 3 XL som kör Android Q beta 3 om till en GSI. I den här miljön kan en apputvecklare installera och testa sin app för Q API-kompatibilitet. När de är klara med testandet kan de helt enkelt starta om till den vanliga Q beta 3-mjukvaran på enheten. Du dubbelstartar i princip en GSI så att du säkert kan testa din app!

*Vi spelade in den här videon på Google I/O 2019 när DSU inte var offentligt tillgänglig ännu, så Q beta 3-bygget på den filmade Pixel 3 XL modifierades något av Google för att inkludera DSU-stöd. Enheter som kör Q beta 4 och senare är berättigade att stödja DSU om de uppfyller kraven nedan.

Krav för dynamiska systemuppdateringar

Det var ingen lätt uppgift för Google att få igång vad som i huvudsak är dubbelstart. Stora ändringar var tvungna att göras i hur partitioner hanteras på Pixel 3, Googles testbädd för DSU. Det första stora kravet för DSU-stöd är alltså att enheten stöder dynamiska partitioner. Dynamiska partitioner involverar en riktig lagringspartition som är uppdelad i logiska partitioner som kan ändras storlek som system, leverantör, odm, oem, produkt, etc. Under installationen av en GSI reserveras utrymme för nya system- och användardatapartitioner genom att oanvända block tas från den befintliga användardatapartitionen. Eftersom dessa nya partitioner kan vara flera gigabyte stora, är DSU-stöd bara vettigt med logiska partitioner annars skulle en enhet behöva reservera flera gigabyte lagringsutrymme permanent för GSI installationer.

Andra krav inkluderar en ramdisk, som bestämmer om den ska startas till återställning, system eller en logisk partition, och en metadatapartition för att lagra metadata för GSI. I allmänhet är byggstenarna för DSU-stödet Android Q lanseringskrav, enligt Project Treble-ledaren Iliyan Malchev. Vi är inte säkra på om allt som behövs för att stödja DSU är ett startkrav för Android Q, men vi kan anta att de flesta om inte alla enheter som startar med Android Q burk stödja DSU även om Google för närvarande inte kräver att de gör det. Hittills är det bara Pixel 3, Pixel 3 XL, Pixel 3a och Pixel 3a XL som har dynamiska partitioner, och av dessa enheter är det bara Pixel 3 och Pixel 3 XL som stöder DSU i Android Q beta 4. Även om DSU-stöd inte krävs, hoppas Google att OEM-tillverkare aktiverar funktionen ändå eftersom det förenklar säker testning av diskantkompatibilitet. Till exempel kan en OEM-programvaruingenjör sätta en GSI på ett SD-kort så att de snabbt kan starta upp på flera enheter för att testa diskantkompatibilitet.

Säkerhet för dynamiska systemuppdateringar

Eftersom DSU i princip introducerar ett andra operativsystem i mixen måste Google se till att den här nya installationen inte kan manipuleras för att bryta enhetens integritet. Alltså samma grundläggande säkerhetsskydd för den ursprungliga installationen finns på plats för GSI-installationen: Android Verified Boot och SELinux policyer. Dessutom kan endast appar med INSTALL_DYNAMIC_SYSTEM-signaturen|privilegierad behörighet initiera en GSI installation, medan appar med signaturbehörighet MANAGE_DYNAMIC_SYSTEM kan aktivera/inaktivera eller radera en GSI installation. Det betyder att endast pålitliga appar på systemnivå kan fungera med DSU.

För att säkerställa att den ursprungliga användardatan är skyddad har Google lagt till en extra skyddsmekanism i Android Q. Kallas "Kontrollstation", skyddar funktionen mot förstörelse av användardata genom att återställa checkpointade partitioner till deras ursprungliga tillstånd. Kontrollpunkter är dock användbara för inte bara DSU. De används också för att skydda mot fel Projekt huvudlinje APEX-modul och A/B OTA-uppdateringar. (Enheter med A/B-partitioner har redan återställningsskydd, men dessa återställningar kräver återställning av fabriksdata medan kontrollpunkter för användardata inte gör det.)

Installera en GSI

Om din enhet stöder DSU som Pixel 3-serien är det enkelt att installera en GSI. Du måste först se till att flaggan för dynamiskt system är aktiverad på ett av två sätt:

1. Om du använder en userdebug-version, aktivera flaggan settings_dynamic_android i Inställningar > System > Utvecklaralternativ > Funktionsflaggor.
2. Om du använder en användarversion, kör följande adb-skalkommando:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Ladda sedan ner den senaste Android Q beta GSI från Google eller din enhets OEM. (DSU tillåter endast installation av GSI: er signerade av Google eller en OEM.) När du har laddat ned, använd simg2img för att konvertera den glesa bilden till en råbild. Använd gzip för att packa den råa bilden och kopiera sedan det resulterande arkivet till en plats på enhetens extern lagring (t.ex. /data/media/0/Download) eller ett faktiskt externt lagringsmedium (som ett fysiskt SD kort). Slutligen, starta DynamicSystemInstallationService-appen med rätt avsikt att påbörja installationen:

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 klickar på starta om startar du in i GSI. Användbarheten av enheten i GSI beror på hur väl din enhets OEM implementerade diskant (eller snarare hur lite de bröt mot diskant kompatibilitet.) Vissa enheter fungerar bättre med GSI än andra, men förvänta dig i allmänhet inte att använda den här installationen som en daglig förare. Det är meningen att du ska testa din app och sedan komma ut genom att starta om. Om du vill stanna kvar i GSI-installationen för ytterligare testning kan du använda gsi_tool skal kommando.

De fullständiga GSI-installationsinstruktionerna för DSU finns här. Buggar kan arkiveras på Google Issue Tracker,Reddit, eller Stack Overflow.

Anledningen bakom dynamiska systemuppdateringar

När jag pratade med Iliyan Malchev på Google I/O, upprepade han vad Hung-ying Tyan från Treble-teamet sa om tidig GSI-åtkomst kl. Novembers Android Dev Summit. Google gjorde DSU till be om feedback från en så bred publik som möjligt. Målet är att förbättra kvaliteten på GSI, vilket i sin tur förbättrar kvaliteten på den framtida Android-versionen eftersom en GSI är den renaste formen av Android. Google är för närvarande det enda företaget som testar nästa version GSI-kompatibilitet (till exempel hur väl Android Q-systembilden fungerar ovanpå Android P leverantörsimplementering), men när fler människor flashar GSI: er och ger feedback, kan OEM: er fixa diskantkompatibilitetsöverträdelser så att GSI: er kommer att fungera ännu bättre i framtida. Iliyan säger att det finns ett stort intresse från OEM-tillverkare och leverantörer som Qualcomm för att återanvända leverantörsbilder från den tidigare Android-versionen med nästa version av systembilden. Initiativ som DSU hjälper Google och OEM: er att täppa till gapet i täckning från automatiserade tester som VTS och CTS-on-GSI. Således får Google fler betatestare för att ge feedback om nästa Android-släpp, samtidigt som de får höra om Treble-kompatibilitetsbrott så att OEM-tillverkare kan förbättra sitt arbete.

Tillägget av dynamiska systemuppdateringar i Android Q är välkommet, men det kommer inte att vara den dubbelstartlösning som vissa av er hoppas på. Som tidigare nämnts kan endast systembilder signerade av Google eller OEM-tillverkare installeras. När jag frågade Iliyan om möjligheten att utöka DSU för att stödja ett ekosystem av alternativ Android system, sa han att det är tekniskt möjligt att göra det eftersom DSU helt enkelt är en kanal för att leverera systemet bilder. Alla OEM kan använda det hur de vill så länge som slutresultatet är Android-kompatibelt. Google har inte skapat ett alternativ till OTA-systemet här, och DSU är inte avsedd att användas för äkta dubbelstart. Oavsett vilket gör arbetet som Google har gjort på Treble Android mer modulärt, så jag skulle inte bli förvånad om inbyggd dubbelstart blir verklighet längre fram.