Hogyan hatnak az A/B partíciók és a zökkenőmentes frissítések az XDA egyedi fejlesztésére

Amikor megjelent az Android Nougat, arról beszéltünk mindenféle újdonság. Újonnan frissített felhasználói felületet kaptunk a kezdőknek, a régóta várt többablakos képességekkel és a Vulkan Graphics API támogatásával. De a legtöbb felhasználó feje fölött elrepült egy, a motorháztető alatti kiegészítés. Az Android Nougat bevezette a "zökkenőmentes frissítéseket" az A/B partíciókat támogató eszközökön. A meglévő Android-eszközök túlnyomó többsége (az új Google Pixel és a Google Pixel XL kivételével) akkoriban nem rendelkezett A/B partíciókkal, így nem tudta kihasználni a zökkenőmentes frissítéseket. Ennek a funkciónak az alapfeltétele, hogy az eszköznek van egy második rendszerkészlete, rendszerindítási, szállítói és más fontos partíciók, és amikor OTA-t kap. A frissítés a frissítés a háttérben történik, miközben a partíciók második csoportja javításra kerül, így zökkenőmentesen újraindítható egy frissített szoftver. Ha egy frissítés meghiúsul, akkor visszakerül a működő buildhez, ami azt jelenti, hogy a vállalatoknak kevesebb fejfájással kell megküzdeniük, a fogyasztók pedig jobban védettek.

A zökkenőmentes frissítések támogatása nem követelmény egyetlen új Android-eszköz esetében sem, ellentétben a Project Treble-lel. Mint ilyen, az új Android-eszközök túlnyomó többsége nem támogatja ezt a funkciót. Eddig listát vezettünk az összes támogatott eszközről, és nyilvánvaló, hogy ez a funkció nem támogatott széles körben. Ez szégyen, mert az A/B partíciók számos előnnyel járnak mind a normál felhasználók, mind a gyakorlott felhasználók számára. A funkciónak azonban egy kicsit rossz híre van a lelkes közösségben, mert úgy érzik, hogy megnehezíti az Android fejlesztését és a villogó egyéni módosításokat. Valójában ez nem így van, ezért szerettük volna tisztázni a zökkenőmentes frissítéseket, és elmagyarázni, hogyan befolyásolják az A/B partíciók az XDA egyedi fejlesztését.

Köszönet az XDA Senior Tagnak npjohnson, a hozzájáruló LineageOS és fenntartója a Motorola Moto Z2 Force, aki segített nekünk ellenőrizni ezt a cikket.

---

Partíciók Android-eszközön

A partíció egyszerűen egy különálló rész a telefon belső tárhelyén, ahol az adatokat tárolják. Az, hogy az egyes partíciókon milyen adatokat tárolnak, a hardvertől, az operációs rendszertől és sok más tényezőtől függ. A bootloadernek lesz egy, a rendszernek (Android OS) egy, a felhasználói adatoknak egy... és így tovább, és így tovább. Amikor azt látja, hogy az emberek "/system" és "/cache"-ről beszélnek, akkor ezeknek a partícióknak a nevekre hivatkoznak. A OnePlus 6 például rendelkezik 72 partíció. Ez soknak hangzik, de a OnePlus 6 egyike azon eszközöknek, amelyek támogatják a zökkenőmentes frissítéseket, ami azt jelenti, hogy a partíciók közül sok egyszerűen egymás másolata.

A partíciók részleges kimenete a OnePlus 6-on. Néhány A/B partíció aláhúzva látható demonstrációs célból.

Egy eszközön sok partíció található, amelyek miatt felhasználóként soha nem kell aggódnia. E partíciók közül sok soha nem módosul egyéni ROM-ok, kernelek, helyreállítások vagy olyan módosítások, mint például a Magisk vagy az Xposed, felvillantásakor. Ezen partíciók nagy része vagy nem lesz felhasználva a céljainkra, vagy túl veszélyes hozzányúlni, hacsak nem tudja, mit csinál (XLOADER és OEMINFO a Huawei/Honor oldalon eszközök jutnak eszembe.) Az Android-felhasználók túlnyomó többsége számára a rendszer, a rendszerindítás, a helyreállítás, a felhasználói adatok és újabban a gyártói és vbmeta. Íme egy rövid magyarázat az egyes partíciók céljáról:

• rendszer – tartalmazza az Android operációs rendszert, a rendszerkönyvtárakat, a rendszeralkalmazásokat és egyéb rendszerhordozókat, például bootanimációkat, háttérképeket, csengőhangokat stb.
• boot - tartalmazza a kernelt, a ramdisket és A/B eszközökön a helyreállítást is
• helyreállítás – tartalmazza a helyreállítást, ahol a TWRP leggyakrabban flash-re kerül a csak A-eszközökön (az A/B eszközöknek nincs dedikált helyreállítási partíciója)
• userdata – az alkalmazás, a rendszer és a belső tárhely összes adatát tartalmazza
• szállító – platform- és eszközspecifikus HAL-okat tartalmaz, az Android operációs rendszernek a mögöttes hardverrel való kommunikációjához szükséges fájlokat
• vbmeta – az Android Verified Boot 2.0 partíciója, amely ellenőrzi a rendszerindítási folyamat integritását

Az eszközök OEM-jei megváltoztathatják partíciós sémáikat, hogy bármilyen elrendezést használhassanak. Például a Huawei felosztja a rendszerindító partíciót ramdisk_recovery és kernel részekre. Ezenkívül sok extra partíció is tartalmazhat más rendszeralkalmazásokat, például cust, product és oem, és míg ezek biztonságosan módosíthatók, általában nem ajánlott, ha meg akarja könnyíteni a raktárba való visszatérést. Tehát hol játszanak szerepet az A/B partíciók?

---

Az A/B felosztási rendszer

A frissítések működése a zökkenőmentes frissítésekkel rendelkező eszközökön

Az alábbi nagyon egyszerű kép azt szemlélteti, hogyan történik a frissítések kezelése egy A/B partíciót támogató eszközön. Az ábrázolt partíció a rendszerpartíció, bár más partíciók, például a rendszerindítás és a szállító is frissíthetők az OEM-től származó bármely adott OTA-frissítéssel. Ez a frissítési folyamat nem csak a főbb Android-verziófrissítésekkel, hanem a biztonsági javításokkal is megtörténik.

1. Két rendszerpartícióval kezdjük, a system_a és system_b, mindkettő ugyanazon az Android verzión.
2. Feltételezve, hogy a system_a aktív, az OTA frissítés a háttérben javítja a system_b inaktív partíciót.
3. A system_a értéke inaktív, a system_b pedig akkor válik aktívvá, amikor a felhasználó újraindul.
4. A most inaktív partíció, a system_a, a következő OTA-frissítés megjelenésekor frissül.

Milyen előnyei vannak ennek a frissítési folyamatnak?

1. Ha a frissítés sikertelen, az eszköz visszaáll a másik nyíláson lévő működő buildre.
2. Az Ön adatai tökéletesen sértetlenek, még akkor is, ha a frissítés le van tiltva, mivel csak egy partíció (felhasználói adatok) tárolja az Ön adatait.
3. Frissítés streaming: Ha az adatpartíció megtelt, akkor a frissítés letölthető és streamelhető az inaktív nyílásba. Ez egy nagyon ügyes funkció, és azt jelenti, hogy nem kell ideiglenes tárhelyet pazarolnia a frissítésekre. Ezért nincs gyorsítótár-partíció az A/B eszközökön, mivel már nincs rájuk szükség.

Milyen hatással van az A/B particionálási séma egy eszköz tárolására?

Az a tény, hogy a zökkenőmentes frissítések egy csomó duplikált partíciót eredményeznek, azt jelenti, hogy egy csomó tárhelyet veszít? Egyáltalán nem. A Google szerint a zökkenőmentes frissítéstámogatással rendelkező eszközök csak néhány száz megabájtot veszíthetnek a /cache és /recovery partíciók eltávolításának köszönhetően. Mindkét eltávolítása kiegyenlíti egy második partíciókészlet hozzáadásának költségeit. A Google szerint a Pixel A/B rendszerképe fele akkora, mint a csak A rendszerképeé. A többlettárhely-használat nagy része valójában egy második szállítói partíció hozzáadásának köszönhető. Ez logikus, mivel a gyártói partíció tartalmazza az OEM-ek által használt összes saját bináris fájlt (a Project Treble része), így várhatóan elég sok helyet foglal el. Noha a Google nem javasolja az A/B particionálást a 4 GB tárhellyel rendelkező eszközökön (mivel ez a teljes rendelkezésre álló tárhely közel 10%-a), a 8 GB-os és nagyobb méretű eszközökön viszont igen.

Íme a Google Pixel A/B partícióval és anélkül használt tárhelyének lebontása.

Mi történt a helyreállítási partícióval?

Az Android-eszközökön található Linux-kernel lehetővé teszi az Android számára, hogy felismerje és megfelelően használja a hardvert egy okostelefonon. A csak A rendszerű Android-eszközökön általában a kernel két verziója van: az egyik a helyreállítási partícióba van csomagolva, míg a másik a rendszerindító partíción. A zökkenőmentes frissítéseket támogató A/B eszközökön a helyreállítás a rendszermaggal együtt a rendszerindító lemezkép belsejében történik. A helyreállítás fő funkciója a frissítések telepítése volt, de mivel ezt maga a rendszer kezeli (update_engine) miközben az Android elindul, a dedikált helyreállítási partícióra már nincs szükség.

Az egyéni helyreállítás A/B eszközökre történő telepítéséhez tehát módosítanunk kell a rendszerindító partíciót, és le kell cserélnünk az állomány-helyreállítást a sajátunkra. Ez az oka annak, hogy a TWRP telepítéséhez egy fastboot parancsot kell használnia az egyéni rendszerindító lemezkép indításához, és először akkor villogtassa a TWRP telepítőszkriptet, mivel a fastboot nem tudja javítani a partíciókat – csak teljes egészében átfújja őket. Technikailag előfoltozhatná a meglévő rendszerindító képét TWRP-vel, majd gyorsindításon keresztül flashelhetné, de ez nagyobb baj, mint megéri. A TWRP telepítő parancsfájlja javítja a boot_a és a boot_b partíciót a TWRP telepítéséhez.

Érdekes tény: A zökkenőmentes frissítéseket kezelő Android update_engine alapvetően egyenesen a Chrome OS-ből származik. Csak mostanában A "Chrome OS"-t tartalmazó karakterláncokat eltávolították az update_engine naplójából, hogy elkerüljék a félreértést azok számára, akik véletlenül megnézik a logcat-et.

Az Android okostelefonom támogatja az A/B partíciókat a zökkenőmentes frissítés érdekében?

Amíg mi készítsen listát az összes eszközről amelyek támogatják, Ön is könnyen ellenőrizheti magát.

---

Hogyan befolyásolják a zökkenőmentes frissítések az egyéni fejlesztést?

Az A/B partíciók felhasználói észlelése

Sok felhasználó akadályozza az egyedi szoftverfejlesztést, ezért a zökkenőmentes frissítések valójában áldás a fejlesztők számára. Az A/B eszközök gyenge fejlesztési támogatásának vélt oka az első A/B eszközök árában rejlik. Végül is a Google Pixel készülékek voltak az elsők, amelyek támogatták a zökkenőmentes frissítéseket, és a korábbi Nexus okostelefonokhoz képest viszonylag drágák voltak. Ezenkívül a Google által az Android operációs rendszeren végrehajtott számtalan fejlesztésnek köszönhetően egyedi ROM-okat és A Google-eszközökön kevésbé népszerű módosítások, a Google Pixel okostelefonok közel sem vették be olyan jól a fórumainkat, mint a Nexus okostelefonok. A külső tényezők kombinációja csökkentette a Google Pixel okostelefonok egyedi fejlesztését, bár a legtöbb felhasználó inkább az A/B partíciók támogatását választotta. Hasonlítsa össze az egyedi fejlesztések elérhetőségét olyan eszközökön, mint a Google Pixel, és olyan eszközöket, mint a Xiaomi Mi A1 fórumainkon.

Ezen túlmenően, az A/B partíciók támogatásának népszerűtlenségéhez vezetett, hogy nem tudták, hogyan változtatták meg az A/B partíciók az egyéni ROM-ok, kernelek, helyreállítások és módosítások telepítésének módját. Mivel a helyreállítás már a rendszerindító lemezkép belsejében található, a rossz sorrendben villogó módosítások, például a Magisk vagy az Xposed ütközéseket okozhatnak, és bootloophoz vezethetnek. Fontos lehet, hogy milyen sorrendben villogtatod ezeket a modokat, bár az egyedi ROM-ok esetében nem kell attól tartanod, hogy melyik slotra villogsz. A közhiedelemmel ellentétben a legtöbb egyéni ROM telepítési szkriptje nem villog mindkét nyílásba. Leginkább nem kell emiatt aggódnia, mivel nem kell manuálisan cserélnie a slotokat.

Hogyan tekintik meg a fejlesztők az A/B partíciókat

A ROM összeállításakor a fejlesztők mindkét partíciót felhasználhatják a külön buildek tesztelésére. Ha az egyik nem működik, egyszerűen visszatérhetnek a működő partícióhoz, és újraépíthetik a ROM-ot. A fejlesztők úgy is tesztelhetik a regressziót, hogy egyszerűen telepítenek egy frissítést, átváltják az aktív partíciót, és összehasonlítják a kettőt anélkül, hogy törölni kellene az adatokat. A LineageOS csapata a következőképpen tekinti az A/B partíciók támogatását:

Az Android-közösségben sokan úgy ítélték meg, hogy az A/B „nehezen támogatható” és „nem fejlesztőbarát”, jóllehet megfelelően végrehajtva könnyebben támogatható és ugyanolyan fejlesztőbarát." - jrizzoli, LineageOS Changelog 19

A fejlesztők számára az A/B támogatással kapcsolatos kezdeti nehézséget a meglévő eszközök módosítása okozta, hogy támogassák ezeket az eszközöket. A Magisk fejlesztője, topjohnwu egy évvel azután hivatalos támogatást adott a Google Pixelhez. kiadták – nem azért, mert nehéz volt, hanem mert egy évbe telt, mire megszerezte az eszközt dolgozik rajta. TWRP támogatás elég gyorsan jött az A/B eszközökön, miután a vezető fejlesztő, Dees_Troy rárontott. LineageOS 15.1 most támogatja A/B eszközök, miután az önkéntesek időt találtak az addon.d szkript javítására.

Egyéni helyreállítással, kernellel vagy egyéb modokkal rendelkező A/B eszköz frissítése

Egyedi ROM-ok

Az egyedi ROM-mal rendelkező eszközök villogása azt jelenti, hogy vigyáznia kell, hogy melyik slotot is villogtatja, igaz? Nem egészen. A TWRP valójában sok mindent megold az Ön helyett, és alapértelmezés szerint az inaktív nyílást használja az egyéni ROM felvillantásához. Ha az aktív nyílásod az A, és egyéni ROM-ot villantasz, akkor valójában a B bővítőhelyre villogsz. Újraindításkor az aktív slot most B. A fejlesztők módosíthatják a telepítési szkriptet és a flash-t mindkét nyílásban, hogy megkönnyítsék a végfelhasználó számára, bár a legtöbb egyéni ROM-telepítési szkript jelenleg csak egyetlen nyílásban villog. Végül az egyedi ROM-ok A/B frissítőt is beépíthetnek a ROM-jukba, így a felhasználóknak még csak nem is kell foglalkozniuk manuálisan villogó frissítések – a legújabb LineageOS 15.1 tartalmaz egy Lineage Updater eszközt és XDA Senior Member USA-RedDragon készült általános A/B frissítő amelyet más fejlesztők használhatnak.

Raktári ROM-ok

De nem okoz problémát, ha az eszközön a készlet ROM fut különféle módosításokkal, és frissítést szeretne telepíteni anélkül, hogy elveszítené ezeket a modokat? Ez akkor fordulhat elő, ha nem ismeri a frissítés telepítésének megfelelő lépéseit. A OnePlus 6-on például nem villanthat fel növekményes OTA-t a módosított eszközön, mert a növekményes OTA megpróbálja javítani a módosított rendszerindító lemezképet. Így valószínűleg bootloop-ot kapsz, és ezért kell a teljes ROM-frissítést flashelni, hogy teljesen felülírhasd a módosított rendszerindító lemezképet. Íme az általános lépések, amelyeket meg kell tennie egy OxygenOS-frissítés telepítéséhez a OnePlus 6-on, miközben továbbra is megtartja a TWRP-t, a Magisket és opcionálisan egy egyéni kernelt.

1. Letöltötte a legújabbat teljes ROM postai irányítószám
2. Flash a teljes ROM zip helyreállításban
3. (Opcionális) Flash egyéni kernel
4. Flash TWRP telepítő
5. Indítsa újra közvetlenül a helyreállításhoz
6. Flash Magisk

A Google Pixel eszközökön megteheti villog a gyári kép adattörlés nélkül, majd indítsa el a TWRP-t, telepítse a TWRP-t a telepítési szkripten keresztül, majd telepítse a Magisk-et.

Frissítés kibontása az egyes partícióképek felvillantásához

Számos A/B eszköz frissítési fájljai kissé eltérnek a csak A-eszközökhöz képest. Már nem csak egy zip-fájl, amely sok képet tartalmaz (kivéve a Google és a Razer gyári képeit), hanem egy payload.bin fájl formájában. Ezt a fájlt kibonthatja, és az egyes részeket manuálisan is flashelheti, de ehhez speciális eszközre van szüksége. Ha szeretné megtanulni, hogyan kell ezt megtenni a OnePlus 6-on, a Xiaomi Mi A1-en és sok más A/B-eszközön, olvasson tovább.

Beállítás a payload.bin kibontásához

1. Győződjön meg arról, hogy Python 3.6-os verziója van telepítve.
2. Töltse le a payload_dumper.py-t és az update_metadata_pb2.py-t itt.
3. Csomagolja ki az OTA zip-fájlt, és helyezze el a payload.bin fájlt ugyanabba a mappába, mint ezekkel a fájlokkal.
4. Nyissa meg a PowerShellt, a Parancssort vagy a Terminált az operációs rendszertől függően.
5. Írja be a következő parancsot: python -m pip install protobuf
6. Ha ezzel végzett, írja be ezt a parancsot: python payload_dumper.py payload.bin
7. Ez elkezdi kibontani a payload.bin fájlban található képeket az aktuális mappába, amelyben tartózkodik.

Ezeket a képeket külön-külön is felvillanthatja most a gyorsindításon keresztül, ha kívánja. A következő rész megmutatja, hogyan kell ezt megtenni.

Fastboot használata képek felvillantásához olyan eszközön, amely támogatja a zökkenőmentes frissítéseket

Számos olyan parancs létezik, amely kizárólag az A/B partíciós rendszereszközökre vonatkozik. Megváltoztathatja az aktív bővítőhelyet és a vakut meghatározott helyekre. Ha van Treble projektjekompatibilis eszköz és szeretné megtanulni, hogyan kell flash általános rendszerképek, ismernie kell ezeket a parancsokat. Vessen egy pillantást az alábbi táblázatra.

(Megjegyzés: Az A/B eszközökön megadhat egy partíciót egy adott nyílásban, amelyre villogni szeretne, vagy elhagyhatja a bővítőhely utótagját, és az az aktuális aktív slothoz fog villogni. Például lecserélheti a "partition" szót a flash parancsban a "rendszer", "rendszer_a" vagy "rendszer_b" kifejezésre.)

---

Egy szó a Project Treble-ről és a zökkenőmentes frissítésekről

Gyakori tévhit az, hogy a Project Treble támogatása és az A/B partíció támogatása összefügg egymással, de valójában nem ez a helyzet. Az egyik megléte nem jelenti a másikat. A Motorola Moto Z2 Force A/B particionálási sémát használ, de nem támogatja a Treble-t. Másrészt a Honor 9 Lite támogatja a Project Treble-t, mégis csak A-eszköz.

---

Gyakran Ismételt Kérdések/Összefoglaló

• Milyen előnyei vannak az A/B particionálásnak?
  • Az A/B particionálás lehetővé teszi az Android okostelefon frissítését használat közben, egyszerűen újra kell indítani, amikor készen áll az új verzióra. Védelmet nyújt a téglák ellen is – ha a frissítés rosszul sikerül, akkor visszatér a működő telepítéshez.
• Az A/B particionálás akadályozza a fejlődést?
  • Bár a fejlesztőknek némi időbe telt az alkalmazkodás, a válasz nagyjából nem. Valójában ez segíthet a fejlesztőknek, mivel az egyéni ROM-jukat a régi verzióval és egy új tesztverzióval kétszer indíthatják el, hogy ellenőrizzék a regressziókat.
• Hogyan hatnak az A/B partíciók az olyan modokra, mint az egyéni kernelek, a Magisk vagy az Xposed?
  • Telepítésükkor óvatosnak kell lennie, de jelenleg nincs probléma. A Magisk hivatalosan támogatja az eszközöket a zökkenőmentes frissítésekkel, és mindaddig, amíg a dolgokat a megfelelő sorrendben villogtatja, nem lehet problémája. Győződjön meg róla, hogy az egyéni kernelt villogtatja, mielőtt a többi modot felvillantja, és már készen is kell lennie.
• Flash-elhetek két különböző ROM-ot minden partíción és kettős rendszerindításkor?
  • Elméletileg igen. A problémák azonban a megosztott adatpartíció miatt merülnek fel, ezért nem ajánlott.
• Az A/B partíciós séma azt jelenti, hogy csökkent a tárhelyem?
  • Dehogy! A Google szerint a zökkenőmentes frissítéseket támogató eszközök csak néhány száz megabájt tárhelyet áldoznak fel annak támogatására. Az előnyök meghaladják ezt a költséget.
• A készülékem támogatja az A/B partíciókat, ez azt jelenti, hogy használhatom a Project Treble Generic System Image-t?
  • Nem feltétlenül. A Treble projekt és az A/B támogatás nem kapcsolódik egymáshoz. A Motorola Moto Z2 Force nem támogatja a Project Treble-t, de támogatja az A/B partíciós sémát.
• Az eszközöm támogatja a Project Treble-t, ez azt jelenti, hogy van A/B partíciós sémám?
  • Ez nem mindig van így. A Honor 9 Lite kiváló példa, mivel támogatja a Project Treble-t, de nincs A/B partíciós sémája.
• Miért kell először a TWRP-t gyorsindítással indítanom, majd flash-el?
  • Ennek oka a gyorsindítás működése és az a tény, hogy a helyreállítási partíció már nem létezik. A helyreállítás a rendszerindító partíción belül található, ezért módosítanunk kell a boot_a-t és a boot_b-t is. Fastbootban nem lehet partíciót patcholni, csak flashelni. Elméletileg készíthetsz egy előre javított rendszerindító képet, majd ezt villogtathatod.
• Vannak-e veszélyek az A/B partíciókkal? Hogyan hat a visszagurulásvédelem a dolgokra?
  • A Google mindent megtett, hogy ez ne legyen probléma, de a Motorola Moto Z2 esetében Force, ismertek olyan esetek, amikor egy eszköz újraaktiválta a régebbi nyílást az Androidra való frissítés után Oreo. Ez azt jelentette, hogy beindult a visszaállítás elleni védelem, és az eszköztulajdonosok csak EDL helyreállítással tudták megmenteni okostelefonjukat. A Google azt állítja, hogy a visszaállítási védelem csak az első rendszerindítás után lép működésbe, tehát a bővítőhelynek teljesen működőképesnek kell lennie a frissítés után, mielőtt nem tud visszamenni.