Google verplicht mogelijk aparte partitie voor installeren updates in Android 11

Google lijkt het ondersteunen van A/B-partities en daarmee het installeren van een update op een aparte partitie op de achtergrond te gaan verplichten in Android 11. Fabrikanten als Samsung, Huawei en Oppo doen dat nu nog niet.

XDA-Developers vond een verwijzing naar de verplichting voor het ondersteunen van A/B-partities in een commit in de openbare code van de Vendor Test Suite. Die tests moet een telefoon met succes doorlopen, anders mogen fabrikanten Google-diensten niet op het apparaat zetten.

Het installeren van updates op een aparte partitie zit sinds vier jaar in Android. Onder meer Google Pixel-telefoons en modellen van OnePlus, LG, Motorola, Asus en Sony ondersteunen de functie, maar telefoons van Samsung, Huawei en Oppo doen dat onder meer niet.

De functie heeft als voordeel dat gebruikers tijdens het installeren van de update het toestel kunnen blijven gebruiken. Bij een reboot schakelt de software vervolgens over op de andere partitie. Bijkomend voordeel is dat als de update fout gaat, gebruikers terug kunnen naar een werkende partitie. Fabrikanten die de functie niet ondersteunen, laten gebruikers de update installeren in de recovery-modus en dan is er ook vaak geen manier om terug te gaan naar de oude software als de update mislukt.

Als de verplichting er komt, geldt die voor modellen die uitkomen met Android 11. Alleen toestellen die nieuw uitkomen, moeten voldoen aan de Vendor Test Suite; bij een upgrade naar Android 11 geldt dat niet. Dat gebeurt vermoedelijk vanaf komend najaar. Dan zullen Samsung en Oppo onder meer overschakelen op het ondersteunen van partities voor updates. Het is nog onduidelijk of dat ook voor Huawei geldt. Door het handelsverbod van de regering van de VS voor Amerikaanse bedrijven gebruiken huidige Huawei-telefoons geen Google-diensten.

Diagram van werking updates op A/B-partities

Reacties (69)

Dit concept komt niet uit de lucht vallen. In Linux zijn er ook al een paar onderdelen die op deze manier werken:
Kernel Live Patching
Het is middels enkele tools mogelijk om de Linux Kernel te upaten zonder deze te herstarten. Dit werkt door het modulaire systeem van de kernel. Veel drivers en netwerk functionaliteit zitten in hun eigen module dus je kunt de geupdate module naast de bestaande zetten, en dan tussen de sys-calls in, deze iut- en inwisselen.

OS-Tree
Dit is de super experimentele en interessante versie, welke Google hier in 'ligt' versie gebruikt. OS-Tree is een techniek waarbij je in feite GIT en LXC (marketingterm; Docker) gebruikt als systeem update mechanisme. Alle patches worden in losse images naast elkaar gelegd en de gebruiker kan dan door middel van een reboot de volgende version-stack activeren. Is er iets mis, dan kan het systeem meteen van de vorige versie booten.

Op dit moment zijn er enkele distros die dit gebruiken:

• Fedora Silverblue: https://silverblue.fedoraproject.org/
• Endless OS: https://endlessos.com/

Flatpak
Tot slot is er nog een packaging systeem dat het zelfde idee omarmt. Flatpak maakt ook gebruik van images die naast elkaar komen te staan en die wisselen wanneer je de app herstart.

[Reactie gewijzigd door Eonfge op 8 april 2020 09:22]

"Dit concept komt niet uit de lucht vallen"

Voor de mensen die het niet weten: Voor Android is het ook niethelemaal nieuw, het wordt nu gewoon alleen verplicht gesteld. Bij Android zelf is het in Oreo al gelanceerd. Gogole Pixels zijn bij Android 8.0 al overgeschakeld naar dual partition setup.

Maar er was nog iemand die nog ietsje eerder was. Sterker nog, in 2011 kwam Xiaomi met zijn eerste Mi Phone en daarin zat dit ook al. Ik weet nog dat ik hier veel gebruik van maakte bij mijn Xoami Mi2S. Mocht er iets mis gaan met de wekelijkse update, had je je oude partitie nog gewoon. Het leuke was dat je op een gegeven moment ook twee totaal verschillende ROM's kon installeren. Zo kon je op partitie A MIUI hebben draaien en op partitie B CyanogenMod (voorganger LineageOS)

Firefox is blijkbaar sinds versie 75 ook via Flatpak beschikbaar. Kende het nog niet, zal er eens naar kijken.

Firefox is now available in Flatpak, an easier way to install and use Firefox on Linux.

downloads: Mozilla Firefox 75.0

[Reactie gewijzigd door job_h op 8 april 2020 09:32]

Jaaah. Grote nieuwe stap voor Firefox. Flatpak packages bieden veel voordelen ten opzichte van de bestaande distributie methoden, dus ik zal iedere Linux gebruiker adviseren om de Flathub versie van Firefox te proberen.

Er zitten nog enkele bugs in, zoals het ontbreken van Wayland support, maar er is een eenvoudige patch beschikbaar.

Disclaimert, ben zelf een package maintainer op Flathub

Beetje offtopic. Maar Flathub was in eerste instantie bedoeld voor developers om hun packages direct aan te bieden aan hun gebruikers zonder tussenpersonen. Andere voordelen zijn inderdaad de sandboxing en het bundelen van alle dependencies zodat het op alle distributies werkt.

Maar zodra je non-affiliated package maintainers krijgt, dan gaat dat hele concept verloren. Vooral als je ziet dat Flatpaks zoals Signal door non-Signal devs wordt aangeboden. Ook gaat dat enigszins met vertrouwen verlies.

Granted, met RPM/DEB files heb je ook vrijwilligers die het maintainen. En zelfs met alle QA, hash checks en meerder ogen die potentieel de spec file checken, er kan altijd misbruik gemaakt worden. Vooral met de post-install scripts, dat is basically gewoon met root-rechten scripten op alle systemen. Ook is er met RPM/DEB veel meer (optionele) controle over hoe packages gebouwd worden. Althans, ik ben alleen bekend met RPM, spec files zitten vol met macro's die aangepast kunnen worden en zo de hele distributie een kant op kunnen sturen. Die best practices ontbreken bij Flatpaks, dat is gewoon een free for all.

Maar de originele belofte van Flathub was dat devs direct hun software voor alle distro's kon aanbieden. Dat wordt steeds meer losgelaten. Dat vind ik wel erg jammer eigenlijk. Het zou een mooie toevoeging zijn als er een mooie grote groene ster bij een Flatpak komt met "verified developer" of zoiets.

[Reactie gewijzigd door UPPERKEES op 8 april 2020 10:42]

Ik ben niet helemaal overtuigd van flatpack.....
Ik had een applicatie geïnstalleerd die had KDE V5.11 nodig, een uitbreiding voor die applicatie had KDE 5.10 nodig, een naastliggende applicatie was verbonden aan KDE 5.8 kortom voor 3 verwante applicatie waren 3 volledige KDE omgevingen meegenomen om het te laten werken...... + een native KDE omdati die al gebruikt werd.

Ik heb uiteindelijk de applicatie maar verwijderd en iets gezocht dat native installeerbaar was...

Google Chrome (Lees: Linux variant) werkt ook al zo.

Je mist nog wat filesystems denk ik, zoals BTRFS en ZFS, heb zo geen lijst van dingen die er mee integreren, maar met hun snapshots en virtuele volumes valt ook een hoop te doen in soortgelijke vorm.

Jep, de Solaris varianten doen zo hun updates met booten van een ander ZFS snapshot

Suse doet dit ook al jaren- elke update is een btrfs transactie en als het mis gaat kun je em ongedaan maken.

Dit concept komt niet uit de lucht vallen.

Welk concept precies?
Kernel Live Patching is toch echt iets anders, dan is een reboot niet nodig.

Iniderdaad. Bovendien moet ik, i.t.t. Linux-distributies, nog meemaken dat Android een kernelupdate of -patch krijgt. Misschien dat Google het wel doet op de Pixels, maar de meeste fabrikanten doen het niet, dus dan heeft KLP sowieso al geen zin.

LXC (marketingterm; Docker)

Hier ga je wel een beetje kort door de bocht... Er zijn best wel wat verschillen. Andere bron

[Reactie gewijzigd door Gropah op 8 april 2020 10:51]

kan je dan wel zelf de partitie waar de veroudere android versie op staat verwijderen? Anders ben je na een paar updates door je geheugen heen.

Nee, je houdt altijd twee partities. Op de ene staat de huidige versie. Op de andere wordt de nieuwe update gezet en daarna switch je naar die partitie. Je krijgt niet voor elke update een extra partitie dus je verliest niets.

Je krijgt niet voor elke update een extra partitie dus je verliest niets.

Is de ruimte van die tweede partitie niet 'permanent' verloren?

Ja, maar die verlies je niet omdat je hem in eerste instantie al niet 'krijgt'.

omdat je hem in eerste instantie al niet 'krijgt'.

Is dat zo? Als ik een telefoon met '64GB' koop, dan gaat die ruimte toch van die 64GB af?

Ja, maar je kunt hem vanaf het begin al niet gebruiken, dus in zekere zin heb je hem initieel al niet.
Semantische discussie

als je een telefoon met 64GB koopt krijg je nu ook geen 64GB aan opslag. je krijgt 64GB ruwe flash capiciteit. daar gaan dingen als je partitietafel en andere metadata nog vanaf, en boot partitie etc.

[Reactie gewijzigd door t link op 8 april 2020 17:11]

Ah duidelijk. Thanks.

Nee, het toestel overschrijft bij elke update gewoon de niet gebruikte partitie op dat moment en daarna wordt er gewisseld.

Edit: typo

[Reactie gewijzigd door Raymond Deen op 8 april 2020 09:01]

Hoef je bij je PC toch ook niet telkens te doen?
Die wordt als 'vrij' gezien en overschreven.

Hoe groot is zo'n partitie eigenlijk? En hoeveel vrije ruimte moet je dus hebben om in dit geval een update te installeren?

Mwa, ongeveer 2 a 3 gig. Maar ik zou verwachten dat men dan tijdelijk de data partitie verkleint, de update installeert, en na succesvolle upgrade de oude verwijdert en de data partitie weer groter maakt?

Mwa, ongeveer 2 a 3 gig. Maar ik zou verwachten dat men dan tijdelijk de data partitie verkleint, de update installeert, en na succesvolle upgrade de oude verwijdert en de data partitie weer groter maakt?

Partities vergroten en verkleinen gaat niet gebeuren op productiesystemen. Daarvoor is dat mechanisme te onbetrouwbaar.

De ongebruikte partitie blijft bestaan, zodat er altijd een situatie is om op terug te vallen. Stel dat na één maand een nieuwe Android versie zichzelf om zeep helpt, dan kan de oude Android versie gebruikt worden om een fix of een nieuwere Android versie te installeren.

[Reactie gewijzigd door The Zep Man op 8 april 2020 09:02]

Mwa dat valt tegen. Je data partitie krijgt ook aanpassingen wat vaak zorgt dat je niet terug kunt naar een oude versie. Misschien wel als de update in het midden mislukt, maar eenmaal geupdate naar een nieuwe major is permanent.

Mwa dat valt tegen. Je data partitie krijgt ook aanpassingen wat vaak zorgt dat je niet terug kunt naar een oude versie.

Het gaat niet om data beschermen. Daarvoor heb je (volgens Google) 'da cloud'. Het gaat erom dat toestellen niet bricken. Een toestel kan altijd een reset naar factory defaults krijgen, waarbij de /data partitie wordt gewist maar nog steeds een werkende /system partitie nodig is.

normaal niet, dat merk je bij custom firmware ook
het enige wat er normaal moet gebeuren ( en dat doet de flash normaal hier wel voor jou ) is de cache partitie ( en eventueel dalvik cache als die nog gebruikt wordt ) leegmaken en dan kan je gewoon terug je gewone data partitie gebruiken

Wat heeft dat voor zin? In de praktijk kan je die ruimte dus als gebruiker niet gebruiken dus lijkt me sterk dat ze dat dan beschikbaar maken om daarna misschien in de knoei te komen als die ruimte weer nodig is om een update te doen.

[Reactie gewijzigd door watercoolertje op 8 april 2020 09:09]

Dat is een trade-off, daar is juist wel bewust voor gekozen. Dit zorgt ervoor dat je altijd kan wisselen en updaten. En zoals eerder genoemd is het dynamisch vergroten en verkleinen van partities niet triviaal.

Ik heb zelf ook veel liever de laatste OS versie (security patches) dan meer foto's of apps.

Je reageert op de verkeerde ik geef net als jij aan dat het vergroten/verkleinen geen optie is

Ik reageerde op iemand die dacht dat zn partitie wel tijdelijk zou kunnen maar dat kan dus niet en dat heb ik dus uit proberen te leggen

[Reactie gewijzigd door watercoolertje op 8 april 2020 10:35]

”A/B updates require an increase of only 320 MiB in flash”
Op moderne devices met 64gb+ dus niet echt significant

Dat is inderdaad niet heel significant, goede oplossing in dat geval.

Daar zit een groot risico in.

Is er dan een 3e partie voor de /data?

ja, maar dat heb je ook met de klassieke layout waarmee systeem updates geïnstalleerd werden d.m.v. de recovery
Met A/B layout heb je eigenlijk 2 /system partities die de bootloader omwisselt tijdens het opstarten na een update.

Ja dat is al zo, je hebt een soort private(os) partitie waar je als gebruiker niet zo veel mee kan en daarnaast een losse partitie voor de data (en eventueel nog een partitie op een microsd-kaartje)

dat staat er los van
android bestaat uit meerdere partities
alleszins al de belangrijkste:

boot
system
data
cache

hier krijg je dus gewoon systemA en systemB als partities
die kan jij bij normaal gebruik niet aanpassen ( vereist su ) , jouw wijzigingen, apps etc staan onder data en die wordt niet aangeraakt

Wordt na de reboot ook partitie A bijgewerkt, of past bij de volgende upate? Staan alle bestanden echt dubbel op het systeem of wordt er veel gebruik gemaakt van symlinks (lijkt me complex over partities heen)?

vermoedelijk wel, maar dit gaat enkel over het OS, dat is zeker niet groter dan 2 GB...

Geen symlinks, want anders heb je bestanden alsnog niet dubbel.
Gewoon 2 volledige partities die los van elkaar kunnen werken alsof de andere er niet is.

Als je vanuit recovery update, zoals een paar merken doen, dan kun je bij een foute update je toestel opnieuw voorzien van een juist update bestand middels een pc en usb verbinding en dan nog een keer updaten, terwijl bij a-b-partities het toestel dat zelf kan regelen.

Afgaande op het schema bij het artikel wordt de partitie pas bijgewerkt op het moment dat de volgende update plaats vindt.

Het OS op mijn router is gebaseerd op Linux en heeft dezelfde setup als dit - tenzij je handmatig een partitie selecteert om te updaten wordt een update naar de inactieve partitie geschreven.

Wordt na de reboot ook partitie A bijgewerkt, of past bij de volgende upate?

Pas bij de volgende update:

1. We start with two system partitions, system_a and system_b, both on the same version of Android.
2. Assuming that system_a is active, the OTA update will patch system_b, the inactive partition, in the background.
3. system_a is set to inactive and system_b then becomes active once the user reboots.
4. The now-inactive partition, system_a, will be updated when the next OTA update rolls out.

Bron

Dank! Dan klopt het plaatje dus niet 100% (bij de meest linker / before update zie je nu 2x zelfde versie, wat dus praktisch nooit het geval zal zijn),

(...) wat dus praktisch nooit het geval zal zijn)

Jawel, dat is altijd het geval bij de eerste ingebruikname. Het OS waarmee de telefoon wordt uitgeleverd wordt op beide partities geplaatst, en een van de partities wordt actief gemaakt.
Dit blijft het geval, tot de eerste succesvolle update. En dat kan soms langer duren dan je denkt...

Ik zelf ben daar niet zo tevreden mee met al die partities, ik heb het al heel vaak gezien dat de partitie waar de APPS geinstalleerd worden bewust heel klein is gemaakt, terwijl het toestel nog ruim voldoende geheugen op de andere partities heeft maar je dit niet mag aanpassen (zonder root toegang).

Vroeger zag je dat vaak 1 of 2 apps installeren en vol zit hij...
En heel veel apps kunnen schijnbaar niet op "sd card" ook met name whatsapp doet niks met een sd card waardoor het telefoongeheugen vol loopt(je kan handmatig bestanden verplaatsen met een app maar dat is krom).

[Reactie gewijzigd door mr_evil08 op 8 april 2020 08:37]

Vroeger ja, toen telefoons nog andere indelingen hadden. Toen had je een interne sd kaart en een interne app opslag. Nu is dat gezamenlijk, en hebben telefoons vaak 16 a 32 gig (of vaak al meer). Dus dat probleem gaat niet meer zo op.

Kijk eens bij budget toestellen, ze zijn er nog genoeg, frustrerend zoals de Samsung s6, begrijp niet waarom daar 2 partities op zitten, de app partitie kan niks op terwijl de andere partitie heel veel ruimte heeft.

De S6 is dan ook wel 5 generaties geleden. De huidige budget toestellen doorgaans niet.

Ik heb dit gisteren nog gehad toen mijn asus zenfone 6 naar de maart security patch ging. Werkt fijn, je telefoon zegt in de notificatiebar dat ie bezig is met een update downloaden en instaleren. Dan vraagt ie, nu opnieuw opstarten of niet? Als je dan ja drukt, start ie opnieuw op, heeft ongeveer 2x zolang nodig als normaal, dus nog steeds niet heel lang, en dan is de update klaar. Eerder was je telefoon minutenlang onbruikbaar, nu wat, 30 seconden?

Dankzij het aan het artikel toegevoegde diagram begreep ik dit best wel ingewikkelde concept.

Hm ik kan mij voorstellen dat de rest zoals /data en /sdcard voor beide systemen beschikbaar blijven, is verder niet te moeilijk. Gewoon aanmaken en de update scripts instrueren om die te gebruiken.

Deze partities verwacht men dan eigenlijk (VOORBEELD):

- Systeem 1
- Systeem 2
- Gebruikersdata
- Recovery (eventueel i.c.m. Boot)
- (Eventueel) Boot

Stel je voor je wilt booten naar een ander OS dan zeg je tegen de bootloader "Laad de volgende keer maar Systeem 2", en daar staan dan de files met de nieuwere Android. Je blijft je gebruikersdata gewoon houden zonder moeilijk te doen.

En vergeet niet de swap partitie. Ik heb al Windows installaties zien vastlopen omdat er geen ruimte meer was voor de pagefile, sindsdien maak ik ook voor Windows altijd een swap partitie, iets ruimer dan het totale RAM geheugen.

Wat is er ingewikkeld aan? Het is eigenlijk gewoon een soort dual boot zoals je ook op je pc kunt hebben. Alleen heb je nu twee Android versies en op je pc bijvoorbeeld Windows en Linux. Beide partities zijn apart te updaten.

Met het kleine verschil dat bij dual boot ook de volledige gebruikersgegevens apart is en bij A/B update ze beide dezelfde data partitie of iets dergelijks gebruiken. Dus enkel en alleen het OS wisselt bij updates van partitie en de data zal vrij aannemelijk op een aparte partitie staan die door beide OSen gebruikt wordt.

EDIT: Bron: https://source.android.com/devices/tech/ota/ab

[Reactie gewijzigd door Remzi1993 op 8 april 2020 09:53]

Proef je het sarcasme niet dan?

Nee

Nee, maar misschien heb ik nog niet genoeg koffie gehad.

Ideaal hoor, ik heb hier zodoende ook twee SSD's in mijn PC om zo zonder aarzeling vers te installeren/testen.
Home staat op aparte disk dus bureaublad/achtergrond met de positie van desktop iconen, Firefox met de nog geopende tabs en alle applicatie user config is na de nwe installatie gewoon het zelfde. alleen even zorgen dat je applicaties er weer op zet.
Bij Linux mint kun je de geïnstalleerde applicaties voorhand exporteren tot tekstbestand om vervolgens weer te importen voor installatie, zelf gebruik hier een eigen installatie script bij voor die specifieke installatie handelingen uitvoert(veelal PPA afhankelijke bronnen).

De eventueel vergeten/niet geautomatiseerde custom system config. op de oude install buiten Home kun je zo ook makkelijk compare copy/pasten in de nwe installatie.

[Reactie gewijzigd door CHBN op 8 april 2020 19:24]

Gister hier een Samsung en een One Plus geüpdate en dit verschil viel mij inderdaad op. Waarbij de One Plus een veel fijnere ervaring had.

Bij ChromeOS en vooral ChromiumOS werkt dit al zo. Onder water is dat gebaseerd op linux techniek en dergelijke. ChromiumOS heeft 2 boot partities. Normaal boot ze van de eerste. Tenzij de tweede partitie een nieuwere versie bevat (en nog wat andere tests) Dan wordt alsnog de tweede geboot. Rond een update van het OS wordt in de regel de 'andere' partitie bijgewerkt. Daarna wordt die andere partitie geboot. Er is ook een handvat gedefinieerd om de 'oude' partitie bij te werken naar de huidige stand zodat ze beide weer gelijk zijn.

Voor de geïnstalleerde applicaties en de gebruikers gegevens zijn andere partities in gebruik. Dat wordt vooral ingevuld door een manier van werken die we al van linux kennen, zoals mounten en overlay-filesystemen.