Põhjalik ülevaade sellest, miks on SD801 seadmed Nougatist välja jäetud

Värskendatud, et kajastada Android 7.0 kas-või Vulkani või OpenGL ES 3.1 nõuet

Hiljuti on kirjutatud palju artikleid versiooniuuenduste, müüja ja kiibistikutootja vahelise suhtluse ning selle kohta, mida see seadmete jaoks tulevikus tähendab. Miks on see sel nädalal tõusnud?

Sel nädalal selgus, et auväärne Nexus 5 ei saa Android 7.0 (Nougat) värskendust ja Qualcomm teatas, et seda ei tehta. pakkudes tuge MSM8974-le (enam tuntud kui Snapdragon 801) versioonis 7.0. See artikkel on kirjutatud koostöös ettevõttega XDA Recognized Arendaja kimalane.

Teema on pälvinud palju huvi erinevatel uudistesaitidel, kuid paljud jätavad tähelepanuta lava taga tegelikult toimuva peened nüansids. See artikkel selgitab veidi lähemalt, kuidas tarkvaravärskendused töötavad, kasutades meie kogemusi originaalseadmete tootjatega nende ametlike püsivara värskenduste osas. Anname teile ülevaate, mis toimub kulisside taga (ja miks) ja miks te ei pruugi oma telefoni uusimat tarkvara hankida.

Androidi püsivara värskenduse esimene samm on ülesvoolu värskendus. See on see, mille kallal Google sisemiselt töötab. Erinevalt "avatud töövoogudest" arendatakse Androidi suletud töövoo abil, mille lähtekood visatakse umbes igal aastal üle seina, kui uus versioon välja tuleb. Algselt ütles Google, et see on mõeldud selleks, et vältida killustumist inimeste poolt, kes kasutavad verise servaga versioone Kuigi asjad arenesid algusaegadel kiiresti, näib, et nad on seda poliitikat järginud koht.

Mingil ajahetkel, tavaliselt enne värskenduse avalikku väljakuulutamist (kuigi avaliku beetaversiooni hiljutise kasutuselevõtuga on need ajavahemikud nihkumas), OEM-e teavitatakse eelseisvast värskendusest. Seejärel saavad nad lähtekoodi teisel ajahetkel lõpliku värskenduse jaoks (varem oli see nii mõnikord veidi enne käivitamist, kuigi oleme teadlikud ka juhtudest, kus pole vara vabastamine).

Ülesvoolu AOSP hoidlad sisaldavad seadme tuge ainult piiratud arvu seadmete jaoks. Need on tavaliselt teie Nexuse seadmed. Peagi selguvatel põhjustel on aga oluline märkida, et Google'il puudub täielik riistvaraline kontroll nende seadmete üle. seadmeid toodab originaalseadmete tootja ja see OEM ostab kiibipõhise süsteemi (SoC) kiibistiku tootjalt.

Kui lähtekood on avaldatud, istub OEM-i püsivara meeskond (piltlikult) maha ja paneb jalad püsti. Peamisel Androidi lähtepuul puudub riistvaratugi lugematute tarneseadmetes kasutatavate kiibikomplektide jaoks. Teie Qualcommi kiibikomplekti näiteks AOSP tõenäoliselt ei toetata. Teie Exynos kindlasti mitte. Mediatek või HiSilicon? Unusta ära!

BSP sisaldab draivereid ja riistvara abstraktsioonikihte (HAL), mis on vajalikud Androidi käivitamiseks

Nüüd on vaja a Juhatuse tugipakett (BSP). See on ülikonfidentsiaalne patenteeritud komponentide pakett, mille kiibistiku tootja tarnib originaalseadmete tootjale. BSP sisaldab vajalikku lähtekoodi, mis võimaldab originaalseadmete tootjatel luua Androidi ja oma seadme jaoks vajalikke draivereid.

Siinkohal tasub märkida, et originaalseadmete tootjad, nagu Qualcomm, ei pruugi oma OEM-partnereid täielikult usaldada – BSP tehakse kättesaadavaks teadmisvajaduse alusel. Originaalseadmete tootjad ei pääse tavaliselt ligi mõne seadme ülisalajase osa (nt põhiribal töötava tarkvara) lähtekoodile. Selle osa sulgemisel on kindlasti ka võimalikke probleeme, nagu näitab lähedal rohkelt ja korduv ASN.1 turvaaukude sõelumine.

BSP sisaldab draivereid ja riistvara abstraktsioonikihte (HAL), mis on vajalikud Androidi käivitamiseks teie seadmes. AOSP sisaldab HAL-ide komplekti, mis toimivad määratlustena selle kohta, mida operatsioonisüsteem teie draiveritelt eeldab. Naeruväärselt ülelihtsustatud (ja demonstratsiooni eesmärgil väljamõeldud) näite kasutamiseks kujutame ette taskulampi teie telefonis.

HAL-i näide – teie taskulamp

Kujutagem ette, et teie seadme tagaküljel on taskulamp (kui teil on Nexus 7 2013, peate natuke rohkem kujutlema kui kõik teised – vabandust!). Seda juhib juht. Meie pööraselt lihtsa näite puhul oletame, et v1 HAL ütleb, et teil peaks olema üks funktsioon nimega "setLED", mis võtab ühe parameetri, valguse oleku. See on tõeväärtus – tõene või vale. C-s näeks see välja umbes selline:

void setLED(bool ledState) {

// here is the actual code to turn on or off the LED, based on ledState

}

See funktsioon on määratletud BSP lähtekoodis. Seejärel kompileerib originaalseadmete valmistaja ROM-i loomise ajal BSP ja sellest saab üks teie seadme müüja partitsioonis või piirkonnas asuvatest patenteeritud ".so" teekidest. See võimaldab originaalseadmete tootjal hoida teatud osa oma seadme töös salajas. Oletame praegu, et nad tahavad takistada kõigil nägemast, kuidas nad LED-i sisse ja välja lülitavad.

Kujutage nüüd ette, et Google avaldab Androidi tulevases versioonis oma HAL-ide värskendatud versiooni. Nüüd otsustavad nad, et oleks tore lubada teil LED-i heledust värskendada, selle asemel et see lihtsalt sisse või välja lülitada. Võib-olla on see mõeldud adaptiivse välgu jaoks või võib-olla lihtsalt HAL-i värskenduse sundimiseks ja kiibistikutootjate tegevuses hoidmiseks? Lugeja, laseme teil selle kohta oma arvamusele jõuda. Mõnel HAL-i värskendusel on selge kasu (nt uus kaamera HAL, mis paljastab töötlemata pildistamise jms), samas kui teistel on eesmärk mõnevõrra ebaselgem.

Selle uue (väljamõeldud) heleduse jaoks mõeldud HAL-i puhul oletame, et Google ütleb, et peate uuesti paljastama funktsiooni nimega setLED, kuid seekord heleduse jaoks on täisarv. Nüüd lülitaks 0 selle välja ja 255 paneks selle täis.

Kui olete originaalseadmete tootja, võite selle LED-i sisselülitamiseks võtta oma ülisalajane koodi ja panna selle uude funktsiooni. LED-i heleduse reguleerimiseks numbri alusel võite isegi kasutada impulsi laiuse modulatsiooni. Muudate funktsiooni, et see näeks nüüd välja selline:

void setLED(uint8_t ledBrightness) {

// some super-secret and ultra-confidential proprietary way to set LED brightness

}

Mis siis? Noh, nüüd ei ühildu see Androidi uus versioon olemasolevate "plokkidega". Teie originaalseadmete valmistaja peab kasutama neid uusi plokke, kuna Android OS eeldab uut funktsioonide määratlust ega leia LED-i seadistamise viisi otsides vana.

Siinkohal teeme lühikese vahetunni, et vaadata, kuidas kohandatud ROM-id (ehitatud allikast) siin hakkama saavad. See on see, mida nutikad teie seast praegu teie ekraanile karjuvad – oleme ju XDA, HTC HD2, maailma pikima tööeaga telefon... (Lihtsalt teadmiseks, hullud geeniused seal jooksevad Tänapäeval on HD2-l Android 6.0! Pole paha telefoni kohta, mis tarniti algselt 2009. aastal Windows Mobile 6.5-ga)

Siin on kasutatud erinevaid lähenemisviise – mõnikord häkivad arendajad ROM-is ringi ja käsivad OS-il kasutada vanu funktsioonide määratlusi. See on natuke räpane ja selle säilitamiseks tuleb palju muudatusi teha. Teine lähenemine on OEM-i kahendfaili "shimm".

"Shim" lähenemisviis on kirjutada ja ehitada ise pisike uus raamatukogu, mis sisaldab eeldatavat funktsiooni definitsiooni – meie näiteks toetaksime heleduse jaoks täisarvu. Seejärel tõlgitakse see vaheplaadi sees, et see vastaks vana HAL-i nõuetele. Nii et meie näite puhul võiksime öelda, et mis tahes heledus, mida nõutakse üle 128, lülitab LED-i sisse ja kõik, mis on väiksem, lülitab selle välja. Või võite öelda, et mis tahes, mitte null, lülitab selle sisse. See on arendaja otsustada. Nad kompileerivad vaheplaadi ja panevad Androidi kasutama seda algseadise asemel. Seejärel nimetab sepp OEM-i blob'iks.

Kiire "adb push" ja taaskäivitamine peaks panema aluse käima ja võimaldama teil juhtida oma väljamõeldud LED-i, kuigi teil on ainult vana HAL.

Probleem on selles, et see on selgelt ebatäiuslik protsess. Nüüd on teil veidrusi – sellel seadmel on üsna närune välk, mis on kas täielikult sisse või välja lülitatud. See pole ideaalne – OS arvab, et see tekitab väga õrna valgust, kuid tegelikule LED-ile öeldakse, et see võistleb kunstliku päikese võistlusel ja püüab teid pimestada. Aga hei, elu pole täiuslik ja teie vanal telefonil on nüüd töötav LED!

(Jah, see on üks põhjusi, miks XDA kasutajad ja arendajad oma hullumeelseid ja hullumeelseid ülekandmisoskusi korraldavad veidrusi ja vigu. Ma mõtlen, pagan, Galaxy S II on pealtnäha kasutuskõlbliku kandmine Android 6.0 ROM nüüd. Paljudel eelmisel aastal välja antud telefonidel pole ikka veel 6.0!)

Hüppame tagasi OEM-i vaatenurga juurde. Kahjuks töötab enamik originaalseadmete tootjaid juba vähemalt ühe telefoni võrra ees, kui me praegu oleme. Nende fookus on järgmisel telefonil, mida nad kohe müüma hakkavad – te ei saa neid tegelikult süüdistada, kuna nad teenivad raha ainult müüdavate seadmete pealt. Nad ei teeni aasta või kaks tagasi müüdud seadmetelt raha, seega peavad nad pidevalt uusi seadmeid välja laskma, et eksisteerida. See on üks põhjus, miks HTC ja Blackberry on raskustes – pole vahet, kui paljud juhid oma vana Blackberry Curve'i surmahaarde säilitavad, kuna nad ei saa seal uusi seadmeid müüki.

Kui originaalseadmete valmistaja ei saa BSP-d, ei kavatse nad XDA lähenemisviisi, milleks on konstruktsiooni kokku häkkimine, loobuda. Miks? Noh, nad peavad seda püsivara oma klientide jaoks toetama. Kui nad lasevad välja pooleldi töötava püsivara, vihkavad kasutajad neid ning tormavad ja raevuvad ning hoiavad nende tugiliinid päevade kaupa väljas.

OEM-id peavad võitlema ka vedajatega, vähemalt mitte-Euroopa turgudel. Vedajad ei taha, et klientidel tekiks tarkvaravärskendustega probleeme. Tegelikult ei soovi operaatorid sageli tarkvaravärskendusi välja anda.

Selle mõistmiseks kujutage ette oma vanatädi Alice'i. Tema helistab teile ebamugavatel kellaaegadel, et paluda abi "selle arvutiasjaga". Seejärel kirjeldate, kuidas klõpsata menüül "Start" ja peate selle identifitseerima kui "suurt lippu alumises vasakus nurgas" ja teid tabab segadus. Umbes 45 minutit (ja palju pettumust) hiljem selgub, et tädi Alice lohistas oma algusmenüü ekraani paremasse serva ja pidi selle lihtsalt tagasi lohistama. Jah, hiire vasaku nupuga!

Kujutage nüüd ette, et teil on tuhat tädi Alice'i. Nad kõik helistavad teie klienditoele, ei leia oma telefonist Candy Crushi ja on mures, et häkker selle nende telefonist kustutas. Oh, ja ikoonid näevad nüüd natuke teistsugused välja – võib-olla on häkker ikka veel nende telefonis?

Jah, see on mõeldud kergemeelse huumorina, kuid kuni te ei koge põhjuseid, miks inimesed oma operaatorilt abi saamiseks helistavad, ei usu te nende probleeme. Tarkvaravärskendus, mis muudab telefoni tööd või asukohta, põhjustab märkimisväärset tugikulu. See nõuab vähemalt tugipersonali ümberõpet (kuna kahjuks pole enamik neist teie innukas XDA-lugeja).

Kui originaalseadmete valmistaja saab BSP-d, pordib ta oma ROM-i ja rakendab kõik muudatused ROM-ile. Nad kuhjavad oma puhitustarbeid ja lisavad kohutava koomiksilaadse naha, mis näeks teismelise animes kodusem välja. Siis nad testivad seda.

Palju.

Teie telefon peab vastama kõikvõimalikele nõuetele. Mobiilsidevõrgud on loodud usaldama kasutajaseadmete (mida me nimetame telefoniks) korrektset käitumist. See tähendab, et seadme heakskiitmiseks on vaja palju katseid. Tarkvaravärskendused võivad käitumist muuta, seega tuleb asju uuesti testida. Seetõttu näete sageli teavet tulevaste Sony tarkvaravärskenduste kohta välistest testteenustest, mis kinnitavad, et püsivara vastab testinõuetele.

Nüüd... mis juhtub pärast värskendust või kahte (või mõnel juhul mitte ühtegi)? SoC-tootja ei anna originaalseadmete valmistajale värskendatud BSP-d. Lõppude lõpuks ei saa SoC tegija sellest palju. OEM ei teeni teie telefoniga pärast selle müümist enam raha. Ja praegu ei saa teie telefon enam olulisi versiooniuuendusi.

OEM-i tarnitavate BSP-de arvu vähendamine on suurepärane viis raha säästmiseks – kui vajate ainult praegust ja te ei kavatse tarnida ühtegi suuremat versiooni suureneb, säästab see raha SoC esialgse ostu ja litsentsimise arvelt, kuid mõne XDA vihase nohiku arvelt, kes mõtlevad, miks nad ei saanud värskendada.

Värskendused on keerulised. Ahelas on palju erinevaid inimesi. Ükski neist ei vabanda originaalseadmete tootjaid Androidi värskenduste praeguse ebapiisava ja haletsusväärse oleku eest. Sellegipoolest on siin mõned tõelised väljakutsed.

Paljud originaalseadmete tootjad on süüdi liigses paljulubamises ja paratamatu alatootmine, mida me praegu seostame. Kurb reaalsus on see, et enamiku originaalseadmete tootjate jaoks on tarkvarauuendused lihtsalt tüütus, ilma milleta nad saaksid hakkama.

Mobiilisektor on enamasti kinni funktsioonitelefonide mõtteviisis. See tähendab, et seade ei saa kunagi värskendusi. Testige seda üks kord, saatke see ja ärge kunagi vaadake tagasi. Kaasaegsete nutitelefonide turbeprobleemide ja täieliku üldotstarbelise operatsioonisüsteemi ja sadade väliste teekide käitamise keerukuse tõttu pole see enam võimalik. Või vähemalt seda ei peaks olla. Google on astunud samme selle parandamiseks, avaldades vähemalt olemasolevate versioonide turvabülletäänid ja paigad Androidist (pidage meeles, et kuni viimase ajani oli turvavärskenduste hankimiseks ainus viis uue suurema Android OS-i versiooni kaudu!)

Kahjuks sellest ei piisa. Kuigi Google avaldab pidevalt värskendusi, sõltub teie seadme turvalisus endiselt SoC-tootjast – kuna SoC-tegijad on nii kivistunud kui keegi avastab, kuidas ta paar LED-i sisse lülitab või kõlarist heli teeb, saadab ta omale tohutul hulgal binaarplokke seadmeid. Need plekid sisaldavad üsna kohutavalt ebaturvalist koodi (kui arvate, et see on liialdus, vaadake lihtsalt Google'i varasemaid turvabülletääne!) ja vajavad värskendamist. Mis tähendab, et on vaja uuendatud BSP-sid.

Lauaarvutid (ja laiemalt ka sülearvutid) erinevad oma arhitektuuri poolest mobiilseadmetest täiesti. Teie mobiiltelefon või tahvelarvuti on tegelikult tugevalt patenteeritud ränitükk, mille on kiirustades loonud mõned inimesed, kes mõtlevad hästi, kuid kellel pole peaaegu piisavalt aega millegi hea tegemiseks. Turg liigub nii kiiresti, et nad ei suuda vaevu sammu pidada tempoga, millega turundus nõuab uute toodete turule toomist.

See tähendab, et kasutatakse otseteid – te ei leia, et teie telefoni põhiline Linuxi kernel toetaks ja igal telefonil on erinev alglaadimisviis. Kuid teie sülearvuti või lauaarvuti puhul otsustasid müüjad alglaadimiseks mõne standardse viisi – varem oli see BIOS-iga MBR (master boot record) ja nüüd on see UEFI. See standardimine võimaldab käitada igas seadmes sama tarkvara.

Kuigi viimasel ajal on selle poole tehtud mõningaid samme, eriti Sony teavitusprogrammi ja nende jaoks ühtne tuum, ei ole enamikus telefonides otstarbekas käitada põhiliini kernelit, kuna igasse seadmesse on lisatud palju uusi müüja-spetsiifilisi häkke.

Kas kõrvaklappide pesa on valesti ühendatud? Häkkige see lihtsalt draiveritesse! Tootmiskujunduses pole aega seda parandada.

Tootmismeeskond paigaldas kaamera mooduli tagurpidi tootmispartiisse 1? Sisemise versiooni koodi kontrollimiseks proovige sisse ja pöörake video ümber, kui see on versioon 1!

Sellised häkid lahendavad kohese probleemi, kuid kaapivad toimuvate veidrate ja tootespetsiifiliste muudatuste pinda. Pagan, äriotsuste tõttu on sama telefoni erinevates versioonides mõnikord isegi täiesti erinevad kiibid. Need põhjustavad häkkimisi draiverites ja veidraid otsuseid, mis olid tol ajal mõistlikud, et telefon tööle saada, et see saaks järgmisel nädalal tarnida.

Kuigi käimas on töö 64-bitiste ARM-kiipide põhivõrgu toe nimel, et käivitada UEFI abil, on seda seni tehtud puudub selge liikumine ARM-seadmete alglaadimise standardsema viisi suunas. Ja see on kurb, sest see tähendab, et telefone visatakse välja enne nende kasutusaja lõppu tööelu, sest nende tehniliste võlgade ja koormuse ülalpidamine on lihtsalt liiga kallis tarkvara.

Teisest küljest, kui originaalseadmete valmistaja teenib raha ainult seadme müügiga, kas nad ei pea tagama, et inimesed jätkaksid uute telefonide ostmist? Kas personaalarvutite turg liiguks selle mudeli juurde, kui seal poleks juba 30 aastat hoogu ja pärandtarkvara, mis kasutab avatud arvutiplatvormi ja standardit?

See on raske küsimus ilma Qualcommi siseteadmisteta, mida meil kahjuks praegu pole. Siiski saame mõnda teavet ammutada Androidi 7.0 draiveri API ja CTS-i nõuetest. CTS-i nõuded täpsustavad, mida Google teatud püsivaraga seadmelt ootab. Nende nõuete jõustamiseks kasutatav "suur haamer" on Google'i litsents kasutada oma Google Play teenuste kogumit – kui te ei järgi, ei saa te Google Appsi seadmesse saata. Kuigi mõne jaoks on see võib pidada eeliseks, see pole ilmselgelt see, mida kasutajad seadmelt tahavad ega oota.

Android 7.0 ei ole HAL-i ega draiverite muudatuste kaudu palju lisanud (nagu ülalpool kirjeldatud), seega on ebatõenäoline, et see ei tulene konkreetselt sellest. Tõenäolisemalt tekitab probleemi aga a uus nõue Vulkani graafika API või GLES 3.1 jaoks, olema saadaval, et läbida CTS.

Praegu pole paljudel süsteemidel kiibil (SoC) oma graafikaprotsessoril Vulkani tuge, sealhulgas MSM8974. See on ka kõige tõenäolisem koht, kus tekib Android 7.0-ga ühilduvuse probleem. Jällegi, ilma Qualcommi siseteadmisteta ja nende tulevikuplaanideta, on meil raske anda lõplikku avaldust ilma seda kvalifitseerimata. Praegu usume siiski, et see on "lihtne" juhtum, kus Qualcomm katkestab (nende silmis) vananev MSM8974 kiibistik ega paku sellel platvormil BSP-d (plaadi tugipakett) 7.0 jaoks. Kui see nii oleks, tähendaks see, et originaalseadmete tootjad ei tarni peaaegu kindlasti seadmesse versiooni 7.0 – nad peaksid kuidagi leidma oma GPU ja GPU allika jaoks Vulkani või GLEs 3.1 toe. kood on üks naeruväärselt rangelt kaitstud osi mobiilsetes virnades (ilma tegeliku põhjuseta lisame – vaata AMD-d, avame oma AMDGPU draiveri töölaual Linux). Kahjuks on Vulkan ja kiirendatud (GLES) graafika üldiselt pisut keerulisemad kui lihtne LED, nii et see ei ole midagi, mille jaoks me ei hakka nägema ühilduvust.

Kuna 7.0 pole kaua väljas olnud, on reaalne võimalus, et teised kiibistikud (peale väikese arvu AOSP-s endas) lahkuvad 6.0-st mahajäänud riistvara- ja draiveriprobleemide tõttu (st ei ole värskendatud BSP-d) või Vulkani või GLES 3.1-ga seotud SoC-müüja toe puudumise tõttu API. Praegu ei toeta ei Snapdragon 800 ega 801 ühtegi neist.

Parim on seda ruumi jälgida - XDA arendajad on juba teinud suuri edusamme mitteametlike portidega 7.0-le paljudes seadmetes, mis ei saa Google'ilt ametlikku 7.0 tuge. Need on aga ilma Vulkani või GLES 3.1 toeta – võib-olla hakkavad Androidi mängude arendajad seda tegema kogevad killustumise tõttu pettumust, kui piisavalt kasutajaid hakkavad kasutama kohandatud ROM-e ilma Vulkani või GLES 3.1ta toetus?

Apple toetab oma iPhone'i sarja uusimas iOS-i versioonis umbes 5 aastat – iPhone 4s toodi turule 2011. aasta oktoobris ja seda on hoitud ajakohasena kuni iOS 9-ni. Siiski ei saa see iOS 10 eelseisvat värskendust, mis annaks telefonile 5-aastase tõhusa eluea, eeldusel, et iOS 10 käivitatakse umbes oktoobris. Väärib märkimist, et Apple ei toeta alati graafika API tugiporti – iPhone 4s ja iPhone 5 seda ei tee sisaldab Apple'i metalligraafika API-d, mis on mõnevõrra sarnane Androidiga Vulkan. Ainus erinevus on see, et Apple jätkas vanemate seadmete toetamist ilma uue graafika API-ta.

Mida sa arvad? Kas vilgutate oma telefonis kohandatud ROM-i, et selle eluiga pikendada? Kas olete öelnud allolevates kommentaarides.