Šajā rakstā mēs izpētām patiesību par to, kāpēc Snapdragon 801 ierīces nesaņem Android Nougat. No mikroshēmojumu ražotājiem līdz pārdevējiem ir daudz problēmu!
Atjaunināts, lai atspoguļotu vai nu-or Vulkan vai OpenGL ES 3.1 prasību operētājsistēmai Android 7.0
Pēdējā laikā ir rakstīts daudz rakstu par versiju atjauninājumiem, mijiedarbību starp pārdevēju un mikroshēmojumu veidotāju un to, ko tas nozīmē turpmākajām ierīcēm. Kāpēc šonedēļ tas ir palielinājies?
Šonedēļ atklājās, ka cienījamais Nexus 5 nesaņems Android 7.0 (Nougat) atjauninājumu, un Qualcomm paziņoja, ka tas nesaņems. nodrošina atbalstu MSM8974 (plašāk pazīstams kā Snapdragon 801) versijā 7.0. Šis raksts tika uzrakstīts sadarbībā ar XDA Recognized Izstrādātājs kamene.
Tēma ir izraisījusi lielu interesi no dažādām ziņu vietnēm, bet daudzi palaiž garām smalkās nianses, kas patiesībā notiek aizkulisēss. Šajā rakstā tiks paskaidrots, kā darbojas programmatūras atjauninājumi, izmantojot mūsu pieredzi darbā ar oriģinālo iekārtu ražotājiem, veicot oficiālos programmaparatūras atjauninājumus. Mēs izskaidrosim, kas notiek aizkulisēs (un kāpēc) un kāpēc jūs, iespējams, neiegūsit jaunāko programmatūru savā tālrunī.
Pirmais solis Android programmaparatūras atjauninājuma dzīvē ir augšupējais atjauninājums. Tas ir tas, ar ko Google strādā iekšēji. Atšķirībā no "atvērtajām darbplūsmām", Android tiek izstrādāta, izmantojot slēgtu darbplūsmu, un avota kods tiek izmests pāri sienai katru gadu, kad tiek izdots jauns laidiens. Sākotnēji Google teica, ka tas ir paredzēts, lai novērstu sadrumstalotību, ko izraisa cilvēki, kuri izmanto jaunākās versijas lai gan sākumā lietas strauji attīstījās, taču šķiet, ka viņi ir saglabājuši šo politiku vieta.
Kādā brīdī, parasti pirms publiska paziņojuma par atjauninājumu (lai gan, nesen ieviešot publiskās beta versijas, šie laika grafiki mainās), OEM tiks informēti par gaidāmo atjauninājumu. Pēc tam viņi saņems avota kodu otrajā brīdī galīgajam atjauninājumam (agrāk tas bija dažreiz nedaudz pirms palaišanas, lai gan mēs zinām arī gadījumus, kad nav agra atbrīvošana).
Augšupējās AOSP krātuvēs ir ierīču atbalsts tikai ierobežotam ierīču skaitam. Parasti tās ir jūsu Nexus ierīces. Tomēr iemeslu dēļ, kas kļūs skaidrs drīzumā, ir svarīgi atzīmēt, ka uzņēmumam Google nav pilnīgas aparatūras kontroles pār šīm ierīcēm; ierīces ražo OEM, un šis OEM iegādāsies System-on-Chip (SoC) no mikroshēmojumu ražotāja.
Kad pirmkods ir izlaists, oriģinālā aprīkojuma ražotāja programmaparatūras komanda (figurālā nozīmē) sēdēs un pieliks kājas. Galvenajam Android avota kokam nav aparatūras atbalsta neskaitāmām mikroshēmām, ko izmanto piegādes ierīcēs. Jūsu Qualcomm mikroshēmojums, visticamāk, netiek atbalstīts, piemēram, AOSP. Jūsu Exynos noteikti nav. Mediatek vai HiSilicon? Aizmirsti!
BSP satur draiverus un aparatūras abstrakcijas slāņus (HAL), kas nepieciešami Android palaišanai
Tagad ir nepieciešams a Valdes atbalsta pakotne (BSP). Šī ir īpaši konfidenciāla patentētu komponentu pakotne, ko mikroshēmojumu ražotājs piegādā oriģinālā aprīkojuma ražotājam. BSP satur nepieciešamo avota kodu, lai ļautu oriģinālo iekārtu ražotājiem izveidot Android un nepieciešamos draiverus savai ierīcei.
Šeit ir vērts atzīmēt, ka oriģinālo iekārtu ražotāji, piemēram, Qualcomm, ne vienmēr pilnībā uzticas saviem OEM partneriem — BSP ir pieejams, pamatojoties uz nepieciešamību zināt. OEM parasti nevar piekļūt avota kodam dažām īpaši slepenām ierīces daļām (piemēram, programmatūrai, kas darbojas pamata joslā). Šīs daļas slēgšanai noteikti ir arī potenciālas problēmas, kā liecina tuvākais bagātīgs un atkārtojas ASN.1 ievainojamību parsēšana.
BSP satur draiverus un aparatūras abstrakcijas slāņus (HAL), kas nepieciešami, lai jūsu ierīcē darbotos Android. AOSP satur HAL kopu, kas darbojas kā definīcijas tam, ko operētājsistēma sagaida, lai jūsu draiveri ieviestu. Lai izmantotu smieklīgi pārāk vienkāršotu (un demonstrācijas nolūkos izdomātu) piemēru, iedomāsimies jūsu tālruņa lukturīti.
HAL piemērs — jūsu lukturītis
Iedomāsimies, ka jūsu ierīces aizmugurē ir zibspuldze (ja jums ir Nexus 7 2013, jums būs jāpieliek vairāk iztēles nekā citiem — atvainojiet!). To kontrolē vadītājs. Mūsu traki vienkāršajam piemēram pieņemsim, ka v1 HAL saka, ka jums vajadzētu būt vienai funkcijai ar nosaukumu "setLED", kas ņem vienu parametru, gaismas stāvokli. Tā ir Būla vērtība — patiesa vai nepatiesa. C valodā tas izskatītos apmēram šādi:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Šī funkcija ir definēta BSP pirmkodā. Pēc tam ROM izveides laikā OEM apkopo BSP, un tā kļūst par vienu no patentētajām ".so" bibliotēkām jūsu ierīces pārdevēja nodalījumā vai apgabalā. Tas ļauj oriģinālo iekārtu ražotājiem paturēt slepenībā noteiktas savas ierīces darbības daļas. Pagaidām pieņemsim, ka viņi vēlas neļaut visiem redzēt, kā viņi ieslēdz un izslēdz šo LED.
Tagad iedomājieties, ka Google nākamajā Android versijā izlaiž atjauninātu savu HAL versiju. Viņi tagad nolemj, ka būtu jauki ļaut jums atjaunināt LED spilgtumu, nevis vienkārši to ieslēgt vai izslēgt. Varbūt tas ir paredzēts adaptīvajai zibspuldzei, vai varbūt tas ir vienkārši, lai piespiestu HAL atjauninājumu un saglabātu mikroshēmojumu veidotājus biznesā? Mēs ļausim jums, lasītāj, izteikt savu viedokli par to. Dažiem HAL atjauninājumiem ir skaidras priekšrocības (piemēram, jaunajai kamerai HAL, kas atklāj neapstrādātu fotografēšanu un tamlīdzīgi), savukārt citiem ir mazāk skaidrs mērķis.
Izmantojot šo jauno (izdomāto) HAL spilgtuma noteikšanai, pieņemsim, ka Google saka, ka jums atkal ir jāatspoguļo funkcija, ko sauc par setLED, taču šoreiz ar spilgtumu tiek nodots vesels skaitlis. Tagad 0 to izslēgtu, bet 255 ieslēgtu pilnībā.
Ja esat oriģinālā aprīkojuma ražotājs, varat paņemt savu īpaši slepeno kodu, lai ieslēgtu šo LED, un ievietot to šajā jaunajā funkcijā. Jūs pat varat izmantot impulsa platuma modulāciju, lai pielāgotu gaismas diodes spilgtumu, pamatojoties uz skaitli. Jūs maināt funkciju, lai tā tagad izskatītos šādi:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Nu ko? Nu, tagad šī jaunā Android versija nav saderīga ar esošajiem "blobiem". Jūsu oriģinālā aprīkojuma ražotājiem ir jāizmanto šie jaunie bloki, jo Android OS sagaida, ka tiks parādīta jaunā funkcijas definīcija, un tā "neatradīs" veco, kad tā meklēs veidu, kā iestatīt LED.
Šajā brīdī veiksim īsu pārtraukumu, lai apskatītu, kā šeit darbojas pielāgotie ROM (izveidoti no avota). Tas ir tas, ko gudrie jūsu vidū tagad kliegs pie jūsu ekrāna — galu galā mēs esam XDA, HTC HD2, visilgāk kalpojošais tālrunis pasaulē... (tikai zināšanai, trakie ģēniji tur skrien Mūsdienās Android 6.0 HD2! Nav slikti tālrunim, kas sākotnēji tika piegādāts ar Windows Mobile 6.5 2009. gadā)
Šeit tiek izmantotas dažādas pieejas — dažreiz izstrādātāji uzlaužas ROM un liek OS izmantot vecās funkciju definīcijas. Tas ir nedaudz netīrs, un tajā ir jāveic daudzas izmaiņas. Otra pieeja ir OEM bināro datu "aizveidošana".
"Shim" pieeja ir pašam uzrakstīt un izveidot mazu jaunu bibliotēku, kurā ir paredzēta funkcijas definīcija — mūsu piemēram, mēs atbalstītu spilgtumu veselu skaitli. Pēc tam starplikas ietvaros tas tiek pārtulkots, lai atbilstu vecās HAL prasībām. Tātad mūsu piemērā mēs varētu teikt, ka jebkurš pieprasītais spilgtums virs 128 ieslēgs LED, un viss, kas ir zemāks, to izslēgs. Vai arī jūs varat teikt jebko, kas nav nulle, to ieslēgs. Tas ir izstrādātāja ziņā. Viņi sastāda starplikas un liek Android to izmantot sākotnējās versijas vietā. Pēc tam shim izsauc OEM lāse.
Ātrai "adb push" un atsāknēšanai vajadzētu iedarbināt starplikas un vadīt savu izdomāto LED, lai gan jums ir tikai vecais HAL.
Problēma ir tā, ka tas acīmredzami ir nepilnīgs process. Tagad jūs iegūsit dīvainības — šai ierīcei būs diezgan traka zibspuldze, kas ir vai nu pilnībā ieslēgta, vai pilnībā izslēgta. Tas nav ideāli — operētājsistēma domā, ka tā rada ļoti maigu gaismu, bet faktiskajam LED tiek paziņots, ka tā sacenšas mākslīgās saules konkursā, un mēģina jūs padarīt aklu. Bet, hei, dzīve nav ideāla, un tagad jūsu vecajā tālrunī ir darba gaismas diode!
(Jā, tas ir viens no iemesliem, kāpēc pastāv dīvainības un kļūdas, kad XDA lietotāji un izstrādātāji pārvalda savus trakos un neprātīgos pārnešanas spējas. Es domāju, heck, the Galaxy S II ir toting šķietami lietojams Android 6.0 ROM tagad. Daudziem pagājušajā gadā izlaistajiem tālruņiem joprojām nav 6.0!)
Atgriezīsimies pie OEM perspektīvas. Diemžēl lielākā daļa oriģinālo iekārtu ražotāju jau strādā vismaz par vienu tālruni pirms pašreizējās darbības. Viņu uzmanības centrā ir nākamais tālrunis, ko viņi gatavojas pārdot – jūs nevarat viņus vainot, jo viņi pelna tikai no pārdotajām ierīcēm. Viņi nepelna no ierīcēm, ko pārdeva pirms gada vai diviem, tāpēc viņiem ir jāturpina izlaist jaunas ierīces, lai tās pastāvētu. Tas ir viens no iemesliem, kāpēc HTC un Blackberry ir nonākušas grūtībās — nav nozīmes tam, cik daudz vadītāju saglabā savu veco Blackberry Curve, jo viņi tur nesaņem jaunu ierīču izpārdošanu.
Ja oriģinālā aprīkojuma ražotāji nesaņems BSP, viņi nedomā par XDA pieeju, veidojot kopīgu uzlaušanu. Kāpēc? Nu viņiem ir jāatbalsta šī programmaparatūra saviem klientiem. Ja viņi izlaidīs daļēji nestrādājošu programmaparatūru, lietotāji viņus ienīdīs, ārdīsies un trakos, un viņu atbalsta līnijas zvanīs dienām ilgi.
OEM ir jācīnās arī ar pārvadātājiem, vismaz tirgos ārpus Eiropas. Pārvadātāji nevēlas, lai klientiem būtu problēmas ar programmatūras atjauninājumiem. Faktiski pārvadātāji bieži nevēlas izlaist programmatūras atjauninājumus.
Lai to saprastu, iedomājieties savu lielo tanti Alisi. Viņa ir tā, kas jums zvana neērtā diennakts laikā, lai lūgtu palīdzību saistībā ar "to datoru lietu". Pēc tam jūs aprakstāt, kā noklikšķināt uz izvēlnes "Sākt", un tas ir jāidentificē kā "lielais karogs apakšējā kreisajā stūrī", un jūs saskaraties ar neizpratni. Pēc aptuveni 45 minūtēm (un ar lielu vilšanos) atklājas, ka tante Alise ir vilkusi savu sākuma izvēlni uz ekrāna labo malu un vienkārši vajadzēja to vilkt atpakaļ. Jā, ar peles kreiso pogu!
Tagad iedomājieties, ka jums ir tūkstotis tante Alise. Viņi visi zvana jūsu klientu atbalsta dienestam, nevarot atrast Candy Crush savā tālrunī, un uztraucas, ka hakeris to izdzēsis no viņu tālruņa. Ak, un ikonas tagad izskatās nedaudz savādāk - varbūt hakeris joprojām ir viņu tālrunī?
Jā, tas ir domāts kā viegls humors, taču, kamēr jūs nejutīsit iemeslus, kāpēc cilvēki zvanīs savam operatoram, lai saņemtu atbalstu, jūs neticēsit viņu problēmām. Programmatūras atjauninājums, kas maina tālruņa darbību vai atrašanās vietu, radīs ievērojamu atbalsta izmaksu. Tas prasa vismaz atbalsta personāla atkārtotu apmācību (jo vairums no viņiem diemžēl nav jūsu kaislīgi XDA lasītāji).
Kad oriģinālā aprīkojuma ražotājs saņems BSP, tas pārslēgs savu ROM un piemēros visas veiktās izmaiņas ROM. Viņi sakrauj savus blēdīgos izstrādājumus un pievienos šausminošu multfilmai līdzīgu apvalku, kas pusaudžu animē izskatītos kā mājās. Tad viņi to pārbaudīs.
Daudz.
Ir visas prasības, kurām jūsu tālrunim ir jāatbilst. Mobilie tīkli ir izstrādāti, lai uzticētos lietotāja aprīkojuma (ko mēs saucam par tālruni) pareizai darbībai. Tas nozīmē, ka, lai ierīci apstiprinātu, ir jāveic daudz testu. Programmatūras atjauninājumi var mainīt uzvedību, tāpēc lietas ir jāpārbauda vēlreiz. Tāpēc parasti tiek rādīta informācija par gaidāmajiem Sony programmatūras atjauninājumiem no ārējiem pārbaudes pakalpojumiem, kas apstiprina, ka programmaparatūra atbilst testa prasībām.
Tagad... kas notiek pēc atjaunināšanas vai diviem (vai dažos gadījumos neviena)? SoC ražotājs nesniegs OEM atjauninātu BSP. Galu galā SoC veidotājs no tā neko daudz neiegūs. Kopš tā pārdošanas oriģinālā aprīkojuma ražotājs jūsu tālrunī vairs nepelna. Un šajā brīdī jūsu tālrunis nesaņem vairāk nozīmīgu versiju atjauninājumus.
OEM piegādāto BSP skaita samazināšana ir lielisks veids, kā ietaupīt naudu — ja jums ir nepieciešams tikai pašreizējais un neplānojat piegādāt nevienu galveno versiju. palielinās, tas ietaupīs naudu sākotnējai SoC iegādei un licencēšanai, taču uz dažu dusmīgu XDA lietotāju rēķina, kuri brīnās, kāpēc viņi nesaņēma Atjaunināt.
Atjauninājumi ir sarežģīti. Ķēdē ir iesaistīti daudz dažādu cilvēku. Neviens no tiem neattaisno oriģinālo iekārtu ražotājus no pašreizējā Android atjaunināšanas neveiksmīgā un nožēlojamā stāvokļa. Tomēr šeit ir daži reāli izaicinājumi.
Daudzi oriģinālo iekārtu ražotāji ir vainojami pārlieku daudzsolīšanā, un neizbēgama nepietiekama izpilde, ko mēs tagad saistām. Skumjā realitāte ir tāda, ka lielākajai daļai oriģinālo iekārtu ražotāju programmatūras atjauninājumi ir tikai apgrūtinājums, bez kura viņi varētu iztikt.
Mobilo sakaru nozare lielākoties ir iestrēgusi funkcionalitātes tālruņu domāšanā. Tas ir, ja ierīce nekad nesaņem nekādus atjauninājumus. Izmēģiniet to vienreiz, nosūtiet un nekad neatskatieties. Ņemot vērā mūsdienu viedtālruņu drošības problēmas un pilnīgas vispārējas nozīmes operētājsistēmas ar simtiem ārējo bibliotēku darbināšanas milzīgo sarežģītību, tas vairs nav risinājums. Vai vismaz tā nevajadzētu būt. Google ir veikusi dažus pasākumus, lai to novērstu, vismaz publicējot drošības biļetenus un ielāpus esošajiem laidieniem Android (atcerieties, ka vēl pavisam nesen vienīgais veids, kā iegūt drošības atjauninājumus, bija, izmantojot jaunu lielāko Android OS versiju!)
Diemžēl ar to īsti nepietiek. Lai gan Google turpina izlaist atjauninājumus, jūsu ierīces drošība joprojām ir atkarīga no SoC veidotāja, jo SoC veidotāji ir tik pārakmeņoti. ja kāds atklāj, kā ieslēdz pāris gaismas diodes vai izdod skaņu pa skaļruni, viņš savā ierīcē nosūta milzīgu daudzumu bināro lāsumu. ierīces. Šajos lāsumos ir diezgan šausmīgi nedrošs kods (tikai apskatiet iepriekšējos Google drošības biļetenus, ja uzskatāt, ka tas ir pārspīlēti!), un tie ir jāatjaunina. Tas nozīmē, ka ir nepieciešami atjaunināti BSP.
Galddatori (un pēc tam klēpjdatori) pēc arhitektūras pilnīgi atšķiras no mobilajām ierīcēm. Jūsu mobilais tālrunis vai planšetdators faktiski ir ļoti patentēts silīcija gabals, ko steigā ir izstrādājuši daži cilvēki, kuri domā labi, bet kuriem ne tuvu nav pietiekami daudz laika, lai kaut ko labu izveidotu. Tirgus attīstās tik strauji, ka viņi tik tikko spēj sekot tempam, kādā mārketings pieprasa jaunu produktu izlaišanu.
Tas nozīmē, ka tiek izmantoti saīsnes — jūs neatradīsiet, ka jūsu tālrunis atbalsta galvenais Linux kodols, un katram tālrunim ir atšķirīgs sāknēšanas veids. Tomēr jūsu klēpjdatorā vai galddatorā pārdevēji izvēlējās dažus standarta sāknēšanas veidus — iepriekš tas bija MBR (galvenais sāknēšanas ieraksts) ar BIOS, bet tagad tas ir UEFI. Šī standartizācija ļauj darbināt vienu un to pašu programmatūru katrā ierīcē.
Lai gan pēdējā laikā ir veikti daži soļi šajā virzienā, jo īpaši saistībā ar Sony informatīvo programmu un to vienots kodols, lielākajā daļā tālruņu nav praktiski darbināt galveno kodolu, jo katrā ierīcē ir ieviests liels skaits jaunu piegādātāju specifisku uzlaušanas.
Vai austiņu ligzda ir savienota nepareizi? Vienkārši uzlauziet to draiveros! Nav laika to labot ražošanas dizainā.
Ražošanas komanda ir uzstādījusi kameras moduli otrādi 1. ražošanas sērijā? Iemācieties, lai pārbaudītu iekšējo versijas kodu, un apgrieziet videoklipu, ja tā ir 1. versija!
Šādi hakeri atrisina tūlītēju problēmu, bet tikai nokasa notiekošo dīvaino un produktam specifisko izmaiņu virsmu. Velns, komerciālu lēmumu dēļ viena un tā paša tālruņa dažādās versijās dažreiz ir pat pilnīgi atšķirīgas mikroshēmas. Tas noved pie draiveru uzlaušanas un dīvainiem lēmumiem, kuriem tobrīd bija jēga, lai tālrunis darbotos, lai to varētu nosūtīt nākamajā nedēļā.
Lai gan notiek darbs pie galvenā atbalsta atbalsta 64 bitu ARM mikroshēmām, lai palaistu, izmantojot UEFI, līdz šim ir bijis nav skaidras virzības uz standartizētāku ARM ierīču sāknēšanas veidu. Un tas ir skumji, jo tas nozīmē, ka tālruņus turpinās izmest krietni pirms to darbības beigām darba mūžu, jo vienkārši ir pārāk dārgi uzturēt tehnisko parādu un slogu programmatūra.
No otras puses, ja oriģinālo iekārtu ražotāji pelnīs naudu tikai, pārdodot ierīci, vai viņiem nav jānodrošina, ka cilvēki turpina pirkt jaunus tālruņus? Vai personālo datoru tirgus pārietu uz šo modeli, ja nebūtu 30 gadus ilga impulsa un mantotās programmatūras, kas jau izmantotu atvērto datoru platformu un standartu?
Šis ir grūts jautājums bez Qualcomm iekšējām zināšanām, kuru mums diemžēl pašlaik nav. Tomēr mēs varam iegūt informāciju no 7.0 Android draivera API un CTS prasībām. CTS prasības nosaka, ko Google sagaida no ierīces, kurā darbojas noteikta programmaparatūra. "Lielais āmurs", ko izmanto šo prasību izpildei, ir Google licence izmantot savu patentēto Google Play pakalpojumu komplektu. ja neievērosit, jūs nevarat piegādāt Google Apps ierīcē. Lai gan dažiem šis var uzskatīt par priekšrocību, tas acīmredzami nav tas, ko lietotāji vēlas un sagaida no ierīces.
Operētājsistēma Android 7.0 nav daudz pievienojusi HAL vai draiveru izmaiņu dēļ (kā aprakstīts iepriekš), tāpēc nesaderība, visticamāk, neradīsies tieši no turienes. Tomēr, visticamāk, problēma ir a jauna prasība vai nu Vulkan grafikas API, vai GLES 3.1, jābūt pieejamam, lai nokārtotu CTS.
Pašlaik daudzām sistēmām-Chip (SoC) nav Vulkan atbalsta to grafikas procesorā, tostarp MSM8974. Šeit, visticamāk, arī radīsies problēma par saderību ar Android 7.0. Tomēr bez iekšējām zināšanām no Qualcomm un viņu nākotnes plāniem mums ir grūti sniegt galīgu paziņojumu, to nekvalificējot. Tomēr šobrīd mēs uzskatām, ka tas ir "vienkāršs" gadījums, kad Qualcomm pārtrauc atbalstu (viņu acīs) novecojošais MSM8974 mikroshēmojums un nenodrošina BSP (plates atbalsta pakotni) 7.0 šai platformai. Ja tas tā būtu, tas nozīmētu, ka oriģinālo iekārtu ražotāji būtu gandrīz droši, ka ierīcē nepiegādās 7.0 — viņiem kaut kādā veidā būtu jāatrod Vulkan vai GLEs 3.1 atbalsts savam GPU un GPU avotam. kods ir viena no smieklīgi stingri aizsargātajām mobilo ierīču skursteņu daļām (bez patiesa iemesla mēs piebilstam — skatiet AMD, atvērtā avota avoti savā darbvirsmā izmanto AMDGPU draiveri, lai Linux). Diemžēl Vulkan un paātrinātā (GLES) grafika kopumā ir nedaudz sarežģītāka nekā vienkārša LED, tāpēc mēs neredzēsim starplikas, lai ieviestu saderību.
Tā kā 7.0 nav bijis ilgu laiku, pastāv reāla iespēja, ka citas mikroshēmas (izņemot nelielo skaitu pašā AOSP) tiks atstātas. atpaliek no 6.0 aparatūras un draivera problēmu (t.i., nav atjaunināta BSP) vai SoC pārdevēja atbalsta trūkuma dēļ attiecībā uz Vulkan vai GLES 3.1. API. Pašlaik ne Snapdragon 800, ne 801 neatbalsta nevienu no tiem.
Vislabāk ir skatīties šo vietu - XDA izstrādātāji jau gūst labus panākumus ar neoficiāliem portiem līdz 7.0 daudzām ierīcēm, kas nesaņem oficiālu 7.0 atbalstu no Google. Tomēr tie ir bez Vulkan vai GLES 3.1 atbalsta - iespējams, spēļu izstrādātāji operētājsistēmā Android sāks to darīt piedzīvo neapmierinātību sadrumstalotības dēļ, ja pietiekami daudz lietotāju sāk palaist pielāgotus ROM bez Vulkan vai GLES 3.1 atbalstu?
Apple parasti atbalsta savu iPhone līniju jaunākajā iOS versijā aptuveni 5 gadus — iPhone 4s tika laists klajā 2011. gada oktobrī, un tas ir atjaunināts līdz pat iOS 9. Tomēr tas nesaņems gaidāmo iOS 10 atjauninājumu, kas nodrošinātu tālruņa efektīvu kalpošanas laiku 5 gadus, pieņemot, ka iOS 10 tiks palaists aptuveni oktobrī. Ir vērts atzīmēt, ka Apple ne vienmēr atbalsta grafikas API atpakaļportu — iPhone 4s un iPhone 5 to nedara. ietver Apple metāla grafikas API, kas ir nedaudz līdzīgs scenārijam, kas redzams operētājsistēmā Android Vulkāns. Vienīgā atšķirība ir tā, ka Apple turpināja atbalstīt vecākas ierīces bez jaunās grafikas API.
Ko tu domā? Vai tālrunī mirgosiet pielāgotu ROM, lai pagarinātu tā kalpošanas laiku? Vai jūs sakāt komentāros zemāk.