To ze mu to trva tak dlouho a na popredi neni chyba Androidu ale vyrobce jeho telefonu(Samaung?), protoze neimplementoval A/B reseni, pri tom se altualizace stahuje&instaluje na pozadi a pak se jen rebootne do druhe slotu (sady systemovych oddillu) a navic v pripade problemu se jen znovu rebootne do predchozi verze co v puvodnim slotu zustava...
Bez A/B se stahne aktualizace do tempu, da reboot a pak se jedinej system patchuje a patchuje a uzivatel ceka a ceka...
ses si jistej? protoze v rodine Samsung A52s 5G nema A/B, kdyz sem hledal dalsi tak treba Samsung S23 nema A/B (a to je model z 2023 vydanej s Android13, s tim ze Goole ma pozadavek na vyrobce na povine A/B u telefonu co se vydaji s Android >=11 ;-), plus hromadu clanku "Samsung stale nepodporuje A/B ani u nejvysich modelu"... ;-)
ja jen vim z vlastni praxe ze A/B meli/ma: Nokia (7 Plus), Motorola (Moto G Pro), Firephone 5...
> prekompiluje pri prvom starte vsetky apk
To právě Android snad už ve verzi 9 nebo 10 umí udělat ještě před restartem, ale možná jen za určitých podmínek. Někdo tu zmiňoval A/B, nicméně to mi na druhý pohled nedává moc smysl – A/B se týká read-only systémových partitions. Je možné, že při nedostatku místa se na to Android vykašle.
> Ale aj to je dnes uz pomerne svizne.
Co to znamená? Možná máme jinou představu o „relativně svižně“ (desítky minut to pro mě nejsou), možná máte výhradně předinstalované aplikace (pak není moc co překompilovávat, zvlášť, pokud jsou již předkompilované), a možná jde o jiný proces. Při rekompilaci aplikací telefon nelze používat a visí tam text něco jako „Optimizing Apps (10/333)“. Nicméně po updatu typicky mi v notifikacích na chvíli přistane něco o dokončování updatu, během čehož již telefon používat lze.
s A/B jde o to ze celej system je dualne a pri OTA se pripravuje ten druhej set, nezkoumal sem jestli se realne prekompilovavaj apky, nebo nekde bokem generujou pomocne soubory ktere by mohli byt i na nejakem oddilu z A/B, nebo jestli si to na datovem spolecnem pripravi bokem...
kazdopadne prave sem delal OTA na Fairphone 5
- aktualizace vcetne stazeni trvala 8m, system sel mezitim pouzivat
- v prubehu sem zahlid "Chvilku strpeni, zarizeni se optimalizuje"
- reboot trval do lock-screenu 90s, pak sem zkusil druhej a ten byl 50s
= post-OTA zabralo 40s
- po odemceni se uz nic nedonastavovalo, jen se zobrazilo okno:
"Aktualizace systemu: The software has been succesfully updated"
BTW: FP5 mam rootlej, OTA se zobrazila bez problemu, pred pustenim sem v Magisk dal Uninstall/RestoreImages, po dokonceni OTA pred rebootem, v Magisk Install/InstallAfterOTA-ToInactiveSlot (A/B), po rebootu rootnuto...
Po instalaci aplikace dochází ke kompilaci do nativního kódu. Přitom může třeba i inlinovat něco ze systémových knihoven. To znamená, že při jejich změně (častý stav při aktualizaci) je nutné rekompilovat.
Toto vypadá, že se nic nerekompilovalo. To může znamenat:
a. Systémové knihovny používané pro kompilaci se nezměnily. Toto se někdy děje při malých updatech.
b. Nemáte nainstalovanou žádnou aplikaci. (Aplikace dodané se systémem se IIRC typicky dodávají předkompilované.)
b. pada, mam doinstalovanych ~150 apps
aktualizace mela ~29MB, mesicni GoogleSecurity + nejake upravy kolem nabijeni
kazdopadne podobne se mi ~3roky choval predchozi Motorola Moto G Pro, take s A/B, jen ta cast instalace trvala dele (i pri ~30MB update), ale take to melo mnohem pomalejsi CPU (Snapdragon 665), reboot trval max o `1-2 minuty dele nez normalne, po odemceni do 30s v notifikaci "Aktualizace dokoncena"
> b. pada, mam doinstalovanych ~150 apps
aktualizace mela ~29MB, mesicni GoogleSecurity + nejake upravy kolem nabijeni
Pak mi z toho vychází, že ty relevantní soubory nejspíš zůstaly netknuté. Což se u malých aktualizací může stát, párkrát jsem to viděl.
> jen ta cast instalace trvala dele (i pri ~30MB update),
Pravděpodobně právě kvůli té rekompilaci…
Nechce se mi moc věřit tomu, že by telefon zvládl rekompilovat ~150 aplikací během 40s, tj. pod 0.3s na aplikaci. Na Pixelu 6a se dostanu klidně na desítky minut (neměřil jsem přesně). A těch aplikací nejsou tisíce…
no jestli to prave nebylo to "Chvilku strpeni, zarizeni se optimalizuje" v prubehu instalace pred rebootem, nebo jinej krok, nesledoval sem celej prubeh v tech 8minutach nez to dojelo :)
na 90% myslim ta Motorola v prubehu te aktualizace (pred rebootem) mela krok "Optimalizuji se aplikace" a to tvalo nejdele
Jen pro představu: teď jsem dělal update GrapheneOS na Pixelu 6a. Je tam patrně nějaký bug, který způsobí, že rekompilace (všech nebo některých aplikací) někdy proběhne při rebootu. Měřil jsem to, cca 334 aplikací / 45 minut. To jsme řádově na třicetinásobku času na aplikaci, pokud rekompiloval všechny.
Ano, liší se procesor (Fairphone 5: 1x2.7 GHz Cortex-A78 & 3x2.2 GHz Cortex-A78 & 4x1.9 GHz Cortex-A55, Pixel 6a: 2x2.80 GHz Cortex-X1 & 2x2.25 GHz Cortex-A76 & 4x1.80 GHz Cortex-A55) a různé aplikace budou různě náročné na kompilaci, ale stejně mi ten poměr přijde až moc velký na to, aby se mi chtělo věřit, že Vám telefon kompiloval jednu aplikaci pod ⅓s.
Nikdy není tak špatně, aby nemohlo být ještě hůř. Můžeš zkusit Xiaomi a mít aktualizováno V mžiku, avšak mnohdy to spíš vypadá na kosmetické přepsání, protože některé chyby jsou stále přítomny v rozporu s dokumentací. A neboj, aktualizace budou otravovat maximálně jednou za kvartál (někdy i 5 měsíců).
"Tak ono je dost otázka"
Osobne davam jako priklad toho, jak veci fungovat maji ... trebas TC. A jak nemaji vlastne skoro cokoli jinyho.
Autor nevydava novou verzi co tyden, chova se to a vypada to desitky let stejne, dela to presne co delat ma, funguje to porad ... i na win 3.x, a semo tamo se tam objevi nejaka drobnost, ktery si treba ani nevsimnes, ale predevsim nic nerozbije.
Zakaznik pouziva ERP, za 15+ let co to pouziva se uz 3x menil frontend, a je to nejmin 10x pomalejsi nez to kdysi na 1000x pomalejsim HW bylo.
Mně teda přijde absurdní, že Androidí telefony to dosud neuměly nebo co. Ukazuje to opět, jak domrvený ten Linux v tom je -- protože normálně Linux tohle samozřejmě umí, je na to hotový jaderný modul a lidé to mnoho let běžně používají.
Ten problém se jmenuje NIH. Android řeší všechno po svém. Jejich kamera není V4L2 aby tam člověk mohl jednoduše spustit tohle hotové řešení, ale něco custom, pro které tyhle věci nejsou a má to vlastní sadu bugů (například mi ta jejich knihovna na kamery odmítala ukládat do tmpfs, ale ukládala do adresáře na filesystému pod tím). Takže člověk nemůže udělat tohle, nebo naopak opačný směr (hodilo by se třeba pro emulaci aplikacím, které trvají na tom, že si z kamery chtějí přečíst QR kód) - v4l2loopback.
A tak je to tam se vším - šifrování disku není standardní LUKS, ale něco custom, takže když si to vlivem yet another bugu přepíše klíče*, tak nejde použít standardní nástroje na recovery. Na sdílení displeje nejde použít VNC, protože to je asi moc mainstream, a mají místo toho custom scrcpy, pro které je právě jeden klient a které streamuje celou obrazovku furt a ne jen změněné oblasti. Audio není normální Alsa/Pulseaudio a musíte si vymýšlet nějaké knihovny protože amixer, arecord a aplay pořádně nefungujou. Odemykání obrazovky není PAM ale něco custom, takže si tam nemůžete přidat jednoduše pam_exec modul (třeba se záchranným/panikovým heslem) jako na normálním Linuxu, a jako bonus tam je nějaké úplné architekturní WTF že když si přidáte do systému další CA, tak to začne vyžadovat unlock heslem nebo co (tohle do teď nechápu, je to jako kdybych si na Linuxu přidal certifikát do /etc/ssl/certs a najednou to změnilo chování nějakého xscreensaveru, můžete mi někdo vysvětlit jak tyhle komponenty vůbec můžou souviset?). tcpdump je moc mainstream, uděláme androiddump. Atd.
Předřečník se ptal: „Jaka je zakladni vlastnost operacniho systemu, kterou android nedisponuje?“ Vyloženě žádná taková není. Ale celý ten systém je naprosto nenastavitelný a nepoužitelný. Nechápu proč tohle udělali, proč vyvinuli takovou hrůzu od nuly, když mohli vzít plně fungující GNU/Linux a postavit to nad tím.
*jejich GUI neumělo nastavit separátní heslo pro odemčení obrazovky a pro šifrování karty; šlo to pomocí adb. Jenže několikrát změnili API kterým se to dělá, a když člověk nastavil přes špatné, tak si to změnilo heslo tak že už to nikdy nešlo odemknout -- i když samotný AES klíč jsem měl zazálohovaný, tak protože to není normální LUKS tak nejde udělat recovery
Android zkrátka není distribuce linuxu a dívat se na něj jako na distribuci linuxu přináší jen velké zklamání. To je celé.Jestli je to dobře nebo špatně, to je jiná otázka. A proč tohle udělali? Tipoval bych, že vyvíjeli mobilní operační systém „shora“ a v nějakém okamžiku zjistili, že by potřebovali vespod vyřešit takové ty nudné věci jako správa paměti, správa procesů nebo souborový systém. Tak se porozhlédli, jestli už něco takového někde není hotové, a vzpomněli si na Linux.
Vzhledem k tomu, že o „letošek bude rokem linuxového desktopu, kdy linux na desktopu překročí 4 %“ se radši už ani nevtipkuje, zdá se rozhodnutí držet linux v těch mobilech od uživatelů co nejdál jako docela pochopitelné rozhodnutí.
Mně by se také líbilo mít v Androidu plnohodnotný linux, ale myslím, že ta volba byla hodně pragmatická a že díky ní Android vůbec vznikl a přežil. A teď k sobě mohou Linux a Android Linux postupně konvergovat.