Dynamische systeemupdates in Android V: Hoe Project Treble toekomstige Android-versies zal verbeteren

Gelijktijdig met de release van Android 8.0 Oreo heeft Google dit onthuld Project Treble: een ingrijpende herinrichting van de manier waarop het Android OS-framework en de HAL's en de Linux-kernel van de leverancier communiceren. Treble is een groot initiatief dat is ontworpen om de versie- en Android-platformversie te verminderen fragmentatie van beveiligingspatches, en alle Android-apparaten die met Android Pie worden gelanceerd, moeten Project Treble ondersteunen. OEM's en leveranciers testen de compatibiliteit van Treble door een Generic System Image (GSI) op te starten (een pure stock-build van Android van AOSP) en de Leverancierstestsuite (VTS) en compatibiliteitstestsuite-op-generieke systeemimage (CTS-op-GSI). De GSI is niet alleen nuttig gebleken omdat software-ingenieurs die voor OEM's werken de compatibiliteit van Treble kunnen testen, maar heeft ook de deur geopend voor een

grote aangepaste ROM-gemeenschap op XDA. Voor de Android Q-release wil Google GSI’s bruikbaar maken voor een andere groep: app-ontwikkelaars.

Sinds de eerste stabiele release en broncodedaling van een bepaald Android-platform komt er meestal een release in augustus, hebben ontwikkelaars die de volgende Android-release op een echt apparaat willen testen doorgaans toegang tot een Google-smartphone nodig als ze niet willen wachten tot de update hun eigen hardware bereikt. Google werkte echter samen met OEM's om een Android P-bèta vorig jaar op verschillende apparaten, en dat hebben ze dit jaar opgevolgd met een Android Q-bèta. Naast een officiële Android Q-bèta heeft Google dit jaar ook een officiële Q bèta GSI zodat elke ontwikkelaar met een Project Treble-compatibel apparaat de nieuwste Q-release kan installeren zonder maanden te hoeven wachten voordat de build zijn apparaten bereikt. Deze nieuwe manier om de volgende Android-release te testen geeft ontwikkelaars meer mogelijkheden, en dus meer tijd, om hun apps te testen grote veranderingen in Android.

Helaas is de huidige werkwijze van het installeren van een GSI kan moeilijk zijn. Het vereist het ontgrendelen van de bootloader (wat betekent dat alle gebruikersgegevens worden gewist en/of de garantie vervalt) en het flashen van een afbeelding via het fastboot-protocol. Het is geen snel en eenvoudig proces dat een app-ontwikkelaar op zijn apparaat kan uitvoeren maakt zelfs het ontgrendelen van de bootloader mogelijk. Daarom is voor de afgelopen maandenheeft Google gewerkt aan een nieuwe manier om GSI's op te starten. Voer een nieuwe functie in met de naam Dynamic System Update of DSU.

(Deze functie is eerder ontwikkeld onder de namen ‘Live Image’, ‘Dynamic Android’ en ‘Android on Tap’, dus wees niet verbaasd als Google het over een paar weken of maanden iets anders noemt.)

Dynamische systeemupdates in Android Q

Het doel van de DSU-functie is om een ​​ontwikkelaar in staat te stellen een GSI op te starten zonder de huidige installatie te verstoren. Dat betekent dat de bootloader niet hoeft te worden ontgrendeld en dat de gebruikersgegevens niet hoeven te worden gewist. Het installatieproces is ook aanzienlijk vereenvoudigd omdat Google een opdrachtregelinterface via ADB heeft geleverd en een app die via intents kan worden bestuurd. Zo ziet het eruit om een ​​GSI op te starten met DSU:

In deze video* wordt een Google Pixel 3 XL met Android Q bèta 3 opnieuw opgestart in een GSI. In deze omgeving kan een app-ontwikkelaar zijn app installeren en testen op Q API-compatibiliteit. Als ze klaar zijn met testen, kunnen ze eenvoudigweg opnieuw opstarten naar de reguliere Q beta 3-software op het apparaat. U start feitelijk een GSI dubbel op, zodat u uw app veilig kunt testen!

*We hebben deze video opgenomen op Google I/O 2019 toen DSU nog niet openbaar beschikbaar was, dus de Q beta 3-versie van de gefilmde Pixel 3 XL werd door Google enigszins aangepast om DSU-ondersteuning te bieden. Apparaten met Q bèta 4 en hoger komen in aanmerking voor ondersteuning van DSU als ze aan de onderstaande vereisten voldoen.

Vereisten voor dynamische systeemupdates

Het operationeel krijgen van wat in wezen dubbel opstarten is, was geen gemakkelijke taak voor Google. Er moesten grote veranderingen worden aangebracht in de manier waarop partities worden beheerd op de Pixel 3, Google's testbed voor DSU. De eerste belangrijke vereiste voor DSU-ondersteuning is dus dat het apparaat dit ondersteunt dynamische partities. Dynamische partities omvatten één echte opslagpartitie die is onderverdeeld in aanpasbare logische partities zoals systeem, leverancier, odm, oem, product, enz. Tijdens de installatie van een GSI wordt ruimte gereserveerd voor nieuwe systeem- en gebruikersdatapartities door ongebruikte blokken uit de bestaande gebruikersdatapartitie te halen. Omdat deze nieuwe partities meerdere gigabytes groot kunnen zijn, is DSU-ondersteuning alleen zinvol als het logisch is partities, anders zou een apparaat permanent meerdere gigabytes aan opslagruimte voor GSI moeten reserveren installaties.

Andere vereisten zijn onder meer een ramdisk, die beslist of er moet worden opgestart vanaf een herstel-, systeem- of logische partitie, en een metadatapartitie om de metadata van de GSI op te slaan. Over het algemeen zijn de bouwstenen voor DSU-ondersteuning de lanceringsvereisten van Android Q, aldus Project Treble-leider Iliyan Malchev. We weten niet zeker of alles dat nodig is om DSU te ondersteunen is een Android Q-lanceringsvereiste, maar we kunnen ervan uitgaan dat de meeste, zo niet alle apparaten worden gestart met Android Q kan ondersteunen DSU, zelfs als Google dit momenteel niet vereist. Tot nu toe hebben alleen de Pixel 3, Pixel 3 XL, Pixel 3a en Pixel 3a XL dynamische partities, en van deze apparaten ondersteunen alleen de Pixel 3 en Pixel 3 XL DSU in Android Q bèta 4. Hoewel DSU-ondersteuning niet vereist is, hoopt Google dat OEM's de functie toch inschakelen, omdat dit het veilig testen op Treble-compatibiliteit vereenvoudigt. Een OEM-software-ingenieur kan bijvoorbeeld een GSI plaatsen op een SD-kaart zodat ze snel op meerdere apparaten kunnen opstarten om de compatibiliteit van Treble te testen.

Beveiliging voor dynamische systeemupdates

Omdat DSU feitelijk een tweede besturingssysteem in de mix introduceert, moet Google ervoor zorgen dat er niet met deze nieuwe installatie kan worden geknoeid om de integriteit van het apparaat te schenden. Dus de dezelfde basisbeveiligingen voor de oorspronkelijke installatie zijn aanwezig voor de GSI-installatie: Android-geverifieerd opstart- en SELinux-beleid. Bovendien kunnen alleen apps met de INSTALL_DYNAMIC_SYSTEM-handtekening|bevoorrechte toestemming een GSI initiëren installatie, terwijl apps met de handtekeningmachtiging MANAGE_DYNAMIC_SYSTEM een GSI kunnen in-/uitschakelen of wissen installatie. Dit betekent dat alleen vertrouwde apps op systeemniveau met DSU kunnen werken.

Om ervoor te zorgen dat de oorspronkelijke gebruikersgegevens worden beschermd, heeft Google een extra beschermingsmechanisme in Android Q. Genaamd "Controlepunt," beschermt de functie tegen vernietiging van gebruikersgegevens door gecontroleerde partities in hun oorspronkelijke staat te herstellen. Controlepunten zijn echter niet alleen nuttig voor DSU. Ze worden ook gebruikt om te beschermen tegen mislukte pogingen Project Hoofdlijn APEX-module en A/B OTA-updates. (Apparaten met A/B-partities beschikken al over terugdraaibeveiliging, maar voor deze terugdraaiingen zijn fabrieksresetten van gegevens vereist, terwijl controlepunten voor gebruikersgegevens dat niet doen.)

Een GSI installeren

Als uw apparaat DSU ondersteunt, zoals de Pixel 3-serie, dan is het eenvoudig om een ​​GSI te installeren. U moet er eerst voor zorgen dat de functievlag Dynamisch systeem op een van de volgende twee manieren is ingeschakeld:

1. Als u een userdebug-build gebruikt, schakelt u de vlag settings_dynamic_android in Instellingen > Systeem > Opties voor ontwikkelaars > Functievlaggen in.
2. Als u een gebruikersbuild gebruikt, voert u de volgende adb shell-opdracht uit:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Download vervolgens de nieuwste Android Q-bèta GSI van Googlen of de OEM van uw apparaat. (DSU staat alleen het installeren van GSI's toe die zijn ondertekend door Google of een OEM.) Na het downloaden kunt u gebruiken simg2img om de schaarse afbeelding naar een onbewerkte afbeelding te converteren. Gebruik gzip om de onbewerkte afbeelding in te pakken en kopieer vervolgens het resulterende archief naar een locatie op uw apparaat externe opslag (bijv. /data/media/0/Download) of een daadwerkelijk extern opslagmedium (zoals een fysieke SD kaart). Start ten slotte de DynamicSystemInstallationService-app met de juiste intentie om met de installatie te beginnen:

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

Zodra u op Opnieuw opstarten klikt, start u de GSI op. De bruikbaarheid van het apparaat in de GSI hangt af van hoe goed de OEM van uw apparaat Treble heeft geïmplementeerd (of beter gezegd, hoe weinig ze Treble hebben geschonden compatibiliteit.) Sommige apparaten zullen beter werken met GSI's dan andere, maar verwacht over het algemeen niet dat u deze installatie dagelijks zult gebruiken bestuurder. Het is de bedoeling dat je je app test en vervolgens afsluit door opnieuw op te starten. Als u in de GSI-installatie wilt blijven om verder te testen, kunt u gebruik maken van de gsi_tool shell-commando.

De volledige GSI installatie-instructies voor DSU kunt u vinden hier. Bugs kunnen worden ingediend op de Google-probleemtracker,Reddit, of Stapeloverloop.

De reden achter dynamische systeemupdates

Toen ik met Iliyan Malchev van Google I/O sprak, herhaalde hij wat Hung-ying Tyan van het Treble-team zei over vroege GSI-toegang bij De Android Dev Summit van november. Google heeft DSU gemaakt Vraag feedback aan een zo breed mogelijk publiek. Het doel is om de kwaliteit van de GSI te verbeteren, wat op zijn beurt verbetert de kwaliteit van de toekomstige Android-release aangezien een GSI de puurste vorm van Android is. Google is momenteel het enige bedrijf dat de GSI-compatibiliteit van de volgende versie test (bijvoorbeeld hoe goed de Android Q-systeemimage werkt bovenop de Android P implementatie door een leverancier), maar naarmate meer mensen GSI's flashen en feedback geven, kunnen OEM's schendingen van de Treble-compatibiliteit oplossen, zodat GSI's nog beter zullen werken in de toekomst. toekomst. Iliyan zegt dat er grote interesse is van OEM's en leveranciers zoals Qualcomm voor het hergebruiken van leveranciersimages uit de vorige Android-release met de systeemimage van de volgende versie. Initiatieven zoals DSU helpen Google en OEM's het gat in de dekking van geautomatiseerde tests zoals VTS en CTS-on-GSI te dichten. Zo krijgt Google meer bètatesters om feedback te geven over de volgende Android-release, terwijl ze ook horen over schendingen van de Treble-compatibiliteit, zodat OEM's hun werk kunnen verbeteren.

De toevoeging van dynamische systeemupdates in Android Q is welkom, maar het zal niet de dual-boot-oplossing zijn waar sommigen van jullie op hopen. Zoals eerder vermeld, kunnen alleen systeemimages die zijn ondertekend door Google of OEM's worden geïnstalleerd. Toen ik Iliyan vroeg naar de mogelijkheid om DSU uit te breiden ter ondersteuning van een ecosysteem van alternatief Android systemen, zei hij dat het technisch mogelijk is om dit te doen, aangezien DSU eenvoudigweg een kanaal is om systemen te leveren afbeeldingen. Elke OEM kan het gebruiken zoals hij of zij wil zolang het eindresultaat Android-compatibel is. Google heeft hier geen alternatief voor het OTA-systeem gemaakt en DSU is niet bedoeld om te worden gebruikt voor echt dual-booting. Hoe dan ook, het werk dat Google aan Treble heeft gedaan, heeft Android modulairer gemaakt, dus het zou me niet verbazen als native dual-booting later werkelijkheid wordt.