Kuinka A/B-osiot ja saumattomat päivitykset vaikuttavat mukautettuun kehittämiseen XDA: ssa

Kun Android Nougat julkaistiin, se sai meidät puhumaan kaikenlaisia ​​uusia ominaisuuksia. Saimme äskettäin päivitetyn käyttöliittymän aloittelijoille sekä kauan odotetut moniikkunaominaisuudet ja Vulkan Graphics API -tuen. Mutta yksi konepellin alla oleva lisäys lensi useimpien käyttäjien pään yli. Android Nougat esitteli "Saumattomat päivitykset" laitteissa, jotka tukevat A/B-osioita. Suurimmalla osalla nykyisistä Android-laitteista (uusia Google Pixeliä ja Google Pixel XL: ää lukuun ottamatta) ei tuolloin ollut A/B-osiot, joten ne eivät voineet hyödyntää saumattomia päivityksiä. Tämän ominaisuuden peruslähtökohtana on, että laitteessa on toinen järjestelmä, käynnistys, toimittaja ja muut tärkeät osiot ja kun saat OTA: n päivitys päivitys tapahtuu taustalla, kun taas toiset osiot on korjattu, jolloin voit käynnistää uudelleen päivitetyn ohjelmistokoontiversion saumattomasti. Jos päivitys epäonnistuu, sinut palautetaan toimivaan koontiversioon, mikä tarkoittaa, että yrityksillä on vähemmän päänsärkyä ja kuluttajat ovat paremmin suojattuja.

Saumattomien päivitysten tukeminen ei ole vaatimus uusille Android-laitteille, toisin kuin Project Treble. Sellaisenaan suurin osa uusista Android-laitteista ei tue ominaisuutta. Olemme pitäneet luetteloa kaikista tuetuista laitteista tähän mennessä, ja on selvää, että tätä ominaisuutta ei tueta laajasti. Se on sääli, koska A/B-osiot tuovat paljon etuja sekä tavallisille käyttäjille että tehokäyttäjille. Ominaisuus on kuitenkin hieman huono maine harrastajayhteisössä, koska sen uskotaan vaikeuttavan Androidin kehitystä ja mukautettujen muutosten vilkkumista. Tämä ei todellisuudessa pidä paikkaansa, joten halusimme selvittää saumattomat päivitykset ja selittää, kuinka A/B-osiot vaikuttavat mukautettuun kehittämiseen XDA: ssa.

Suuri kiitos XDA Senior -jäsenelle npjohnson, a osallistuja LineageOS ja ylläpitäjä Motorola Moto Z2 Force, joka auttoi meitä tarkistamaan tämän artikkelin.

---

Osiot Android-laitteella

Osio on yksinkertaisesti erillinen osa puhelimen sisäisessä muistissa, jossa tietoja säilytetään. Se, millaisia ​​tietoja kullakin osiolla säilytetään, riippuu laitteistosta, käyttöjärjestelmästä ja monista muista tekijöistä. Käynnistyslataimella on yksi, järjestelmällä (Android OS) yksi, käyttäjätiedoilla yksi... ja niin edelleen. Kun näet ihmisten puhuvan "/system" ja "/cache", he viittaavat näiden osioiden etunimiin. Esimerkiksi OnePlus 6:ssa on 72 osiota. Se kuulostaa paljon, mutta OnePlus 6 on yksi laitteista, joka tukee saumattomia päivityksiä, mikä tarkoittaa, että monet näistä osioista ovat yksinkertaisesti toistensa kaksoiskappaleita.

Osioiden osittainen tulostus OnePlus 6:ssa. Jotkut A/B-osiot on alleviivattu esittelytarkoituksessa.

Laitteessa on paljon osioita, joista sinun ei koskaan tarvitse huolehtia käyttäjänä. Monia näistä osioista ei koskaan muokata, kun muokattuja ROM-levyjä, ytimiä, palautuksia tai muutoksia, kuten Magisk tai Xposed, päivitetään. Monet näistä osioista ovat joko käyttämättömiä tarkoituksiin tai ovat liian vaarallisia koskea, ellet tiedä mitä olet tekemässä (XLOADER ja OEMINFO Huaweissa/Honorissa laitteet tulevat mieleen.) Suurimmalle osalle Android-käyttäjistä käsittelemme enimmäkseen järjestelmä-, käynnistys-, palautus-, käyttäjätiedot ja viime aikoina myyjä- ja vbmeta. Tässä on lyhyt selitys kunkin osion tarkoituksesta:

• järjestelmä - sisältää Android-käyttöjärjestelmän, järjestelmäkirjastot, järjestelmäsovellukset ja muut järjestelmämediat, kuten bootanimaatiot, taustakuvat, soittoäänet jne.
• boot - sisältää ytimen, muistilevyn ja A/B-laitteissa myös palautuksen
• palautus - säilyttää palautuksen, jossa TWRP: tä yleisimmin välähdetään vain A-laitteissa (A/B-laitteissa ei ole erillistä palautusosiota)
• userdata - sisältää kaikki sovelluksesi, järjestelmäsi ja sisäisen tallennustilan tiedot
• toimittaja – sisältää alusta- ja laitekohtaisia ​​HAL-tiedostoja, tiedostoja, joita Android-käyttöjärjestelmä tarvitsee kommunikoidakseen taustalla olevan laitteiston kanssa
• vbmeta - Android Verified Boot 2.0:n osio, joka varmistaa käynnistysprosessin eheyden

Laitteen OEM-valmistajat voivat muuttaa osiojärjestelmiään käyttääkseen haluamaansa asettelua. Esimerkiksi Huawei jakaa käynnistysosion osaksi ramdisk_recovery ja ydin. On myös paljon ylimääräisiä osioita, jotka voivat sisältää muita järjestelmäsovelluksia, kuten cust, product ja oem, ja vaikka näitä on turvallista muokata, sitä ei yleensä suositella, jos haluat helpottaa varastoon palauttamista. Joten missä A/B-osioilla on rooli?

---

A/B-osiojärjestelmä

Kuinka päivitykset toimivat laitteissa, joissa on saumaton päivitys

Alla tekemäni hyvin yksinkertainen kuva havainnollistaa, kuinka päivitys käsitellään laitteessa, jossa on A/B-osiotuki. Kuvattu osio on järjestelmäosio, mutta myös muut osiot, kuten käynnistys ja toimittaja, voidaan päivittää millä tahansa OTA-päivityksellä OEM: ltä. Tämä päivitysprosessi tapahtuu paitsi suurten Android-versiopäivitysten myös tietoturvakorjauspäivitysten kanssa.

1. Aloitamme kahdella järjestelmäosiolla, system_a ja system_b, molemmat samassa Android-versiossa.
2. Olettaen, että system_a on aktiivinen, OTA-päivitys korjaa ei-aktiivisen osion system_b taustalla.
3. system_a asetetaan epäaktiiviseksi ja system_b muuttuu aktiiviseksi, kun käyttäjä käynnistyy uudelleen.
4. Nyt ei-aktiivinen osio, system_a, päivitetään, kun seuraava OTA-päivitys julkaistaan.

Mitä hyötyä tästä päivitysprosessista on?

1. Jos päivitys epäonnistuu, laite palaa toisen paikan toimivaan koontiversioon.
2. Tietosi säilyvät täydellisesti ennallaan, vaikka päivitys keskeytettäisiin, koska on vain yksi osio (userdata), joka sisältää tietosi.
3. Päivitysten suoratoisto: Jos tietoosiosi on täynnä, päivitys voidaan ladata ja suoratoistaa ei-aktiiviseen paikkaan. Se on melko siisti ominaisuus ja tarkoittaa, että sinun ei tarvitse tuhlata tilapäistä tallennustilaa päivityksiisi. Tästä syystä A/B-laitteissa ei ole välimuistiosiota, koska niitä ei enää tarvita.

Mikä vaikutus A/B-osiointimenetelmällä on laitteen tallennustilaan?

Tarkoittaako se, että saumattomat päivitykset johtavat moniin päällekkäisiin osioihin, sitä, että menetät paljon tallennustilaa? Ei lainkaan. Google sanoo, että laitteiden, joissa on saumaton päivitystuki, pitäisi laskea vain noin muutama sata megatavua /cache- ja /recovery-osioiden poistamisen ansiosta. Molempien poistaminen tasapainottaa toisen osiosarjan lisäämisen kustannukset. Googlen mukaan Pixelin A/B-järjestelmäkuva on puolet koko A-järjestelmäkuvasta. Suurin osa lisätallennustilan käytöstä tulee itse asiassa toisen toimittajaosion lisäämisestä. Tämä on järkevää, koska toimittajaosio sisältää kaikki OEM-valmistajien käyttämät binaaritiedostot (osa Project Trebleä), joten sen odotetaan vievän melko vähän tilaa. Vaikka Google ei suosittele A/B-osiointia laitteissa, joissa on 4 Gt tallennustilaa (koska se on lähes 10 % käytettävissä olevasta kokonaistallennustilasta), se suosittelee sitä laitteille, joissa on vähintään 8 Gt.

Tässä on erittely Google Pixelin tallennustilasta A/B-osiolla ja ilman.

Mitä palautusosiolle tapahtui?

Android-laitteiden taustalla oleva Linux-ydin antaa Androidin tunnistaa ja käyttää älypuhelimen laitteistoa oikein. Vain A-Android-laitteissa sinulla on yleensä kaksi versiota ytimestä: Toinen on pakattu palautusosion sisälle, kun taas toinen on käynnistysosioon. A/B-laitteissa, jotka tukevat saumattomia päivityksiä, palautus tapahtuu nyt käynnistyskuvan sisällä ytimen kanssa. Palautuksen päätehtävä oli päivitysten asentaminen, mutta koska järjestelmä hoitaa sen itse (update_engine), kun Android on käynnistetty, erillistä palautusosiota ei enää tarvita.

Jotta voimme asentaa mukautetun palautuksen A/B-laitteisiin, meidän on siis muutettava käynnistysosiota ja korvattava kaluston palautus omallamme. Tästä syystä TWRP: n asentamiseksi sinun on käytettävä fastboot-komentoa mukautetun käynnistyskuvan käynnistämiseksi ensin ja sitten flash TWRP-asennusskripti, koska pikakäynnistys ei voi korjata osioita - vain flash yli niiden kokonaan. Voisit teknisesti esipaikata olemassa olevan käynnistysvedon TWRP: llä ja sitten flash-lataa sen pikakäynnistyksen kautta, mutta se on enemmän vaivaa kuin sen arvoinen. TWRP-asennusohjelman komentosarja korjaa sekä boot_a- että boot_b-osiot TWRP: n asentamiseksi.

Hauska tosiasia: Saumattomia päivityksiä käsittelevä Android update_engine on periaatteessa kopioitu suoraan Chrome-käyttöjärjestelmästä. Vasta äskettäin poistettiinko "Chrome OS" sisältävät merkkijonot update_enginen lokista, jotta vältetään sekaannukset kaikille, jotka sattuvat tarkistamaan logcatin.

Tukeeko Android-älypuhelimeni A/B-osioita saumattomia päivityksiä varten?

Kun me pidä luettelo kaikista laitteista jotka tukevat sitä, voit myös helposti tarkistaa itsesi.

---

Miten saumattomat päivitykset vaikuttavat mukautettuun kehitykseen?

Käyttäjän käsitys A/B-osioista

Monet käyttäjät katsovat, että saumattomat päivitykset haittaavat räätälöityjen ohjelmistojen kehitystä, ja ne ovat itse asiassa siunaus kehittäjille. Syy siihen, että A/B-laitteiden koetaan olevan heikko kehitystuki, johtuu ensimmäisten A/B-laitteiden hinnasta. Loppujen lopuksi Google Pixel -laitteet olivat ensimmäisiä, jotka tukivat saumattomia päivityksiä, ja verrattuna menneiden Nexus-älypuhelimiin ne olivat suhteellisen kalliita. Lisäksi Googlen Android-käyttöjärjestelmään tekemien lukemattomien parannusten ansiosta, jotka ovat tehneet mukautettuja ROM-levyjä ja Google-laitteissa vähemmän suosittuja muutoksia, Google Pixel -älypuhelimet eivät nousseet foorumeillamme yhtä hyvin kuin Nexus älypuhelimet. Ulkoisten tekijöiden yhdistelmä johti Google Pixel -älypuhelimien mukautetun kehityksen vähenemiseen, vaikka useimmat käyttäjät päättivät syyttää sen sijaan A/B-osion tukea. Vertaa mukautetun kehitystyön saatavuutta laitteissa, kuten Google Pixel, laitteisiin, kuten Xiaomi Mi A1 foorumeillamme.

Lisäksi ymmärryksen puute siitä, kuinka A/B-osiot muuttivat käyttäjien tapaa asentaa mukautettuja ROM-levyjä, ytimiä, palautuksia ja muutoksia, johti A/B-osion tuen epäsuosioon. Kun palautus on nyt käynnistysvedoksen sisällä, väärässä järjestyksessä vilkkuvat muutokset, kuten Magisk tai Xposed, voivat aiheuttaa ristiriitoja ja johtaa käynnistyssilmukaan. Se, missä järjestyksessä nämä modit päivität, voi olla tärkeää, mutta mukautettujen ROM-levyjen tapauksessa sinun ei tarvitse huolehtia siitä, mihin korttipaikkaan vilkkuu. Vastoin yleistä uskomusta useimpien mukautettujen ROM-levyjen asennusskripti ei vilku molempiin paikkoihin. Sinun ei useimmiten tarvitse huolehtia siitä, koska sinun ei tarvitse vaihtaa paikkoja manuaalisesti.

Kuinka kehittäjät näkevät A/B-osioita

ROM-levyä rakentaessaan kehittäjät voivat käyttää molempia osioita erillisten koontiversioiden testaamiseen. Jos jokin ei toimi, he voivat palata takaisin toimivaan osioon ja rakentaa ROM-muistinsa uudelleen. Kehittäjät voivat myös testata regressioita yksinkertaisesti asentamalla päivityksen, vaihtamalla aktiivisen osion ja vertaamalla näitä kahta ilman tietojen pyyhkimistä. Näin LineageOS-tiimi näkee A/B-osion tuen:

"Monet Android-yhteisössä ovat pitäneet A/B: tä "vaikeasti tuettavaksi" ja "ei kehittäjäystävälliseksi", vaikka se itse asiassa on oikein toteutettu. helpompi tukea ja yhtä kehittäjäystävällinen." - jrizzoli, LineageOS Changelog 19

A/B-tuen alkuvaikeudet kehittäjille johtuivat olemassa olevien työkalujen muokkaamisesta tukemaan näitä laitteita. Magiskin kehittäjä topjohnwu lisäsi virallisen tuen Google Pixelille vuosi sen jälkeen julkaistiin – ei siksi, että se oli vaikeaa, vaan pikemminkin siksi, että laitteen hankkimiseen meni vuosi työskentele. TWRP-tuki tuli aika nopeasti A/B-laitteilla sen jälkeen, kun johtava kehittäjä Dees_Troy murtui siihen. LineageOS 15.1 nyt tukee A/B-laitteet, kun vapaaehtoiset löysivät aikaa korjata addon.d-skriptinsä.

Kuinka päivittää A/B-laite, jossa on mukautettu palautus, ydin tai muut modit

Mukautetut ROM-levyt

Päivitysten vilkkuminen mukautetulla ROM-muistilla varustetussa laitteessa tarkoittaa, että sinun on oltava varovainen sen suhteen, mitä paikkaa vilkkuu, eikö niin? Ei aivan. TWRP hoitaa itse asiassa suuren osan siitä puolestasi, ja se käyttää oletuksena passiivista paikkaa mukautetun ROM-muistin vilkkumista varten. Jos aktiivinen korttipaikkasi on A ja käytät mukautettua ROM-muistia, vilkkuu itse asiassa paikkaan B. Kun käynnistät uudelleen, aktiivinen paikka on nyt B. Kehittäjät voivat muokata asennuskomentosarjaa ja flashiä molemmissa paikoissa helpottaakseen loppukäyttäjää, vaikka useimmat mukautetut ROM-asennusskriptit vilkkuvat tällä hetkellä vain yhteen paikkaan. Lopuksi mukautetut ROM-levyt voivat ottaa käyttöön A/B-päivityksen ROM-muistiin, joten käyttäjien ei tarvitse edes sotkea manuaalisesti vilkkuvat päivitykset – uusin LineageOS 15.1 sisältää Lineage Updater -työkalun ja XDA Senior Member USA-RedDragon teki yleinen A/B-päivitys joita muut kehittäjät voivat käyttää.

Varastolliset ROM-levyt

Mutta eikö se ole ongelmallista, jos laitteesi käyttää varastossa olevaa ROM-muistia useilla muokkauksilla ja haluat asentaa päivityksen menettämättä kaikkia näitä modeja? Se voi johtua siitä, että et tiedä oikeita vaiheita päivityksen asentamiseksi. Esimerkiksi OnePlus 6:ssa et voi flash-päivittää muokatun laitteen OTA-päivitystä, koska inkrementaalinen OTA yrittää korjata muokatun käynnistyskuvasi. Siten saatat todennäköisesti päätyä käynnistyssilmukaan, ja siksi sinun on päivitettävä koko ROM-päivitys korvataksesi muokatun käynnistyskuvan kokonaan. Tässä ovat yleiset vaiheet, jotka sinun on suoritettava asentaaksesi OxygenOS-päivityksen OnePlus 6:een säilyttäen silti TWRP: n, Magiskin ja valinnaisesti mukautetun ytimen.

1. Ladattu uusin täysi ROM postinumero
2. Flash-muistin koko zip palautustilassa
3. (Valinnainen) Mukautettu Flash-ydin
4. Flash TWRP -asennusohjelma
5. Käynnistä uudelleen suoraan takaisin palautukseen
6. Flash Magisk

Google Pixel -laitteilla voit flash tehdaskuva pyyhkimättä tietoja, käynnistä TWRP, asenna TWRP asennuskomentosarjan avulla ja asenna sitten Magisk.

Poimitaan päivitys yksittäisten osiokuvien flash-muistiin

Useiden A/B-laitteiden päivitystiedostot ovat hieman erilaisia ​​verrattuna vain A-laitteisiin. Ne eivät ole enää vain zip-tiedostoja, jotka sisältävät paljon kuvia (pois lukien Googlen ja Razerin tehdaskuvat), vaan ne ovat payload.bin-tiedoston muodossa. Voit purkaa tämän tiedoston ja päivittää jokaisen osan manuaalisesti, mutta se vaatii erityisen työkalun. Jos olet kiinnostunut oppimaan, miten se tehdään OnePlus 6:lla, Xiaomi Mi A1:llä ja monilla muilla A/B-laitteilla, lue eteenpäin.

Asetetaan purkamaan payload.bin

1. Varmista, että sinulla on Python 3.6 asennettu.
2. Lataa payload_dumper.py ja update_metadata_pb2.py tässä.
3. Pura OTA-zip ja sijoita payload.bin samaan kansioon näiden tiedostojen kanssa.
4. Avaa PowerShell, Command Prompt tai Terminal käyttöjärjestelmästäsi riippuen.
5. Kirjoita seuraava komento: python -m pip install protobuf
6. Kun se on valmis, kirjoita tämä komento: python payload_dumper.py payload.bin
7. Tämä alkaa purkaa payload.bin-tiedoston kuvia nykyiseen kansioon, jossa olet.

Halutessasi voit flash-lataa nämä kuvat erikseen nyt pikakäynnistyksen kautta. Seuraava osa näyttää, kuinka se tehdään.

Pikakäynnistyksen käyttäminen kuvien vilkkumiseen laitteella, joka tukee saumattomia päivityksiä

On olemassa useita komentoja, jotka ovat yksinomaan A/B-osiojärjestelmän laitteissa. Voit vaihtaa aktiivisen korttipaikan ja salaman tiettyihin paikkoihin. Jos sinulla on projekti Treble-yhteensopiva laite ja haluat oppia kuinka flash Generic System Images, sinun pitäisi tuntea nämä komennot. Katso alla olevaa taulukkoa.

(Huomaa: A/B-laitteissa voit joko määrittää tietyssä paikassa olevan osion, johon vilkkuu, tai voit jättää pois paikan jälkiliitteen, jolloin se vilkkuu nykyiseen aktiiviseen paikkaan. Voit esimerkiksi korvata "osion" flash-komennossa sanalla "system", "system_a" tai "system_b.")

---

Sana Project Treblestä ja saumattomista päivityksistä

Yleinen väärinkäsitys on, että Project Treble -tuki ja A/B-osion tuki liittyvät toisiinsa, mutta näin ei todellisuudessa ole. Yhden omistaminen ei tarkoita toista. Motorola Moto Z2 Force käyttää A/B-osiointijärjestelmää, mutta ei tue diskanttia. Toisaalta Honor 9 Lite tukee Project Trebleä, mutta on kuitenkin vain A-laite.

---

Usein kysytyt kysymykset/yhteenveto

• Mitä hyötyä A/B-osiosta on?
  • A/B-osion avulla voit päivittää Android-älypuhelimesi sitä käytettäessä, yksinkertaisesti käynnistämällä uudelleen, kun olet valmis käynnistämään uuden version. Se toimii myös suojana palikoita vastaan ​​– jos päivitys menee pieleen, palaat toimivaan asennukseen.
• Estääkö A/B-osiointi kehitystä?
  • Vaikka kehittäjiltä kestikin hieman aikaa sopeutua, vastaus on melko ei. Itse asiassa se voi auttaa kehittäjiä, koska he voivat käynnistää mukautetun ROM-levynsä kaksoiskäynnistyksen kanssa vanhan version ja uuden testiversion kanssa tarkistaakseen regressioita.
• Miten A/B-osiot vaikuttavat modeihin, kuten mukautettuihin ytimiin, Magiskiin tai Xposediin?
  • Sinun on oltava varovainen asentaessasi niitä, mutta tällä hetkellä ei ole ongelmia. Magisk tukee virallisesti laitteita saumattomilla päivityksillä, ja niin kauan kuin päivität asiat oikeassa järjestyksessä, sinulla ei pitäisi olla ongelmia. Muista päivittää mukautettu ydin ennen muiden modien vilkkumista, niin sinun pitäisi olla valmis.
• Voinko flash-palauttaa kaksi eri ROM-levyä kussakin osiossa ja kaksoiskäynnistyksenä?
  • Teoriassa kyllä. Ongelmia syntyy kuitenkin jaetun dataosion vuoksi, joten sitä ei suositella.
• Tarkoittaako A/B-osiokaavio, että minulla on vähemmän tallennustilaa?
  • Ei! Google sanoo, että saumattomia päivityksiä tukevat laitteet uhraavat vain muutaman sadan megatavun tallennustilaa sen tukemiseen. Edut ovat suuremmat kuin ne kustannukset.
• Laitteeni tukee A/B-osioita, tarkoittaako se, että voin käyttää Project Treble Generic -järjestelmäkuvaa?
  • Ei välttämättä. Project Treble ja A/B-tuki eivät liity toisiinsa. Motorola Moto Z2 Force ei tue Project Trebleä, mutta se tukee A/B-osiojärjestelmää.
• Laitteeni tukee Project Trebleä, tarkoittaako se, että minulla on A/B-osiojärjestelmä?
  • Näin ei aina ole. Honor 9 Lite on erinomainen esimerkki, koska se tukee Project Trebleä, mutta sillä ei ole A/B-osiojärjestelmää.
• Miksi minun on käynnistettävä TWRP ensin fastbootilla ja sitten flash se?
  • Tämä johtuu siitä, kuinka pikakäynnistys toimii ja että palautusosiota ei enää ole. Palautus sijoitetaan käynnistysosion sisään, joten meidän on muokattava sekä boot_a että boot_b. Et voi korjata osiota fastbootissa, vain vilkkua sen yli. Teoriassa voisit tehdä esipatsoidun käynnistyskuvan ja sitten flash sen sijaan.
• Onko A/B-osioissa vaaroja? Miten palautussuoja vaikuttaa asioihin?
  • Google on yrittänyt kaikkensa tehdäkseen tästä ongelman, mutta Motorola Moto Z2:n tapauksessa Force, tiedettiin tapauksia, joissa laite aktivoi vanhan paikan uudelleen Androidiin päivittämisen jälkeen Oreo. Tämä tarkoitti, että palautussuoja käynnistyi, ja laitteen omistajat pystyivät pelastamaan älypuhelimensa vain EDL-palautuksen avulla. Google sanoo, että palautussuojaus käynnistyy kuitenkin vasta ensimmäisen käynnistyksen jälkeen, joten paikan on oltava täysin toimiva päivityksen jälkeen, ennen kuin et voi enää päivittää sitä.