U ovom članku istražujemo istinu o tome zašto Snapdragon 801 uređaji ne dobivaju Android Nougat. Od proizvođača čipseta do dobavljača, problema je mnogo!
Ažurirano kako bi odražavalo zahtjeve ili-ili Vulkan ili OpenGL ES 3.1 za Android 7.0
Nedavno je napisano mnogo članaka o ažuriranjima verzija, interakcijama između dobavljača i proizvođača čipseta i što to znači za buduće uređaje. Zašto je ovo poraslo ovaj tjedan?
Pa, pojavilo se ovaj tjedan s obzirom da časni Nexus 5 neće primiti ažuriranje na Android 7.0 (Nougat), a Qualcomm je najavio da neće biti pružanje podrške za MSM8974 (poznatiji kao Snapdragon 801) na 7.0. Ovaj članak je napisan u suradnji s XDA Recognized Developer bumbar.
Tema je privukla prilično zanimanje raznih stranica s vijestima, ali mnogi propuštaju suptilne nijanse onoga što se stvarno događa iza scenes. Ovaj članak će objasniti nešto više o tome kako funkcioniraju ažuriranja softvera, koristeći naše iskustvo u radu s OEM proizvođačima na njihovim službenim ažuriranjima firmvera. Provest ćemo vas kroz ono što se događa iza kulisa (i zašto) i zašto na kraju možda nećete dobiti najnoviji softver na svom telefonu.
Prvi korak u životu ažuriranja firmvera za Android je ažuriranje uzvodno. To je ono na čemu Google radi interno. Za razliku od "otvorenih radnih tijekova", Android se razvija korištenjem zatvorenog tijeka rada, s izvornim kodom koji se baca preko zida svake godine ili tako nešto, kada se pojavi novo izdanje. Izvorno, Google je rekao da je to kako bi spriječio fragmentaciju od ljudi koji koriste najnovije verzije dok su se stvari brzo razvijale u ranim danima, ali čini se da su zadržali ovu politiku mjesto.
U nekom trenutku, obično prije javne objave ažuriranja (iako se s nedavnim uvođenjem javnih beta verzija ti vremenski okviri pomiču), OEM-ovi će biti obaviješteni o nadolazećem ažuriranju. Zatim će primiti izvorni kod u drugom trenutku za konačno ažuriranje (u prošlosti je bilo ponekad malo prije lansiranja, iako smo također svjesni slučajeva u kojima ne postoji rano oslobađanje).
Uzvodna AOSP spremišta sadrže podršku za samo ograničeni broj uređaja. To su obično vaši Nexus uređaji. Međutim, iz razloga koji će uskoro postati jasni, važno je napomenuti da Google nema potpunu hardversku kontrolu nad ovim uređajima; uređaje proizvodi OEM, a taj će OEM kupiti System-on-Chip (SoC) od proizvođača čipseta.
Nakon što se izvorni kod objavi, OEM-ov firmware tim će (figurativno) sjesti i podići noge. Glavno izvorno stablo Androida nema hardversku podršku za mnoštvo skupova čipova koji se koriste u uređajima za isporuku. Vaš Qualcomm čipset najvjerojatnije nije podržan unutar AOSP-a, na primjer. Vaš Exynos to definitivno nije. Mediatek ili HiSilicon? Zaboravi!
BSP sadrži upravljačke programe i slojeve apstrakcije hardvera (HAL) koji su potrebni za pokretanje Androida
Ono što je sada potrebno je a Paket podrške za ploču (BSP). Ovo je super-povjerljivi paket vlasničkih komponenti, koji proizvođač čipseta isporučuje OEM-u. BSP sadrži potreban izvorni kod koji OEM-ima omogućuje izgradnju Androida i potrebne upravljačke programe za njihov uređaj.
Ovdje je vrijedno napomenuti da OEM-i poput Qualcomma ne vjeruju nužno u potpunosti svojim OEM partnerima -- BSP je dostupan na temelju "treba znati". Proizvođači originalne opreme obično nemaju pristup izvornom kodu za neke od super-tajnih dijelova uređaja (kao što je softver koji radi na osnovnom pojasu). Zatvaranje ovog dijela sigurno također ima potencijalne probleme, kao što pokazuje blizu obilan i ponavljajući ASN.1 raščlanjivanje ranjivosti.
BSP sadrži upravljačke programe i slojeve apstrakcije hardvera (HAL) koji su potrebni da bi se Android pokrenuo na vašem uređaju. AOSP sadrži skup HAL-ova koji djeluju kao definicije o tome što operativni sustav očekuje da vaši upravljački programi implementiraju. Da upotrijebimo smiješno previše pojednostavljen (i izmišljen, u svrhu demonstracije) primjer, zamislimo svjetiljku na vašem telefonu.
Primjer HAL-a - Vaša svjetiljka
Zamislimo da vaš uređaj ima svjetiljku na stražnjoj strani (ako imate Nexus 7 2013, morat ćete malo više zamišljati nego svi drugi -- oprostite!). Ovo kontrolira vozač. Za naš ludo jednostavan primjer, pretpostavimo da v1 HAL kaže da trebate imati jednu funkciju pod nazivom "setLED" koja uzima jedan parametar, stanje svjetla. To je booleov - istinit ili lažan. U C-u bi to izgledalo otprilike ovako:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Ova je funkcija definirana unutar BSP izvornog koda. BSP zatim kompilira OEM tijekom izgradnje ROM-a, i to postaje jedna od vlasničkih ".so" biblioteka na particiji dobavljača ili području vašeg uređaja. To OEM-u omogućuje da određene dijelove rada svog uređaja drži u tajnosti. Za sada, pretpostavimo da žele spriječiti da svi vide kako pale i gase LED.
Sada zamislite da Google izda ažuriranu verziju svojih HAL-ova u budućoj verziji Androida. Sada odlučuju da bi bilo lijepo dopustiti vam da ažurirate svjetlinu svoje LED diode, umjesto da je samo palite ili gasite. Možda je ovo za adaptive flash, ili je možda samo za prisiljavanje HAL ažuriranja i održavanje proizvođača čipseta u poslu? Dopustit ćemo vama, čitatelju, da sami donesete mišljenje o tome. Neka ažuriranja HAL-a imaju jasne prednosti (kao što je novi HAL kamere koji izlaže neobrađeno snimanje i slično), dok su druga nešto manje jasne svrhe.
S ovim novim (izmišljenim) HAL-om za svjetlinu, pretpostavimo da Google kaže da morate ponovno izložiti funkciju pod nazivom setLED, ali ovaj put s cijelim brojem proslijeđenim za svjetlinu. Sada, 0 bi ga isključio, a 255 bi ga stavio na puno.
Ako ste OEM, možete uzeti svoj supertajni kod za uključivanje tog LED-a i staviti ga u ovu novu funkciju. Možete čak koristiti modulaciju širine pulsa za podešavanje svjetline LED-a na temelju broja. Promijenite funkciju da sada izgleda ovako:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Pa što? Pa, sada je ova nova verzija Androida nekompatibilna s postojećim "blobovima". Vaš OEM treba koristiti ove nove mrlje, jer Android OS očekuje da vidi novu definiciju funkcije i neće "pronaći" staru kada traži način da postavi LED.
U ovom trenutku, uzmimo kratku pauzu da pogledamo kako se ovdje snalaze prilagođeni ROM-ovi (izgrađeni iz izvora). To je ono što će oštroumni među vama upravo sada vikati na svoj ekran - na kraju krajeva, mi smo XDA, dom HTC HD2, najdugovječniji telefon na svijetu... (samo za zapisnik, ludi genijalci tamo trče Android 6.0 na HD2 ovih dana! Nije loše za telefon koji je izvorno isporučen s Windows Mobile 6.5 2009.)
Ovdje se koriste različiti pristupi - ponekad programeri hakiraju unutar ROM-a i govore OS-u da koristi stare definicije funkcija. To je malo neuredno i zahtijeva mnogo promjena za održavanje. Drugi pristup je "shim" OEM binarne datoteke.
Pristup "shim" je da sami napišete i izgradite malu novu biblioteku koja sadrži očekivanu definiciju funkcije - za naš primjer, podržali bismo cijeli broj za svjetlinu. Zatim, unutar podloške, ovo se prevodi kako bi zadovoljilo zahtjeve starog HAL-a. Dakle, za naš primjer, možda bismo rekli da će bilo koja zahtijevana svjetlina iznad 128 uključiti LED, a sve ispod toga će je isključiti. Ili možete reći da će ga uključiti sve što nije nula. To ovisi o programeru. Sastavljaju shim i dobivaju Android da ga koristi umjesto izvornog. Podloška tada poziva OEM blob.
Brzo `adb push` i ponovno pokretanje trebali bi pokrenuti podlošku i omogućiti vam da upravljate svojim izmišljenim LED-om, iako imate samo stari HAL.
Problem je u tome što je ovo očito nesavršen proces. Sada ćete imati mane - ovaj uređaj će imati prilično jadnu bljeskalicu, koja je ili potpuno uključena ili potpuno isključena. To nije idealno - OS misli da stvara vrlo nježno svjetlo, ali stvarnom LED-u je rečeno da se natječe u natjecanju umjetnog sunca i pokušava vas zaslijepiti. Ali hej, život nije savršen, a sada imate radni LED na svom starom telefonu!
(Da, ovo je jedan od razloga zašto postoje nedoumice i greške kada XDA korisnici i programeri upravljaju svojim ludim i suludim pothvatima portiranja. Mislim, dovraga, Galaxy S II toting je naizgled upotrebljiv Android 6.0 ROM sada. Mnogi telefoni izdani prošle godine još uvijek nemaju 6.0!)
Vratimo se na perspektivu OEM-a. Nažalost, većina OEM-a već radi barem 1 telefon ispred onoga na čemu smo mi sada. Njihov fokus je na sljedećem telefonu koji će prodati - ne možete ih zapravo kriviti jer zarađuju samo na uređajima koje prodaju. Oni ne zarađuju novac od uređaja koje su prodali prije godinu ili dvije, tako da moraju stalno izdavati nove uređaje da bi postojali. Ovo je jedan od razloga zašto su HTC i Blackberry u problemima - nije važno koliko rukovoditelja čvrsto drži svoj stari Blackberry Curve, jer ondje ne dobivaju nove uređaje u prodaji.
Ako OEM ne dobije BSP, neće se spustiti na XDA pristup zajedničkog hakiranja izgradnje. Zašto? Dobro, moraju podržati ovaj firmware za svoje klijente. Ako izdaju firmware koji napola radi, korisnici će ih mrziti, buncati i buncati, a njihove linije podrške zvonit će danima.
OEM proizvođači također se moraju boriti s prijevoznicima, barem na izvaneuropskim tržištima. Prijevoznici ne žele da korisnici imaju problema s ažuriranjem softvera. Zapravo, operateri često radije ne bi izdavali ažuriranja softvera.
Da biste ovo razumjeli, zamislite svoju pratetu Alice. Ona je ta koja vas zove telefonom u nezgodno doba dana i traži pomoć oko "one računalne stvari". Zatim opisujete kako kliknuti na "izbornik Start" i morate ga identificirati kao "veliku zastavu u donjem lijevom kutu" i nailazite na zbunjenost. Oko 45 minuta (i mnogo frustracije) kasnije, pokazalo se da je teta Alice povukla svoj početni izbornik na desni rub zaslona i jednostavno ga je morala povući natrag. Da, lijevom tipkom miša!
Sada zamislite da imate tisuću tete Alice'. Svi oni zovu vašu korisničku podršku, ne mogu pronaći Candy Crush na svom telefonu, zabrinuti da ju je haker izbrisao s njihovog telefona. Oh, i ikone sada izgledaju malo drugačije - možda je haker još uvijek u njihovom telefonu?
Da, ovo je zamišljeno kao malo bezbrižnog humora, ali dok ne iskusite razloge zbog kojih će ljudi zvati svog operatera za podršku, nećete vjerovati kakve probleme imaju. Ažuriranje softvera koje mijenja način na koji telefon radi ili gdje se stvari nalaze, uzrokovat će značajne troškove podrške. U najmanju ruku, zahtijeva ponovnu obuku osoblja za podršku (jer većina njih, nažalost, nisu vaši strastveni čitači XDA).
Nakon što OEM dobije BSP, prenijet će svoj ROM i primijeniti sve svoje promjene na ROM. Nagomilat će svoj bloatware i dodati užasan skin kao iz crtića koji bi više izgledao kao kod kuće u animeu za tinejdžere. Onda će ga testirati.
Puno.
Postoje razne vrste zahtjeva koje vaš telefon mora zadovoljiti. Mobilne mreže dizajnirane su tako da vjeruju da će se korisnička oprema (ono što zovemo telefon) ispravno ponašati. To znači da je potrebno mnogo testiranja da bi se uređaj odobrio. Ažuriranja softvera riskiraju promjenu ponašanja, pa stvari treba ponovno testirati. Zbog toga ćete obično vidjeti informacije o nadolazećim Sonyjevim ažuriranjima softvera od vanjskih usluga testiranja, koje potvrđuju da je firmver usklađen sa zahtjevima testiranja.
Sada... što se događa nakon ažuriranja ili dva (ili u nekim slučajevima, nijedno)? Proizvođač SoC-a neće OEM-u dati ažurirani BSP. Na kraju krajeva, proizvođač SoC-a ovim neće puno dobiti. OEM više ne zarađuje na vašem telefonu otkako je prodan. I u ovom trenutku vaš telefon više ne dobiva značajna ažuriranja verzije.
Smanjenje broja BSP-ova koje OEM želi isporučiti izvrstan je način da uštedite novac - ako vam je potreban samo trenutni i ne namjeravate isporučiti veću verziju povećava, to će uštedjeti novac na početnoj kupnji SoC-a i licenciranju, ali nauštrb nekoliko ljutih štrebera na XDA-u koji će se pitati zašto nisu dobili Ažuriraj.
Ažuriranja su složena. Mnogo je različitih ljudi uključeno u lanac. Ništa od ovoga ne opravdava proizvođače originalne opreme od trenutnog beznačajnog i jadnog stanja ažuriranja na Androidu. Unatoč tome, ovdje postoje neki pravi izazovi.
Mnogi proizvođači originalne opreme krivi su za previše obećanja, a neizbježno nedovoljno isporučivanje koje sada povezujemo. Tužna je stvarnost da su za većinu OEM-ova ažuriranja softvera samo smetnja bez koje bi mogli.
Mobilni sektor uglavnom je zapeo u razmišljanju o telefonima s značajkama. To jest, gdje uređaj nikada ne dobiva ažuriranja. Testirajte jednom, pošaljite i nikada se ne osvrćite. Sa sigurnosnim problemima modernih pametnih telefona i čistom složenošću pokretanja punog operativnog sustava opće namjene, sa stotinama vanjskih biblioteka, to više nije opcija. Ili barem to ne bi trebalo biti. Google je poduzeo neke korake kako bi to popravio, barem objavljivanjem sigurnosnih biltena i zakrpa za postojeća izdanja Androida (sjetite se da je donedavno jedini način za dobivanje sigurnosnih ažuriranja bio putem nove glavne verzije OS-a Android!)
Nažalost, to zapravo nije dovoljno. Iako Google neprestano objavljuje ažuriranja, sigurnost vašeg uređaja još uvijek ovisi o proizvođaču SoC-a - budući da su proizvođači SoC-a toliko skamenjeni netko otkrije kako uključuje nekoliko LED dioda ili proizvodi zvuk kroz zvučnik, šalje ogromne količine binarnih mrljica na svoje uređaja. Ove mrlje sadrže prilično užasno nesiguran kod (samo pogledajte prethodne Googleove biltene o sigurnosti ako mislite da je ovo pretjerivanje!) i treba ih ažurirati. Što znači da su potrebni ažurirani BSP-ovi.
Stolna računala (a time i prijenosna računala) po svojoj su arhitekturi potpuno drugačija od mobilnih uređaja. Vaš mobilni telefon ili tablet zapravo je uvelike vlasnički komad silicija, dizajniran u žurbi od strane nekih ljudi koji misle dobro, ali nemaju ni blizu dovoljno vremena da naprave nešto dobro. Tržište se kreće tako brzo da jedva uspijevaju pratiti tempo kojim marketing zahtijeva lansiranje novih proizvoda.
To znači da se koriste prečaci - nećete naći da vaš telefon podržava glavni Linux kernel i vidjet ćete da svaki telefon ima drugačiji način pokretanja. Međutim, na prijenosnom ili stolnom računalu proizvođači su se odlučili za neke standardne načine pokretanja - prije je to bio MBR (master boot record) s BIOS-om, a sada je to UEFI. Ova standardizacija omogućuje pokretanje istog softvera na svakom uređaju.
Iako je nedavno učinjeno nekoliko koraka prema tome, posebno sa Sonyjevim programom za širenje javnosti i njihovim unificirana jezgra, nije praktično pokretati glavnu jezgru na većini telefona, zbog ogromnog broja novih hakova specifičnih za dobavljače koji su uvedeni na svaki uređaj.
Pogrešno spojili priključak za slušalice? Samo hakirajte upravljačke programe! Nema vremena da se to popravi u proizvodnom dizajnu.
Je li proizvodni tim montirao modul kamere naopako u proizvodnoj seriji 1? Baci hakiranje da provjeriš interni kod verzije i okreni video ako je verzija 1!
Ovakvi hakovi rješavaju trenutni problem, ali samo skidaju s površine čudne promjene specifične za proizvod koje se događaju. Dovraga, čak ponekad postoje potpuno različiti čipovi u različitim revizijama istog telefona, zbog komercijalnih odluka. To je dovelo do hakiranja upravljačkih programa i čudnih odluka koje su imale smisla samo u to vrijeme, kako bi telefon radio kako bi se mogao isporučiti sljedeći tjedan.
Iako je u tijeku rad na glavnoj podršci za 64-bitne ARM čipove za pokretanje pomoću UEFI-ja, do sada je nema jasnog pomaka prema standardiziranijem načinu pokretanja ARM uređaja. I to je tužno, jer to znači da će se telefoni i dalje izbacivati mnogo prije kraja radnog vijeka, jer je jednostavno preskupo održavati tehnički dug i teret na njima softver.
S druge strane, ako će OEM zarađivati samo na prodaji uređaja, ne moraju li osigurati da ljudi nastave kupovati nove telefone? Bi li tržište osobnih računala prešlo na ovaj model da već nema 30 godina zamaha i naslijeđenog softvera koji koristi otvorenu PC platformu i standard?
Ovo je teško pitanje bez znanja iz Qualcomma, koje nažalost trenutno nemamo. Međutim, možemo izvući neke informacije iz 7.0 Android driver API-ja i CTS zahtjeva. Zahtjevi CTS-a navode što Google očekuje od uređaja koji koristi određeni firmware. "Veliki čekić" korišten za provedbu ovih zahtjeva je Googleovo licenciranje za korištenje njihovog vlasničkog paketa Google Play Services - ako se ne pridržavate, ne možete slati Google Apps na uređaj. Dok, za neke, ovo može se smatrati prednošću, to očito nije ono što korisnici žele i očekuju od uređaja.
Android 7.0 nije dodao puno promjena u HAL-u ili upravljačkim programima (kao što je gore opisano), tako da bilo kakva nekompatibilnost vjerojatno ne dolazi upravo odatle. Međutim, vjerojatnije je da će predstavljati problem uvođenje a novi zahtjev za Vulkan graphics API ili GLES 3.1, biti dostupan kako bi prošao CTS.
Trenutačno mnogi sustavi na čipu (SoC) nemaju podršku za Vulkan na svojim grafičkim procesorima, uključujući MSM8974. Tu će se najvjerojatnije pojaviti i problem kompatibilnosti s Androidom 7.0. Ipak, opet, bez znanja iznutra iz Qualcomma i njihovih planova za budućnost, teško nam je dati konačnu izjavu, a da je ne kvalificiramo. Međutim, u ovom trenutku vjerujemo da je vjerojatno da je ovo "jednostavni" slučaj Qualcommovog prekida podrške za (u njihovim očima) zastarjeli MSM8974 čipset, i ne pruža BSP (paket podrške za ploču) za 7.0 na toj platformi. Da je to bio slučaj, to bi značilo da proizvođači originalne opreme gotovo sigurno neće isporučiti 7.0 na uređaju - morali bi nekako pronaći podršku za Vulkan ili GLE 3.1 za svoj GPU i GPU izvor kod je jedan od smiješno strogo čuvanih dijelova mobilnih skupova (bez pravog razloga, dodali bismo - pogledajte AMD, otvoreni izvor vlastitog AMDGPU upravljačkog programa na radnoj površini za Linux). Međutim, nažalost, Vulkan i ubrzana (GLES) grafika općenito su malo složeniji od jednostavnog LED-a, tako da ovo nije nešto za što ćemo vidjeti podloške za uvođenje kompatibilnosti.
Budući da 7.0 nije dugo izlazio, postoji stvarna mogućnost da ostali čipseti (osim malog broja unutar samog AOSP-a) ostanu zaostaju na 6.0, ili zbog problema s hardverom i upravljačkim programom (tj. bez ažuriranog BSP-a) ili zbog nedostatka podrške dobavljača SoC-a u vezi s Vulkanom ili GLES-om 3.1 API. Trenutačno ni Snapdragon 800 ni 801 ne podržavaju jedno od toga.
Najbolje je promatrati ovaj prostor - programeri na XDA već dobro napreduju s neslužbenim portovima na 7.0 za mnoge uređaje koji ne dobivaju službenu podršku za 7.0 od Googlea. Međutim, oni nemaju podršku za Vulkan ili GLES 3.1 - možda će to početi razvijači igara na Androidu doživjeti frustraciju zbog fragmentacije ako dovoljno korisnika počne pokretati prilagođene ROM-ove bez Vulkana ili GLES 3.1 podrška?
Apple podržava svoju iPhone liniju na najnovijoj verziji iOS-a već oko 5 godina - iPhone 4s lansiran je u listopadu 2011. i ažuriran je do iOS-a 9. Međutim, neće primiti nadolazeće ažuriranje za iOS 10, što bi telefonu dalo efektivni životni vijek od 5 godina, pod pretpostavkom da iOS 10 bude lansiran oko listopada. Vrijedno je napomenuti da Apple ne podržava uvijek back-port grafički API podršku - iPhone 4s i iPhone 5 nemaju imaju Appleov Metal graphics API, što je donekle sličan scenariju viđenom s Androidom u Vulkan. Jedina razlika je u tome što je Apple nastavio podržavati starije uređaje bez novog grafičkog API-ja.
Što misliš? Hoćete li fleširati prilagođeni ROM na svom telefonu da mu produžite životni vijek? Jeste li rekli u komentarima ispod.