Kuidas A/B-partitsioonid ja sujuvad värskendused mõjutavad XDA kohandatud arendust

Võib-olla olete varem kuulnud sujuvatest värskendustest. See hõlmab midagi, mida nimetatakse "A/B vaheseinteks". Mis see on ja kuidas see mõjutab XDA kohandatud arendust?

Kui Android Nougat välja tuli, pani see meid rääkima igasuguseid uusi funktsioone. Saime äsja värskendatud kasutajaliidese algajatele koos kauaoodatud mitme akna võimalustega ja Vulkan Graphics API toega. Kuid üks kapotialune lisa lendas enamiku kasutajate peade kohal. Android Nougat tutvustas seadmetes, mis toetavad A/B-sektsioone, "õmblusteta värskendusi". Enamikul olemasolevatest Android-seadmetest (v.a uus Google Pixel ja Google Pixel XL) ei olnud sel ajal A/B-sektsioone ja seetõttu ei saanud nad sujuvaid värskendusi ära kasutada. Selle funktsiooni põhieeldus on, et seadmel on teine ​​komplekt süsteemist, alglaadimisest, tarnijast ja muudest olulistest partitsioonidest ning kui saate OTA Värskendamine toimub taustal, samal ajal kui teine ​​partitsioonide komplekt on paigatud, mis võimaldab teil sujuvalt taaskäivitada värskendatud tarkvaraversioon. Kui värskendus ebaõnnestub, suunatakse teid tagasi töötava konstruktsiooni juurde, mis tähendab, et ettevõtetel on vähem peavalu ja tarbijad on paremini kaitstud.

Erinevalt Project Treble'ist ei ole sujuvate värskenduste toetamine ühegi uue Android-seadme jaoks nõutav. Seetõttu ei toeta enamik uusi Android-seadmeid seda funktsiooni. Oleme seni pidanud loendit kõigist toetatud seadmetest, ja on selge, et seda funktsiooni laialdaselt ei toetata. Sellest on kahju, sest A/B-partitsioonid toovad palju kasu nii tavakasutajatele kui ka tavakasutajatele. Sellel funktsioonil on entusiastide kogukonnas aga pisut halb maine, kuna arvatakse, et see muudab Androidi arendamise ja kohandatud muudatuste vilkumise keerulisemaks. See pole tegelikult nii, seega tahtsime demüstifitseerida sujuvaid värskendusi ja selgitada, kuidas A/B-sektsioonid mõjutavad XDA kohandatud arendust.

Suur tänu XDA vanemliikmele npjohnson, a kaasaaitaja LineageOS ja hooldaja Motorola Moto Z2 Force, kes aitas meil seda artiklit kontrollida.


Android-seadme partitsioonid

Sektsioon on lihtsalt diskreetne osa telefoni sisemälus, kus andmeid hoitakse. Milliseid andmeid igal partitsioonil hoitakse, sõltub riistvarast, operatsioonisüsteemist ja paljudest muudest teguritest. Alglaaduril on üks, süsteemil (Android OS) üks, kasutajaandmetel üks... ja nii edasi. Kui näete, et inimesed räägivad sõnadest "/system" ja "/cache", viitavad nad nende partitsioonide eesnimedele. Näiteks OnePlus 6-l on 72 vaheseina. See kõlab palju, kuid OnePlus 6 on üks seadmetest, mis toetab sujuvaid värskendusi, mis tähendab, et paljud neist partitsioonidest on lihtsalt üksteise duplikaadid.

OnePlus 6 partitsioonide osaline väljund. Mõned A/B-partitsioonid on tutvustamise eesmärgil alla joonitud.

Seadmes on palju partitsioone, mille pärast te kasutajana kunagi muretsema ei pea. Paljusid neist partitsioonidest ei muudeta kunagi kohandatud ROM-ide, tuumade, taaste või modifikatsioonide (nt Magisk või Xposed) vilkumisel. Paljud neist vaheseintest jäävad meie eesmärkidel kasutamata või on puudutamiseks liiga ohtlikud, kui te ei tea, mida teete (XLOADER ja OEMINFO Huaweil/Honoril seadmed tulevad meelde.) Enamiku Androidi kasutajate jaoks on partitsioonid, millega me enamasti tegeleme, on süsteem, alglaadimine, taastamine, kasutajaandmed ning hiljuti tarnija ja vbmeta. Siin on iga partitsiooni eesmärgi lühike selgitus:

  • süsteem – sisaldab Android OS-i, süsteemiteeke, süsteemirakendusi ja muud süsteemimeediat, nagu alglaadimine, taustpildid, helinad jne.
  • boot - sisaldab kernelit, ramdisket ja A/B-seadmetel ka taastamist
  • taastamine – säilitab taastamise, kus TWRP-d välgutatakse kõige sagedamini ainult A-seadmetes (A/B-seadmetel pole spetsiaalset taastesektsiooni)
  • kasutajaandmed – sisaldab kõiki teie rakenduse, süsteemi ja sisemälu andmeid
  • tarnija – sisaldab platvormi- ja seadmepõhiseid HAL-e, faile, mis on vajalikud Android OS-i jaoks aluseks oleva riistvaraga suhtlemiseks
  • vbmeta – Android Verified Boot 2.0 partitsioon, mis kontrollib alglaadimisprotsessi terviklikkust

Seadme originaalseadmete tootjad saavad muuta oma partitsiooniskeeme, et kasutada mis tahes paigutust, mida nad soovivad. Näiteks Huawei jagab alglaadimise partitsiooni ramdisk_recovery ja kernel. Samuti on palju täiendavaid partitsioone, mis võivad sisaldada muid süsteemirakendusi, nagu cust, product ja oem, ning samas neid on ohutu muuta, üldiselt pole see soovitatav, kui soovite laost tagasi naasmist enda jaoks lihtsamaks muuta. Kus siis A/B vaheseinad rolli mängivad?


A/B jaotusskeem

Kuidas värskendused sujuvate värskendustega seadmetes töötavad

Allpool tehtud väga lihtne pilt illustreerib, kuidas A/B-sektsiooni toega seadmes värskendusi käsitletakse. Illustreeritud partitsioon on süsteemi partitsioon, kuigi ka muid partitsioone, nagu alglaadimine ja tarnija, võidakse värskendada OTA-värskendustega OEM-ilt. See värskendusprotsess toimub mitte ainult suuremate Androidi versioonivärskenduste, vaid ka turvapaiga värskendustega.

  1. Alustame kahe süsteemisektsiooniga, süsteem_a ja süsteem_b, mõlemad samas Androidi versioonis.
  2. Eeldades, et system_a on aktiivne, parandab OTA värskendus taustal passiivse partitsiooni system_b.
  3. system_a on seatud passiivseks ja system_b muutub aktiivseks, kui kasutaja taaskäivitub.
  4. Praegu passiivset partitsiooni system_a värskendatakse järgmise OTA värskenduse väljaselgitamisel.

Millised on selle värskendusprotsessi eelised?

  1. Kui värskendamine ebaõnnestub, naaseb seade teise pesa töötavale järgule.
  2. Teie andmeid hoitakse täiesti puutumatuna, isegi kui värskendus on katkenud, kuna teie andmeid on ainult üks partitsioon (kasutajaandmed).
  3. Värskenduste voogesitus: kui teie andmesektsioon on täis, saab värskenduse alla laadida ja passiivsesse pessa voogesitada. See on päris kena funktsioon ja tähendab, et te ei pea oma värskendustele ajutist salvestusruumi raiskama. Seetõttu pole A/B-seadmetes vahemälu partitsiooni, kuna neid pole enam vaja.

Millist mõju avaldab A/B jaotusskeem seadme salvestusele?

Kas tõsiasi, et sujuvate värskenduste tulemuseks on hunnik dubleeritud partitsioone, tähendab, et kaotate hulga salvestusruumi? Üldse mitte. Google ütleb, et tõrgeteta värskenduste toega seadmed peaksid tänu partitsioonide /cache ja /recovery eemaldamisele langema vaid umbes paarsada megabaiti. Mõlema eemaldamine tasakaalustab teise partitsioonide komplekti lisamise kulud. Google'i andmetel on Pixeli A/B süsteemipilt poole väiksem kui ainult A-süsteemi kujutis. Suurem osa täiendavast salvestusruumi kasutusest tuleneb tegelikult teise tarnija partitsiooni lisamisest. See on mõistlik, kuna müüja partitsioonis on kõik originaalseadmete tootjate kasutatavad binaarfailid (osa Project Treble'ist), seega võtab see eeldatavasti üsna vähe ruumi. Kuigi Google ei soovita A/B-seotust seadmetes, millel on 4 GB salvestusruumi (kuna see moodustab peaaegu 10% kogu saadaolevast salvestusruumist), soovitavad nad seda 8 GB ja suurema mälumahuga seadmetes.

Siin on A/B-sektsioonidega ja ilma nendeta Google Pixelis kasutatava salvestusruumi jaotus.

Vaheseinte suurused

A/B

Ainult A-

Alglaadur

50 MB*2

50 MB

Boot

32MB*2

32 MB

Taastumine

32 MB

Vahemälu

100 MB

Raadio

70 MB*2

70 MB

Müüja

300 MB*2

300 MB

Süsteem

2048 MB*2

4096 MB

Kokku

5000 MB

4680 MB

Mis juhtus taastepartitsiooniga?

Android-seadmete aluseks olev Linuxi tuum võimaldab Androidil nutitelefoni riistvara ära tunda ja õigesti kasutada. Ainult A-tüüpi Android-seadmetes on tavaliselt kaks kerneli versiooni: üks on pakitud taastesektsiooni sisse, teine ​​aga alglaadimise partitsiooni. Sujuvaid värskendusi toetavates A/B-seadmetes on taastamine nüüd koos tuumaga alglaadimispildi sees. Taastamise põhifunktsioon oli värskenduste installimine, kuid kuna sellega tegeleb süsteem ise (update_engine), kui Android on käivitatud, pole spetsiaalset taastesektsiooni enam vaja.

A/B-seadmetele kohandatud taastamise installimiseks peame seega muutma alglaadimise partitsiooni ja asendama varude taastamise enda omaga. Seetõttu peate TWRP installimiseks kasutama kiirkäivituskäsku, et esmalt käivitada kohandatud alglaadimispilt ja siis TWRP installiskripti välgutamine, kuna kiirkäivitus ei saa partitsioone paika panna – piisab ainult nende täielikust muutmisest. Võiksite oma olemasoleva alglaadimispildi tehniliselt TWRP-ga eelnevalt parandada ja seejärel kiirkäivituse kaudu flashida, kuid see on rohkem vaeva kui asi väärt. TWRP installiskript parandab TWRP installimiseks nii partitsioonid boot_a kui ka boot_b.

Lõbus fakt: Androidi uuendusmootor, mis tegeleb sujuvate värskendustega, on põhimõtteliselt rippitud otse Chrome OS-ist. Alles hiljuti kas "Chrome OS-i" sisaldavad stringid eemaldati update_engine logist, et vältida segadust kõigi jaoks, kes juhtuvad logcati kontrollima.

Kas minu Android-nutitelefon toetab sujuvate värskenduste jaoks A/B-sektsioone?

Samal ajal kui meie pidage kõigi seadmete loendit mis seda toetavad, saate ka ise hõlpsasti kontrollida.


Kuidas sujuvad värskendused kohandatud arendust mõjutavad?

Kasutaja arusaam A/B-sektsioonidest

Paljud kasutajad peavad kohandatud tarkvaraarendust takistuseks, kuid sujuvad värskendused on arendajatele tegelikult õnnistuseks. Põhjus, miks A/B-seadmete arendustoetust peetakse kehvaks, taandub esimeste A/B-seadmete hinnale. Lõppude lõpuks olid Google Pixeli seadmed ühed esimesed, mis toetasid sujuvaid värskendusi ja võrreldes eelmiste Nexuse nutitelefonidega olid need suhteliselt kallid. Lisaks, tänu arvukatele täiustustele, mida Google on teinud Android OS-is, mis on teinud kohandatud ROM-e ja Google'i seadmetes vähem populaarsed muudatused, ei saanud Google Pixeli nutitelefonid meie foorumites nii hästi esile kui Nexus nutitelefonid. Väliste tegurite kombinatsioon tõi kaasa Google Pixeli nutitelefonide kohandatud arenduse vähenemise, kuigi enamik kasutajaid otsustas selle asemel süüdistada A/B-sektsiooni tuge. Võrrelge kohandatud arenduse saadavust sellistes seadmetes nagu Google Pixel selliste seadmetega nagu Xiaomi Mi A1 meie foorumites.

Lisaks põhjustas ebapopulaarne arusaamine sellest, kuidas A/B-sektsioonid muutsid viisi, kuidas kasutajad peavad installima kohandatud ROM-e, tuumasid, taasteid ja muudatusi. Kuna taastamine asub nüüd alglaadimispildi sees, võivad vales järjekorras vilkuvad muudatused, nagu Magisk või Xposed, põhjustada konflikte ja põhjustada alglaadimissilmuse. See, millises järjekorras neid modifikatsioone välgutate, võib olla oluline, kuigi kohandatud ROM-ide puhul ei peaks te muretsema selle pärast, millisesse pesasse vilgutate. Vastupidiselt levinud arvamusele ei vilgu enamiku kohandatud ROM-ide installiskript mõlemasse pesasse. Tavaliselt ei pea te selle pärast muretsema, kuna te ei peaks pesasid käsitsi vahetama.

Kuidas arendajad vaatavad A/B-sektsioone

ROM-i loomisel saavad arendajad kasutada mõlemat partitsiooni, et testida eraldi ehitusi. Kui see ei tööta, saavad nad lihtsalt naasta töötava partitsiooni juurde ja oma ROM-i uuesti üles ehitada. Arendajad saavad ka regressioone testida, installides lihtsalt värskenduse, vahetades aktiivset partitsiooni ja võrdledes neid kahte ilma andmeid kustutamata. LineageOS-i meeskond vaatab A/B-sektsiooni tuge järgmiselt.

"Paljud Androidi kogukonnas on A/B-d nimetanud "raskesti toetatavaks" ja "mitte arendajasõbralikuks", kuigi tegelikult on see õigesti rakendatud. lihtsam toetada ja sama arendajasõbralik." - jrizzoli, LineageOS-i muudatuste logi 19

Esialgsed raskused A/B toega arendajatele tekkisid olemasolevate tööriistade muutmisest, et neid seadmeid toetada. Magiski arendaja topjohnwu lisas Google Pixelile ametliku toe aasta pärast seda vabastati – mitte sellepärast, et see oli raske, vaid pigem seetõttu, et seadme hankimiseks kulus tal aasta millegi kallal töötama. TWRP tugi tuli päris kiiresti A/B-seadmetes pärast seda, kui juhtivarendaja Dees_Troy selle kallal lõi. LineageOS 15.1 nüüd toetab A/B-seadmed pärast seda, kui vabatahtlikud leidsid aega oma addon.d skripti parandamiseks.

Kuidas värskendada A/B-seadet, millel on kohandatud taastamine, kernel või muud modifikatsioonid

Kohandatud ROM-id

Värskenduste vilkumine kohandatud ROM-iga seadmes tähendab, et peate olema ettevaatlik, mis pesa vilgub, eks? Mitte päris. TWRP tegeleb sellega tegelikult teie eest ja vaikimisi on kohandatud ROM-i vilkumiseks passiivne pesa. Kui teie aktiivne pesa on A ja vilgutate kohandatud ROM-i, vilgute tegelikult pesas B. Taaskäivitamisel on aktiivne pesa nüüd B. Arendajad saavad lõppkasutaja jaoks lihtsamaks muutmiseks installiskripti ja flashi mõlemasse pesa muuta, kuigi enamik kohandatud ROM-i installiskripte vilgub praegu ainult ühes pesas. Lõpuks saavad kohandatud ROM-id lisada oma ROM-i A/B-värskendaja, nii et kasutajad ei pea isegi sellega segama käsitsi vilkuvad värskendused – uusim LineageOS 15.1 sisaldab Lineage Updateri tööriista ja XDA vanemliiget USA-RedDragon tegi üldine A/B värskendaja mida teised arendajad saavad kasutada.

Lao ROM-id

Kuid kas see pole problemaatiline, kui teie seadmes töötab mitmesuguste muudatustega varu-ROM ja soovite installida värskenduse ilma kõiki neid modifikatsioone kaotamata? See võib juhtuda, kui te ei tea värskenduse installimiseks õigeid samme. Näiteks OnePlus 6 puhul ei saa te oma muudetud seadmes astmelist OTA-d välgutada, kuna astmeline OTA proovib teie muudetud alglaadimispilti parandada. Seega tekib tõenäoliselt alglaadimissilmus ja seetõttu peate modifitseeritud alglaadimispildi täielikuks ülekirjutamiseks ROM-i täieliku värskenduse vilkuma. Siin on üldised sammud, mida peate tegema OxygenOS-i värskenduse installimiseks oma OnePlus 6-sse, säilitades samas TWRP, Magiski ja valikuliselt kohandatud kerneli.

  1. Laaditi alla uusim täis ROM tõmblukk
  2. Värskendage taastamisel kogu ROM-i zip
  3. (Valikuline) Flashi kohandatud kernel
  4. Flash TWRP installer
  5. Taaskäivitage otse taastamise juurde
  6. Flash Magisk

Google Pixeli seadmetes saate seda teha tehasepilt välgub ilma andmeid kustutamata, seejärel käivitage TWRP, installige TWRP installiskripti kaudu ja seejärel installige Magisk.

Värskenduse ekstraktimine üksikute partitsioonipiltide välgutamiseks

Paljude A/B-seadmete värskendusfailid on ainult A-seadmetega võrreldes pisut erinevad. Need pole enam lihtsalt ZIP-failid, mis sisaldavad palju pilte (v.a Google'i ja Razeri tehasepildid), vaid need on faili payload.bin kujul. Saate selle faili ekstraktida ja iga osa käsitsi flashida, kuid selleks on vaja spetsiaalset tööriista. Kui soovite õppida, kuidas seda OnePlus 6, Xiaomi Mi A1 ja paljude teiste A/B-seadmetega teha, lugege edasi.

Seadistamine payload.bin ekstraktimiseks

  1. Veenduge, et teil oleks Python 3.6 paigaldatud.
  2. Laadige alla payload_dumper.py ja update_metadata_pb2.py siin.
  3. Pakkige oma OTA ZIP-fail välja ja asetage fail payload.bin nende failidega samasse kausta.
  4. Sõltuvalt teie operatsioonisüsteemist avage PowerShell, Command Prompt või Terminal.
  5. Sisestage järgmine käsk: python -m pip install protobuf
  6. Kui see on lõpetatud, sisestage järgmine käsk: python payload_dumper.py payload.bin
  7. See alustab failis payload.bin olevate piltide ekstraktimist praegusesse kausta, milles olete.

Soovi korral saate nüüd kiirkäivituse kaudu kõik need pildid eraldi vilkuda. Järgmine jaotis näitab, kuidas seda teha.

Fastboot kasutamine piltide välgutamiseks seadmes, mis toetab sujuvaid värskendusi

On mitmeid käske, mis on mõeldud ainult A/B partitsioonisüsteemi seadmetele. Saate muuta aktiivse pesa ja välgu teatud pesadeks. Kui teil on projekt Treble-ühilduv seade ja tahan õppida, kuidas seda teha flash Generic System Images, peaksite olema nende käskudega tuttav. Heitke pilk allolevale tabelile.

Fastboot käsud

Käsk

Hangi praegune aktiivne pesa

fastboot getvar kõik | grep "current-slot"Kui kasutate Windowsi arvutit, siis käsk "grep" ei tööta.

Määra teine ​​pesa aktiivseks

fastboot set_active muu

Määra määratud pesa aktiivseks

fastboot set_active $ORfastboot --set-active=_$pesa kus $ on kas a või b

Välgu pilt praeguse pesa määratud partitsioonile

fastboot flash partitsioon partitsioon.img

Flash pilt määratud partitsioonile määratud pesas

fastboot flash partition_a partition.imgfastboot flash partition_b partition.img

(Märkus. A/B-seadmetes saate määrata konkreetses pesas partitsiooni, kuhu vilkuma minna, või jätta pesa järelliide välja ja see vilgub praegusesse aktiivsesse pesasse. Näiteks võite asendada välkkäskluse "partitsioon" sõnadega "system", "system_a" või "system_b.")

Windowsi arvutites ei saa te grep'i kasutada, nii et eemaldage see osa ja otsige "praegune pesa".

Sõna Project Treble'i ja sujuvate värskenduste kohta

Levinud eksiarvamus on, et Project Treble'i tugi ja A/B-sektsiooni tugi on omavahel seotud, kuid tegelikult see nii ei ole. Ühe olemasolu ei tähenda teist. Motorola Moto Z2 Force kasutab A/B jaotusskeemi, kuid ei toeta Treble'i. Teisest küljest toetab Honor 9 Lite Project Treble'i, kuid see on ainult A-seade.

Honor 9 Lite toetab Project Treble'i, kuid ei toeta sujuvaid värskendusi

Korduma kippuvad küsimused/kokkuvõte

  • Millised on A/B-seotuse eelised?
    • A/B partitsioonid võimaldavad teil oma Android-nutitelefoni selle kasutamise ajal värskendada, lihtsalt taaskäivitades, kui olete valmis uude versiooni käivitama. See toimib ka kaitsena telliste eest – kui värskendus läheb valesti, naasete töötava installi juurde.
  • Kas A/B jaotamine takistab arengut?
    • Kuigi arendajatel kulus kohanemiseks veidi aega, on vastus üsna eitav. Tegelikult võib see aidata arendajaid, kuna nad saavad regressioonide kontrollimiseks oma kohandatud ROM-i topeltkäivitada vana versiooniga ja uue testversiooniga.
  • Kuidas mõjutavad A/B-partitsioonid modifikatsioone, nagu kohandatud tuumad, Magisk või Xposed?
    • Nende paigaldamisel peate olema ettevaatlik, kuid praegu pole probleeme. Magisk toetab ametlikult sujuvate värskendustega seadmeid ja nii kaua, kui vilgutate asju õiges järjekorras, ei tohiks probleeme tekkida. Enne teiste modifikatsioonide välgutamist välgutage kohandatud kernel ja peaksite olema valmis.
  • Kas ma saan igal partitsioonil ja topeltkäivitamisel välgutada kahte erinevat ROM-i?
    • Teoreetiliselt jah. Probleemid tekivad siiski jagatud andmete partitsiooni tõttu, seega pole see soovitatav.
  • Kas A/B partitsiooniskeem tähendab, et olen vähendanud salvestusruumi?
    • Ei! Google ütleb, et sujuvaid värskendusi toetavad seadmed ohverdavad selle toetamiseks vaid paarsada megabaiti salvestusruumi. Kasu kaalub selle kulu üles.
  • Minu seade toetab A/B-sektsioone. Kas see tähendab, et saan kasutada Project Treble'i üldist süsteemipilti?
    • Mitte tingimata. Projekti Treble ja A/B tugi ei ole omavahel seotud. Motorola Moto Z2 Force ei toeta Project Treble'i, kuid toetab A/B partitsiooniskeemi.
  • Minu seade toetab Project Treble'i, kas see tähendab, et mul on A/B partitsiooniskeem?
    • See ei ole alati nii. Honor 9 Lite on suurepärane näide, kuna see toetab Project Treble'i, kuid sellel pole A/B partitsiooniskeemi.
  • Miks ma pean TWRP-i esmalt kiirkäivitusega käivitama ja seejärel välgutama?
    • Selle põhjuseks on kiirkäivituse toimimine ja asjaolu, et taastepartitsiooni enam ei eksisteeri. Taastamine asetatakse alglaadimissektsiooni sisse, seega peame muutma nii boot_a kui ka boot_b. Fastbootis ei saa partitsiooni paika panna, vaid ainult flash üle. Teoreetiliselt võite teha eelpaigaldatud alglaadimispildi ja seejärel selle asemel vilkuda.
  • Kas A/B vaheseintega kaasneb oht? Kuidas tagasipööramise kaitse asju mõjutab?
    • Google on teinud kõik endast oleneva, et muuta see probleemiks, kuid Motorola Moto Z2 puhul Force, oli teada juhtumeid, kus seade aktiveeris pärast Androidi versioonile üleminekut vanema pesa uuesti Oreo. See tähendas, et tagasipööramiskaitse hakkas tööle ja seadmete omanikud said oma nutitelefoni päästa ainult EDL-i taastamisega. Google ütleb, et tagasipööramise kaitse rakendub siiski alles pärast esimest käivitamist, nii et pesa peab pärast värskendust täielikult töötama, enne kui te ei saa enam versioonile üle minna.