V tem članku raziskujemo resnico o tem, zakaj naprave Snapdragon 801 ne dobijo Android Nougat. Težav je veliko, od izdelovalcev naborov čipov do prodajalcev!
Posodobljeno tako, da odraža zahtevo ali-ali Vulkan ali OpenGL ES 3.1 za Android 7.0
V zadnjem času je bilo napisanih veliko člankov o posodobitvah različic, interakcijah med prodajalcem in izdelovalcem nabora čipov ter o tem, kaj to pomeni za naprave v prihodnosti. Zakaj se je ta teden povečalo?
No, ta teden se je izkazalo, da častitljivi Nexus 5 ne bo prejel posodobitve na Android 7.0 (Nougat), in Qualcomm je napovedal, da je ne bo zagotavlja podporo za MSM8974 (bolj znan kot Snapdragon 801) na 7.0. Ta članek je bil napisan v sodelovanju z XDA Recognized Razvijalec čmrlj.
Tema je pritegnila precej zanimanja na različnih spletnih mestih z novicami, vendar mnogi spregledajo subtilne nianse tega, kar se v resnici dogaja v ozadjus. Ta članek bo razložil nekaj več o delovanju posodobitev programske opreme z uporabo naših izkušenj pri delu z proizvajalci originalne opreme pri njihovih uradnih posodobitvah vdelane programske opreme. Povedali vam bomo, kaj se dogaja v zakulisju (in zakaj) in zakaj na koncu morda ne boste prejeli najnovejše programske opreme v telefonu.
Prvi korak v življenju posodobitve vdelane programske opreme Android je posodobitev navzgor. To je tisto, na čemer Google deluje interno. V nasprotju z "odprtimi delovnimi tokovi" je Android razvit z uporabo zaprtega delovnega toka, pri čemer se izvorna koda vsako leto vrže čez zid, ko pride nova izdaja. Prvotno je Google dejal, da je to preprečilo razdrobljenost zaradi ljudi, ki uporabljajo najnovejše različice medtem ko so se stvari v zgodnjih dneh hitro razvijale, vendar se zdi, da so ohranili to politiko mesto.
V nekem trenutku, običajno pred javno objavo posodobitve (čeprav se z nedavno uvedbo javnih različic beta ti časovni okviri premikajo), Proizvajalci originalne opreme bodo obveščeni o prihajajoči posodobitvi. Nato bodo prejeli izvorno kodo drugič za končno posodobitev (v preteklosti je bilo včasih malo pred lansiranjem, čeprav poznamo tudi primere, ko ni zgodnjega sprostitev).
Repozitoriji AOSP navzgor vsebujejo podporo za naprave samo za omejeno število naprav. To so običajno vaše naprave Nexus. Zaradi razlogov, ki bodo kmalu jasni, je pomembno omeniti, da Google nima popolnega nadzora strojne opreme nad temi napravami; naprave izdeluje proizvajalec originalne opreme in ta bo kupil sistem na čipu (SoC) od proizvajalca nabora čipov.
Ko bo izvorna koda izdana, se bo ekipa proizvajalca vdelane programske opreme (figurativno) usedla in postavila noge pokonci. Glavno izvorno drevo Android nima podpore za strojno opremo za nešteto naborov čipov, ki se uporabljajo v napravah za pošiljanje. Vaš nabor čipov Qualcomm na primer najverjetneje ni podprt v AOSP. Vaš Exynos zagotovo ni. Mediatek ali HiSilicon? Pozabi!
BSP vsebuje gonilnike in plasti abstrakcije strojne opreme (HAL), potrebne za delovanje Androida
Kar je zdaj potrebno, je a Paket podpore za plošče (BSP). To je zelo zaupen paket lastniških komponent, ki ga proizvajalec nabora čipov dostavi proizvajalcu originalne opreme. BSP vsebuje potrebno izvorno kodo, ki proizvajalcem originalne opreme omogoča izdelavo Androida in potrebnih gonilnikov za njihovo napravo.
Tu je vredno omeniti, da proizvajalci originalne opreme, kot je Qualcomm, ne zaupajo nujno popolnoma svojim partnerjem proizvajalcem originalne opreme – BSP je na voljo na podlagi "potrebe vedeti". Proizvajalci originalne opreme običajno nimajo dostopa do izvorne kode za nekatere superskrivne dele naprave (kot je programska oprema, ki deluje na osnovnem pasu). Zaprtje tega dela zagotovo povzroča tudi morebitne težave, kot je razvidno iz bližnjega obilno in ponavljajoče se ASN.1 razčlenjevanje ranljivosti.
BSP vsebuje gonilnike in plasti abstrakcije strojne opreme (HAL), ki so potrebni za delovanje sistema Android v vaši napravi. AOSP vsebuje nabor HAL-jev, ki delujejo kot definicije glede tega, kaj operacijski sistem pričakuje od vaših gonilnikov. Če uporabimo smešno preveč poenostavljen (in izmišljen za namene predstavitve) primer, si predstavljajmo svetilko na vašem telefonu.
Primer HAL - Vaša svetilka
Predstavljajmo si, da ima vaša naprava na hrbtni strani svetilko (če imate Nexus 7 2013, si boste morali malo bolj predstavljati kot vsi drugi – oprosti!). To nadzira voznik. Za naš noro preprost primer, predpostavimo, da v1 HAL pravi, da bi morali imeti eno funkcijo, imenovano "setLED", ki prevzame en sam parameter, stanje svetlobe. To je logična vrednost – resnična ali napačna. V C bi to izgledalo nekako takole:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Ta funkcija je definirana v izvorni kodi BSP. BSP nato prevede proizvajalec originalne opreme med gradnjo ROM-a in ta postane ena od lastniških knjižnic ".so" na particiji prodajalca ali območju vaše naprave. To proizvajalcem originalne opreme omogoča, da obdržijo nekatere dele delovanja svoje naprave v tajnosti. Zaenkrat predpostavimo, da želijo preprečiti, da bi vsi videli, kako prižigajo in izklapljajo LED.
Zdaj pa si predstavljajte, da Google izda posodobljeno različico svojih HAL v prihodnji različici Androida. Zdaj so se odločili, da bi bilo lepo, če bi vam omogočili posodobitev svetlosti LED, namesto da bi jo samo vklopili ali izklopili. Mogoče je to za prilagodljivo bliskavico ali pa samo za prisilno posodobitev HAL in ohranjanje izdelovalcev čipov v poslu? Dovolili vam bomo, da si o tem, bralec, ustvarite svoje mnenje. Nekatere posodobitve HAL imajo jasne prednosti (na primer nova kamera HAL, ki razkrije neobdelano fotografiranje in podobno), medtem ko so drugi glede namena nekoliko manj jasni.
S tem novim (izmišljenim) HAL za svetlost, recimo, da Google pravi, da morate znova izpostaviti funkcijo, imenovano setLED, vendar tokrat s celim številom, posredovanim za svetlost. Zdaj bi ga 0 izklopil, 255 pa bi ga dal na polno.
Če ste OEM, lahko vzamete svojo superskrivno kodo, da vklopite to LED, in jo vstavite v to novo funkcijo. Lahko celo uporabite pulzno-širinsko modulacijo, da prilagodite svetlost LED na podlagi števila. Funkcijo spremenite tako, da bo zdaj prikazana takole:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Pa kaj? No, zdaj ta nova različica Androida ni združljiva z obstoječimi "blobi". Vaš OEM mora uporabiti te nove madeže, ker OS Android pričakuje, da bo videl novo definicijo funkcije, in ne bo "našel" stare, ko bo iskal način za nastavitev LED.
Na tej točki si vzemimo kratek premor, da si ogledamo, kako tukaj delujejo ROM-i po meri (zgrajeni iz vira). To je tisto, kar bodo prebrisani med vami zdaj kričali na vaš zaslon - navsezadnje smo XDA, dom HTC HD2, najdlje vzdržljiv telefon na svetu... (samo za zapisnik, nori geniji tam bežijo Android 6.0 na HD2 v teh dneh! Ni slabo za telefon, ki je bil prvotno dobavljen z operacijskim sistemom Windows Mobile 6.5 leta 2009)
Tu so uporabljeni različni pristopi - včasih razvijalci vdirajo znotraj ROM-a in naročijo operacijskemu sistemu, naj uporabi stare definicije funkcij. To je nekoliko neurejeno in zahteva veliko sprememb, ki jih je treba vzdrževati. Drugi pristop je "šimiranje" binarne datoteke OEM.
Pristop "shim" je, da sami napišete in zgradite majhno novo knjižnico, ki vsebuje pričakovano definicijo funkcije - v našem primeru bi podprli celo število za svetlost. Nato se znotraj podložke to prevede v skladu z zahtevami starega HAL. Za naš primer bi morda rekli, da bo katera koli zahtevana svetlost nad 128 vklopila LED, vse, kar je nižje, pa jo bo izklopilo. Ali pa bi lahko rekli, da ga bo vklopilo karkoli, kar ni nič. To je odvisno od razvijalca. Prevedejo shim in pripravijo Android, da ga uporablja namesto izvornega. Podložka nato pokliče OEM blob.
Hiter `adb push` in ponovni zagon bi morala zagnati shim in vam omogočiti nadzor nad vašo izmišljeno LED, čeprav imate samo stari HAL.
Težava je v tem, da je to očitno nepopoln postopek. Zdaj boste dobili posebnosti - ta naprava bo imela precej klavrno bliskavico, ki bo popolnoma vklopljena ali popolnoma izklopljena. To ni idealno – operacijski sistem misli, da oddaja zelo nežno svetlobo, dejanski LED pa je rečeno, da tekmuje v tekmovanju umetnega sonca in vas poskuša zaslepiti. Ampak hej, življenje ni popolno in zdaj imate delujočo LED na svojem starem telefonu!
(Da, to je eden od razlogov, zakaj obstajajo čudnosti in napake, ko uporabniki in razvijalci XDA upravljajo s svojimi norimi in norimi podvigi spretnosti pri prenašanju. Mislim hudiča, Galaxy S II je navidezno uporaben Android 6.0 ROM zdaj. Veliko telefonov, izdanih lani, še vedno nima 6.0!)
Vrnimo se k perspektivi OEM. Na žalost večina proizvajalcev originalne opreme že dela vsaj en telefon pred tem, kjer smo trenutno. Njihov poudarek je na naslednjem telefonu, ki ga nameravajo prodati – ne morete jim zameriti, saj služijo samo z napravami, ki jih prodajajo. Z napravami, ki so jih prodali pred letom ali dvema, ne zaslužijo denarja, zato morajo za obstoj izdajati nove naprave. To je eden od razlogov, zakaj sta HTC in Blackberry v težavah - ni pomembno, koliko vodilnih delavcev še vedno drži svoj stari Blackberry Curve, saj tam ne prodajajo novih naprav.
Če proizvajalec originalne opreme ne dobi BSP, se ne bo odločil za pristop XDA in skupaj vdrl v gradnjo. Zakaj? no, morajo podpirati to firmware za svoje stranke. Če izdajo vdelano programsko opremo, ki napol deluje, jih bodo uporabniki sovražili, tarnali in tarnali, njihove linije za podporo pa bodo zvonile še dneve.
Proizvajalci originalne opreme se morajo boriti tudi s prevozniki, vsaj na neevropskih trgih. Prevozniki ne želijo, da imajo stranke težave s posodobitvami programske opreme. Pravzaprav operaterji pogosto raje ne bi izdali posodobitev programske opreme.
Da bi to razumeli, si predstavljajte svojo staro teto Alice. Ona je tista, ki te pokliče ob neprimernih urah dneva in prosi za pomoč pri "tisti računalniški stvari". Nato opišete, kako kliknete »meni Start« in ga morate prepoznati kot »veliko zastavo v spodnjem levem kotu«, pri čemer naletite na zmedo. Približno 45 minut (in veliko razočaranja) pozneje se izkaže, da je teta Alice svoj začetni meni potegnila na desni rob zaslona in ga je preprosto morala povleči nazaj. Da, z levim gumbom miške!
Zdaj pa si predstavljajte, da imate tisoč teto Alice'. Vsi kličejo vašo podporo strankam, ne morejo najti Candy Crush v svojem telefonu in so zaskrbljeni, da jo je heker izbrisal iz njihovega telefona. Oh, ikone so zdaj videti nekoliko drugače – morda je heker še vedno v njihovem telefonu?
Da, to je mišljeno kot lahkoten humor, a dokler ne izkusite razlogov, zaradi katerih bodo ljudje poklicali svojega operaterja za podporo, ne boste verjeli, kakšne težave imajo. Posodobitev programske opreme, ki spremeni delovanje telefona ali kje so stvari, bo povzročila precejšnje stroške podpore. Zahteva najmanj ponovno usposabljanje podpornega osebja (ker večina od njih žal ni vaš navdušeni bralec XDA).
Ko proizvajalec originalne opreme dobi BSP, bo prenesel svoj ROM in uporabil vse svoje spremembe v ROM-u. Nabrali bodo svoje napihnjene programe in dodali grozljivo preobleko, ki spominja na risanke, ki bi bila bolj domača v najstniških animejih. Potem ga bodo preizkusili.
Veliko.
Vaš telefon mora izpolnjevati vse vrste zahtev. Mobilna omrežja so zasnovana tako, da zaupajo uporabniški opremi (temu pravimo telefon), da se pravilno obnaša. To pomeni, da je za odobritev naprave potrebnih veliko testiranj. Posodobitve programske opreme lahko spremenijo vedenje, zato je treba stvari znova preizkusiti. Zato boste pogosto videli informacije o prihajajočih posodobitvah programske opreme Sony od zunanjih preskusnih storitev, ki potrjujejo, da je vdelana programska oprema skladna s preskusnimi zahtevami.
zdaj... kaj se zgodi po posodobitvi ali dveh (ali v nekaterih primerih nič)? Proizvajalec SoC proizvajalcu originalne opreme ne bo dal posodobljenega BSP. Navsezadnje izdelovalec SoC od tega ne bo imel veliko. Proizvajalec originalne opreme ne zasluži več denarja z vašim telefonom, odkar je bil prodan. In na tej točki vaš telefon ne prejema več večjih posodobitev različice.
Zmanjšanje števila BSP-jev, ki jih OEM želi dostaviti, je odličen način za prihranek denarja – če potrebujete samo trenutnega in ne nameravate dostaviti nobene večje različice poveča, bo to prihranilo denar pri začetnem nakupu in licenciranju SoC, a na račun nekaj jeznih piflarjev na XDA v nadaljevanju, ki se sprašujejo, zakaj niso dobili nadgradnja.
Posodobitve so zapletene. V verigi je vpletenih veliko različnih ljudi. Nič od tega ne opravičuje proizvajalcev originalne opreme pred trenutnim pomanjkljivim in patetičnim stanjem posodobitev za Android. Kljub temu je tukaj nekaj resničnih izzivov.
Mnogi proizvajalci originalne opreme so krivi za preveč obetavne in neizogibno premajhno zagotavljanje, ki ga zdaj povezujemo. Žalostna resničnost je, da so za večino proizvajalcev originalne opreme posodobitve programske opreme le nadloga, brez katere bi lahko storili.
Mobilni sektor je večinoma obtičal v miselnosti funkcijskih telefonov. To pomeni, da naprava nikoli ne dobi nobenih posodobitev. Preizkusite enkrat, pošljite in se nikoli več ne ozirajte nazaj. Z varnostnimi težavami sodobnih pametnih telefonov in izjemno zapletenostjo izvajanja celotnega splošnega operacijskega sistema s stotinami zunanjih knjižnic to ni več možnost. Ali vsaj to ne bi smel biti. Google je naredil nekaj korakov, da bi to popravil, z objavo vsaj varnostnih biltenov in popravkov za obstoječe izdaje Androida (ne pozabite, da je bil do nedavnega edini način za pridobitev varnostnih posodobitev prek nove glavne različice OS Android!)
Žal pa to v resnici ni dovolj. Čeprav Google nenehno objavlja posodobitve, je varnost vaše naprave še vedno odvisna od izdelovalca SoC – saj so izdelovalci SoC tako okameneli nad nekdo, ki odkrije, kako prižge nekaj LED diod ali oddaja zvok skozi zvočnik, pošlje ogromne količine binarnih madežev na naprave. Ti madeži vsebujejo nekaj precej grozljivo nevarne kode (samo poglejte pretekle Googlove varnostne biltene, če menite, da je to pretiravanje!) in jih je treba posodobiti. Kar pomeni, da so potrebni posodobljeni BSP.
Namizni računalniki (in posledično prenosniki) so po arhitekturi popolnoma drugačni od mobilnih naprav. Vaš mobilni telefon ali tablični računalnik je v bistvu močno lastniška kos silicija, ki so ga v naglici oblikovali nekateri ljudje, ki mislijo dobro, vendar nimajo niti približno dovolj časa, da bi naredili nekaj dobrega. Trg se premika tako hitro, da komaj sledijo tempu, s katerim trženje zahteva lansiranje novih izdelkov.
To pomeni, da so uporabljene bližnjice - vašega telefona ne boste podpirali z glavnim jedrom Linuxa in ugotovili boste, da ima vsak telefon drugačen način zagona. Na prenosnem ali namiznem računalniku pa so se prodajalci odločili za nekatere standardne načine zagona - prej je bil to MBR (glavni zagonski zapis) z BIOS-om, zdaj pa UEFI. Ta standardizacija omogoča izvajanje iste programske opreme na vsaki napravi.
Čeprav je bilo v zadnjem času narejenih nekaj korakov v smeri tega, zlasti s Sonyjevim programom ozaveščanja in njihovimi poenoteno jedro, ni praktično izvajati glavnega jedra na večini telefonov zaradi ogromnega števila novih vdorov, specifičnih za posameznega prodajalca, uvedenih v vsako napravo.
Ste priključek za slušalke priključili v napačno smer? Samo vdrj v gonilnike! Ni časa, da bi to popravili v proizvodnem načrtu.
Ali je proizvodna ekipa modul kamere namestila na glavo v proizvodni seriji 1? Vdrli, da preverite notranjo kodo različice, in obrnite videoposnetek, če je različica 1!
Vdori, kot so ti, rešijo takojšnjo težavo, vendar le postrgajo površje nenavadnih in specifičnih sprememb, ki se dogajajo. Hudiča, včasih so zaradi komercialnih odločitev v različnih različicah istega telefona celo popolnoma različni čipi. To vodi do vdorov v gonilnike in čudnih odločitev, ki so bile takrat smiselne samo za to, da telefon deluje, da ga je mogoče poslati naslednji teden.
Medtem ko poteka delo za glavno podporo za 64-bitne čipe ARM za zagon z uporabo UEFI, je bilo doslej ni jasnega premika v smeri bolj standardiziranega načina zagona naprav ARM. In to je žalostno, saj to pomeni, da bodo telefone še naprej zavrgli precej pred koncem njihove uporabe delovne dobe, ker je preprosto predrago vzdrževati tehnični dolg in breme na njih programsko opremo.
Po drugi strani pa, če bo proizvajalec originalne opreme zaslužil samo s prodajo naprave, ali ne mora zagotoviti, da bodo ljudje še naprej kupovali nove telefone? Ali bi se trg osebnih računalnikov preusmeril na ta model, če ne bi bilo 30 let zagona in podedovane programske opreme, ki uporablja odprto platformo in standard PC?
To je težko vprašanje brez notranjega znanja Qualcomma, ki ga na žalost trenutno nimamo. Vendar pa lahko nekaj informacij črpamo iz API-ja gonilnika Android 7.0 in zahtev CTS. Zahteve CTS določajo, kaj Google pričakuje od naprave, ki uporablja dano vdelano programsko opremo. "Veliko kladivo", ki se uporablja za uveljavljanje teh zahtev, je Googlova licenca za uporabo njihovega lastniškega paketa storitev Google Play - če ne izpolnjujete pogojev, ne morete poslati Google Apps v napravo. Medtem ko za nekatere to morda razumeti kot prednost, to očitno ni tisto, kar uporabniki želijo in pričakujejo od naprave.
Android 7.0 ni dodal veliko s spremembami HAL ali gonilnikov (kot je opisano zgoraj), zato je malo verjetno, da bi kakršna koli nezdružljivost izvirala od tam. Kar pa bo bolj verjetno predstavljalo težavo, je uvedba a nova zahteva za grafični API Vulkan ali GLES 3.1, biti na voljo za opravljanje CTS.
Trenutno veliko sistemov na čipu (SoC) nima podpore za Vulkan na svojem grafičnem procesorju, vključno z MSM8974. Tu se bo najverjetneje pojavilo tudi vprašanje združljivosti z Androidom 7.0. Še enkrat, brez notranjega znanja Qualcomma in njihovih načrtov za prihodnost težko podamo dokončno izjavo, ne da bi jo opredelili. Trenutno pa verjamemo, da je to verjetno "preprost" primer Qualcommove opustitve podpore za (v njihovih očeh) starajoč se nabor čipov MSM8974 in ne zagotavljajo BSP (paket za podporo plošče) za 7.0 na tej platformi. Če bi bilo tako, bi to pomenilo, da proizvajalci originalne opreme skoraj zagotovo ne bodo poslali različice 7.0 v napravo – morali bi nekako najti podporo za Vulkan ali GLEs 3.1 za svoj GPE in vir GPE. koda je eden od smešno strogo varovanih delov mobilnih skladov (brez pravega razloga, bi dodali – glejte AMD, odprtokodni gonilnik AMDGPU na namizju za Linux). Na žalost pa sta Vulkan in pospešena (GLES) grafika na splošno nekoliko bolj zapleteni kot preprosta LED, zato to ni nekaj, za kar ne bomo videli podstavkov za uvedbo združljivosti.
Ker različica 7.0 ni bila na voljo že dolgo, obstaja resnična možnost, da drugi nabori čipov (razen majhnega števila v samem AOSP) ostanejo zaostaja za različico 6.0 zaradi težav s strojno opremo in gonilniki (tj. ni posodobljenega BSP) ali pomanjkanja podpore prodajalca SoC v zvezi z Vulkanom ali GLES 3.1 API. Trenutno niti Snapdragon 800 niti 801 ne podpirata enega od teh.
Najbolje je opazovati ta prostor - razvijalci na XDA že dobro napredujejo z neuradnimi vrati na 7.0 za številne naprave, ki nimajo uradne podpore za 7.0 od Googla. Te pa so brez podpore za Vulkan ali GLES 3.1 – morda bodo začeli razvijalci iger za Android občutite frustracije zaradi razdrobljenosti, če dovolj uporabnikov začne izvajati ROM-e po meri brez Vulkana ali GLES 3.1 podpora?
Apple podpira svojo linijo iPhone na najnovejši različici iOS-a približno 5 let - iPhone 4s je bil predstavljen oktobra 2011 in je bil posodobljen do iOS 9. Vendar pa ne bo prejel prihajajoče posodobitve za iOS 10, ki bi telefonu zagotovila učinkovito življenjsko dobo 5 let, ob predpostavki, da bo iOS 10 predstavljen okoli oktobra. Treba je omeniti, da Apple ne nudi vedno podpore za grafični API za back-port – iPhone 4s in iPhone 5 tega ne podpirata. vsebuje Applov Metal graphics API, ki je nekoliko podoben scenariju, kot ga vidimo pri Androidu v Vulkan. Edina razlika je v tem, da je Apple še naprej podpiral starejše naprave brez novega grafičnega API-ja.
Kaj misliš? Ali boste na svojem telefonu preklopili ROM po meri, da mu podaljšate življenjsko dobo? Ste povedali v spodnjih komentarjih.