Hur A/B-partitioner och sömlösa uppdateringar påverkar anpassad utveckling på XDA

När Android Nougat släpptes pratade vi om det alla typer av nya funktioner. Vi fick ett nyuppdaterat användargränssnitt till att börja med tillsammans med efterlängtade multiwindow-funktioner och Vulkan Graphics API-stöd. Men ett tillägg under huven flög över huvudet på de flesta användare. Android Nougat introducerade "Sömlösa uppdateringar" på enheter som stöder A/B-partitioner. De allra flesta befintliga Android-enheter (exklusive nya Google Pixel och Google Pixel XL) hade inte A/B-partitioner vid den tiden och kunde därför inte dra fördel av sömlösa uppdateringar. Den grundläggande utgångspunkten för den här funktionen är att enheten har en andra uppsättning av systemet, boot, leverantör och andra viktiga partitioner, och när du får en OTA uppdatera uppdateringen sker i bakgrunden medan den andra uppsättningen partitioner korrigeras vilket låter dig starta om till en uppdaterad mjukvarubyggnad sömlöst. Om en uppdatering misslyckas, kommer du att sparkas tillbaka till en fungerande version, vilket innebär att företag kommer att ha färre huvudvärk att hantera och konsumenterna är bättre skyddade.

Att stödja sömlösa uppdateringar är inte ett krav för någon ny Android-enhet, till skillnad från Project Treble. Som sådan stöder de allra flesta nya Android-enheter inte funktionen. Vi har fört en lista över alla enheter som stöds hittills, och det är tydligt att den här funktionen inte stöds brett. Det är synd eftersom A/B-partitioner ger många fördelar för både vanliga användare och avancerade användare. Funktionen har dock lite dåligt rykte i entusiastgemenskapen eftersom den uppfattas göra Android-utveckling och blinkande anpassade modifieringar svårare. Detta är faktiskt inte fallet, så vi ville avmystifiera sömlösa uppdateringar och förklara hur A/B-partitioner påverkar anpassad utveckling på XDA.

Stort tack till XDA Senior Member npjohnson, a bidragsgivare till LineageOS och underhållare av Motorola Moto Z2 Force, som hjälpte oss att kolla den här artikeln.

---

Partitioner på en Android-enhet

En partition är helt enkelt en diskret sektion på telefonens interna lagring där data lagras. Vilken typ av data som lagras på varje partition beror på hårdvaran, operativsystemet och många andra faktorer. Starthanteraren kommer att ha en, systemet (Android OS) kommer att ha en, användardatan kommer att ha en... och så vidare. När du ser folk prata om "/system" och "/cache" syftar de på de givna namnen för dessa partitioner. OnePlus 6 har till exempel 72 partier. Det låter som mycket, men OnePlus 6 är en av enheterna som stöder sömlösa uppdateringar vilket innebär att många av dessa partitioner helt enkelt är dubbletter av varandra.

Delvis utmatning av partitionerna på OnePlus 6. Vissa A/B-partitioner är understrukna i demonstrationssyfte.

Det finns många partitioner på en enhet som du aldrig behöver oroa dig för som användare. Många av dessa partitioner modifieras aldrig när anpassade ROM, kärnor, återställningar eller modifieringar som Magisk eller Xposed flashas. Många av dessa partitioner kommer antingen att vara oanvända för våra syften eller är för farliga att röra om du inte vet vad du gör (XLOADER och OEMINFO på Huawei/Honor enheter kommer att tänka på.) För de allra flesta Android-användare är de partitioner som vi oftast hanterar system, boot, återställning, användardata och på senare tid leverantör och vbmeta. Här är en kort förklaring av syftet med varje partition:

• system - innehåller Android OS, systembibliotek, systemappar och andra systemmedia som bootanimationer, bakgrundsbilder, ringsignaler etc.
• boot - håller kärnan, ramdisken och på A/B-enheter även återställningen
• återställning - håller återställningen, där TWRP oftast flashas på enheter med endast A (A/B-enheter har ingen dedikerad återställningspartition)
• användardata – innehåller all din app-, system- och interna lagringsdata
• leverantör - innehar plattforms- och enhetsspecifika HAL: er, filerna som krävs för att Android OS ska kunna kommunicera med den underliggande hårdvaran
• vbmeta - partitionen för Android Verified Boot 2.0 som verifierar uppstartsprocessens integritet

Enhets-OEM kan ändra sina partitionsscheman för att använda vilken layout de vill. Till exempel delar Huawei upp startpartitionen i ramdisk_recovery och kärna. Det finns också många extra partitioner som kan innehålla andra systemappar som cust, product och oem, och medan dessa är säkra att modifiera, det rekommenderas i allmänhet inte om du vill göra det lättare för dig själv att återgå till lager. Så var spelar A/B-partitioner en roll?

---

A/B-partitionsschemat

Hur uppdateringar fungerar på enheter med sömlösa uppdateringar

Den mycket enkla bilden jag gjorde nedan illustrerar hur en uppdatering hanteras på en enhet med A/B-partitionsstöd. Partitionen som visas är systempartitionen, även om andra partitioner som boot och leverantör också kan uppdateras med vilken OTA-uppdatering som helst från en OEM. Denna uppdateringsprocess sker med inte bara stora Android-versionsuppdateringar utan även säkerhetsuppdateringar.

1. Vi börjar med två systempartitioner, system_a och system_b, båda på samma version av Android.
2. Förutsatt att system_a är aktivt kommer OTA-uppdateringen att korrigera system_b, den inaktiva partitionen, i bakgrunden.
3. system_a är inställt på inaktivt och system_b blir sedan aktivt när användaren startar om.
4. Den nu inaktiva partitionen, system_a, kommer att uppdateras när nästa OTA-uppdatering rullas ut.

Vilka är fördelarna med den här uppdateringsprocessen?

1. Om en uppdatering misslyckas kommer enheten att återgå till den fungerande versionen på den andra kortplatsen.
2. Din data hålls perfekt intakt, även om uppdateringen är borrad, eftersom det bara finns en partition (användardata) som innehåller dina data.
3. Uppdatera streaming: Om din datapartition är full kan uppdateringen laddas ner och streamas till den inaktiva platsen. Det är en ganska snygg funktion och gör att du inte behöver slösa bort någon tillfällig lagring på dina uppdateringar. Det är därför det inte finns någon cache-partition på A/B-enheter eftersom de inte längre behövs.

Vilken inverkan har A/B-partitioneringsschemat på lagringen av en enhet?

Betyder det faktum att sömlösa uppdateringar i ett gäng dubblerade partitioner att du förlorar en massa lagringsutrymme? Inte alls. Google säger att enheter med sömlöst uppdateringsstöd bara borde vara nere på cirka några hundra megabyte tack vare att /cache- och /återställningspartitionerna togs bort. Att ta bort båda balanserar kostnaden för att lägga till en andra uppsättning partitioner. Enligt Google är Pixels A/B-systembild hälften så stor som A-only systembilden. Det mesta av den extra lagringsanvändningen kommer faktiskt från tillägget av en andra leverantörspartition. Det är vettigt eftersom leverantörspartitionen rymmer alla proprietära binärer som används av OEMs (en del av Project Treble), så det förväntas ta upp en hel del utrymme. Även om Google inte rekommenderar att ha A/B-partitionering på enheter med 4 GB lagringsutrymme (eftersom det är nästan 10 % av det totala tillgängliga lagringsutrymmet), rekommenderar de det på enheter med 8 GB och högre.

Här är en uppdelning av lagringsutrymmet som används på en Google Pixel med och utan A/B-partitioner.

Vad hände med återställningspartitionen?

Den underliggande Linux-kärnan på Android-enheter är det som låter Android känna igen och använda hårdvaran korrekt på en smartphone. På Android-enheter med endast A har du vanligtvis två versioner av kärnan: Den ena är packad inuti återställningspartitionen medan den andra är i startpartitionen. På A/B-enheter som stöder sömlösa uppdateringar är återställningen nu inne i startavbildningen tillsammans med kärnan. Återställningens huvudfunktion var att installera uppdateringar, men eftersom det hanteras av systemet självt (update_engine) medan Android startas upp behövs inte längre den dedikerade återställningspartitionen.

För att installera en anpassad återställning på A/B-enheter måste vi alltså modifiera startpartitionen och ersätta lageråterställningen med vår egen. Det är därför du för att installera TWRP måste använda ett fastboot-kommando för att starta en anpassad startavbildning först och sedan flasha TWRP-installationsskriptet, eftersom fastboot inte kan patcha partitioner – bara flasha över dem helt och hållet. Du skulle tekniskt kunna förfixa din befintliga startavbildning med TWRP och sedan flasha den via fastboot, men det är mer problem än det är värt. TWRP-installationsskriptet korrigerar både boot_a- och boot_b-partitionerna för att installera TWRP.

Kul fakta: Android update_engine som hanterar sömlösa uppdateringar är i princip rippad direkt från Chrome OS. Bara nyligen togs strängar som innehåller "Chrome OS" bort från update_engines logg för att undvika förvirring för alla som råkar kolla logcat.

Stöder min Android-smarttelefon A/B-partitioner för sömlösa uppdateringar?

Medans vi hålla en lista över alla enheter som stöder det, du kan också enkelt kolla själv.

---

Hur påverkar sömlösa uppdateringar anpassad utveckling?

Användaruppfattning om A/B-partitioner

Anses vara ett hinder för anpassad mjukvaruutveckling av många användare, sömlösa uppdateringar är faktiskt en välsignelse för utvecklare. Anledningen till att A/B-enheter uppfattas ha dåligt utvecklingsstöd beror på priset på de första A/B-enheterna. När allt kommer omkring var Google Pixel-enheterna några av de första som stödde sömlösa uppdateringar och jämfört med Nexus-smarttelefonerna från förr var de relativt dyra. Dessutom, tack vare den myriad av förbättringar som Google har gjort för Android OS som har gjort anpassade ROM och ändringar mindre populära på Google-enheter, Google Pixel-smarttelefonerna tog inte fart på våra forum nästan lika bra som Nexus smartphones. En kombination av externa faktorer ledde till en minskning av anpassad utveckling på Google Pixel-smarttelefonerna, även om de flesta användare valde att skylla på A/B-partitionsstöd istället. Jämför tillgängligheten för anpassad utveckling på enheter som Google Pixel med enheter som Xiaomi Mi A1 på våra forum.

Dessutom ledde en bristande förståelse för hur A/B-partitioner förändrade hur användarna behöver installera anpassade ROM, kärnor, återställningar och modifieringar till att stöd för A/B-partitioner blev impopulärt. Med återställningen som nu finns inne i startavbildningen, kan blinkande modifieringar i fel ordning som Magisk eller Xposed orsaka konflikter och kan leda till en bootloop. Vilken ordning du flashar dessa mods i kan vara viktigt, men när det gäller anpassade ROM-skivor behöver du inte oroa dig för vilken plats du blinkar till. I motsats till vad man tror, ​​blinkar inte installationsskriptet för de flesta anpassade ROM till båda platserna. Du behöver oftast inte oroa dig för det eftersom du inte borde behöva byta slots manuellt.

Hur utvecklare ser A/B-partitioner

När man bygger en ROM kan utvecklare använda båda partitionerna för att testa separata builds. Om en inte fungerar kan de bara återgå till arbetspartitionen och bygga om sin ROM. Utvecklare kan också testa för regressioner genom att helt enkelt installera en uppdatering, byta den aktiva partitionen och jämföra de två utan att behöva radera data. Så här ser LineageOS-teamet på A/B-partitionsstöd:

"Många i Android-communityt har fördömt A/B som "svårt att stödja" och "inte utvecklarvänligt", när det faktiskt är korrekt implementerat. lättare att stödja och lika utvecklarvänlig." - jrizzoli, LineageOS Changelog 19

Den initiala svårigheten med A/B-stöd för utvecklare kom från att modifiera sina befintliga verktyg för att stödja dessa enheter. Utvecklaren av Magisk, topjohnwu, lade till officiellt stöd för Google Pixel ett år efter det släpptes – inte för att det var svårt, utan snarare för att det tog honom ett år att faktiskt skaffa enheten jobba på. TWRP-stöd kom ganska snabbt på A/B-enheter efter att den ledande utvecklaren, Dees_Troy, tog ett slag för det. LineageOS 15.1 stöder nu A/B-enheter efter att volontärer hittat tid att fixa sitt addon.d-skript.

Hur man uppdaterar en A/B-enhet som har en anpassad återställning, kärna eller andra mods

Anpassade ROM

Blinkande uppdateringar på en enhet med en anpassad ROM betyder att du måste vara försiktig med vilken kortplats du blinkar också, eller hur? Inte riktigt. TWRP kommer faktiskt att hantera mycket av det åt dig, och det är standard på den inaktiva kortplatsen för att blinka ett anpassat ROM. Om din aktiva plats är A och du flashar ett anpassat ROM, blinkar du faktiskt till kortplats B. När du startar om är den aktiva platsen nu B. Utvecklare kan modifiera installationsskriptet och flasha till båda platserna för att göra det enklare för slutanvändaren, även om de flesta anpassade ROM-installationsskript för närvarande bara flashar till en enda plats. Slutligen kan anpassade ROM-skivor implementera en A/B-uppdatering i sin ROM så att användare inte ens behöver bråka med manuellt blinkande uppdateringar – det senaste LineageOS 15.1 inkluderar ett Lineage Updater-verktyg och XDA Senior Member USA-RedDragon gjorde en generisk A/B-uppdatering som andra utvecklare kan använda.

Lager ROM

Men är det inte problematiskt om din enhet kör lager-ROM med olika modifieringar och du vill installera en uppdatering utan att förlora alla dessa mods? Det kan vara om du inte kan de rätta stegen för att installera en uppdatering. På OnePlus 6, till exempel, kan du inte flasha en inkrementell OTA på din modifierade enhet eftersom den inkrementella OTA kommer att försöka korrigera din modifierade startavbildning. Således kommer du sannolikt att sluta med en bootloop, och det är därför du måste flasha hela ROM-uppdateringen för att helt skriva över din modifierade startavbildning. Här är de allmänna stegen du behöver ta för att installera en OxygenOS-uppdatering på din OnePlus 6 samtidigt som du behåller TWRP, Magisk och eventuellt en anpassad kärna.

1. Laddade ner det senaste full ROM blixtlås
2. Flasha hela ROM-zip-filen vid återställning
3. (Valfritt) Flash anpassad kärna
4. Flash TWRP-installationsprogram
5. Starta om direkt tillbaka till återställning
6. Flash Magisk

På Google Pixel-enheter kan du flasha fabriksbilden utan att torka data, starta sedan TWRP, installera TWRP via installationsskriptet, installera sedan Magisk.

Extraherar en uppdatering för att flasha enskilda partitionsbilder

Uppdateringsfiler för många A/B-enheter skiljer sig lite jämfört med A-enheter. De är inte längre bara en zip-fil som innehåller massor av bilder (exklusive Google och Razers fabriksbilder), istället är de i form av en payload.bin-fil. Du kan extrahera den här filen och flasha varje del manuellt, men det kräver ett speciellt verktyg för att göra det. Om du är intresserad av att lära dig hur du gör det på OnePlus 6, Xiaomi Mi A1 och många andra A/B-enheter, läs vidare.

Ställer in för att extrahera payload.bin

1. Se till att du har Python 3.6 installerat.
2. Ladda ner payload_dumper.py och update_metadata_pb2.py här.
3. Extrahera din OTA-zip och placera payload.bin i samma mapp som dessa filer.
4. Öppna PowerShell, Kommandotolken eller Terminal beroende på ditt operativsystem.
5. Ange följande kommando: python -m pip install protobuf
6. När det är klart anger du det här kommandot: python payload_dumper.py payload.bin
7. Detta kommer att börja extrahera bilderna i filen payload.bin till den aktuella mappen du befinner dig i.

Du kan flasha var och en av dessa bilder separat nu via fastboot om du vill. Nästa avsnitt visar hur du gör det.

Använda fastboot för att flasha bilder på en enhet som stöder sömlösa uppdateringar

Det finns ett antal kommandon som är exklusiva för A/B-partitionssystemenheter. Du kan ändra din aktiva slot och flash till specifika slots. Om du har en Project Treble-kompatibel enhet och vill lära dig hur man gör flash Generiska systembilder, bör du vara bekant med dessa kommandon. Ta en titt på tabellen nedan.

(Obs: På A/B-enheter kan du antingen ange en partition i en viss plats att blinka till eller så kan du utelämna slotsuffixet och det blinkar till den aktuella aktiva luckan. Du kan till exempel ersätta "partition" i flash-kommandot med "system", "system_a" eller "system_b.")

---

Ett ord om Project Treble och sömlösa uppdateringar

En vanlig missuppfattning är att att ha Project Treble-stöd och A/B-partitionsstöd är relaterade till varandra, men det är faktiskt inte fallet. Att ha det ena innebär inte det andra. Motorola Moto Z2 Force använder ett A/B-partitioneringsschema men stöder inte diskant. Å andra sidan stöder Honor 9 Lite Project Treble, men är ändå en A-enhet.

---

Vanliga frågor/sammanfattning

• Vilka är fördelarna med A/B-partitionering?
  • A/B-partitionering låter dig uppdatera din Android-smarttelefon medan du använder den, helt enkelt starta om när du är redo att starta upp den nya versionen. Det fungerar också som skydd mot tegelstenar – om uppdateringen går fel återgår du till den fungerande installationen.
• Hindrar utvecklingen att ha A/B-partitionering?
  • Även om det tog utvecklare lite tid att anpassa sig, är svaret i stort sett nej. Faktum är att det kan hjälpa utvecklare eftersom de kan dubbelstarta sin anpassade ROM med den gamla versionen och en ny testversion för att kontrollera om det finns regressioner.
• Hur påverkar A/B-partitioner mods som anpassade kärnor, Magisk eller Xposed?
  • Du måste vara försiktig när du installerar dem, men det finns inga problem för närvarande. Magisk stöder officiellt enheter med sömlösa uppdateringar, och så länge du flashar saker i rätt ordning bör du inte ha några problem. Se till att flasha den anpassade kärnan innan du flashar dina andra mods, och du borde vara igång.
• Kan jag flasha två olika ROM på varje partition och dual boot?
  • I teorin, ja. Problem uppstår dock på grund av den delade datapartitionen, så det rekommenderas inte.
• Betyder ett A/B-partitionsschema att jag har minskat lagringsutrymme?
  • Nej! Google säger att enheter som stöder sömlösa uppdateringar bara offra några hundra megabyte lagringsutrymme för att stödja det. Fördelarna överväger den kostnaden.
• Min enhet stöder A/B-partitioner, betyder det att jag kan använda en Project Treble Generic System Image?
  • Inte nödvändigtvis. Project Treble och A/B-stöd är inte relaterade. Motorola Moto Z2 Force stöder inte Project Treble, men den stöder A/B-partitionsschemat.
• Min enhet stöder Project Treble, betyder det att jag har ett A/B-partitionsschema?
  • Detta är inte alltid fallet. Honor 9 Lite är ett utmärkt exempel eftersom den stöder Project Treble men inte har ett A/B-partitionsschema.
• Varför måste jag starta TWRP med fastboot först och sedan flasha det?
  • Detta beror på hur fastboot fungerar och det faktum att återställningspartitionen inte längre existerar. Återställningen placeras inuti startpartitionen, så vi måste modifiera både boot_a och boot_b. Du kan inte patcha en partition i fastboot, bara flasha över den. Du kan i teorin göra en förpatchad startbild och sedan flasha den istället.
• Finns det några faror med A/B-partitioner? Hur påverkar återställningsskydd saker och ting?
  • Google har försökt sitt bästa för att göra detta inte ett problem, utan i fallet med Motorola Moto Z2 Force, det fanns kända fall av en enhet som återaktiverade den äldre kortplatsen efter uppgradering till Android Oreo. Detta innebar att återställningsskyddet slog in och enhetsägare kunde bara rädda sin smartphone med EDL-återställning. Google säger att återställningsskyddet bara startar efter första uppstart, så kortplatsen måste fungera fullt ut efter en uppdatering innan du inte längre kan nedgradera.