Hvordan A/B-partisjoner og sømløse oppdateringer påvirker tilpasset utvikling på XDA

Da Android Nougat ble utgitt, snakket vi om det alle slags nye funksjoner. Vi fikk et nylig oppdatert brukergrensesnitt til å begynne med sammen med etterlengtede multivindusfunksjoner og Vulkan Graphics API-støtte. Men ett tillegg under panseret fløy over hodet på de fleste brukere. Android Nougat introduserte "Sømløse oppdateringer" på enheter som støtter A/B-partisjoner. De aller fleste eksisterende Android-enheter (unntatt de nye Google Pixel og Google Pixel XL) hadde ikke A/B-partisjoner på den tiden og kunne derfor ikke dra nytte av sømløse oppdateringer. Den grunnleggende forutsetningen for denne funksjonen er at enheten har et andre sett med systemet, oppstart, leverandør og andre viktige partisjoner, og når du får en OTA oppdater oppdateringen skjer i bakgrunnen mens det andre settet med partisjoner lappes som lar deg starte på nytt i en oppdatert programvarebygging sømløst. Hvis en oppdatering mislykkes, vil du bli kastet tilbake til en fungerende konstruksjon, noe som betyr at bedrifter vil ha færre hodepine å håndtere og forbrukere er bedre beskyttet.

Støtte for sømløse oppdateringer er ikke et krav for noen nye Android-enheter, i motsetning til Project Treble. Som sådan støtter det store flertallet av nye Android-enheter ikke funksjonen. Vi har holdt en liste over alle støttede enheter så langt, og det er tydelig at denne funksjonen ikke er allment støttet. Det er synd fordi A/B-partisjoner gir mange fordeler for både vanlige brukere og superbrukere. Imidlertid har funksjonen et litt dårlig rykte i entusiastmiljøet fordi det oppfattes å gjøre Android-utvikling og blinkende tilpassede modifikasjoner vanskeligere. Dette er faktisk ikke tilfelle, så vi ønsket å avmystifisere sømløse oppdateringer og forklare hvordan A/B-partisjoner påvirker tilpasset utvikling på XDA.

Tusen takk til XDA Senior Member npjohnson, a Bidragsyter til LineageOS og vedlikeholder av Motorola Moto Z2 Force, som hjalp oss med å sjekke denne artikkelen.

---

Partisjoner på en Android-enhet

En partisjon er ganske enkelt en diskret del på telefonens interne lagring der data lagres. Hva slags data som lagres på hver partisjon avhenger av maskinvaren, operativsystemet og mange andre faktorer. Oppstartslasteren vil ha en, systemet (Android OS) vil ha en, brukerdataene vil ha en... og så videre. Når du ser folk snakke om "/system" og "/cache", refererer de til de gitte navnene for disse partisjonene. OnePlus 6 har for eksempel 72 partisjoner. Det høres ut som mye, men OnePlus 6 er en av enhetene som støtter sømløse oppdateringer, noe som betyr at mange av disse partisjonene ganske enkelt er duplikater av hverandre.

Delvis utgang av partisjonene på OnePlus 6. Noen A/B-partisjoner er understreket for demonstrasjonsformål.

Det er mange partisjoner på en enhet som du aldri trenger å bekymre deg for som bruker. Mange av disse partisjonene blir aldri modifisert når du blinker tilpassede ROM-er, kjerner, gjenopprettinger eller modifikasjoner som Magisk eller Xposed. Mange av disse partisjonene vil enten være ubrukte til våre formål eller er for farlige å berøre med mindre du vet hva du gjør (XLOADER og OEMINFO på Huawei/Honor enheter kommer til tankene.) For det store flertallet av Android-brukere er partisjonene vi stort sett arbeider med system, oppstart, gjenoppretting, brukerdata og mer nylig leverandør og vbmeta. Her er en kort forklaring på formålet med hver partisjon:

• system - inneholder Android OS, systembiblioteker, systemapper og andre systemmedier som bootanimasjoner, bakgrunnsbilder, ringetoner osv.
• boot - holder kjernen, ramdisken og på A/B-enheter også gjenopprettingen
• gjenoppretting - holder gjenopprettingen, der TWRP oftest flashes på bare A-enheter (A/B-enheter har ikke en dedikert gjenopprettingspartisjon)
• brukerdata – inneholder alle app-, system- og interne lagringsdata
• leverandør - har plattform- og enhetsspesifikke HAL-er, filene som er nødvendige for at Android OS skal kommunisere med den underliggende maskinvaren
• vbmeta - partisjonen for Android Verified Boot 2.0 som verifiserer integriteten til oppstartsprosessen

Enhets-OEM-er kan endre partisjonsskjemaene sine for å bruke den layouten de ønsker. For eksempel deler Huawei oppstartspartisjonen i ramdisk_recovery og kjerne. Det er også mange ekstra partisjoner som kan inneholde andre systemapper som tilpasset, produkt og oem, og mens disse er trygge å endre, det anbefales generelt ikke hvis du ønsker å gjøre det enklere for deg selv å gå tilbake til lageret. Så hvor spiller A/B-partisjoner en rolle?

---

A/B-partisjonsordningen

Hvordan oppdateringer fungerer på enheter med sømløse oppdateringer

Det veldig enkle bildet jeg laget nedenfor illustrerer hvordan en oppdatering håndteres på en enhet med A/B-partisjonsstøtte. Partisjonen som er illustrert er systempartisjonen, selv om andre partisjoner som boot og leverandør også kan oppdateres med en gitt OTA-oppdatering fra en OEM. Denne oppdateringsprosessen skjer med ikke bare store Android-versjonsoppdateringer, men også sikkerhetsoppdateringer.

1. Vi starter med to systempartisjoner, system_a og system_b, begge på samme versjon av Android.
2. Forutsatt at system_a er aktiv, vil OTA-oppdateringen patche system_b, den inaktive partisjonen, i bakgrunnen.
3. system_a er satt til inaktiv og system_b blir deretter aktiv når brukeren starter på nytt.
4. Den nå inaktive partisjonen, system_a, vil bli oppdatert når neste OTA-oppdatering ruller ut.

Hva er fordelene med denne oppdateringsprosessen?

1. Hvis en oppdatering mislykkes, vil enheten rulle tilbake til den fungerende bygningen på det andre sporet.
2. Dataene dine holdes perfekt intakt, selv om oppdateringen er borket, siden det bare er én partisjon (brukerdata) som inneholder dataene dine.
3. Oppdater streaming: Hvis datapartisjonen din er full, kan oppdateringen lastes ned og streames til det inaktive sporet. Det er en ganske ryddig funksjon og betyr at du ikke trenger å kaste bort noe midlertidig lagring på oppdateringene dine. Det er derfor det ikke er noen cache-partisjon på A/B-enheter siden de ikke lenger er nødvendige.

Hvilken innvirkning har A/B-partisjoneringsskjemaet på lagringen av en enhet?

Betyr det at sømløse oppdateringer resulterer i en haug med dupliserte partisjoner at du mister en haug med lagringsplass? Ikke i det hele tatt. Google sier at enheter med sømløs oppdateringsstøtte bare skal være nede rundt noen få hundre megabyte takket være å fjerne /cache- og /recovery-partisjonene. Å fjerne begge balanserer kostnadene ved å legge til et andre sett med partisjoner. Ifølge Google er Pixels A/B-systembilde halvparten av størrelsen på A-only systembildet. Mesteparten av den ekstra lagringsbruken kommer faktisk fra tillegget av en andre leverandørpartisjon. Det er fornuftig siden leverandørpartisjonen inneholder alle de proprietære binærfilene som brukes av OEM-er (en del av Project Treble), så det forventes å ta opp ganske mye plass. Selv om Google ikke anbefaler å ha A/B-partisjonering på enheter med 4 GB lagringsplass (ettersom det er nesten 10 % av totalt tilgjengelig lagringsplass), anbefaler de det på enheter med 8 GB og høyere.

Her er en oversikt over lagringsplassen som brukes på en Google Pixel med og uten A/B-partisjoner.

Hva skjedde med gjenopprettingspartisjonen?

Den underliggende Linux-kjernen på Android-enheter er det som lar Android gjenkjenne og bruke maskinvaren riktig på en smarttelefon. På A-bare Android-enheter har du vanligvis to versjoner av kjernen: Den ene er pakket inne i gjenopprettingspartisjonen mens den andre er i oppstartspartisjonen. På A/B-enheter som støtter sømløse oppdateringer, er gjenopprettingen nå inne i oppstartsbildet sammen med kjernen. Gjenopprettingens hovedfunksjon var å installere oppdateringer, men siden det håndteres av systemet selv (update_engine) mens Android er startet opp er den dedikerte gjenopprettingspartisjonen ikke lenger nødvendig.

For å installere en tilpasset gjenoppretting på A/B-enheter, må vi derfor endre oppstartspartisjonen og erstatte lagergjenopprettingen med vår egen. Dette er grunnen til at du for å installere TWRP må bruke en fastboot-kommando for å starte opp et tilpasset oppstartsbilde først og deretter flash TWRP-installasjonsskriptet, siden fastboot ikke kan lappe partisjoner – bare flash over dem fullstendig. Du kan teknisk forhåndspatche det eksisterende oppstartsbildet ditt med TWRP og deretter flashe det via fastboot, men det er mer trøbbel enn det er verdt. TWRP-installasjonsskriptet retter både boot_a- og boot_b-partisjonene for å installere TWRP.

Morsomt faktum: Android update_engine som håndterer sømløse oppdateringer er i utgangspunktet dratt rett fra Chrome OS. Bare nylig ble strenger som inneholder "Chrome OS" fjernet fra update_engines logg for å unngå forvirring for alle som tilfeldigvis sjekker logcat.

Støtter min Android-smarttelefon A/B-partisjoner for sømløse oppdateringer?

Mens vi holde en liste over alle enheter som støtter det, du kan også enkelt sjekke selv.

---

Hvordan påvirker sømløse oppdateringer tilpasset utvikling?

Brukeroppfatning av A/B-partisjoner

Ansett som en hindring for utvikling av tilpasset programvare av mange brukere, er sømløse oppdateringer faktisk en velsignelse for utviklere. Årsaken til at A/B-enheter oppfattes å ha dårlig utviklingsstøtte kommer ned til prisen på de første A/B-enhetene. Tross alt var Google Pixel-enhetene noen av de første som støttet sømløse oppdateringer, og sammenlignet med Nexus-smarttelefonene fra før var de relativt dyre. Videre, takket være utallige forbedringer Google har gjort til Android OS som har laget tilpassede ROM-er og modifikasjoner mindre populære på Google-enheter, Google Pixel-smarttelefonene tok ikke like bra fart på forumene våre som Nexus smarttelefoner. En kombinasjon av eksterne faktorer førte til en nedgang i tilpasset utvikling på Google Pixel-smarttelefonene, selv om de fleste brukere valgte å skylde på støtte for A/B-partisjoner i stedet. Sammenlign tilgjengeligheten av tilpasset utvikling på enheter som Google Pixel med enheter som Xiaomi Mi A1 på våre forum.

I tillegg førte mangel på forståelse av hvordan A/B-partisjoner endret måten brukere trenger for å installere tilpassede ROM-er, kjerner, gjenopprettinger og modifikasjoner til at støtte for A/B-partisjoner ble upopulær. Med gjenopprettingen nå inne i oppstartsbildet, kan blinkende modifikasjoner i feil rekkefølge som Magisk eller Xposed forårsake konflikter og kan føre til en oppstartssløyfe. Hvilken rekkefølge du flasher disse modsene i kan være viktig, men når det gjelder tilpassede ROM-er, bør du ikke bekymre deg for hvilket spor du blinker til. I motsetning til vanlig tro, blinker ikke installasjonsskriptet for de fleste tilpassede ROM-er til begge sporene. Du trenger stort sett ikke bekymre deg for det, siden du ikke trenger å bytte spor manuelt.

Hvordan utviklere ser på A/B-partisjoner

Når du bygger en ROM, kan utviklere bruke begge partisjonene for å teste separate bygg. Hvis en ikke fungerer, kan de bare gå tilbake til arbeidspartisjonen og gjenoppbygge ROM-en. Utviklere kan også teste for regresjoner ved ganske enkelt å installere en oppdatering, bytte den aktive partisjonen og sammenligne de to uten å måtte slette data. Slik ser LineageOS-teamet på støtte for A/B-partisjoner:

"Mange rundt i Android-fellesskapet har utskjelt A/B som "vanskelig å støtte" og "ikke utviklervennlig", når det faktisk er riktig implementert. lettere å støtte og like utviklervennlig." - jrizzoli, LineageOS Changelog 19

De første vanskelighetene med A/B-støtte for utviklere kom fra å endre eksisterende verktøy for å støtte disse enhetene. Utvikleren av Magisk, topjohnwu, la til offisiell støtte for Google Pixel et år etter det utgitt – ikke fordi det var vanskelig, men snarere fordi det tok ham et år å faktisk få tak i enheten jobbe med. TWRP-støtte kom ganske raskt på A/B-enheter etter at hovedutvikleren, Dees_Troy, tok en knekk på det. LineageOS 15.1 støtter nå A/B-enheter etter at frivillige fant tid til å fikse addon.d-skriptet.

Hvordan oppdatere en A/B-enhet som har en tilpasset gjenoppretting, kjerne eller andre mods

Egendefinerte ROM-er

Blinkende oppdateringer på en enhet med en tilpasset ROM betyr at du må være forsiktig med hvilket spor du blinker også, ikke sant? Ikke helt. TWRP vil faktisk håndtere mye av det for deg, og det er som standard det inaktive sporet for å blinke en tilpasset ROM. Hvis det aktive sporet ditt er A og du flasher en tilpasset ROM, blinker du faktisk til spor B. Når du starter på nytt, er det aktive sporet nå B. Utviklere kan modifisere installasjonsskriptet og flashe til begge sporene for å gjøre det enklere for sluttbrukeren, selv om de fleste tilpassede ROM-installasjonsskript for øyeblikket bare flasher til et enkelt spor. Til slutt kan tilpassede ROM-er implementere en A/B-oppdatering i ROM-en slik at brukerne ikke engang trenger å rote med manuelt blinkende oppdateringer – den siste LineageOS 15.1 inkluderer et Lineage Updater-verktøy og XDA Senior Member USA-RedDragon lagde en generisk A/B-oppdatering som andre utviklere kan bruke.

Lager ROM-er

Men er det ikke problematisk hvis enheten din kjører lager-ROM med forskjellige modifikasjoner og du vil installere en oppdatering uten å miste alle disse modsene? Det kan være hvis du ikke vet de riktige trinnene for å installere en oppdatering. På OnePlus 6, for eksempel, kan du ikke flashe en inkrementell OTA på den modifiserte enheten din fordi den inkrementelle OTA vil forsøke å lappe det modifiserte oppstartsbildet ditt. Dermed vil du sannsynligvis ende opp med en bootloop, og det er derfor du må flashe hele ROM-oppdateringen for å fullstendig overskrive det modifiserte oppstartsbildet ditt. Her er de generelle trinnene du må ta for å installere en OxygenOS-oppdatering på OnePlus 6 mens du fortsatt beholder TWRP, Magisk og eventuelt en tilpasset kjerne.

1. Lastet ned det siste full ROM glidelås
2. Flash hele ROM-zipen under gjenoppretting
3. (Valgfritt) Flash tilpasset kjerne
4. Flash TWRP-installasjonsprogram
5. Start på nytt rett tilbake til gjenoppretting
6. Flash Magisk

På Google Pixel-enhetene kan du flash fabrikkbildet uten å tørke data, start deretter TWRP, installer TWRP via installasjonsskriptet, og installer deretter Magisk.

Trekker ut en oppdatering for å flashe individuelle partisjonsbilder

Oppdateringsfiler for mange A/B-enheter er litt annerledes sammenlignet med A-bare enheter. De er ikke lenger bare en zip-fil som inneholder mange bilder (unntatt Google og Razers fabrikkbilder), i stedet er de i form av en payload.bin-fil. Du kan pakke ut denne filen og flashe hver del manuelt, men det krever et spesielt verktøy for å gjøre det. Hvis du er interessert i å lære hvordan du gjør det på OnePlus 6, Xiaomi Mi A1 og mange andre A/B-enheter, les videre.

Oppsett for å trekke ut payload.bin

1. Sørg for at du har Python 3.6 installert.
2. Last ned payload_dumper.py og update_metadata_pb2.py her.
3. Pakk ut OTA-zipen og plasser payload.bin i samme mappe som disse filene.
4. Åpne PowerShell, ledetekst eller terminal avhengig av operativsystemet ditt.
5. Skriv inn følgende kommando: python -m pip install protobuf
6. Når det er ferdig, skriv inn denne kommandoen: python payload_dumper.py payload.bin
7. Dette vil begynne å trekke ut bildene i payload.bin-filen til den gjeldende mappen du er i.

Du kan flashe hvert av disse bildene separat nå via fastboot hvis du ønsker det. Den neste delen viser deg hvordan du gjør det.

Bruke fastboot til å flashe bilder på en enhet som støtter sømløse oppdateringer

Det er en rekke kommandoer som er eksklusive for A/B-partisjonssystemenheter. Du kan endre ditt aktive spor og flash til spesifikke spor. Hvis du har en prosjektdiskant-kompatibel enhet og ønsker å lære hvordan flash Generiske systembilder, bør du være kjent med disse kommandoene. Ta en titt på tabellen nedenfor.

(Merk: På A/B-enheter kan du enten spesifisere en partisjon i et bestemt spor å blinke til, eller du kan utelate sporsuffikset og det vil blinke til det gjeldende aktive sporet. For eksempel kan du erstatte "partisjon" i flash-kommandoen med "system", "system_a" eller "system_b.")

---

Et ord om Project Diskant og sømløse oppdateringer

En vanlig misforståelse er at støtte for Project Treble og A/B-partisjonsstøtte er relatert til hverandre, men det er faktisk ikke tilfelle. Å ha det ene betyr ikke det andre. Motorola Moto Z2 Force bruker et A/B-partisjoneringsskjema, men støtter ikke diskant. På den annen side støtter Honor 9 Lite Project Treble, men er likevel en A-only enhet.

---

Ofte stilte spørsmål/oppsummering

• Hva er fordelene med A/B-partisjonering?
  • A/B-partisjonering lar deg oppdatere Android-smarttelefonen din mens du bruker den, bare omstart når du er klar til å starte opp i den nye versjonen. Den fungerer også som beskyttelse mot murstein – hvis oppdateringen går galt, går du tilbake til den fungerende installasjonen.
• Hindrer det å ha A/B-partisjonering utvikling?
  • Selv om det tok utviklerne litt tid å tilpasse seg, er svaret stort sett nei. Faktisk kan det hjelpe utviklere ettersom de kan dobbeltstarte sin egendefinerte ROM med den gamle versjonen og en ny testversjon for å se etter regresjoner.
• Hvordan påvirker A/B-partisjoner mods som tilpassede kjerner, Magisk eller Xposed?
  • Du må være forsiktig når du installerer dem, men det er for øyeblikket ingen problemer. Magisk støtter offisielt enheter med sømløse oppdateringer, og så lenge du flasher ting i riktig rekkefølge bør du ikke ha noen problemer. Sørg for å flashe den tilpassede kjernen før du flasher de andre moddene dine, og du bør være i gang.
• Kan jeg flashe to forskjellige ROM-er på hver partisjon og dual boot?
  • I teorien, ja. Det oppstår imidlertid problemer på grunn av den delte datapartisjonen, så det anbefales ikke.
• Betyr det å ha en A/B-partisjonsordning at jeg har redusert lagringsplass?
  • Nei! Google sier at enheter som støtter sømløse oppdateringer bare ofrer noen få hundre megabyte lagringsplass for å støtte det. Fordelene oppveier den kostnaden.
• Enheten min støtter A/B-partisjoner, betyr det at jeg kan bruke et Project Treble Generic System Image?
  • Ikke nødvendigvis. Project Diskant og A/B-støtte er ikke relatert. Motorola Moto Z2 Force støtter ikke Project Treble, men den støtter A/B-partisjonsskjemaet.
• Enheten min støtter Project Treble, betyr det at jeg har et A/B-partisjonsskjema?
  • Dette er ikke alltid tilfelle. Honor 9 Lite er et godt eksempel ettersom den støtter Project Treble, men ikke har et A/B-partisjonsskjema.
• Hvorfor må jeg starte opp TWRP med fastboot først og deretter flashe den?
  • Dette er på grunn av hvordan fastboot fungerer og det faktum at gjenopprettingspartisjonen ikke lenger eksisterer. Gjenoppretting er plassert inne i oppstartspartisjonen, så vi må endre både boot_a og boot_b. Du kan ikke lappe en partisjon i fastboot, bare flashe over den. Du kan i teorien lage et forhåndspatchet oppstartsbilde og deretter flashe det i stedet.
• Er det noen farer med A/B-partisjoner? Hvordan påvirker tilbakerullingsbeskyttelse ting?
  • Google har prøvd sitt beste for å gjøre dette ikke et problem, men i tilfelle av Motorola Moto Z2 Force, det var kjente tilfeller av en enhet som reaktiverte det eldre sporet etter oppgradering til Android Oreo. Dette betydde at tilbakerullingsbeskyttelsen startet, og enhetseiere kunne bare redde smarttelefonen med EDL-gjenoppretting. Google sier at tilbakerullingsbeskyttelsen bare starter etter første oppstart, så sporet må fungere fullt ut etter en oppdatering før du ikke lenger kan nedgradere.