V tomto článku skúmame pravdu o tom, prečo zariadenia Snapdragon 801 nedostávajú Android Nougat. Od výrobcov čipsetov až po predajcov je veľa problémov!
Aktualizované tak, aby odrážali požiadavky Vulkan alebo OpenGL ES 3.1 pre Android 7.0
Nedávno bolo napísaných veľa článkov o aktualizáciách verzií, interakciách medzi predajcom a výrobcom čipsetov a o tom, čo to znamená pre zariadenia v budúcnosti. Prečo sa to tento týždeň zvýšilo?
Tento týždeň sa ukázalo, že ctihodný Nexus 5 nedostane aktualizáciu na Android 7.0 (Nougat) a Qualcomm oznámil, že nebude poskytovanie podpory pre MSM8974 (bežnejšie známy ako Snapdragon 801) na 7.0. Tento článok bol napísaný v spolupráci s XDA Recognized Vývojár čmeliak.
Téma vzbudila značný záujem rôznych spravodajských webov, ale mnohým unikajú jemné nuansy toho, čo sa v skutočnosti deje v zákulisís. Tento článok vysvetlí trochu viac o tom, ako fungujú aktualizácie softvéru, pričom využijeme naše skúsenosti s prácou s výrobcami OEM na ich oficiálnych aktualizáciách firmvéru. Prevedieme vás tým, čo sa deje v zákulisí (a prečo) a prečo nakoniec nezískate najnovší softvér do telefónu.
Prvým krokom v živote aktualizácie firmvéru systému Android je upstream aktualizácia. Google na tom interne pracuje. Na rozdiel od „otvorených pracovných postupov“ sa Android vyvíja pomocou uzavretého pracovného toku, pričom zdrojový kód sa vyhodí cez stenu približne každý rok, keď vyjde nové vydanie. Pôvodne Google povedal, že to má zabrániť fragmentácii od ľudí, ktorí používajú najbežnejšie verzie zatiaľ čo v prvých dňoch sa veci rýchlo vyvíjali, ale zdá sa, že túto politiku udržali miesto.
V určitom okamihu, zvyčajne pred verejným oznámením aktualizácie (hoci s nedávnym zavedením verejných beta verzií sa tieto časové rámce posúvajú), OEM budú informovaní o pripravovanej aktualizácii. Potom dostanú zdrojový kód v druhom okamihu pre konečnú aktualizáciu (v minulosti to bolo niekedy s malým predstihom pred uvedením na trh, aj keď vieme aj o prípadoch, keď nie je možné predčasne uvoľnenie).
Upstream archívy AOSP obsahujú podporu zariadení len pre obmedzený počet zariadení. Zvyčajne ide o vaše zariadenia Nexus. Z dôvodov, ktoré budú čoskoro jasné, je dôležité poznamenať, že Google nemá úplnú hardvérovú kontrolu nad týmito zariadeniami. zariadenia vyrába OEM a tento OEM kúpi System-on-Chip (SoC) od výrobcu čipovej sady.
Po vydaní zdrojového kódu sa tím firmvéru OEM (obrazne) posadí a dá nohy hore. Hlavný zdrojový strom Androidu nemá hardvérovú podporu pre nespočetné množstvo čipsetov používaných v prepravných zariadeniach. Váš čipset Qualcomm s najväčšou pravdepodobnosťou napríklad nie je podporovaný v rámci AOSP. Váš Exynos určite nie je. Mediatek alebo HiSilicon? Zabudni na to!
BSP obsahuje ovládače a vrstvy hardvérovej abstrakcie (HAL), ktoré sú potrebné na spustenie systému Android
Čo je teraz potrebné, je a Balík podpory dosky (BSP). Toto je super-dôverný balík proprietárnych komponentov, ktorý výrobca čipovej sady dodáva výrobcovi OEM. BSP obsahuje potrebný zdrojový kód, ktorý umožňuje výrobcom OEM zostavovať Android a potrebné ovládače pre ich zariadenie.
Tu stojí za zmienku, že výrobcovia OEM ako Qualcomm nemusia nevyhnutne plne dôverovať svojim partnerom OEM – BSP je k dispozícii na základe „potreby vedieť“. Výrobcovia OEM zvyčajne nezískajú prístup k zdrojovému kódu niektorých supertajných častí zariadenia (napríklad softvéru bežiaceho v základnom pásme). Uzavretie tejto časti má určite tiež potenciálne problémy, ako ukazuje blízkosť hojný a opakujúce sa ASN.1 analyzovať zraniteľnosti.
BSP obsahuje ovládače a vrstvy hardvérovej abstrakcie (HAL), ktoré sú potrebné na spustenie systému Android na vašom zariadení. AOSP obsahuje sadu HAL, ktoré fungujú ako definície toho, čo operačný systém očakáva od vašich ovládačov. Aby sme použili smiešne príliš zjednodušený (a na účely demonštrácie vymyslený) príklad, predstavme si baterku na vašom telefóne.
Príklad HAL - Vaša baterka
Predstavme si, že vaše zariadenie má na zadnej strane baterku (ak máte Nexus 7 2013, budete musieť urobiť trochu viac predstavivosti ako všetci ostatní – prepáčte!). Toto je riadené vodičom. Pre náš šialene jednoduchý príklad predpokladajme, že v1 HAL hovorí, že by ste mali mať jednu funkciu s názvom „setLED“, ktorá preberá jediný parameter, stav svetla. Je to boolovská hodnota - pravda alebo nepravda. V C by to vyzeralo asi takto:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Táto funkcia je definovaná v zdrojovom kóde BSP. BSP je potom skompilovaný OEM počas vytvárania ROM, a to sa stane jednou z proprietárnych ".so" knižníc v oddiele dodávateľa alebo oblasti vášho zariadenia. To umožňuje výrobcovi OEM udržiavať určité časti fungovania svojho zariadenia v tajnosti. Zatiaľ predpokladajme, že chcú každému zabrániť, aby videl, ako zapína a vypína túto LED.
Teraz si predstavte, že Google vydá aktualizovanú verziu svojich HAL v budúcej verzii Androidu. Teraz sa rozhodnú, že by bolo pekné, keby ste vám umožnili aktualizovať jas vašej LED, namiesto toho, aby ste ju len zapínali alebo vypínali. Možno je to kvôli adaptívnemu flashu, alebo možno len preto, aby si vynútil aktualizáciu HAL a udržal výrobcov čipsetov v podnikaní? Necháme vás, čitateľov, aby ste si na to urobili vlastný názor. Niektoré aktualizácie HAL majú jasný prínos (napríklad nový Camera HAL odhaľujúci nespracované snímanie a podobne), zatiaľ čo iné majú o niečo menej jasný účel.
S týmto novým (fiktívnym) HAL pre jas predpokladajme, že Google hovorí, že musíte znova vystaviť funkciu s názvom setLED, ale tentoraz s celým číslom odovzdaným pre jas. Teraz ho 0 vypne a 255 ho zapne naplno.
Ak ste OEM, môžete použiť svoj supertajný kód na zapnutie tejto LED a vložiť ho do tejto novej funkcie. Môžete dokonca použiť moduláciu šírky impulzu na nastavenie jasu LED na základe čísla. Teraz zmeníte funkciu, aby vyzerala takto:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
No a čo? Teraz je táto nová verzia Androidu nekompatibilná s existujúcimi „blobmi“. Váš OEM musí použiť tieto nové bloby, pretože operačný systém Android očakáva, že uvidí novú definíciu funkcie a „nenájde“ tú starú, keď bude hľadať spôsob, ako nastaviť LED.
V tomto bode si dáme krátku prestávku, aby sme sa pozreli na to, ako sa tu spravujú Custom ROM (zostavené zo zdroja). To je to, čo bystrí medzi vami budú práve teraz kričať na vašu obrazovku – veď sme XDA, domov HTC HD2, telefón s najdlhšou výdržou na svete... (len pre záznam, blázniví géniovia tam bežia Android 6.0 na HD2 v týchto dňoch! Nie je to zlé pre telefón pôvodne dodaný s Windows Mobile 6.5 v roku 2009)
Používajú sa tu rôzne prístupy – niekedy sa vývojári nabúrajú do ROM a povedia OS, aby použil staré definície funkcií. Je to trochu chaotické a robí to veľa zmien, ktoré je potrebné udržiavať. Druhým prístupom je „shim“ binárny kód OEM.
Prístup „shim“ spočíva v tom, že si sami napíšete a vytvoríte malú novú knižnicu, ktorá obsahuje očakávanú definíciu funkcie – pre náš príklad by sme podporili celé číslo pre jas. Potom sa to v rámci podložky preloží tak, aby spĺňalo požiadavky starého HAL. Takže pre náš príklad by sme možno povedali, že akýkoľvek požadovaný jas nad 128 zapne LED a čokoľvek nižšie, čo ho vypne. Alebo môžete povedať čokoľvek, čo nie je nula, zapne ho. Je to na vývojárovi. Zostavia shim a prinútia Android, aby ho používal namiesto pôvodného. Podložka potom zavolá OEM blob.
Rýchly `adb push` a reštart by mal spustiť podložku a umožniť vám ovládať vašu fiktívnu LED, aj keď máte len starý HAL.
Problém je, že ide jednoznačne o nedokonalý proces. Teraz budete mať vtipy - toto zariadenie bude mať dosť mizerný blesk, ktorý je buď úplne zapnutý, alebo úplne vypnutý. To nie je ideálne – operačný systém si myslí, že vydáva veľmi jemné svetlo, ale skutočnej LED sa hovorí, že súťaží v súťaži umelého slnka a snaží sa vás oslepiť. Ale hej, život nie je dokonalý a teraz máte na svojom starom telefóne fungujúcu LED!
(Áno, to je jeden z dôvodov, prečo existujú zvláštnosti a chyby, keď používatelia a vývojári XDA spravujú svoje šialené a šialené výkony v oblasti portovania. Myslím sakra, ten Galaxy S II je nosenie zdanlivo použiteľné Android 6.0 ROM teraz. Veľa telefónov vydaných minulý rok stále nemá 6.0!)
Vráťme sa k pohľadu OEM. Je smutné, že väčšina OEM už pracuje aspoň o 1 telefón pred tým, kde sme práve teraz. Zameriavajú sa na ďalší telefón, ktorý sa chystajú predať – nemôžete im to veľmi vyčítať, keďže zarábajú iba na zariadeniach, ktoré predávajú. Nezarábajú žiadne peniaze zo zariadení, ktoré predali pred rokom alebo dvoma, takže musia neustále vydávať nové zariadenia, aby existovali. To je jeden z dôvodov, prečo sú HTC a Blackberry v problémoch – nezáleží na tom, koľko manažérov si zachovalo smrteľnú priľnavosť na svojom starom Blackberry Curve, keďže tam nedostávajú predaj nových zariadení.
Ak výrobca OEM nezíska BSP, nezvolí prístup XDA spočívajúci v hackovaní zostavy. prečo? no, musia podporovať tento firmvér pre svojich zákazníkov. Ak vydajú firmvér, ktorý je napoly funkčný, používatelia ich budú nenávidieť, budú sa rozhorčovať, pričom ich linky podpory budú vyzváňať celé dni.
OEM musia tiež zápasiť s dopravcami, aspoň na mimoeurópskych trhoch. Dopravcovia nechcú, aby mali zákazníci problémy s aktualizáciami softvéru. V skutočnosti by operátori často radšej nevydávali aktualizácie softvéru.
Aby ste to pochopili, predstavte si svoju pratetu Alicu. Je to ona, ktorá vám v nevhodnú dennú dobu zavolá a požiada o pomoc s „tým počítačom“. Potom opíšete, ako kliknúť na „ponuku Štart“ a musíte ju identifikovať ako „veľkú vlajku v ľavom dolnom rohu“ a narazíte na zmätok. Asi o 45 minút (a veľa frustrácie) neskôr sa ukáže, že teta Alice presunula svoju ponuku Štart na pravý okraj obrazovky a jednoducho ju potrebovala potiahnuť späť. Áno, ľavým tlačidlom myši!
Teraz si predstavte, že máte tisícku tety Alice. Všetci volajú na vašu zákaznícku podporu, nevedia nájsť Candy Crush na svojom telefóne, obávajú sa, že ju z telefónu vymazal hacker. Och, a ikony teraz vyzerajú trochu inak - možno je hacker stále v ich telefóne?
Áno, toto má byť trochu odľahčený humor, ale kým nezažijete dôvody, prečo ľudia volajú svojho operátora o podporu, neuveríte, aké problémy majú. Aktualizácia softvéru, ktorá zmení spôsob, akým telefón funguje alebo kde sa veci nachádzajú, spôsobí značné náklady na podporu. Minimálne to vyžaduje preškolenie podporného personálu (pretože väčšina z nich nie je váš vášnivý XDA čitateľ, bohužiaľ).
Keď OEM získa BSP, prenesie svoju ROM a aplikujú všetky svoje zmeny na ROM. Nahromadia svoj bloatware a pridajú strašný kreslený vzhľad, ktorý by vyzeral viac doma v anime pre tínedžerov. Potom to otestujú.
Veľa.
Existujú všetky druhy požiadaviek, ktoré musí váš telefón spĺňať. Mobilné siete sú navrhnuté tak, aby dôverovali používateľskému zariadeniu (čomu hovoríme telefón), že sa správa správne. To znamená, že na schválenie zariadenia je potrebných veľa testov. Aktualizácie softvéru riskujú zmenu správania, takže veci treba znova otestovať. To je dôvod, prečo bežne uvidíte informácie o pripravovaných aktualizáciách softvéru Sony od externých testovacích služieb, ktoré potvrdzujú, že firmvér je v súlade s testovacími požiadavkami.
Teraz... čo sa stane po aktualizácii alebo dvoch (alebo v niektorých prípadoch žiadnej)? Výrobca SoC neposkytne OEM aktualizované BSP. Koniec koncov, výrobca SoC z toho veľa nedostane. Výrobca OEM na vašom telefóne od jeho predaja nezarába žiadne ďalšie peniaze. A v tomto bode váš telefón nedostáva žiadne ďalšie hlavné aktualizácie verzií.
Zníženie počtu BSP, ktoré chce OEM dodať, je skvelý spôsob, ako ušetriť peniaze – ak potrebujete iba aktuálnu a neplánujete dodávať žiadnu hlavnú verziu. zvyšuje, ušetrí to peniaze na počiatočný nákup SoC a licencovanie, ale na úkor niekoľkých nahnevaných nerdov na XDA, ktorí sa čudujú, prečo nedostali aktualizovať.
Aktualizácie sú zložité. V reťazci je zapojených veľa rôznych ľudí. Nič z toho neospravedlňuje výrobcov pôvodných zariadení zo súčasného chabého a žalostného stavu aktualizácií pre Android. Napriek tomu je tu niekoľko skutočných výziev.
Mnohí OEM sú vinní za prílišné sľuby a nevyhnutné nedostatočné poskytovanie, ktoré teraz spájame. Smutnou realitou je, že pre väčšinu OEM sú aktualizácie softvéru len nepríjemnosťou, bez ktorej by sa zaobišli.
Mobilný sektor je väčšinou uviaznutý v myslení bežných telefónov. To znamená, že zariadenie nikdy nedostane žiadne aktualizácie. Raz to otestujte, odošlite a nikdy sa nepozerajte späť. S bezpečnostnými problémami moderných smartfónov a úplnou zložitosťou spustenia plne univerzálneho operačného systému so stovkami externých knižníc to už nie je možné. Alebo aspoň to nemal by byť. Spoločnosť Google urobila niekoľko krokov na vyriešenie tohto problému, a to aspoň zverejnením bezpečnostných bulletinov a opráv pre existujúce vydania systému Android (pamätajte, že až donedávna bol jediný spôsob, ako získať aktualizácie zabezpečenia, prostredníctvom novej hlavnej verzie operačného systému Android!)
Bohužiaľ, toto však naozaj nestačí. Aj keď Google neustále vydáva aktualizácie, bezpečnosť vášho zariadenia stále závisí od výrobcu SoC – keďže výrobcovia SoC sú tak skamenení Keď niekto objaví, ako rozsvieti niekoľko LED diód alebo vydajú zvuk cez reproduktor, odošle obrovské množstvo binárnych kvapôčok zariadení. Tieto guľôčky obsahujú dosť strašne nezabezpečený kód (ak si myslíte, že je to prehnané, pozrite si predchádzajúce bezpečnostné bulletiny Google!) a je potrebné ich aktualizovať. To znamená, že sú potrebné aktualizované BSP.
Stolové počítače (a v širšom zmysle aj notebooky) sú architektúrou úplne odlišné od mobilných zariadení. Váš mobilný telefón alebo tablet je v skutočnosti silne proprietárna hrudka kremíka, ktorú v zhone navrhli niektorí ľudia, ktorí to myslia dobre, no ani zďaleka nemajú dostatok času na výrobu niečoho dobrého. Trh sa pohybuje tak rýchlo, že sotva dokážu držať krok s tempom, ktorým marketing vyžaduje uvedenie nových produktov na trh.
To znamená, že sa používajú skratky – nenájdete váš telefón podporovaný hlavným jadrom Linuxu a zistíte, že každý telefón má iný spôsob spustenia. Na vašom notebooku alebo desktope sa však predajcovia usadili na niektorých štandardných spôsoboch bootovania – predtým to bol MBR (master boot record) s BIOSom a teraz je to UEFI. Táto štandardizácia umožňuje spúšťať rovnaký softvér na každom zariadení.
Aj keď v poslednej dobe došlo k určitým krokom smerom k tomuto, najmä s programom Sony pre dosah a ich jednotné jadro, nie je praktické spúšťať jadro hlavnej línie na väčšine telefónov, kvôli obrovskému množstvu nových hackov špecifických pre výrobcu zavedených do každého zariadenia.
Zapojili ste konektor slúchadiel nesprávnym smerom? Len to hacknite v ovládačoch! Nie je čas to opravovať v produkčnom dizajne.
Výrobný tím namontoval modul kamery hore nohami vo výrobnej dávke 1? Vhoďte hack, aby ste skontrolovali interný kód verzie a otočte video, ak ide o verziu 1!
Hacky ako tieto riešia bezprostredný problém, ale iba zoškrabú povrch podivných a pre produkt špecifických zmien, ktoré prebiehajú. Sakra, niekedy sú dokonca úplne odlišné čipy v rôznych revíziách toho istého telefónu kvôli komerčným rozhodnutiam. Tie vedú k hackovaniu ovládačov a podivným rozhodnutiam, ktoré mali zmysel len v tom čase, aby telefón fungoval, aby mohol byť odoslaný budúci týždeň.
Zatiaľ čo prebiehajú práce na podpore hlavnej línie pre 64-bitové čipy ARM na zavádzanie pomocou UEFI, zatiaľ žiadny jasný posun smerom k štandardizovanejšiemu spôsobu spúšťania zariadení ARM. A to je smutné, pretože to znamená, že telefóny sa budú aj naďalej vyhadzovať dlho pred koncom ich životnosti pracovný život, pretože je jednoducho príliš drahé udržiavať ich technický dlh a záťaž softvér.
Na druhej strane, ak OEM bude zarábať iba na predaji zariadenia, nemusí zabezpečiť, aby ľudia naďalej kupovali nové telefóny? Presunul by sa trh s počítačmi na tento model, keby neexistovalo 30 rokov dynamiky a starší softvér využívajúci otvorenú platformu a štandard PC?
Toto je ťažká otázka bez vnútorných znalostí od Qualcommu, ktoré bohužiaľ momentálne nemáme. Niektoré informácie však môžeme čerpať z API ovládača pre Android 7.0 a požiadaviek CTS. Požiadavky CTS špecifikujú, čo Google očakáva od zariadenia s daným firmvérom. „Veľkým kladivom“ používaným na presadzovanie týchto požiadaviek je licencovanie spoločnosti Google na používanie ich vlastného balíka služieb Google Play – ak ich nedodržíte, nebudete môcť do zariadenia dodávať Google Apps. Zatiaľ čo pre niektorých toto možno považovať za výhodu, to zjavne nie je to, čo používatelia od zariadenia chcú a očakávajú.
Android 7.0 nepridal veľa zmien v HAL alebo ovládačoch (ako je popísané vyššie), takže je nepravdepodobné, že by odtiaľ konkrétne pochádzala akákoľvek nekompatibilita. Čo je však pravdepodobnejšie problémom, je zavedenie a nová požiadavka na grafické rozhranie API Vulkan alebo GLES 3.1, byť k dispozícii, aby ste mohli prejsť CTS.
V súčasnosti veľa systémov na čipe (SoC) nemá na svojom grafickom procesore podporu Vulkan, vrátane MSM8974. Tu sa tiež s najväčšou pravdepodobnosťou objaví problém kompatibility s Androidom 7.0. Opäť však platí, že bez vnútorných znalostí spoločnosti Qualcomm a ich plánov do budúcnosti je pre nás ťažké poskytnúť definitívne vyhlásenie bez toho, aby sme to kvalifikovali. V súčasnosti sa však domnievame, že je pravdepodobné, že ide o „jednoduchý“ prípad ukončenia podpory spoločnosti Qualcomm (v ich očiach) starnúci čipset MSM8974 a neposkytnutie BSP (balíček podpory dosky) pre 7.0 na tejto platforme. Ak by to tak bolo, znamenalo by to, že výrobcovia OEM by takmer určite nedodali 7.0 na zariadení – museli by nejakým spôsobom nájsť podporu Vulkan alebo GLE 3.1 pre svoj GPU a zdroj GPU kód je jedna zo smiešne prísne strážených častí mobilných zásobníkov (bez skutočného dôvodu by sme pridali - pozri AMD, otvorené získavanie vlastného ovládača AMDGPU na ploche pre Linux). Je však smutné, že grafika Vulkan a akcelerovaná (GLES) grafika vo všeobecnosti sú o niečo zložitejšie ako obyčajná LED, takže to nie je niečo, čo by sme zaviedli kompatibilitu.
Keďže 7.0 nie je vonku dlho, existuje reálna možnosť, že iné čipsety (okrem malého počtu v samotnom AOSP) odídu za 6.0 kvôli problémom s hardvérom a ovládačom (t. j. bez aktualizovaného BSP) alebo nedostatočnou podporou dodávateľa SoC s ohľadom na Vulkan alebo GLES 3.1 API. V súčasnosti ani Snapdragon 800 alebo 801 nepodporuje jeden z nich.
Najlepšie je sledovať tento priestor - Vývojári na XDA už robia dobrý pokrok s neoficiálnymi portami na 7.0 pre mnohé zariadenia, ktoré od spoločnosti Google nedostávajú oficiálnu podporu 7.0. Tieto sú však bez podpory Vulkan alebo GLES 3.1 - možno vývojári hier pre Android začnú zažijete frustráciu z fragmentácie, ak dostatočný počet používateľov spustí vlastné ROM bez Vulkan alebo GLES 3.1 podpora?
Apple má tendenciu podporovať svoju líniu iPhone na najnovšej verzii iOS približne 5 rokov - iPhone 4s bol uvedený na trh v októbri 2011 a bol neustále aktualizovaný až do iOS 9. Nedostane však nadchádzajúcu aktualizáciu iOS 10, ktorá by telefónu poskytla efektívnu životnosť 5 rokov za predpokladu, že iOS 10 bude spustený okolo októbra. Stojí za zmienku, že Apple nie vždy podporuje grafické rozhranie API – iPhone 4s a iPhone 5 nie obsahujú grafické rozhranie Apple Metal Graphics API, čo je trochu podobný scenár ako v systéme Android Vulkan. Jediný rozdiel je v tom, že Apple naďalej podporoval staršie zariadenia bez nového grafického API.
Co si myslis? Budete flashovať vlastnú ROM v telefóne, aby ste predĺžili jeho životnosť? Vyjadrite sa v komentároch nižšie.