Hvordan A/B-partitioner og sømløse opdateringer påvirker tilpasset udvikling på XDA

Da Android Nougat udkom, talte vi om det alle slags nye funktioner. Vi fik en nyligt opdateret brugergrænseflade til at starte med sammen med længe ventede multiwindow-funktioner og Vulkan Graphics API-understøttelse. Men en tilføjelse under hætten fløj hen over hovedet på de fleste brugere. Android Nougat introducerede "Sømløse opdateringer" på enheder, der understøtter A/B-partitioner. Langt de fleste eksisterende Android-enheder (undtagen den nye Google Pixel og Google Pixel XL) havde ikke A/B-partitioner på det tidspunkt og kunne derfor ikke drage fordel af problemfri opdateringer. Den grundlæggende forudsætning for denne funktion er, at enheden har et andet sæt system, boot, leverandør og andre vigtige partitioner, og når du får en OTA Opdater opdateringen sker i baggrunden, mens det andet sæt partitioner lappes, hvilket lader dig genstarte i en opdateret software-build problemfrit. Hvis en opdatering mislykkes, vil du blive sparket tilbage til en fungerende build, hvilket betyder, at virksomheder vil have færre hovedpine at håndtere, og forbrugerne er bedre beskyttet.

Understøttelse af sømløse opdateringer er ikke et krav for nogen ny Android-enhed, i modsætning til Project Treble. Som sådan understøtter langt de fleste nye Android-enheder ikke funktionen. Vi har ført en liste over alle de understøttede enheder indtil videre, og det er tydeligt, at denne funktion ikke er bredt understøttet. Det er en skam, fordi A/B-partitioner giver en masse fordele for både almindelige brugere og superbrugere. Funktionen har dog et lidt dårligt ry i entusiastmiljøet, fordi det opfattes som at gøre Android-udvikling og blinkende tilpassede ændringer vanskeligere. Dette er faktisk ikke tilfældet, så vi ønskede at afmystificere sømløse opdateringer og forklare, hvordan A/B-partitioner påvirker tilpasset udvikling på XDA.

Mange tak til XDA Senior Member npjohnson, a bidragyder til LineageOS og vedligeholder af Motorola Moto Z2 Force, som hjalp os med at tjekke denne artikel.

---

Partitioner på en Android-enhed

En partition er simpelthen et diskret afsnit på telefonens interne lager, hvor data opbevares. Hvilken slags data der opbevares på hver partition afhænger af hardwaren, operativsystemet og mange andre faktorer. Bootloaderen vil have en, systemet (Android OS) vil have en, brugerdataene vil have en... og så videre og så videre. Når du ser folk tale om "/system" og "/cache", henviser de til de givne navne for disse partitioner. OnePlus 6 har f.eks 72 skillevægge. Det lyder af meget, men OnePlus 6 er en af ​​de enheder, der understøtter sømløse opdateringer, hvilket betyder, at mange af disse partitioner simpelthen er duplikater af hinanden.

Delvis output af partitionerne på OnePlus 6. Nogle A/B-partitioner er understreget til demonstrationsformål.

Der er mange partitioner på en enhed, som du aldrig behøver at bekymre dig om som bruger. Mange af disse partitioner bliver aldrig ændret, når der flashes tilpassede ROM'er, kerner, gendannelser eller ændringer som Magisk eller Xposed. Mange af disse partitioner vil enten være ubrugte til vores formål eller er for farlige at røre ved, medmindre du ved, hvad du laver (XLOADER og OEMINFO på Huawei/Honor) enheder kommer til at tænke på.) For langt de fleste Android-brugere er de partitioner, som vi for det meste beskæftiger os med, system, opstart, gendannelse, brugerdata og for nylig leverandør og vbmeta. Her er en kort forklaring af formålet med hver partition:

• system - indeholder Android OS, systembiblioteker, systemapps og andre systemmedier som bootanimationer, lagerbaggrunde, ringetoner osv.
• boot - holder kernen, ramdisken og på A/B-enheder også gendannelsen
• recovery - holder gendannelsen, hvor TWRP oftest flashes på kun A-enheder (A/B-enheder har ikke en dedikeret gendannelsespartition)
• brugerdata - indeholder alle dine app-, system- og interne lagerdata
• leverandør - har platform- og enhedsspecifikke HAL'er, de filer, der er nødvendige for, at Android OS kan kommunikere med den underliggende hardware
• vbmeta - partitionen til Android Verified Boot 2.0, som verificerer opstartsprocessens integritet

Enheds-OEM'er kan ændre deres partitionsskemaer for at bruge det layout, de ønsker. For eksempel opdeler Huawei boot-partitionen i ramdisk_recovery og kerne. Der er også en masse ekstra partitioner, der kan indeholde andre systemapps såsom cust, produkt og oem, og mens disse er sikre at ændre, det anbefales generelt ikke, hvis du vil gøre det nemmere for dig selv at vende tilbage til lageret. Så hvor spiller A/B-partitioner en rolle?

---

A/B-partitionsordningen

Sådan fungerer opdateringer på enheder med problemfri opdateringer

Det meget enkle billede, jeg lavede nedenfor, illustrerer, hvordan en opdatering håndteres på en enhed med A/B-partitionsunderstøttelse. Den partition, der er illustreret, er systempartitionen, selvom andre partitioner såsom boot og leverandør også kan opdateres med en given OTA-opdatering fra en OEM. Denne opdateringsproces sker ikke kun med større Android-versionsopdateringer, men også sikkerhedsopdateringer.

1. Vi starter med to systempartitioner, system_a og system_b, begge på samme version af Android.
2. Forudsat at system_a er aktiv, vil OTA-opdateringen patch system_b, den inaktive partition, i baggrunden.
3. system_a er sat til inaktiv, og system_b bliver derefter aktiv, når brugeren genstarter.
4. Den nu inaktive partition, system_a, vil blive opdateret, når den næste OTA-opdatering rulles ud.

Hvad er fordelene ved denne opdateringsproces?

1. Hvis en opdatering mislykkes, vil enheden rulle tilbage til den fungerende build på den anden slot.
2. Dine data holdes perfekt intakte, selvom opdateringen er boret, da der kun er én partition (brugerdata), som rummer dine data.
3. Opdater streaming: Hvis din datapartition er fuld, kan opdateringen downloades og streames til det inaktive slot. Det er en ret smart funktion og betyder, at du ikke behøver at spilde nogen midlertidig lagring på dine opdateringer. Det er derfor, der ikke er nogen cache-partition på A/B-enheder, da de ikke længere er nødvendige.

Hvilken indflydelse har A/B-partitioneringsskemaet på lagringen af ​​en enhed?

Betyder det faktum, at sømløse opdateringer resulterer i en masse duplikerede partitioner, at du mister en masse lagerplads? Slet ikke. Google siger, at enheder med problemfri opdateringsunderstøttelse kun bør være nede omkring et par hundrede megabyte takket være at fjerne /cache- og /recovery-partitionerne. Fjernelse af begge udligner omkostningerne ved at tilføje et andet sæt partitioner. Ifølge Google er Pixels A/B-systembillede halvt så stort som A-only systembilledet. Det meste af det ekstra lagerforbrug kommer faktisk fra tilføjelsen af ​​en anden leverandørpartition. Det giver mening, da leverandørpartitionen huser alle de proprietære binære filer, der bruges af OEM'er (en del af Project Treble), så det forventes at optage en del plads. Selvom Google ikke anbefaler at have A/B-partitionering på enheder med 4 GB lagerplads (da det er næsten 10 % af den samlede tilgængelige lagerplads), anbefaler de det på enheder med 8 GB og højere.

Her er en oversigt over den lagerplads, der bruges på en Google Pixel med og uden A/B-partitioner.

Hvad skete der med gendannelsespartitionen?

Den underliggende Linux-kerne på Android-enheder er det, der lader Android genkende og bruge hardwaren korrekt på en smartphone. På Android-enheder kun A har du generelt to versioner af kernen: Den ene er pakket inde i gendannelsespartitionen, mens den anden er i bootpartitionen. På A/B-enheder, der understøtter problemfri opdateringer, er gendannelsen nu inde i boot-billedet sammen med kernen. Gendannelsens hovedfunktion var at installere opdateringer, men da det håndteres af systemet selv (update_engine) mens Android er startet op, er den dedikerede gendannelsespartition ikke længere nødvendig.

For at installere en brugerdefineret gendannelse på A/B-enheder skal vi derfor ændre boot-partitionen og erstatte lagergendannelsen med vores egen. Dette er grunden til, at du for at installere TWRP skal bruge en fastboot-kommando til at starte et brugerdefineret opstartsbillede først og derefter flash TWRP-installationsscriptet, da fastboot ikke kan patche partitioner - kun flash over dem helt. Du kunne teknisk set forhåndspatche dit eksisterende boot-image med TWRP og derefter flashe det via fastboot, men det er mere besvær, end det er værd. TWRP-installationsscriptet patcher både boot_a- og boot_b-partitionerne for at installere TWRP.

Sjov fakta: Android update_engine, som håndterer problemfri opdateringer, er dybest set rippet direkte fra Chrome OS. Først for nylig blev strenge indeholdende "Chrome OS" fjernet fra update_engines log for at undgå forvirring for alle, der tilfældigvis tjekker logcat.

Understøtter min Android-smartphone A/B-partitioner til problemfri opdateringer?

Mens vi holde en liste over alle enheder der understøtter det, du kan også nemt tjekke dig selv.

---

Hvordan påvirker sømløse opdateringer tilpasset udvikling?

Brugeropfattelse af A/B-partitioner

Anset for at være en hindring for tilpasset softwareudvikling af mange brugere, er sømløse opdateringer faktisk en velsignelse for udviklere. Årsagen til, at A/B-enheder opfattes som dårlig udviklingsstøtte, kommer ned til prisen på de første A/B-enheder. Når alt kommer til alt var Google Pixel-enhederne nogle af de første, der understøttede problemfri opdateringer, og sammenlignet med tidligere tiders Nexus-smartphones var de relativt dyre. Desuden, takket være de utallige forbedringer, Google har foretaget til Android OS, som har lavet brugerdefinerede ROM'er og modifikationer mindre populære på Google-enheder, Google Pixel-smartphones tog ikke så godt fart på vores fora som Nexus smartphones. En kombination af eksterne faktorer førte til et fald i tilpasset udvikling på Google Pixel-smartphones, selvom de fleste brugere valgte at give A/B-partitionsunderstøttelse skylden i stedet for. Sammenlign tilgængeligheden af ​​tilpasset udvikling på enheder som Google Pixel med enheder som Xiaomi Mi A1 på vores fora.

Derudover førte en manglende forståelse af, hvordan A/B-partitioner ændrede den måde, brugerne har brug for til at installere brugerdefinerede ROM'er, kerner, gendannelser og modifikationer, til, at understøttelse af A/B-partitioner var upopulær. Med genoprettelsen nu inde i boot-billedet, kan blinkende ændringer i den forkerte rækkefølge, såsom Magisk eller Xposed, forårsage konflikter og kan føre til en bootloop. Hvilken rækkefølge du flasher disse mods i kan være vigtig, selvom du i tilfælde af brugerdefinerede ROM'er ikke behøver at bekymre dig om, hvilken slot du flasher til. I modsætning til almindelig tro blinker installationsscriptet for de fleste brugerdefinerede ROM'er ikke til begge slots. Du behøver for det meste ikke at bekymre dig om det, da du ikke behøver at bytte slots manuelt.

Sådan ser udviklere A/B-partitioner

Når man bygger en ROM, kan udviklere gøre brug af begge partitioner til at teste separate builds. Hvis en ikke virker, kan de bare vende tilbage til arbejdspartitionen og genopbygge deres ROM. Udviklere kan også teste for regressioner ved blot at installere en opdatering, skifte den aktive partition og sammenligne de to uden at skulle slette data. Sådan ser LineageOS-teamet på understøttelse af A/B-partitioner:

"Mange rundt omkring i Android-fællesskabet har udtalt A/B som værende 'svært at understøtte' og 'ikke udviklervenligt', når det faktisk er korrekt implementeret. nemmere at støtte og lige så udviklervenlig." - jrizzoli, LineageOS Changelog 19

Den indledende vanskelighed med A/B-understøttelse for udviklere kom fra at ændre deres eksisterende værktøjer til at understøtte disse enheder. Udvikleren af ​​Magisk, topjohnwu, tilføjede officiel support til Google Pixel et år efter det frigivet – ikke fordi det var svært, men snarere fordi det tog ham et år at få enheden til arbejde på. TWRP-understøttelse kom ret hurtigt på A/B-enheder, efter at hovedudvikleren, Dees_Troy, tog et knæk på det. LineageOS 15.1 understøtter nu A/B-enheder, efter at frivillige fandt tid til at rette deres addon.d-script.

Sådan opdaterer du en A/B-enhed, der har en tilpasset gendannelse, kerne eller andre mods

Brugerdefinerede ROM'er

Blinkende opdateringer på en enhed med en brugerdefineret ROM betyder, at du også skal være på vagt over, hvilken slot du blinker, ikke? Ikke helt. TWRP vil faktisk håndtere meget af det for dig, og det er som standard den inaktive slot til at blinke en brugerdefineret ROM. Hvis dit aktive slot er A, og du flasher en brugerdefineret ROM, blinker du faktisk til slot B. Når du genstarter, er den aktive plads nu B. Udviklere kan ændre installationsscriptet og flashe til begge slots for at gøre det nemmere for slutbrugeren, selvom de fleste brugerdefinerede ROM-installationsscripts i øjeblikket kun flasher til en enkelt slot. Til sidst kan brugerdefinerede ROM'er implementere en A/B-opdatering i deres ROM, så brugerne ikke engang behøver at rode med manuelt blinkende opdateringer - den seneste LineageOS 15.1 inkluderer et Lineage Updater-værktøj og XDA Senior Member USA-RedDragon lavede en generisk A/B-opdatering som andre udviklere kan bruge.

Lager ROM'er

Men er det ikke problematisk, hvis din enhed kører lager-ROM'en med forskellige modifikationer, og du vil installere en opdatering uden at miste alle disse mods? Det kan være, hvis du ikke kender de rigtige trin til at installere en opdatering. På OnePlus 6 kan du for eksempel ikke flashe en trinvis OTA på din modificerede enhed, fordi den trinvise OTA vil forsøge at lappe dit ændrede bootimage. Således vil du sandsynligvis ende med en bootloop, og det er derfor, du skal flashe den fulde ROM-opdatering for fuldstændigt at overskrive dit ændrede boot-image. Her er de generelle trin, du skal tage for at installere en OxygenOS-opdatering på din OnePlus 6, mens du stadig beholder TWRP, Magisk og eventuelt en brugerdefineret kerne.

1. Downloadede den seneste fuld ROM lynlås
2. Flash den fulde ROM-zip under gendannelse
3. (Valgfrit) Flash tilpasset kerne
4. Flash TWRP installationsprogram
5. Genstart direkte tilbage til gendannelse
6. Flash Magisk

På Google Pixel-enhederne kan du flash fabriksbilledet uden at slette data, start derefter TWRP, installer TWRP via installationsscriptet, og installer derefter Magisk.

Udpakning af en opdatering til flash af individuelle partitionsbilleder

Opdateringsfiler for mange A/B-enheder er lidt anderledes sammenlignet med A-only-enheder. De er ikke længere kun en zip-fil, der indeholder masser af billeder (undtagen Google og Razers fabriksbilleder), i stedet er de i form af en payload.bin-fil. Du kan udpakke denne fil og flashe hver del manuelt, men det kræver et specielt værktøj til at gøre det. Hvis du er interesseret i at lære, hvordan du gør det på OnePlus 6, Xiaomi Mi A1 og mange andre A/B-enheder, så læs videre.

Opsætning til at udtrække payload.bin

1. Sørg for, at du har Python 3.6 installeret.
2. Download payload_dumper.py og update_metadata_pb2.py her.
3. Udpak din OTA-zip og placer payload.bin i samme mappe som disse filer.
4. Åbn PowerShell, Kommandoprompt eller Terminal afhængigt af dit OS.
5. Indtast følgende kommando: python -m pip install protobuf
6. Når det er færdigt, indtast denne kommando: python payload_dumper.py payload.bin
7. Dette vil begynde at udpakke billederne i payload.bin-filen til den aktuelle mappe, du er i.

Du kan flashe hvert af disse billeder separat nu via fastboot, hvis du ønsker det. Det næste afsnit viser dig, hvordan du gør det.

Brug af fastboot til at flashe billeder på en enhed, der understøtter problemfri opdateringer

Der er en række kommandoer, der er eksklusive for A/B-partitionssystemenheder. Du kan ændre dit aktive slot og flash til specifikke slots. Hvis du har en projektdiskant-kompatibel enhed og ønsker at lære at flash Generiske systembilleder, bør du være bekendt med disse kommandoer. Tag et kig på tabellen nedenfor.

(Bemærk: På A/B-enheder kan du enten angive en partition i et bestemt slot, der skal flashes til, eller du kan udelade slot-suffikset, og det blinker til det aktuelle aktive slot. For eksempel kan du erstatte "partition" i flash-kommandoen med "system", "system_a" eller "system_b.")

---

Et ord om Project Diskant og problemfri opdateringer

En almindelig misforståelse er, at det at have Project Treble-understøttelse og A/B-partitionsunderstøttelse er relateret til hinanden, men det er faktisk ikke tilfældet. At have det ene betyder ikke det andet. Motorola Moto Z2 Force bruger et A/B-partitioneringsskema, men understøtter ikke diskant. På den anden side understøtter Honor 9 Lite Project Treble, men er dog kun en A-enhed.

---

Ofte stillede spørgsmål/resumé

• Hvad er fordelene ved A/B-partitionering?
  • A/B-partitionering giver dig mulighed for at opdatere din Android-smartphone, mens du bruger den, ved blot at genstarte, når du er klar til at starte op i den nye version. Det fungerer også som beskyttelse mod mursten - hvis opdateringen går galt, går du tilbage til den fungerende installation.
• Hindrer det at have A/B-partitionering udvikling?
  • Selvom det tog udviklere lidt tid at tilpasse sig, er svaret stort set nej. Faktisk kan det hjælpe udviklere, da de kan dobbeltstarte deres brugerdefinerede ROM med den gamle version og en ny testversion for at tjekke for regressioner.
• Hvordan påvirker A/B-partitioner mods såsom brugerdefinerede kerner, Magisk eller Xposed?
  • Du skal være forsigtig, når du installerer dem, men der er i øjeblikket ingen problemer. Magisk understøtter officielt enheder med problemfri opdateringer, og så længe du flasher tingene i den rigtige rækkefølge, skulle du ikke have nogen problemer. Sørg for at flashe den brugerdefinerede kerne, før du flasher dine andre mods, og du burde være god til at gå.
• Kan jeg flashe to forskellige ROM'er på hver partition og dual boot?
  • I teorien, ja. Der opstår dog problemer på grund af den delte datapartition, så det anbefales ikke.
• Betyder det at have et A/B-partitionsskema, at jeg har reduceret lagerplads?
  • Nix! Google siger, at enheder, der understøtter sømløse opdateringer, kun ofrer et par hundrede megabytes lagerplads for at understøtte det. Fordelene opvejer disse omkostninger.
• Min enhed understøtter A/B-partitioner, betyder det, at jeg kan bruge et Project Treble Generic System Image?
  • Ikke nødvendigvis. Project Diskant og A/B-support er ikke relaterede. Motorola Moto Z2 Force understøtter ikke Project Treble, men alligevel understøtter den A/B-partitionsskemaet.
• Min enhed understøtter Project Treble, betyder det, at jeg har et A/B-partitionsskema?
  • Dette er ikke altid tilfældet. Honor 9 Lite er et godt eksempel, da den understøtter Project Treble, men alligevel ikke har et A/B-partitionsskema.
• Hvorfor skal jeg starte TWRP med fastboot først og derefter flashe det?
  • Dette er på grund af, hvordan fastboot fungerer, og det faktum, at gendannelsespartitionen ikke længere eksisterer. Gendannelse er placeret inde i boot-partitionen, så vi er nødt til at ændre både boot_a og boot_b. Du kan ikke patche en partition i fastboot, kun flashe over den. Du kunne i teorien lave et præpatchet opstartsbillede og derefter flashe det i stedet.
• Er der nogen farer med A/B-partitioner? Hvordan påvirker tilbagerulningsbeskyttelse tingene?
  • Google har prøvet deres bedste for at gøre dette ikke et problem, men i tilfældet med Motorola Moto Z2 Force, der var kendte tilfælde af en enhed, der genaktiverede den ældre slot efter opgradering til Android Oreo. Dette betød, at tilbagerulningsbeskyttelse satte ind, og enhedsejere kunne kun redde deres smartphone med EDL-gendannelse. Google siger, at tilbagerulningsbeskyttelsen først træder i kraft efter første opstart, så slot skal være fuldt funktionsdygtigt efter en opdatering, før du ikke længere kan nedgradere.