În acest articol, explorăm adevărul de ce dispozitivele Snapdragon 801 nu primesc Android Nougat. De la producătorii de chipset-uri la furnizori, problemele sunt multe!
Actualizat pentru a reflecta cerințele Vulkan sau OpenGL ES 3.1 pentru Android 7.0
Recent, au fost scrise o mulțime de articole despre actualizările versiunilor, despre interacțiunile dintre furnizor și producătorul de chipset-uri și despre ce înseamnă acest lucru pentru dispozitive în viitor. De ce a ajuns să crească acest lucru săptămâna aceasta?
Ei bine, a apărut săptămâna aceasta având în vedere că venerabilul Nexus 5 nu va primi actualizarea la Android 7.0 (Nougat), iar Qualcomm a anunțat că nu va fi oferind suport pentru MSM8974 (cunoscut mai frecvent ca Snapdragon 801) pe 7.0. Acest articol a fost scris ca o colaborare cu XDA Recognized Dezvoltator bondar.
Subiectul a atras un pic de interes de la diverse site-uri de știri, dar mulți ratează nuanțele subtile ale a ceea ce se întâmplă cu adevărat în spatele sceneis. Acest articol va explica puțin mai multe despre cum funcționează actualizările de software, folosind experiența noastră în lucrul cu OEM-uri cu actualizările oficiale de firmware. Vă vom prezenta ce se întâmplă în culise (și de ce) și de ce s-ar putea să nu ajungeți să obțineți cel mai recent software pe telefon.
Primul pas în viața unei actualizări de firmware Android este actualizarea în amonte. Acesta este ceea ce lucrează Google pe plan intern. Spre deosebire de „fluxurile de lucru deschise”, Android este dezvoltat folosind un flux de lucru închis, cu codul sursă aruncat peste perete în fiecare an sau cam asa ceva, atunci când apare o nouă versiune. Inițial, Google a spus că acest lucru a fost pentru a preveni fragmentarea de la persoanele care rulează versiuni de vârf în timp ce lucrurile evoluau rapid în primele zile, dar se pare că au păstrat această politică loc.
La un moment dat, de obicei înainte de anunțul public al unei actualizări (deși odată cu introducerea recentă a beta-urilor publice, aceste intervale de timp se schimbă), Producătorii OEM vor fi informați cu privire la o actualizare viitoare. Ei vor primi apoi codul sursă la un al doilea moment pentru actualizarea finală (în trecut, era uneori cu puțin înainte de lansare, deși suntem conștienți și de cazuri în care nu există timpuriu eliberare).
Arhivele AOSP din amonte conțin suport pentru dispozitive doar pentru un număr limitat de dispozitive. Acestea sunt de obicei dispozitivele dvs. Nexus. Din motive care vor deveni clare în curând, este important să rețineți că Google nu are control complet hardware asupra acestor dispozitive; dispozitivele sunt fabricate de un OEM și acel OEM va cumpăra un System-on-Chip (SoC) de la un producător de chipset-uri.
Odată ce codul sursă este eliberat, echipa de firmware a OEM se va așeza (în sens figurat) și va pune picioarele în sus. Principalul arbore sursă Android nu are suport hardware pentru multitudinea de chipset-uri utilizate în dispozitivele de transport. Cel mai probabil, chipset-ul dvs. Qualcomm nu este acceptat în AOSP, de exemplu. Exynos-ul tău cu siguranță nu este. Mediatek sau HiSilicon? Uită-l!
BSP conține driverele și straturile de abstractizare hardware (HAL) necesare pentru a rula Android
Ceea ce este nevoie acum este a Pachetul de suport pentru bord (BSP). Acesta este un pachet super-confidențial de componente proprietare, livrat de un producător de chipset-uri unui OEM. BSP conține codul sursă necesar pentru a permite OEM-urilor să construiască Android și driverele necesare pentru dispozitivul lor.
Este demn de remarcat aici că OEM-uri precum Qualcomm nu au neapărat încredere deplină în partenerii lor OEM -- BSP-ul este pus la dispoziție pe baza „necesității de știut”. De obicei, OEM-urile nu au acces la codul sursă pentru unele dintre părțile super-secrete ale dispozitivului (cum ar fi software-ul care rulează pe banda de bază). A avea această parte închisă cu siguranță are și probleme potențiale, așa cum arată aproape copios și recurente ASN.1 analizarea vulnerabilităților.
BSP conține driverele și straturile de abstractizare hardware (HAL) necesare pentru a rula Android pe dispozitivul dvs. AOSP conține un set de HAL, care acționează ca definiții cu privire la ceea ce se așteaptă sistemul de operare să implementeze driverele dvs. Pentru a folosi un exemplu ridicol de suprasimplificat (și inventat, în scopul demonstrației), să ne imaginăm lanterna de pe telefonul tău.
Un exemplu HAL - Lanterna ta
Să ne imaginăm că dispozitivul dvs. are o lanternă pe spate (dacă aveți un Nexus 7 2013, va trebui să vă imaginați puțin mai mult decât toți ceilalți -- îmi pare rău!). Aceasta este controlată de un șofer. Pentru exemplul nostru nebun de simplu, să presupunem că v1 HAL spune că ar trebui să aveți o funcție numită „setLED” care ia un singur parametru, starea luminii. Este un boolean - adevărat sau fals. În C, ar arăta cam așa:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Această funcție este definită în codul sursă BSP. BSP-ul este apoi compilat de OEM în timpul construirii ROM-ului, iar aceasta devine una dintre bibliotecile proprietare „.so” din partiția sau zona furnizorului dispozitivului dumneavoastră. Acest lucru permite unui OEM să păstreze secrete anumite părți ale funcționării dispozitivului său. Deocamdată, să presupunem că vor să-i împiedice pe toți să vadă cum pornesc și sting acel LED.
Acum imaginați-vă că Google lansează o versiune actualizată a HAL-urilor lor într-o versiune viitoare de Android. Ei decid acum că ar fi bine să vă permită să actualizați luminozitatea LED-ului, mai degrabă decât să îl porniți sau să îl opriți. Poate că acest lucru este pentru flash adaptiv, sau poate este doar pentru a forța o actualizare HAL și a menține producătorii de chipset-uri în afaceri? Vă vom lăsa pe dvs., cititorul, să vă găsiți propria opinie despre aceasta. Unele actualizări HAL au beneficii clare (cum ar fi noua cameră HAL care expune fotografierea brută și similare), în timp ce altele sunt oarecum mai puțin clare ca scop.
Cu acest nou HAL (fictiv) pentru luminozitate, să presupunem că Google spune că trebuie să expuneți din nou o funcție numită setLED, dar de data aceasta cu un număr întreg transmis pentru luminozitate. Acum, 0 l-ar dezactiva, iar 255 l-ar pune complet.
Dacă sunteți OEM, puteți lua codul super-secret pentru a porni acel LED și îl puteți pune în această nouă funcție. S-ar putea chiar să utilizați modularea lățimii impulsului pentru a regla luminozitatea LED-ului în funcție de număr. Schimbați funcția astfel încât să apară acum:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Şi ce dacă? Ei bine, acum această nouă versiune de Android este incompatibilă cu „blob-urile” existente. OEM-ul dvs. trebuie să folosească aceste noi blob-uri, deoarece sistemul de operare Android se așteaptă să vadă noua definiție a funcției și nu o va „găsi” pe cea veche atunci când caută o modalitate de a seta LED-ul.
În acest moment, să luăm o scurtă pauză pentru a vedea cum se descurcă aici ROM-urile personalizate (construite din sursă). Este ceea ce isteții dintre voi vor țipa la ecran chiar acum - la urma urmei, suntem XDA, casa HTC HD2, cel mai durabil telefon din lume... (doar pentru consemnare, genii nebuni de acolo aleargă Android 6.0 pe HD2 în zilele noastre! Nu este rău pentru un telefon livrat inițial cu Windows Mobile 6.5 în 2009)
Există mai multe abordări luate aici - uneori, dezvoltatorii pirata în ROM-ul și îi spun sistemului de operare să folosească vechile definiții ale funcției. Este puțin dezordonat și face multe modificări de menținut. Cealaltă abordare este să „shim” binarul OEM.
Abordarea „shim” este să scrieți și să construiți singur o nouă bibliotecă mică, care conține definiția funcției așteptată - pentru exemplul nostru, am accepta numărul întreg pentru luminozitate. Apoi, în interiorul lamei, aceasta este tradusă pentru a îndeplini cerințele vechiului HAL. Deci, pentru exemplul nostru, am putea spune că orice luminozitate cerută peste 128 va aprinde LED-ul, iar orice luminozitate mai jos l-ar stinge. Sau ai putea spune că orice nu este zero îl va porni. Depinde de dezvoltator. Ei compilează shim-ul și îl fac pe Android să îl folosească în locul celui nativ. Apoi, shim-ul numește blob OEM.
O „împingere adb” și o repornire rapidă ar trebui să pună în funcțiune shim-ul și să vă permită să vă controlați LED-ul fictiv, chiar dacă aveți doar vechiul HAL.
Problema este că acesta este în mod clar un proces imperfect. Acum veți primi ciudatenii - acest dispozitiv va avea un bliț destul de slab, care este fie complet pornit, fie complet oprit. Nu este ideal - sistemul de operare crede că face o lumină foarte blândă, dar LED-ului real i se spune că concurează la un concurs de soare artificial și încearcă să te orbească. Dar hei, viața nu este perfectă și acum aveți un LED funcțional pe vechiul telefon!
(Da, acesta este unul dintre motivele pentru care există ciudățenii și erori atunci când utilizatorii și dezvoltatorii XDA își gestionează faptele nebunești și nebunești de portare. Adică naiba, Galaxy S II este toting un aparent utilizabil Android 6.0 ROM acum. Multe telefoane lansate anul trecut încă nu au 6.0!)
Să revenim la perspectiva OEM. Din păcate, majoritatea OEM-urilor lucrează deja cu cel puțin 1 telefon înainte de locul în care ne aflăm acum. Accentul lor este pe următorul telefon pe care sunt pe cale să-l vândă – nu îi poți învinovăți, deoarece câștigă bani doar pe dispozitivele pe care le vând. Nu câștigă bani din dispozitivele vândute cu un an sau doi în urmă, așa că trebuie să lanseze în continuare dispozitive noi pentru a exista. Acesta este unul dintre motivele pentru care HTC și Blackberry au probleme - nu contează câți directori își păstrează o stăpânire pe vechea lor Blackberry Curve, deoarece nu primesc o vânzare de dispozitive noi acolo.
Dacă OEM-ul nu primește un BSP, nu vor urma abordarea XDA de a pirata împreună o construcție. De ce? Bine, trebuie să accepte acest firmware pentru clienții lor. Dacă lansează un firmware care funcționează pe jumătate, utilizatorii îi vor ura, vor răbufni și vor elogia și își vor menține liniile de asistență să sune zile întregi.
OEM-urile trebuie să se confrunte și cu transportatorii, cel puțin pe piețele non-europene. Transportatorii nu doresc ca clienții să aibă probleme cu actualizările software. De fapt, transportatorii preferă adesea să nu lanseze actualizări de software.
Pentru a înțelege acest lucru, imaginează-ți mătușa ta Alice. Ea este cea care te sună la ore incomode ale zilei pentru a cere ajutor cu „chestia aia cu computerul”. Apoi descrieți cum să faceți clic pe „meniul Start” și trebuie să îl identificați drept „steagul mare în colțul din stânga jos”, și vă confruntați cu confuzie. Aproximativ 45 de minute (și multă frustrare) mai târziu, reiese că mătușa Alice și-a tras meniul de pornire în marginea din dreapta a ecranului și pur și simplu trebuia să-l tragă înapoi. Da, cu butonul stâng al mouse-ului!
Acum imaginează-ți că ai o mie de mătușă Alice. Toți vă sună la asistența pentru clienți, nu reușesc să găsească Candy Crush pe telefonul lor, îngrijorat că un hacker l-a șters de pe telefonul lor. Ah, și pictogramele arată puțin diferit acum - poate hackerul este încă în telefonul lor?
Da, acest lucru este menit să fie un pic de umor ușor, dar până când nu veți experimenta motivele pentru care oamenii își vor apela operatorul pentru sprijin, nu veți crede problemele pe care le au. O actualizare de software care modifică modul în care funcționează telefonul sau unde sunt lucrurile, va cauza o suprasolicitare semnificativă a suportului. Cel puțin, necesită reinstruire a personalului de asistență (pentru că cei mai mulți dintre ei nu sunt cititorii dvs. pasionați XDA, din păcate).
Odată ce OEM primește BSP-ul, își vor porta ROM-ul și își vor aplica toate modificările la ROM. Se vor îngrămădi în bloatware-ul lor și vor adăuga o piele îngrozitoare de desene animate, care ar arăta mai ca acasă în anime-ul unui adolescent. Apoi o vor testa.
Mult.
Există tot felul de cerințe pe care trebuie să le îndeplinească telefonul dvs. Rețelele mobile sunt concepute pentru a avea încredere în echipamentul utilizatorului (ceea ce numim telefon) să se comporte corect. Aceasta înseamnă că sunt necesare multe teste pentru a obține aprobarea dispozitivului. Actualizările software riscă să schimbe comportamentele, așa că lucrurile trebuie testate din nou. Acesta este motivul pentru care veți vedea în mod obișnuit informații despre viitoarele actualizări de software Sony de la serviciile de testare externe, care confirmă că firmware-ul este compatibil cu cerințele de testare.
Acum... ce se întâmplă după o actualizare sau două (sau, în unele cazuri, niciuna)? Producătorul de SoC nu va oferi OEM-ului un BSP actualizat. La urma urmei, producătorul de SoC nu va obține mare lucru din asta. OEM nu mai câștigă bani pe telefonul tău de când a fost vândut. Și în acest moment, telefonul tău nu mai primește actualizări majore de versiune.
Reducerea numărului de BSP pe care OEM dorește să fie livrate este o modalitate excelentă de a economisi bani - dacă aveți nevoie doar de cel actual și nu intenționați să livrați nicio versiune majoră crește, acest lucru va economisi bani la achiziția inițială a SoC și licențierea, dar în detrimentul câțiva tocilari supărați de pe XDA, întrebându-se de ce nu au primit un Actualizați.
Actualizările sunt complexe. Sunt o mulțime de oameni diferiți implicați în lanț. Nimic din toate acestea nu scuză OEM-urile de starea actuală nelipsită și jalnică a actualizărilor pe Android. Cu toate acestea, există câteva provocări reale aici.
Mulți OEM sunt de vină pentru excesul de promițători, iar inevitabil sublivrare pe care o asociam acum. Trista realitate este că pentru majoritatea OEM-urilor, actualizările de software sunt doar o supărare fără de care s-ar putea descurca.
Sectorul mobil este în mare parte blocat în mentalitatea telefoanelor cu caracteristici. Adică, acolo unde un dispozitiv nu primește niciodată actualizări. Testați-l o dată, expediați-l și nu vă uitați niciodată înapoi. Cu problemele de securitate ale smartphone-urilor moderne și complexitatea absolută a rulării unui sistem de operare cu uz general complet, cu sute de biblioteci externe, aceasta nu mai este o opțiune. Sau cel puțin asta nu ar trebui fi. Google a făcut câțiva pași pentru a remedia acest lucru, cel puțin publicând buletine de securitate și patch-uri pentru versiunile existente. de Android (rețineți că, până de curând, singura modalitate de a obține actualizări de securitate era printr-o nouă versiune majoră a sistemului de operare Android!)
Din păcate, totuși, acest lucru nu este cu adevărat suficient. Chiar dacă Google continuă să lanseze actualizări, securitatea dispozitivului dvs. depinde în continuare de producătorul de SoC - deoarece producătorii de SoC sunt atât de încremeniți de cineva care descoperă cum aprinde câteva LED-uri sau scoate un sunet printr-un difuzor, ei expediază cantități uriașe de blob-uri binare pe dispozitive. Aceste blob-uri conțin un cod destul de nesigur (doar aruncați o privire la buletinele de securitate Google anterioare dacă credeți că este o exagerare!) și trebuie actualizate. Ceea ce înseamnă că sunt necesare BSP-uri actualizate.
Computerele desktop (și prin extensie, laptopurile) sunt complet diferite ca arhitectură de dispozitivele mobile. Telefonul sau tableta dvs. mobilă este în mod efectiv un bulgăre de siliciu foarte proprietar, proiectat în grabă de unii oameni care au intenții bune, dar nu au suficient timp pentru a face ceva bun. Piața se mișcă atât de rapid încât abia reușesc să țină pasul cu ritmul în care marketingul cere lansarea de noi produse.
Aceasta înseamnă că sunt luate comenzi rapide - nu veți găsi telefonul dvs. acceptat de kernel-ul Linux principal și veți descoperi că fiecare telefon are o modalitate diferită de pornire. Pe laptop sau desktop, totuși, vânzătorii s-au hotărât pe câteva modalități standard de pornire - anterior era MBR (master boot record) cu un BIOS, iar acum este UEFI. Această standardizare face posibilă rularea aceluiași software pe fiecare dispozitiv.
Deși au fost câțiva pași în acest sens recent, în special cu programul de informare Sony și a acestora nucleu unificat, nu este practic să rulați un nucleu principal pe majoritatea telefoanelor, din cauza numărului mare de hack-uri noi specifice furnizorului introduse pentru fiecare dispozitiv.
Ați conectat mufa pentru căști în sensul greșit? Doar piratați-l în drivere! Nu există timp să o rezolvi în designul de producție.
Echipa de producție a montat modulul camerei cu capul în jos în lotul de producție 1? Aruncă un hack pentru a verifica codul intern al versiunii și răsturnează videoclipul dacă este versiunea 1!
Hack-uri ca acestea rezolvă problema imediată, dar doar răzuiesc suprafața schimbărilor ciudate și specifice produsului care au loc. La naiba, există uneori chiar și cipuri complet diferite în diferite versiuni ale aceluiași telefon, din cauza deciziilor comerciale. Acestea duc la hackuri în șoferi și la decizii ciudate care aveau sens doar la momentul respectiv, pentru a face telefonul să funcționeze, astfel încât să poată fi expediat săptămâna viitoare.
Deși se lucrează la suportul principal pentru cipurile ARM pe 64 de biți pentru a porni folosind UEFI, până acum au existat nicio mișcare clară către o modalitate mai standardizată de a porni dispozitivele ARM. Și asta este trist, pentru că înseamnă că telefoanele vor continua să fie aruncate cu mult înainte de sfârșitul lor viața profesională, pentru că pur și simplu este prea scump să mențină datoria tehnică și povara asupra lor software.
Pe de altă parte, totuși, dacă un OEM va câștiga bani doar din vânzarea unui dispozitiv, nu trebuie să se asigure că oamenii continuă să cumpere telefoane noi? Piața PC-urilor s-ar muta la acest model dacă nu ar exista deja 30 de ani de impuls și software moștenit care să folosească platforma și standardul deschis pentru PC?
Aceasta este o întrebare grea fără cunoștințe interne de la Qualcomm, pe care, din păcate, nu o avem în acest moment. Cu toate acestea, putem extrage câteva informații din cerințele API și CTS ale driverului Android 7.0. Cerințele CTS specifică ce se așteaptă Google de la un dispozitiv care rulează un anumit firmware. „Ciocanul mare” folosit pentru a impune aceste cerințe este licența de la Google pentru a utiliza pachetul de servicii proprietar Google Play - dacă nu respectați, nu puteți livra Google Apps pe dispozitiv. În timp ce, pentru unii, asta ar putea fi privit ca un avantaj, acest lucru nu este, evident, ceea ce doresc și așteaptă utilizatorii de la un dispozitiv.
Android 7.0 nu a adăugat prea multe prin intermediul modificărilor HAL sau driverelor (așa cum este descris mai sus), așa că este puțin probabil ca orice incompatibilitate să vină de acolo în mod specific. Totuși, ceea ce este mai probabil să pună o problemă este introducerea unui o nouă cerință fie pentru API-ul grafic Vulkan, fie pentru GLES 3.1, să fie disponibil pentru a trece CTS.
În prezent, o mulțime de Systems-on-Chip (SoC) nu au avut suport Vulkan pe procesorul lor grafic, inclusiv MSM8974. De asemenea, aici va apărea cel mai probabil problema compatibilității cu Android 7.0. Din nou, totuși, fără cunoștințele interne de la Qualcomm și planurile lor de viitor, este greu pentru noi să dăm o declarație definitivă fără a o califica. În acest moment, însă, credem că este probabil ca acesta să fie cazul „simplu” în care Qualcomm a întrerupt suportul pentru chipset-ul MSM8974 îmbătrânit (în ochii lor) și nu oferă un BSP (pachet de suport pentru bord) pentru 7.0 pe platforma respectivă. Dacă acesta ar fi cazul, ar însemna că OEM-urile ar fi aproape sigur că nu vor livra 7.0 pe dispozitiv - ar trebui să găsească cumva suport Vulkan sau GLEs 3.1 pentru GPU-ul lor și sursa GPU. codul este una dintre părțile ridicol de bine păzite ale stack-urilor mobile (fără un motiv real, am adăuga - vezi AMD, care își deschide propriul driver AMDGPU pe desktop pentru Linux). Din păcate, totuși, grafica Vulkan și accelerată (GLES) în general sunt puțin mai complexe decât un simplu LED, așa că nu este ceva pentru care vom vedea shims pentru a introduce compatibilitatea.
Deoarece 7.0 nu a fost lansat de mult timp, există o posibilitate reală ca alte chipset-uri (altele decât numărul mic din AOSP în sine) să fie lăsate în urmă pe versiunea 6.0, din cauza fie problemelor hardware și ale driverului (adică fără BSP actualizat), fie din cauza lipsei de suport pentru furnizorii de SoC în ceea ce privește Vulkan sau GLES 3.1 API. În prezent, nici Snapdragon 800, nici 801 nu acceptă unul dintre acestea.
Cel mai bun pariu este să urmărești acest spațiu - Dezvoltatorii de pe XDA fac deja progrese bune cu porturile neoficiale la 7.0 pentru multe dintre dispozitivele care nu primesc suport oficial 7.0 de la Google. Totuși, acestea sunt fără suport Vulkan sau GLES 3.1 - poate dezvoltatorii de jocuri pe Android vor începe să experimentați frustrare prin fragmentare dacă destui utilizatori încep să ruleze ROM-uri personalizate fără Vulkan sau GLES 3.1 a sustine?
Apple tinde să-și susțină linia iPhone pe cea mai recentă versiune iOS timp de aproximativ 5 ani - iPhone 4s a fost lansat în octombrie 2011 și a fost ținut la zi până la iOS 9. Cu toate acestea, nu va primi viitoarea actualizare iOS 10, ceea ce ar oferi telefonului o durată de viață efectivă de 5 ani, presupunând că iOS 10 este lansat în jurul lunii octombrie. Este demn de remarcat faptul că Apple nu acceptă întotdeauna back-port graphics API - iPhone 4s și iPhone 5 nu prezintă API-ul grafic Apple Metal, care este un scenariu oarecum similar cu cel văzut cu Android Vulkan. Singura diferență este că Apple a continuat să accepte dispozitivele mai vechi fără noul API grafic.
Ce crezi? Veți flash un ROM personalizat pe telefon pentru a prelungi durata de viață a acestuia? Ai spus în comentariile de mai jos.