Tässä artikkelissa tutkimme totuutta siitä, miksi Snapdragon 801 -laitteet eivät saa Android Nougatia. Ongelmia on monia piirisarjan valmistajista myyjiin!
Päivitetty vastaamaan Android 7.0:n joko-tai Vulkan- tai OpenGL ES 3.1 -vaatimusta
Viime aikoina on kirjoitettu paljon artikkeleita versiopäivityksistä, toimittajan ja piirisarjan valmistajan välisestä vuorovaikutuksesta ja siitä, mitä tämä tarkoittaa tuleville laitteille. Miksi tämä on noussut tällä viikolla?
No, tällä viikolla kävi ilmi, että kunnianarvoisa Nexus 5 ei saa päivitystä Android 7.0:aan (Nougat), ja Qualcomm ilmoitti, ettei sitä tule tarjoaa tuen MSM8974:lle (tunnetaan yleisemmin nimellä Snapdragon 801) versiossa 7.0. Tämä artikkeli on kirjoitettu yhteistyössä XDA Recognizedin kanssa Kehittäjä kimalainen.
Aihe on herättänyt melkoisen kiinnostuksen useilta uutissivustoilta, mutta monet jäävät huomaamatta kulissien takana tapahtuvan hienovaraiset vivahteets. Tämä artikkeli selittää hieman enemmän ohjelmistopäivitysten toiminnasta käyttämällä kokemustamme työskentelystä OEM-valmistajien kanssa heidän virallisissa laiteohjelmistopäivityksissä. Selvitämme, mitä kulissien takana tapahtuu (ja miksi) ja miksi et ehkä saa viimeisintä ohjelmistoa puhelimeesi.
Ensimmäinen askel Android-laiteohjelmistopäivityksen elämässä on alkupään päivitys. Tätä Google toimii sisäisesti. Toisin kuin "avoimissa työnkuluissa", Android on kehitetty käyttämällä suljettua työnkulkua, jolloin lähdekoodi heitetään seinän yli joka vuosi, kun uusi julkaisu ilmestyy. Alun perin Google sanoi, että tämän tarkoituksena oli estää ihmisten aiheuttama pirstoutumista käyttävien versioiden leviämiseen vaikka asiat kehittyivät nopeasti alkuaikoina, mutta he näyttävät pitäneen tämän politiikan ennallaan paikka.
Jossain vaiheessa, yleensä ennen julkista päivityksestä ilmoittamista (vaikka julkisten betaversioiden äskettäisen käyttöönoton myötä nämä aikataulut ovat siirtymässä), OEM-valmistajille ilmoitetaan tulevasta päivityksestä. He saavat sitten lähdekoodin toisessa vaiheessa viimeistä päivitystä varten (aiemmin se oli joskus hieman ennen julkaisua, vaikka olemme myös tietoisia tapauksista, joissa ei ole aikaista vapauttaa).
Ylävirran AOSP-varastot sisältävät laitetuen vain rajoitetulle määrälle laitteita. Nämä ovat yleensä Nexus-laitteitasi. Pian selvittävistä syistä on kuitenkin tärkeää huomata, että Googlella ei ole täydellistä laitteisto-hallintaa näihin laitteisiin. laitteet on valmistanut OEM, ja tämä OEM ostaa System-on-Chipin (SoC) piirisarjan valmistajalta.
Kun lähdekoodi on julkaistu, OEM: n laiteohjelmistotiimi (kuvaannollisesti) istuu alas ja nostaa jalkansa. Androidin päälähdepuussa ei ole laitteistotukea lukuisille kuljetuslaitteissa käytetyille piirisarjoille. Qualcomm-piirisarjaasi ei todennäköisesti tueta esimerkiksi AOSP: ssä. Sinun Exynos ei todellakaan ole. Mediatek vai HiSilicon? Unohda!
BSP sisältää ajurit ja laitteiston abstraktiokerrokset (HAL), joita tarvitaan Androidin käynnistämiseen
Nyt tarvitaan a Board Support Package (BSP). Tämä on erittäin luottamuksellinen paketti patentoituja komponentteja, jotka piirisarjan valmistaja toimittaa OEM: lle. BSP sisältää tarvittavan lähdekoodin, jonka avulla OEM-valmistajat voivat rakentaa Androidin ja tarvittavat ohjaimet laitteelleen.
Tässä on syytä huomata, että Qualcommin kaltaiset OEM-valmistajat eivät välttämättä luota täysin OEM-kumppaneihinsa - BSP on saatavilla "tarve tietää" -periaatteella. OEM-valmistajat eivät yleensä pääse käsiksi joidenkin laitteen supersalaisten osien lähdekoodiin (kuten kantataajuudella toimivaan ohjelmistoon). Tämän osan sulkemisella on varmasti myös mahdollisia ongelmia, kuten lähikuva osoittaa runsas ja toistuva ASN.1 jäsentää haavoittuvuuksia.
BSP sisältää ajurit ja laitteiston abstraktiokerrokset (HAL), joita tarvitaan Androidin käynnistämiseen laitteessasi. AOSP sisältää joukon HAL: ita, jotka toimivat määritelminä sille, mitä käyttöjärjestelmä odottaa ohjaimiesi toteuttavan. Jos haluat käyttää naurettavan liian yksinkertaistettua (ja esittelyä varten keksittyä) esimerkkiä, kuvitellaan taskulamppu puhelimessasi.
Esimerkki HAL - taskulamppu
Kuvitellaan, että laitteesi takana on taskulamppu (jos sinulla on Nexus 7 2013, sinun täytyy tehdä vähän enemmän mielikuvitusta kuin kaikkien muiden – anteeksi!). Tätä ohjaa kuljettaja. Hullun yksinkertaisessa esimerkissämme oletetaan, että v1 HAL sanoo, että sinulla pitäisi olla yksi toiminto nimeltä "setLED", joka ottaa yhden parametrin, valon tilan. Se on totuusarvo – totta tai tarua. C: ssä tämä näyttäisi suunnilleen tältä:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Tämä toiminto on määritelty BSP-lähdekoodissa. OEM kääntää sitten BSP: n ROM-levyn rakentamisen aikana, ja tästä tulee yksi omistetuista ".so"-kirjastoista laitteesi toimittajaosiossa tai -alueella. Tämä antaa OEM: n pitää tietyt osat laitteensa toiminnasta salassa. Oletetaan toistaiseksi, että he haluavat estää kaikkia näkemästä, kuinka he kytkevät LEDin päälle ja pois.
Kuvittele nyt, että Google julkaisee päivitetyn version HALeistaan tulevassa Android-versiossa. He päättävät nyt, että olisi mukavaa antaa sinun päivittää LEDin kirkkautta sen sijaan, että laittaisit sen päälle tai pois päältä. Ehkä tämä on mukautuvaa salamaa varten tai ehkä se vain pakottaa HAL-päivitystä ja pitää piirisarjan valmistajat toiminnassa? Annamme sinun, lukijan, muodostaa oman mielipiteesi siitä. Joillakin HAL-päivityksillä on selkeä etu (kuten uusi Camera HAL, joka paljastaa raakakuvauksen ja vastaavat), kun taas toisten tarkoitus on hieman epäselvä.
Tämän uuden (fiktiivisen) kirkkauden HAL: n avulla oletetaan, että Google sanoo, että sinun täytyy jälleen paljastaa setLED-niminen toiminto, mutta tällä kertaa kirkkautta varten on välitetty kokonaisluku. Nyt 0 sammuttaisi sen ja 255 laittaisi sen täyteen.
Jos olet OEM-valmistaja, voit ottaa supersalaisen koodisi sytyttääksesi kyseisen LEDin ja laittaa sen tähän uuteen toimintoon. Voit jopa käyttää pulssinleveysmodulaatiota LED-valon kirkkauden säätämiseen numeron perusteella. Muutat toiminnon näyttämään nyt tältä:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Mitä sitten? No, nyt tämä uusi Android-versio ei ole yhteensopiva olemassa olevien "blobs" kanssa. OEM-valmistajan on käytettävä näitä uusia blobeja, koska Android-käyttöjärjestelmä odottaa näkevänsä uuden funktion määritelmän, eikä "löydä" vanhaa, kun se etsii tapaa asettaa LED.
Otetaan tässä vaiheessa lyhyt tauko tarkastellaksemme kuinka mukautetut ROM-levyt (rakennettu lähteestä) toimivat täällä. Sitä älykkäät teistä huutavat näytöllesi juuri nyt – olemmehan XDA, HTC HD2, maailman pisimpään kestävä puhelin... (Ilmoitukseksi, hullut nerot siellä juoksevat Android 6.0 HD2:ssa nykyään! Ei huono puhelimelle, joka toimitettiin alun perin Windows Mobile 6.5:n kanssa vuonna 2009)
Tässä on käytetty erilaisia lähestymistapoja – joskus kehittäjät hakkeroivat ROM: n sisällä ja käskevät käyttöjärjestelmää käyttämään vanhoja toimintomääritelmiä. Se on vähän sotkuinen ja tekee paljon muutoksia ylläpidettäväksi. Toinen lähestymistapa on "sovittaa" OEM-binääri.
"Shim"-lähestymistapa on kirjoittaa ja rakentaa itse pieni uusi kirjasto, joka sisältää odotetun funktion määritelmän - esimerkiksi meidän pitäisi tukea kokonaislukua kirkkauden suhteen. Sitten välilevyn sisällä tämä käännetään täyttämään vanhan HAL: n vaatimukset. Joten esimerkissämme voisimme sanoa, että mikä tahansa vaadittu kirkkaus yli 128 sytyttää LEDin ja mikä tahansa alle sen sammuttaisi sen. Tai voit sanoa, että mikä tahansa muu kuin nolla käynnistää sen. Se on kehittäjästä kiinni. He kokoavat välilevyn ja saavat Androidin käyttämään sitä alkuperäisen sijasta. Välilevy kutsuu sitten OEM-blobiksi.
Nopea "adb-työntö" ja uudelleenkäynnistys saavat välilevyn toimimaan ja antaa sinun ohjata kuvitteellista LEDiäsi, vaikka sinulla on vain vanha HAL.
Ongelmana on, että tämä on selvästi epätäydellinen prosessi. Saat nyt omituisuuksia – tässä laitteessa on melko surkea salama, joka on joko täysin päällä tai kokonaan pois päältä. Se ei ole ihanteellinen - käyttöjärjestelmä luulee tekevänsä erittäin hellävaraista valoa, mutta todelliselle LEDille kerrotaan, että se kilpailee keinotekoisessa aurinkokilpailussa ja yrittää sokeuttaa sinut. Mutta hei, elämä ei ole täydellistä, ja sinulla on nyt toimiva LED vanhassa puhelimessasi!
(Kyllä, tämä on yksi syy siihen, miksi XDA-käyttäjien ja -kehittäjien omituisia ja järjettömiä siirtotaitojaan hallitsee omituuksia ja virheitä. Tarkoitan helvettiä Galaxy S II kantaa käyttökelpoiselta näyttävää Android 6.0 ROM nyt. Monissa viime vuonna julkaistuissa puhelimissa ei vieläkään ole 6.0!)
Palataanpa takaisin OEM: n näkökulmaan. Valitettavasti useimmat OEM-valmistajat työskentelevät jo vähintään yhden puhelimen verran nykyisestämme. He keskittyvät seuraavaan puhelimeen, jonka he ovat aikeissa myydä – et voi syyttää heitä, koska he tienaavat vain myymillään laitteilla. He eivät ansaitse rahaa laitteista, jotka he myivät vuosi tai kaksi sitten, joten heidän on julkaistava uusia laitteita ollakseen olemassa. Tämä on yksi syy, miksi HTC ja Blackberry ovat vaikeuksissa – sillä ei ole väliä, kuinka moni johtaja säilyttää otteen vanhassa Blackberry Curvessa, koska he eivät saa sieltä uusia laitteita.
Jos OEM ei saa BSP: tä, he eivät aio hylätä XDA-lähestymistapaa, jossa hakkeroidaan yhteen rakenne. Miksi? Hyvin, heidän on tuettava tätä laiteohjelmistoa asiakkailleen. Jos he julkaisevat laiteohjelmiston, joka on puoliksi toimiva, käyttäjät vihaavat heitä, raivoavat ja raivoavat ja pitävät tukilinjansa soimassa päiviä.
OEM-valmistajien on myös taisteltava lentoyhtiöiden kanssa, ainakin Euroopan ulkopuolisilla markkinoilla. Operaattorit eivät halua asiakkaiden olevan ongelmia ohjelmistopäivitysten kanssa. Itse asiassa operaattorit eivät usein halua julkaista ohjelmistopäivityksiä.
Ymmärtääksesi tämän, kuvittele Liisa-tätisi. Hän on se, joka soittaa sinulle epämukavina aikoina pyytääkseen apua "se tietokonejuttu". Sitten kuvailet, kuinka napsautat "Käynnistä-valikkoa", ja sinun on tunnistettava se "isoksi lipuksi vasemmassa alakulmassa", ja kohtaat hämmennyksen. Noin 45 minuuttia (ja paljon turhautumista) myöhemmin käy ilmi, että Alice-täti on vetänyt aloitusvalikkonsa näytön oikeaan reunaan, ja se täytyi vetää takaisin. Kyllä, hiiren vasemmalla painikkeella!
Kuvittele nyt, että sinulla on tuhat Alice-tätiä. He kaikki soittavat asiakastukeesi, eivätkä löydä Candy Crushia puhelimestasi. He ovat huolissaan siitä, että hakkeri poisti sen heidän puhelimeltaan. Ja kuvakkeet näyttävät nyt hieman erilaisilta - ehkä hakkeri on edelleen heidän puhelimessaan?
Kyllä, tämän on tarkoitus olla hieman kevytmielistä huumoria, mutta ennen kuin koet syitä, miksi ihmiset kutsuvat palveluntarjoajaltaan tukea, et usko heidän ongelmiaan. Ohjelmistopäivitys, joka muuttaa puhelimen toimintaa tai missä asiat ovat, aiheuttaa huomattavia tukikustannuksia. Se vaatii vähintään tukihenkilöstön uudelleenkoulutusta (koska useimmat heistä eivät valitettavasti ole innokkaita XDA-lukijoitasi).
Kun OEM-valmistaja saa BSP: n, he siirtävät ROM-muistinsa ja soveltavat kaikki muutokset ROMiin. He kasaavat bloatwarensa ja lisäävät kauhistuttavan sarjakuvamaisen ihon, joka näyttäisi kodikkaammalta teinien animessa. Sitten he testaavat sen.
Paljon.
Puhelimesi on täytettävä kaikenlaiset vaatimukset. Mobiiliverkot on suunniteltu luottamaan käyttäjän laitteiden (jota kutsumme puhelimeksi) käyttäytymiseen oikein. Tämä tarkoittaa, että laitteen hyväksyminen edellyttää paljon testausta. Ohjelmistopäivitykset voivat muuttaa käyttäytymistä, joten asiat on testattava uudelleen. Tästä syystä näet usein tietoja tulevista Sony-ohjelmistopäivityksistä ulkoisista testipalveluista, jotka vahvistavat, että laiteohjelmisto on testivaatimusten mukainen.
Nyt... mitä tapahtuu yhden tai kahden päivityksen jälkeen (tai joissain tapauksissa ei yhtään)? SoC-valmistaja ei anna OEM: lle päivitettyä BSP: tä. Loppujen lopuksi SoC-valmistaja ei saa tästä paljon. OEM ei tienaa enempää rahaa puhelimellasi sen myynnin jälkeen. Ja tässä vaiheessa puhelimesi ei saa enää merkittäviä versiopäivityksiä.
OEM: n toimitettavien BSP-laitteiden määrän vähentäminen on loistava tapa säästää rahaa - jos tarvitset vain nykyisen etkä aio toimittaa mitään isompaa versiota Tämä säästää rahaa alkuperäisessä SoC-ostossa ja lisensoinnissa, mutta muutaman XDA: n vihaisen nörtin kustannuksella, jotka ihmettelevät, miksi he eivät saaneet päivittää.
Päivitykset ovat monimutkaisia. Ketjussa on mukana paljon erilaisia ihmisiä. Mikään näistä ei vapauta alkuperäisiä valmistajia Androidin nykyisestä puutteellisesta ja säälittävästä päivitystilasta. Tässä on kuitenkin joitain todellisia haasteita.
Monet OEM-valmistajat ovat syyllisiä liiallisesta lupaamisesta, ja väistämätön alitoimitus, jonka nyt yhdistämme. Surullinen todellisuus on, että useimmille OEM-valmistajille ohjelmistopäivitykset ovat vain harmia, jota he voisivat tehdä ilman.
Mobiiliala on enimmäkseen jumissa ominaisuuspuhelimien ajattelutavassa. Eli laite ei koskaan saa päivityksiä. Testaa kerran, lähetä se äläkä koskaan katso taaksepäin. Nykyaikaisten älypuhelimien turvallisuusongelmien ja satojen ulkoisten kirjastojen sisältävän täydellisen yleiskäyttöjärjestelmän käytön monimutkaisuuden vuoksi se ei ole enää vaihtoehto. Tai ainakin se ei pitäisi olla. Google on ottanut joitakin askeleita korjatakseen tämän julkaisemalla ainakin tietoturvatiedotteet ja korjaukset olemassa oleville julkaisuille Androidista (muista, että viime aikoihin asti ainoa tapa saada tietoturvapäivityksiä oli uuden suuren Android-käyttöjärjestelmän versio!)
Valitettavasti tämä ei kuitenkaan todellakaan riitä. Vaikka Google julkaisee jatkuvasti päivityksiä, laitteesi tietoturva on edelleen riippuvainen SoC-valmistajasta - koska SoC-valmistajat ovat niin kivettyneitä joku huomaa kuinka he sytyttävät pari LED-valoa tai antavat äänen kaiuttimesta, he lähettävät valtavia määriä binääripaloja laitteet. Nämä blobit sisältävät melko hirvittävän epävarmaa koodia (katso vain Googlen aiempia tietoturvatiedotteita, jos tämä on mielestäsi liioittelua!), ja ne on päivitettävä. Tämä tarkoittaa, että päivitetyt BSP: t vaaditaan.
Pöytätietokoneet (ja laajemmin kannettavat) ovat arkkitehtuuriltaan täysin erilaisia kuin mobiililaitteet. Matkapuhelimesi tai tablettisi on käytännössä vahvasti patentoitu piikimpale, jonka ovat suunnitelleet nopeasti ihmiset, jotka haluavat hyvää, mutta joilla ei ole läheskään tarpeeksi aikaa tehdä jotain hyvää. Markkinat liikkuvat niin nopeasti, että he tuskin pystyvät pysymään tahdissa, jolla markkinointi vaatii uusien tuotteiden lanseerausta.
Tämä tarkoittaa, että pikakuvakkeet otetaan käyttöön - et löydä puhelintasi Linux-ytimen tukeman, ja huomaat, että jokaisella puhelimella on erilainen käynnistystapa. Kannettavan tietokoneen tai pöytätietokoneen toimittajat päätyivät kuitenkin joihinkin tavallisiin käynnistystapoihin - aiemmin se oli MBR (master boot record) BIOSilla ja nyt UEFI. Tämä standardointi mahdollistaa saman ohjelmiston käyttämisen jokaisessa laitteessa.
Vaikka tähän on viime aikoina otettu joitakin askeleita, erityisesti Sonyn tiedotusohjelman ja niiden kanssa yhtenäinen ydin, ei ole käytännöllistä käyttää päälinjan ydintä useimmissa puhelimissa, koska jokaisessa laitteessa on valtava määrä uusia toimittajakohtaisia hakkereita.
Onko kuulokeliitäntä johdettu väärin päin? Hakkeroi se vain ajureihin! Ei ole aikaa korjata sitä tuotantosuunnittelussa.
Valmistustiimi on asentanut kameramoduulin ylösalaisin tuotantoerässä 1? Tarkista sisäinen versiokoodi ja käännä video ympäri, jos se on versio 1!
Tämänkaltaiset hakkerit ratkaisevat välittömän ongelman, mutta raaputtavat vain pintaa meneillään olevista oudoista ja tuotekohtaisista muutoksista. Hitto, joskus saman puhelimen eri versioissa on jopa täysin erilaisia siruja kaupallisten päätösten vuoksi. Nämä johtavat ohjaimien hakkeroimiseen ja outoihin päätöksiin, jotka olivat järkeviä vain tuolloin, saada puhelin toimimaan, jotta se voidaan lähettää ensi viikolla.
Vaikka 64-bittisille ARM-siruille UEFI-käynnistystä varten on meneillään päälinjan tuki, sitä on toistaiseksi ei selkeää liikettä kohti standardoidumpaa tapaa käynnistää ARM-laitteet. Ja se on surullista, koska se tarkoittaa, että puhelimia heitetään edelleen pois hyvissä ajoin ennen niiden loppumista työelämää, koska on yksinkertaisesti liian kallista ylläpitää heidän teknistä velkaa ja taakkaa ohjelmisto.
Toisaalta, jos OEM ansaitsee rahaa vain laitteen myynnistä, eikö heidän tarvitse varmistaa, että ihmiset ostavat edelleen uusia puhelimia? Siirtyisivätkö PC-markkinat tähän malliin, jos siellä ei olisi jo 30 vuoden vauhtia ja vanhoja ohjelmistoja, jotka käyttävät avointa PC-alustaa ja standardia?
Tämä on vaikea kysymys ilman Qualcommin sisäistä tietoa, jota meillä ei valitettavasti tällä hetkellä ole. Voimme kuitenkin saada joitain tietoja 7.0 Android -ohjaimen API- ja CTS-vaatimuksista. CTS-vaatimukset määrittelevät, mitä Google odottaa laitteelta, joka käyttää tiettyä laiteohjelmistoa. "Iso vasara", jota käytetään näiden vaatimusten täytäntöönpanoon, on Googlen lisenssi käyttää Google Play -palvelupakettia - Jos et noudata vaatimuksia, et voi lähettää Google Appsia laitteeseen. Vaikka joillekin tämä voidaan nähdä etuna, tämä ei tietenkään ole sitä, mitä käyttäjät haluavat ja odottavat laitteelta.
Android 7.0 ei ole lisännyt paljon muutoksia HAL: iin tai ohjaimiin (kuten yllä on kuvattu), joten yhteensopimattomuutta ei todennäköisesti tule juuri sieltä. Todennäköisemmin ongelma on kuitenkin a uusi vaatimus joko Vulkan-grafiikkasovellusliittymälle tai GLES 3.1:lle, olla käytettävissä CTS: n läpäisemiseksi.
Tällä hetkellä monilla Systems-on-Chip-järjestelmillä (SoC) ei ole ollut Vulkan-tukea näytönohjaimessaan, mukaan lukien MSM8974. Tässä tulee myös todennäköisesti esiin ongelma yhteensopivuus Android 7.0:n kanssa. Jälleen kerran, ilman Qualcommin sisäpiiritietoa ja heidän tulevaisuuden suunnitelmiaan, meidän on vaikea antaa lopullista lausuntoa ilman ehtoja. Tällä hetkellä uskomme kuitenkin, että tämä on "yksinkertainen" tapaus, jossa Qualcomm lopettaa tuen (heidän silmissään) ikääntyvä MSM8974-piirisarja, eikä BSP: tä (levytukipaketti) ole saatavilla 7.0:lle kyseisellä alustalla. Jos näin olisi, se tarkoittaisi, että OEM-valmistajat eivät melkein varmasti toimittaisi 7.0:aa laitteelle - heidän olisi jotenkin löydettävä Vulkan- tai GLEs 3.1 -tuki GPU: lleen ja GPU-lähteelleen. koodi on yksi naurettavan tiukasti suojatuista mobiilipinojen osista (ilman todellista syytä, lisäisimme - katso AMD, avoimen lähdekoodin omaa AMDGPU-ohjainta työpöydälle Linux). Valitettavasti Vulkan ja kiihdytetty (GLES) grafiikka yleensä ovat hieman monimutkaisempia kuin yksinkertainen LED, joten emme tule näkemään välilevyjä yhteensopivuuden lisäämiseksi.
Koska 7.0 ei ole ollut käytössä pitkään aikaan, on olemassa todellinen mahdollisuus, että muut piirisarjat (paitsi itse AOSP: ssä oleva pieni määrä) jäävät pois 6.0:ssa jäljessä joko laitteisto- ja ajuriongelmien vuoksi (eli ei päivitettyä BSP: tä) tai Vulkanin tai GLES 3.1:n SoC-toimittajatuen puutteesta. API. Tällä hetkellä Snapdragon 800 tai 801 eivät tue yhtäkään näistä.
Paras vaihtoehto on katsella tätä tilaa - XDA: n kehittäjät edistyvät jo hyvin epävirallisten porttien suhteen 7.0:aan monissa laitteissa, jotka eivät saa virallista 7.0-tukea Googlelta. Nämä ovat kuitenkin ilman Vulkan- tai GLES 3.1 -tukea - ehkä Android-pelien kehittäjät alkavat tehdä niin kokea turhautumista pirstoutumisesta, jos riittävä määrä käyttäjiä alkaa käyttää mukautettuja ROM-levyjä ilman Vulkan tai GLES 3.1 tuki?
Apple yleensä tukee iPhone-linjaansa uusimmassa iOS-versiossa noin viiden vuoden ajan – iPhone 4s julkaistiin lokakuussa 2011, ja se on pidetty ajan tasalla iOS 9:ään asti. Se ei kuitenkaan saa tulevaa iOS 10 -päivitystä, joka antaisi puhelimelle tehokkaan 5 vuoden käyttöiän olettaen, että iOS 10 julkaistaan lokakuun tienoilla. On syytä huomata, että Apple ei aina tarjoa back-port-grafiikka API-tukea - iPhone 4s ja iPhone 5 eivät sisältää Applen metalligrafiikkasovellusliittymän, joka on hieman samanlainen skenaario kuin Androidin kanssa Vulkan. Ainoa ero on, että Apple jatkoi vanhempien laitteiden tukemista ilman uutta grafiikkasovellusliittymää.
Mitä mieltä sinä olet? Haluatko pidentää puhelimesi käyttöikää? Kerrotko alla olevissa kommenteissa.