Aktualizace OTA (Over The Air), i když nejsou specifické pro Android, jsou oblíbeným způsobem aktualizace vzdálených zařízení přes internet. Aktualizační balíčky se stahují přímo do vašeho zařízení, ale jak se tyto aktualizace skutečně aplikují ve světě Androidu? Než se ponoříme, promluvme si trochu o různých typech aktualizací OTA.
V současné době Android podporuje dva různé mechanismy aktualizace:
Systémy jiné než A/B ukládají pouze jednu kopii každého oddílu. U zařízení s omezenou velikostí flash lze tento starší aktualizační mechanismus stále používat. Použití tohoto typu aktualizace je poměrně jednoduché. Aktualizační balíček se jednoduše stáhne do /cache nebo /data oddílů a používá se RecoverySystem API, aktualizace je zahájena. Toto je systémové API a vyžaduje, aby jej měl volající android.permission.RECOVERY povolení, které není uděleno běžným aplikacím.
RecoverySystem.installPackage je volána k použití aktualizace, pokud je aktualizační balíček skutečně pod oddílem /cache, jednoduše nastaví BCB (Bootloader Control Block) nastavením některých spouštěcích parametrů, jako je umístění souboru aktualizačního balíčku, informace o národním prostředí (aby se zobrazil text aktualizace ve správném jazyce) a zda se jedná o zabezpečenou aktualizaci či nikoli. Dalším krokem je restart do obnovy.
Pokud je aktualizační balíček pod /data, balíček musí být Uncrypt-ed. Odšifrovat je binární soubor, který jednoduše vezme soubor a vytvoří jeho blokovou mapu. Tuto mapu bloků lze poté použít ke čtení obsahu souboru bez připojení souborového systému. To se provádí tak, aby obnova mohla přistupovat k obsahu aktualizace bez připojování oddílu /data, protože systém obnovy nemá měnit jeho obsah (existují pravidla SElinuxu, která zajistí, že se obnovení nemůže dotknout datového oddílu během OTA aktualizace).
Jakmile se zařízení zavede do obnovy, aktualizují se oddíly /system a /boot. Co takhle aktualizovat oddíl pro obnovení? můžete se zeptat. Ve skutečnosti není v tuto chvíli aktualizován. Místo toho, když se zařízení spustí pomocí nových oddílů /boot a /system, Android hledá soubor s názvem recovery-from-boot.p v novém systémovém oddílu a aktualizuje oddíl pro obnovení pomocí této opravy. Existuje způsob, jak aktualizovat oddíl pro obnovení První a pomocí něj provést zbytek aktualizace. Při vytváření aktualizačního balíčku pomocí ota_from_target_files skript, použití -2 možnost vytvořit dvoufázový aktualizační balíček (Výsledkem je větší aktualizační balíček, protože vkládá spouštěcí i obnovovací obraz přímo do aktualizačního balíčku, což může být problém u přírůstkových aktualizací).
Existují dva typy aktualizací mimo A/B:
- Aktualizace založené na souborech — Aktualizuje každý soubor na úrovni souborového systému. Problém s tímto přístupem je, že v závislosti na tom, kdy je aktualizace skutečně použita, bude mít systémový oddíl soubory s nekonzistentními datum poslední změny informace. Z tohoto důvodu nelze aktualizace OTA založené na souborech použít, když dm-pravda je povoleno, protože pokusy dm-verity počítají SHA256 každého bloku a porovnávají je s očekávanými hodnotami. Vzhledem k datům poslední změny varianty tato kontrola selže a systém nebude možné po aktualizaci spustit.
- Aktualizace založené na blocích — Pro konzistentnější systémový oddíl po aktualizaci se používají blokové aktualizace OTA. Aktualizace OTA založené na blocích zajistí, že po aktualizaci budou mít všichni přesně stejný obraz systému.
Hlavním nedostatkem aktualizace Non-A/B je to, že má potenciál vylepšit systém. Protože se aktualizace přímo aplikují na každý oddíl, zůstane vám systém, který nelze spustit, pokud se něco pokazí (Zejména u televizorů Android, které na rozdíl od chytrých telefonů nemají vlastní baterie, jste v podstatě jeden výpadek napájení od ztráty zařízení.
Jak tedy zajistíte, že můžete mít stále funkční systém i poté, co se aktualizace systému pokazí? Samozřejmě uložením dvou z každého potřebného oddílu!
Počínaje Androidem 7.1 jsou zavedeny aktualizace A/B. Systémy A/B uchovávají redundantní kopie /system, /boot, /vendor a dalších volitelných/oddílů specifických pro dodavatele (jako je /bootloader nebo nějaký jiný vlastní oddíl). Oddíl /recovery se již nepoužívá, protože byl v první řadě velmi podobný oddílu /boot, oddíl /boot nyní obsahuje recovery ramdisk. Zachování dvou z každého oddílu efektivně zdvojnásobí velikost úložného prostoru, ale pokud máte místo navíc, stojí to za to.
Systémy A/B obsahují tzv. oddíly A/B sloty jako jsou sloty system_a/system_b. Váš aktuální slot je aktivní a spouštěcí slot a aktualizace se ve skutečnosti aplikuje na neaktivní slot. Pokud se během aktualizace něco pokazí, stále máte svůj aktuální systém nedotčený.
Aktualizace jsou aplikovány, když je vaše zařízení stále spuštěno, protože jsou aplikovány na neaktivní slot. Jakmile jsou použity, dojde k restartu a váš neaktivní slot je označen jako aktivní a zaváděcí slot. Pokud se úspěšně spustí, je označen jako úspěšný takže ho od té chvíle používáte dál. Pokud se po několika pokusech nepodaří nabootovat, bootloader jej označí jako nespouštěcí a váš starý, nedotčený slot označí znovu jako aktivní/zaváděcí.
Streamování A/B aktualizací
Systémy A/B také podporují streamování aktualizací, které mohou vašemu systému Android umožnit používat aktualizace při jejich stahování. Vzhledem k tomu, že není nutné stahovat celý balíček, nepotřebujete další místo, které je přiděleno oddílu /cache, a proto není vůbec potřeba žádný oddíl mezipaměti.
O plné aktualizaci Androidu se nedá moc mluvit, jak už název napovídá, jednoduše přepíše celé oddíly novými. Přírůstkové aktualizace jsou zajímavější, tak si o nich povíme:
Přírůstkové aktualizace OTA
Balíčky přírůstkové aktualizace se generují pomocí dvou cílových_souborů (předchozí verze a nová verze), aby se mezi nimi vygenerovala oprava. Tyto opravy jsou poté aplikovány během mechanismu aktualizace. Protože se přírůstkové aktualizace generují specificky pro určité verze, lze je použít pouze k aktualizaci z jedné konkrétní verze na jinou. Z tohoto důvodu by i nepatrná změna v aktivních oddílech na zařízení vedla k selhání přírůstkových aktualizací, protože se před pokusem o aktualizaci vypočítá hash oddílu a porovná se s očekávanou hodnotou (Pokud zařízení nějak rootnete a upravíte systémový oddíl po opětovném připojení se můžete rozloučit s přírůstkovými aktualizacemi).
OTA balíčky jsou všechny generovány z cílové_soubory zip soubory. Tyto balíčky obsahují všechny oddíly. ota_from_target_files.py se používá ke generování balíčku OTA z cílového souboru. -blok volba je určena pro generování blokové aktualizace OTA, výchozí je souborová. Zadáním můžete generovat přírůstkové aktualizace -i a poskytuje skriptu dva zipy target_files.
Cílové soubory a balíček Full OTA se generují automaticky při sestavování AOSP dist volba.
Zde je několik příkladů generování balíčků OTA z kořenového adresáře vašeho Android adresáře:
# Exportujte cestu ota_from_target_files.py pro snadnější použití.
export GENERATE_OTA=$ANDROID_BUILD_TOP/build/tools/releasetools/ota_from_target_files.py
# Generuje běžné OTA založené na souborech.
$GENERATE_OTA
# Generuje plné blokové OTA.
$GENERATE_OTA—blok
# Generuje přírůstkové OTA mezi dvěma verzemi.
$GENERATE_OTA -i
OTA balíčky obsahují každý oddíl (nebo jejich záplaty pro přírůstkové aktualizace). Obsahuje také soubor s názvem otacerts který se používá pro ověření balíčku (ve srovnání s /system/etc/security/otacerts.zip). Tip: I když kontrolu certifikátu za vás provádí systém obnovy po restartu, můžete stále používat RecoverySystem.verifyPackage k provedení kontroly certifikátu před spuštěním instalační balíček. Pokud kontrola selže, nebudete muset restartovat do obnovy, což ušetří spoustu času.
Kromě samotných aktualizačních souborů existují dva soubory tzv updater-script a updater-binary. Updater binární jednoduše spouští příkazy definované ve skriptu updater, aby provedl aktualizaci.
Updater-script se může lišit v závislosti na způsobu generování balíčku OTA, ale obecně obsahuje následující:
- Porovnání data sestavení (Pro úplné aktualizace OTA, takže starší aktualizaci nelze použít na novější systém).
- Extra kontroly majetku jako např ro.product.device, ro.build.otisk prstu atd.
- Porovnání kryptografických hashů (pro přírůstkové aktualizace).
- Příkazy pro extrahování souborů, použití aktualizačních bloků.
- Tiskne pro ladění (obvykle přihlášen do sériových ladicích linek).
