V tomto článku zkoumáme pravdu o tom, proč zařízení Snapdragon 801 nedostávají Android Nougat. Od výrobců čipových sad až po dodavatele je mnoho problémů!
Aktualizováno tak, aby odráželo požadavek buď-nebo Vulkan nebo OpenGL ES 3.1 pro Android 7.0
V poslední době bylo napsáno mnoho článků o aktualizacích verzí, interakcích mezi dodavatelem a výrobcem čipové sady a o tom, co to znamená pro zařízení v budoucnu. Proč se to tento týden zvýšilo?
Tento týden se ukázalo, že úctyhodný Nexus 5 neobdrží aktualizaci na Android 7.0 (Nougat) a Qualcomm oznámil, že nebude poskytování podpory pro MSM8974 (běžněji známý jako Snapdragon 801) na 7.0. Tento článek byl napsán ve spolupráci s XDA Recognized Vývojář čmelák.
Téma vzbudilo značný zájem různých zpravodajských webů, ale mnozí přicházejí o jemné nuance toho, co se skutečně děje v zákulisís. Tento článek vysvětlí trochu více o tom, jak aktualizace softwaru fungují, s využitím našich zkušeností s prací s výrobci OEM na jejich oficiálních aktualizacích firmwaru. Provedeme vás tím, co se děje v zákulisí (a proč) a proč možná nakonec nezískáte nejnovější software do telefonu.
Prvním krokem v životě aktualizace firmwaru Android je upstream aktualizace. Na tom Google interně pracuje. Na rozdíl od „otevřených pracovních postupů“ je Android vyvíjen pomocí uzavřeného pracovního postupu, se zdrojovým kódem hozeným přes zeď každý rok, když vyjde nová verze. Původně to měl Google říkat, aby se zabránilo fragmentaci lidí, kteří používají verze s krví zatímco se věci v prvních dnech rychle vyvíjely, ale zdá se, že si tuto politiku udrželi místo.
V určitém okamžiku, obvykle před veřejným oznámením aktualizace (ačkoli s nedávným zavedením veřejných beta verzí se tyto časové osy posouvají), OEM budou informováni o nadcházející aktualizaci. Poté obdrží zdrojový kód v druhém okamžiku pro konečnou aktualizaci (v minulosti to bylo někdy s malým předstihem před spuštěním, i když jsme si vědomi i případů, kdy tomu tak není uvolnění).
Upstream repozitáře AOSP obsahují podporu zařízení pouze pro omezený počet zařízení. Obvykle se jedná o vaše zařízení Nexus. Z důvodů, které budou brzy jasné, je však důležité poznamenat, že Google nemá nad těmito zařízeními úplnou kontrolu hardwaru; zařízení vyrábí OEM a tento OEM koupí System-on-Chip (SoC) od výrobce čipové sady.
Jakmile bude zdrojový kód uvolněn, tým firmwaru OEM se (obrazně) posadí a dá nohy nahoru. Hlavní zdrojový strom Androidu nemá hardwarovou podporu pro nesčetné množství čipových sad používaných v přepravních zařízeních. Vaše čipová sada Qualcomm s největší pravděpodobností není podporována například v rámci AOSP. Váš Exynos rozhodně není. Mediatek nebo HiSilicon? Zapomeň na to!
BSP obsahuje ovladače a vrstvy abstrakce hardwaru (HAL), které jsou potřeba ke spuštění Androidu
Co je nyní potřeba, je a Balíček podpory desky (BSP). Jedná se o super-důvěrný balíček proprietárních komponent, který dodává výrobce čipové sady výrobci OEM. BSP obsahuje nezbytný zdrojový kód, který umožní výrobcům OEM sestavit Android a potřebné ovladače pro jejich zařízení.
Zde stojí za zmínku, že výrobci OEM, jako je Qualcomm, nemusí nutně plně důvěřovat svým partnerům OEM – BSP je k dispozici na základě „potřeby vědět“. OEM výrobci obvykle nemají přístup ke zdrojovému kódu některých supertajných částí zařízení (jako je software běžící v základním pásmu). Uzavření této části má jistě také potenciální problémy, jak ukazuje blízkost hojný a opakující se ASN.1 analyzovat zranitelnosti.
BSP obsahuje ovladače a vrstvy hardwarové abstrakce (HAL) potřebné k tomu, aby Android na vašem zařízení běžel. AOSP obsahuje sadu HAL, které fungují jako definice toho, co operační systém očekává od vašich ovladačů. Abychom použili směšně příliš zjednodušený (a pro účely demonstrace vymyšlený) příklad, představme si baterku na vašem telefonu.
Příklad HAL - Vaše baterka
Představme si, že vaše zařízení má na zadní straně svítilnu (pokud máte Nexus 7 2013, budete si muset představovat trochu víc než všichni ostatní – omlouváme se!). To je řízeno řidičem. Pro náš bláznivě jednoduchý příklad předpokládejme, že v1 HAL říká, že byste měli mít jednu funkci nazvanou „setLED“ s jediným parametrem, stavem světla. Je to logická hodnota - pravda nebo nepravda. V C by to vypadalo nějak takto:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Tato funkce je definována ve zdrojovém kódu BSP. BSP je poté zkompilován výrobcem OEM během vytváření ROM a stane se jednou z proprietárních knihoven „.so“ na oddílu dodavatele nebo oblasti vašeho zařízení. To umožňuje výrobci OEM udržet určité části fungování svého zařízení v tajnosti. Prozatím předpokládejme, že chtějí všem zabránit, aby viděli, jak zapínají a vypínají tuto LED.
Nyní si představte, že Google vydá aktualizovanou verzi svých HAL v budoucí verzi Androidu. Nyní se rozhodli, že by bylo hezké umožnit vám aktualizovat jas vaší LED, spíše než ji pouze zapínat nebo vypínat. Možná je to pro adaptivní flash, nebo možná jen pro vynucení aktualizace HAL a udržení výrobců čipových sad v podnikání? Necháme vás, čtenáře, abyste si na to udělali svůj vlastní názor. Některé aktualizace HAL mají jasný přínos (například nový Camera HAL odhalující syrové fotografování a podobně), zatímco jiné mají poněkud méně jasný účel.
S tímto novým (fiktivním) HAL pro jas předpokládejme, že Google říká, že musíte znovu vystavit funkci nazvanou setLED, ale tentokrát s celým číslem zadaným pro jas. Nyní by to 0 vypnulo a 255 by to zapnulo naplno.
Pokud jste OEM, můžete použít svůj supertajný kód k rozsvícení této LED a vložit jej do této nové funkce. Můžete dokonce použít modulaci šířky pulzu k nastavení jasu LED na základě čísla. Nyní změníte funkci, aby vypadala takto:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
No a co? Nyní je tato nová verze Androidu nekompatibilní se stávajícími „bloby“. Váš OEM musí tyto nové bloby používat, protože operační systém Android očekává, že uvidí novou definici funkce, a když bude hledat způsob, jak nastavit LED, „nenajde“ tu starou.
Na tomto místě si dáme krátkou přestávku, abychom se podívali na to, jak si zde poradí Custom ROM (postavené ze zdroje). To je to, co ti bystří mezi vámi budou právě teď křičet na vaši obrazovku – koneckonců jsme XDA, domov HTC HD2, telefon s nejdelší výdrží na světě... (jen pro pořádek, ti šílení géniové tam běží Android 6.0 na HD2 v těchto dnech! Není to špatné pro telefon původně dodaný s Windows Mobile 6.5 v roce 2009)
Jsou zde použity různé přístupy – někdy se vývojáři nabourají do ROM a řeknou OS, aby použil staré definice funkcí. To je trochu chaotické a vyžaduje to spoustu změn. Druhým přístupem je „shim“ binárního kódu OEM.
Přístup „shim“ spočívá v tom, že si sami napíšete a vytvoříte malou novou knihovnu, která obsahuje očekávanou definici funkce – pro náš příklad bychom podporovali celé číslo pro jas. Pak se to v rámci podložky přeloží tak, aby splňovalo požadavky staré HAL. Takže pro náš příklad bychom možná řekli, že jakýkoli jas požadovaný nad 128 rozsvítí LED a cokoli pod to ji vypne. Nebo můžete říct, že cokoliv, co není nula, to zapne. Je to na vývojáři. Zkompilují shim a přimějí jej používat Android místo nativního. Shim pak zavolá OEM blob.
Rychlý „adb push“ a restart by měl spustit podložku a umožnit vám ovládat vaši fiktivní LED, i když máte pouze starý HAL.
Problém je v tom, že jde jednoznačně o nedokonalý proces. Nyní budete mít vtipy - toto zařízení bude mít poněkud mizerný blesk, který je buď plně zapnutý, nebo zcela vypnutý. To není ideální – OS si myslí, že vydává velmi jemné světlo, ale skutečné LED je řečeno, že soutěží v soutěži umělého slunce a snaží se vás oslepit. Ale ouha, život není dokonalý a vy teď máte na svém starém telefonu funkční LED!
(Ano, to je jeden z důvodů, proč se objevují vtípky a chyby, když uživatelé a vývojáři XDA zvládají své šílené a šílené výkony portování. Myslím sakra, ten Galaxy S II je tahání zdánlivě použitelné Android 6.0 ROM nyní. Mnoho telefonů vydaných v loňském roce stále nemá 6.0!)
Vraťme se k pohledu OEM. Je smutné, že většina výrobců OEM již pracuje minimálně o 1 telefon před tím, kde jsme právě teď. Zaměřují se na další telefon, který se chystají prodat – nemůžete jim to mít za zlé, protože vydělávají pouze na zařízeních, která prodávají. Nevydělávají žádné peníze na zařízeních, která prodali před rokem nebo dvěma, takže musí neustále vydávat nová zařízení, aby existovali. To je jeden z důvodů, proč mají HTC a Blackberry potíže – nezáleží na tom, kolik manažerů si zachovává smrtící přilnavost na jejich starém Blackberry Curve, protože tam nedostávají prodej nového zařízení.
Pokud výrobce OEM nezíská BSP, nepostoupí z přístupu XDA spočívajícího v hackování sestavení. Proč? Studna, potřebují podporovat tento firmware pro své zákazníky. Pokud vydají firmware, který je napůl funkční, uživatelé je budou nenávidět, řvát a běsnit a jejich linky podpory budou zvonit celé dny.
OEM také musí bojovat s dopravci, alespoň na mimoevropských trzích. Operátoři nechtějí, aby zákazníci měli problémy s aktualizacemi softwaru. Ve skutečnosti by dopravci často raději nevydávali aktualizace softwaru.
Abyste tomu porozuměli, představte si svou pratetu Alici. Je to ona, kdo vám v nevhodnou denní dobu zatelefonuje a požádá o pomoc s "tím počítačem". Poté popíšete, jak kliknout na "nabídku Start", a musíte ji identifikovat jako "velkou vlajku v levém dolním rohu", a narazíte na zmatek. Asi o 45 minut (a hodně frustrace) později se ukázalo, že teta Alice přetáhla svou nabídku Start k pravému okraji obrazovky a jednoduše ji potřebovala přetáhnout zpět. Ano, levým tlačítkem myši!
A teď si představ, že máš tisíc tety Alice. Všichni volají na vaši zákaznickou podporu, ale nemohou najít Candy Crush na svém telefonu, obávají se, že ji hacker smazal z jejich telefonu. Jo, a ikony teď vypadají trochu jinak - možná je hacker stále v jejich telefonu?
Ano, je to myšleno jako trochu odlehčený humor, ale dokud nezažijete důvody, proč lidé volají svému operátorovi o podporu, neuvěříte, jaké problémy mají. Aktualizace softwaru, která změní způsob, jakým telefon funguje nebo kde se věci nacházejí, způsobí značnou režii podpory. Minimálně to vyžaduje přeškolení podpůrného personálu (protože většina z nich bohužel není váš vášnivý čtenář XDA).
Jakmile OEM získá BSP, přenese svou ROM a použijí všechny své změny na ROM. Nashromáždí své bloatware a přidají příšerný kreslený skin, který by v anime pro teenagery vypadal víc jako doma. Pak to otestují.
Mnoho.
Váš telefon musí splňovat nejrůznější požadavky. Mobilní sítě jsou navrženy tak, aby důvěřovaly uživatelskému zařízení (to, čemu říkáme telefon), že se bude chovat správně. To znamená, že ke schválení zařízení je potřeba mnoho testů. Aktualizace softwaru riskují změnu chování, takže je potřeba věci znovu otestovat. To je důvod, proč běžně uvidíte informace o nadcházejících aktualizacích softwaru Sony od externích testovacích služeb, které potvrzují, že firmware je v souladu s požadavky testu.
Nyní... co se stane po aktualizaci nebo dvou (nebo v některých případech žádné)? Výrobce SoC neposkytne OEM aktualizované BSP. Ostatně, výrobce SoC z toho moc nedostane. Výrobce OEM na vašem telefonu od jeho prodeje nevydělává žádné další peníze. A v tuto chvíli váš telefon nedostává žádné další aktualizace hlavních verzí.
Snížení počtu BSP, které chce OEM dodat, je skvělý způsob, jak ušetřit peníze – pokud potřebujete pouze ten aktuální a nehodláte dodávat žádnou hlavní verzi. zvýší, ušetří to peníze za počáteční nákup SoC a licencování, ale na úkor několika naštvaných pitomců na XDA, kteří se diví, proč nedostali Aktualizace.
Aktualizace jsou složité. V řetězci je zapojeno mnoho různých lidí. Nic z toho neomlouvá výrobce OEM ze současného chabého a žalostného stavu aktualizací na Androidu. Přesto zde existují skutečné výzvy.
Mnoho výrobců OEM je vinných za přílišné sliby a nevyhnutelné nedostatečné plnění, které nyní spojujeme. Smutnou realitou je, že pro většinu výrobců OEM jsou aktualizace softwaru jen nepříjemností, bez které se obejdou.
Mobilní sektor většinou uvízl v myšlení běžných telefonů. To znamená, že zařízení nikdy nedostává žádné aktualizace. Jednou otestujte, odešlete a nikdy se neohlížejte. Vzhledem k bezpečnostním problémům moderních smartphonů a naprosté složitosti provozu plnohodnotného operačního systému pro všeobecné použití se stovkami externích knihoven to již není možné. Nebo alespoň to neměl by být. Google podnikl určité kroky k nápravě toho, že alespoň publikoval bezpečnostní bulletiny a opravy pro stávající verze systému Android (pamatujte, že až donedávna byl jediný způsob, jak získat aktualizace zabezpečení, prostřednictvím nové hlavní verze operačního systému Android!)
Bohužel to však opravdu nestačí. I když Google neustále vydává aktualizace, zabezpečení vašeho zařízení stále závisí na výrobci SoC – protože výrobci SoC jsou tak zkamenělí když někdo objeví, jak rozsvěcí několik LED nebo vydávají zvuk z reproduktoru, pošle na své zařízení obrovské množství binárních kuliček zařízení. Tyto bloby obsahují dost děsivě nezabezpečený kód (pokud si myslíte, že je to přehnané, podívejte se na minulé bezpečnostní bulletiny Google!) a je třeba je aktualizovat. Což znamená, že jsou vyžadovány aktualizované BSP.
Stolní počítače (a potažmo notebooky) se architekturou zcela liší od mobilních zařízení. Váš mobilní telefon nebo tablet je ve skutečnosti silně proprietární kus křemíku, navržený ve spěchu některými lidmi, kteří to myslí dobře, ale nemají ani zdaleka dost času udělat něco dobrého. Trh se pohybuje tak rychle, že jsou stěží schopni držet krok s tempem, kterým marketing požaduje uvedení nových produktů na trh.
To znamená, že jsou použity zkratky – nenajdete váš telefon podporovaný hlavním linuxovým jádrem a zjistíte, že každý telefon má jiný způsob bootování. Na vašem notebooku nebo desktopu se však prodejci usadili na některých standardních způsobech bootování – dříve to byl MBR (master boot record) s BIOSem a nyní je to UEFI. Tato standardizace umožňuje provozovat stejný software na každém zařízení.
I když v poslední době k tomu byly učiněny určité kroky, zejména s programem Sony pro dosah a jejich jednotné jádro, není praktické spouštět jádro hlavní řady na většině telefonů kvůli obrovskému množství nových hacků specifických pro dodavatele zavedených do každého zařízení.
Zapojili jste konektor sluchátek špatně? Stačí to nabourat do ovladačů! Není čas to opravovat v produkčním návrhu.
Výrobní tým namontoval modul kamery obráceně ve výrobní dávce 1? Vhoďte hack a zkontrolujte interní kód verze a otočte video, pokud je to verze 1!
Hacky jako tyto řeší okamžitý problém, ale pouze seškrábou povrch podivných a pro produkt specifických změn, které se dějí. Sakra, někdy jsou kvůli komerčním rozhodnutím dokonce úplně odlišné čipy v různých revizích stejného telefonu. Ty vedou k hackování ovladačů a podivným rozhodnutím, která dávala smysl pouze v té době, aby telefon fungoval, aby mohl být odeslán příští týden.
Zatímco probíhají práce na podpoře hlavní řady pro 64bitové čipy ARM pro spouštění pomocí UEFI, dosud žádný jasný posun směrem ke standardizovanějšímu způsobu spouštění zařízení ARM. A to je smutné, protože to znamená, že telefony budou i nadále vyhazovány dlouho před koncem jejich životnosti pracovní životy, protože udržet technický dluh a zátěž na nich je prostě příliš drahé software.
Na druhou stranu, pokud OEM bude vydělávat peníze pouze na prodeji zařízení, nemusí zajistit, aby lidé i nadále kupovali nové telefony? Přešel by trh s PC na tento model, kdyby tam již nebylo 30 let hybnosti a staršího softwaru využívajícího otevřenou platformu PC a standard?
To je těžká otázka bez vnitřních znalostí od Qualcommu, které bohužel v tuto chvíli nemáme. Některé informace však můžeme čerpat z API ovladače pro Android 7.0 a požadavků CTS. Požadavky CTS specifikují, co Google očekává od zařízení s daným firmwarem. „Velkým kladivem“ používaným k vymáhání těchto požadavků je licencování společnosti Google k používání jejich proprietárního balíčku služeb Google Play – pokud nevyhovíte, nebudete moci do zařízení odeslat Google Apps. Zatímco pro některé, toto může být vnímáno jako výhoda, to samozřejmě není to, co uživatelé od zařízení chtějí a očekávají.
Android 7.0 nepřidal mnoho změn v HAL nebo ovladačích (jak je popsáno výše), takže je nepravděpodobné, že by nějaká nekompatibilita pocházela konkrétně odtud. Co však pravděpodobně bude představovat problém, je zavedení a nový požadavek na grafické rozhraní API Vulkan nebo GLES 3.1, být k dispozici, aby prošel CTS.
V současné době mnoho Systems-on-Chip (SoC) nemá podporu Vulkan na svém grafickém procesoru, včetně MSM8974. Zde také s největší pravděpodobností vyvstane problém kompatibility s Androidem 7.0. Opět však platí, že bez vnitřních znalostí společnosti Qualcomm a jejich budoucích plánů je pro nás těžké vydat definitivní prohlášení, aniž bychom to kvalifikovali. V tuto chvíli se však domníváme, že je pravděpodobné, že se jedná o „jednoduchý“ případ ukončení podpory společnosti Qualcomm (v jejich očích) stárnoucí čipová sada MSM8974 a neposkytování BSP (balíček podpory desky) pro 7.0 na této platformě. Pokud by tomu tak bylo, znamenalo by to, že výrobci OEM by si byli téměř jisti, že nebudou dodávat 7.0 na zařízení – museli by nějakým způsobem najít podporu Vulkan nebo GLEs 3.1 pro svůj GPU a zdroj GPU kód je jednou ze směšně přísně střežených částí mobilních zásobníků (bez skutečného důvodu bychom přidali - viz AMD, otevřené získávání vlastního ovladače AMDGPU na ploše pro Linux). Je však smutné, že grafika Vulkan a akcelerovaná (GLES) grafika obecně jsou o něco složitější než jednoduchá LED, takže to není něco, pro co bychom měli zavádět kompatibilitu.
Vzhledem k tomu, že verze 7.0 nebyla vydána dlouho, existuje reálná možnost, že jiné čipové sady (kromě malého počtu v samotném AOSP) odejdou za 6.0, buď kvůli problémům s hardwarem a ovladači (tj. bez aktualizovaného BSP) nebo kvůli nedostatku podpory dodavatele SoC s ohledem na Vulkan nebo GLES 3.1 API. V současné době ani Snapdragon 800 nebo 801 nepodporuje jeden z nich.
Nejlepší je sledovat tento prostor - Vývojáři na XDA již dosáhli dobrého pokroku s neoficiálními porty na 7.0 pro mnoho zařízení, která od společnosti Google nedostávají oficiální podporu 7.0. Ty jsou však bez podpory Vulkanu nebo GLES 3.1 - snad začnou vývojáři her pro Android zažít frustraci z fragmentace, pokud dostatek uživatelů začne používat vlastní ROM bez Vulkan nebo GLES 3.1 Podpěra, podpora?
Apple má tendenci podporovat svou řadu iPhone na nejnovější verzi iOS po dobu přibližně 5 let – iPhone 4s byl uveden na trh v říjnu 2011 a byl aktualizován až na iOS 9. Nedostane však nadcházející aktualizaci iOS 10, která by telefonu poskytla efektivní životnost 5 let, za předpokladu, že iOS 10 bude spuštěn kolem října. Stojí za zmínku, že Apple ne vždy podporuje grafické rozhraní API – iPhone 4s a iPhone 5 ne funkce Apple Metal Graphics API, což je poněkud podobný scénář jako u Androidu Vulkan. Jediný rozdíl je v tom, že Apple nadále podporoval starší zařízení bez nového grafického API.
Co myslíš? Budete flashovat vlastní ROM v telefonu, abyste prodloužili jeho životnost? Řekněte v komentářích níže.