Šiame straipsnyje nagrinėjame tiesą, kodėl „Snapdragon 801“ įrenginiai negauna „Android Nougat“. Nuo lustų rinkinių gamintojų iki pardavėjų – problemų yra daug!
Atnaujinta, kad atitiktų „Android 7.0“ arba „Vulkan“ arba „OpenGL ES 3.1“ reikalavimą
Pastaruoju metu buvo parašyta daug straipsnių apie versijų atnaujinimus, pardavėjo ir mikroschemų rinkinio gamintojo sąveiką ir apie tai, ką tai reiškia įrenginiams. Kodėl šią savaitę tai išaugo?
Na, šią savaitę paaiškėjo, kad gerbiamasis „Nexus 5“ negaus „Android 7.0“ („Nougat“) atnaujinimo, o „Qualcomm“ paskelbė, kad jo nebus. 7.0 versijos MSM8974 (labiau žinomo kaip Snapdragon 801) palaikymas. Šis straipsnis parašytas bendradarbiaujant su XDA Recognized Programuotojas kamanė.
Ši tema sulaukė nemažo susidomėjimo įvairiose naujienų svetainėse, tačiau daugelis nepastebi subtilių niuansų to, kas iš tikrųjų vyksta už kadros. Šiame straipsnyje bus paaiškinta šiek tiek daugiau apie tai, kaip veikia programinės įrangos naujinimai, pasinaudojant mūsų patirtimi dirbant su OĮG dėl jų oficialių programinės įrangos naujinių. Išsiaiškinsime, kas vyksta užkulisiuose (ir kodėl) ir kodėl gali nepavykti gauti naujausios programinės įrangos savo telefone.
Pirmasis „Android“ programinės aparatinės įrangos atnaujinimo veiksmas yra atnaujinimas. Tuo „Google“ dirba viduje. Priešingai nei „atvirosios darbo eigos“, „Android“ kuriama naudojant uždarą darbo eigą, o šaltinio kodas kasmet išmetamas ant sienos, kai pasirodo nauja versija. Iš pradžių „Google“ teigė, kad taip siekiama užkirsti kelią žmonių susiskaidymui, naudojantiems pažangiausias versijas Nors iš pradžių viskas sparčiai vystėsi, bet panašu, kad jie išlaikė šią politiką vieta.
Tam tikru metu, paprastai prieš viešai paskelbiant naujinimą (nors neseniai pradėjus naudoti viešas beta versijas, šie terminai keičiasi), OEM gamintojai bus informuoti apie būsimą atnaujinimą. Tada jie gaus šaltinio kodą antrą kartą galutiniam atnaujinimui (anksčiau taip buvo kartais šiek tiek prieš paleidimą, nors mes taip pat žinome atvejus, kai nėra anksti paleidimas).
AOSP saugyklose yra palaikomas tik ribotas įrenginių skaičius. Paprastai tai yra „Nexus“ įrenginiai. Tačiau dėl priežasčių, kurios paaiškės netrukus, svarbu pažymėti, kad „Google“ neturi visiškos aparatinės įrangos kontrolės šių įrenginių; įrenginius gamina OĮG, o šis OĮG pirks sistemą lustą (SoC) iš mikroschemų rinkinio gamintojo.
Kai šaltinio kodas bus išleistas, OĮG programinės įrangos komanda (vaizdine prasme) atsisės ir pasikels. Pagrindinis „Android“ šaltinio medis nepalaiko daugybės lustų rinkinių, naudojamų siuntimo įrenginiuose. Pavyzdžiui, jūsų „Qualcomm“ mikroschemų rinkinys greičiausiai nepalaikomas AOSP. Jūsų Exynos tikrai ne. Mediatek ar HiSilicon? Pamiršk tai!
BSP yra tvarkyklės ir aparatinės įrangos abstrakcijos sluoksniai (HAL), kurių reikia norint paleisti „Android“.
Dabar reikia a Lentos palaikymo paketas (BSP). Tai itin konfidencialus patentuotų komponentų paketas, kurį mikroschemų rinkinio gamintojas pristato originalios įrangos gamintojui. BSP yra būtinas šaltinio kodas, leidžiantis originalios įrangos gamintojams kurti „Android“ ir reikiamas tvarkykles savo įrenginiui.
Čia verta paminėti, kad OĮG, tokie kaip „Qualcomm“, nebūtinai visiškai pasitiki savo OĮG partneriais – BSP yra prieinamas „būtina žinoti“. OĮG paprastai negauna prieigos prie kai kurių itin slaptų įrenginio dalių (pvz., bazinėje juostoje veikiančios programinės įrangos) šaltinio kodo. Šios dalies uždarymas tikrai taip pat turi galimų problemų, kaip rodo artimiausias gausus ir pasikartojantis ASN.1 pažeidžiamumų analizė.
BSP yra tvarkyklės ir aparatinės įrangos abstrakcijos sluoksniai (HAL), kurių reikia norint, kad „Android“ veiktų jūsų įrenginyje. AOSP yra HAL rinkinys, kuris veikia kaip apibrėžimai, ką operacinė sistema tikisi įdiegti iš jūsų tvarkyklių. Norėdami naudoti juokingai pernelyg supaprastintą (ir sugalvotą demonstravimo tikslais) pavyzdį, įsivaizduokime, kad jūsų telefone yra žibintuvėlis.
HAL pavyzdys – jūsų žibintuvėlis
Įsivaizduokime, kad jūsų įrenginio gale yra žibintuvėlis (jei turite „Nexus 7 2013“, jums reikės šiek tiek daugiau įsivaizduoti nei visiems kitiems – atsiprašau!). Tai valdo vairuotojas. Mūsų beprotiškai paprastame pavyzdyje tarkime, kad v1 HAL sako, kad turėtumėte turėti vieną funkciją, pavadintą „setLED“, kuri paima vieną parametrą – šviesos būseną. Tai loginė vertė – tiesa ar klaidinga. C kalboje tai atrodytų maždaug taip:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Ši funkcija apibrėžta BSP šaltinio kode. Tada BSP sukompiliuoja OĮG, kurdamas ROM, ir tai tampa viena iš patentuotų „.so“ bibliotekų jūsų įrenginio pardavėjo skaidinyje arba srityje. Tai leidžia OĮG išlaikyti tam tikras savo įrenginio veikimo dalis paslaptyje. Kol kas darykime prielaidą, kad jie nori neleisti visiems matyti, kaip jie įjungia ir išjungia tą šviesos diodą.
Dabar įsivaizduokite, kad „Google“ išleidžia atnaujintą savo HAL versiją būsimoje „Android“ versijoje. Dabar jie nusprendžia, kad būtų puiku leisti atnaujinti šviesos diodo ryškumą, o ne tik jį įjungti ar išjungti. Galbūt tai skirta prisitaikančiajai blykstei, o gal tiesiog priverstinai atnaujinti HAL ir išlaikyti lustų rinkinių gamintojus versle? Leisime jums, skaitytojau, susidaryti savo nuomonę šiuo klausimu. Kai kurie HAL naujinimai turi aiškią naudą (pavyzdžiui, naujoji Camera HAL, atskleidžianti neapdorotą fotografavimą ir panašiai), o kiti yra šiek tiek ne tokie aiškūs.
Tarkime, kad naudojant šį naują (išgalvotą) HAL, skirtą ryškumui, „Google“ sako, kad reikia dar kartą parodyti funkciją, vadinamą setLED, tačiau šį kartą ryškumui perduotas sveikasis skaičius. Dabar 0 jį išjungs, o 255 įjungs visiškai.
Jei esate originalios įrangos gamintojas, galite paimti savo ypač slaptą kodą, kad įjungtumėte tą šviesos diodą ir įtrauktumėte jį į šią naują funkciją. Jūs netgi galite naudoti impulso pločio moduliaciją, kad reguliuotumėte šviesos diodo ryškumą pagal skaičių. Pakeičiate funkciją, kad dabar atrodytų taip:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Tai kas? Na, dabar ši nauja „Android“ versija nesuderinama su esamomis „dėmėmis“. OĮG turi naudoti šias naujas dėmes, nes „Android“ OS tikisi pamatyti naują funkcijos apibrėžimą ir „neras“ senosios, kai ieškos būdo nustatyti LED.
Šiuo metu trumpai pakalbėkime apie tai, kaip čia veikia pasirinktiniai ROM (sukurti iš šaltinio). Štai ką sumanieji tarp jūsų dabar šauks į jūsų ekraną – juk mes esame XDA, HTC HD2, ilgiausiai veikiantis telefonas pasaulyje... (tik dėl to, ten bėga beprotiški genijai „Android 6.0“ šiomis dienomis HD2! Neblogai telefonui, kuris iš pradžių buvo pristatytas su Windows Mobile 6.5 2009 m.)
Čia taikomi įvairūs metodai – kartais kūrėjai įsilaužia į ROM ir liepia OS naudoti senus funkcijų apibrėžimus. Tai šiek tiek nepatogu, todėl reikia daug pakeitimų. Kitas būdas yra „pakeisti“ OĮG dvejetainį elementą.
„Tinkamas“ metodas yra pačiam parašyti ir sukurti mažą naują biblioteką, kurioje būtų numatytas funkcijos apibrėžimas – pavyzdžiui, ryškumui palaikytume sveikąjį skaičių. Tada tarpiklio viduje tai išversta taip, kad atitiktų senojo HAL reikalavimus. Taigi, pavyzdžiui, galime pasakyti, kad bet koks ryškumas, kurio reikalaujama virš 128, įjungs šviesos diodą, o bet koks mažesnis - jį išjungs. Arba galite pasakyti bet ką, o ne nulį, jį įjungs. Tai priklauso nuo kūrėjo. Jie sukompiliuoja tarpiklį ir priverčia „Android“ jį naudoti vietoje savosios. Tada tarpiklis vadina OEM blob.
Greitas „adb stūmimas“ ir paleidimas iš naujo turėtų suaktyvinti tarpiklį ir leisti valdyti išgalvotą šviesos diodą, net jei turite tik seną HAL.
Problema ta, kad tai akivaizdžiai netobulas procesas. Dabar gausite keistenybių – šis įrenginys turės gana niūrią blykstę, kuri bus visiškai įjungta arba visiškai išjungta. Tai nėra idealu – OS mano, kad ji skleidžia labai švelnią šviesą, tačiau tikram šviesos diodui pranešama, kad jis dalyvauja dirbtinės saulės konkurse ir bando jus apakinti. Bet ei, gyvenimas nėra tobulas, o dabar sename telefone turite veikiantį šviesos diodą!
(Taip, tai yra viena iš priežasčių, kodėl XDA naudotojai ir kūrėjai valdo savo beprotiškus ir beprotiškus perkėlimo meistriškumo žygdarbius, dėl kurių kyla keistenybių ir klaidų. Aš turiu galvoje po velnių, Galaxy S II yra nešiojimas iš pažiūros tinkamas naudoti Android 6.0 ROM dabar. Daugelis praėjusiais metais išleistų telefonų vis dar neturi 6.0!)
Grįžkime prie OĮG perspektyvos. Deja, dauguma originalios įrangos gamintojų jau dirba bent vienu telefonu anksčiau nei esame dabar. Jų dėmesys sutelktas į kitą telefoną, kurį ketina parduoti – tikrai negalite jų kaltinti, nes jie uždirba tik iš parduodamų įrenginių. Jie neuždirba iš įrenginių, kuriuos pardavė prieš metus ar dvejus, todėl jie turi nuolat leisti naujus įrenginius, kad egzistuotų. Tai yra viena iš priežasčių, kodėl HTC ir Blackberry susiduria su bėdomis – nesvarbu, kiek vadovų išlaiko savo seną „Blackberry Curve“ mirtį, nes jie negauna naujų įrenginių.
Jei originalios įrangos gamintojas negauna BSP, jie nesiruošia nusileisti XDA metodu, kad įsilaužtų kartu. Kodėl? Na, jie turi palaikyti šią programinę-aparatinę įrangą savo klientams. Jei jie išleis neveikiančią programinę-aparatinę įrangą, vartotojai jų nekęs, pyks ir šėls, o palaikymo linijos skambės kelias dienas.
Originalios įrangos gamintojai taip pat turi kovoti su vežėjais, bent jau ne Europos rinkose. Vežėjai nenori, kad klientams kiltų problemų dėl programinės įrangos atnaujinimų. Tiesą sakant, vežėjai dažnai nenorėtų išleisti programinės įrangos naujinimų.
Norėdami tai suprasti, įsivaizduokite savo Didžiąją tetą Alisą. Ji skambina jums nepatogiu paros metu ir paprašo pagalbos dėl „to kompiuterio reikalo“. Tada aprašote, kaip spustelėti meniu „Pradėti“, ir turite jį identifikuoti kaip „didelę vėliavą apatiniame kairiajame kampe“, ir sutinkate sumaištį. Po maždaug 45 minučių (ir daug nusivylimo) paaiškėja, kad teta Alisa nutempė pradžios meniu į dešinįjį ekrano kraštą ir tiesiog reikėjo jį nutempti atgal. Taip, kairiuoju pelės mygtuku!
Dabar įsivaizduokite, kad turite tūkstantį tetos Alisos. Jie visi skambina jūsų klientų aptarnavimo tarnybai, neranda „Candy Crush“ savo telefone ir nerimauja, kad įsilaužėlis jį ištrynė iš jų telefono. O ir piktogramos dabar atrodo kiek kitaip – gal įsilaužėlis vis dar yra jų telefone?
Taip, tai yra šiek tiek lengvabūdiškas humoras, bet kol nepatirsite priežasčių, kodėl žmonės kreipsis į savo vežėją pagalbos, nepatikėsite jų turimomis problemomis. Programinės įrangos naujinimas, kuris pakeičia telefono veikimą arba vietą, sukels didelių papildomų išlaidų. Tam reikia bent jau iš naujo apmokyti pagalbinį personalą (nes, deja, dauguma jų nėra jūsų aistringi XDA skaitytuvai).
Kai OĮG gaus BSP, jie perkels savo ROM ir pritaikys visus pakeitimus ROM. Jie prisidės prie savo palaidinių ir pridės siaubingą animacinį filmą, kuris atrodytų kaip namuose paauglių anime. Tada jie tai išbandys.
Daug.
Yra visų reikalavimų, kuriuos turi atitikti jūsų telefonas. Mobilieji tinklai sukurti taip, kad vartotojo įranga (tai vadiname telefonu) veiktų teisingai. Tai reiškia, kad norint gauti įrenginio patvirtinimą, reikia atlikti daug bandymų. Dėl programinės įrangos atnaujinimų kyla pavojus, kad elgsena pasikeis, todėl viską reikia išbandyti dar kartą. Štai kodėl dažnai matysite informaciją apie būsimus „Sony“ programinės įrangos atnaujinimus iš išorinių bandymų tarnybų, kurie patvirtina, kad programinė įranga atitinka bandymo reikalavimus.
Dabar... kas nutinka po ar dviejų atnaujinimų (arba kai kuriais atvejais nė vieno)? SoC gamintojas nesuteiks OĮG atnaujinto BSP. Galų gale, SoC gamintojas iš to daug nepasieks. OĮG daugiau neuždirba iš jūsų telefono nuo tada, kai jis buvo parduotas. Ir šiuo metu jūsų telefonas negauna daugiau svarbių versijos naujinių.
OĮG norimų pristatyti BSP skaičiaus sumažinimas yra puikus būdas sutaupyti pinigų – jei jums reikia tik dabartinės ir neketinate pristatyti jokios pagrindinės versijos. padidės, tai sutaupys pinigų pradiniam SoC pirkimui ir licencijavimui, tačiau kai kurie pikti XDA vėplai, stebintys, kodėl jie negavo atnaujinti.
Atnaujinimai yra sudėtingi. Grandinėje dalyvauja daug skirtingų žmonių. Nė vienas iš šių dalykų neatleidžia originalios įrangos gamintojų nuo dabartinės prastos ir apgailėtinos „Android“ atnaujinimų būklės. Nepaisant to, čia yra keletas tikrų iššūkių.
Daugelis originalios įrangos gamintojų yra kalti dėl per daug žadančių ir neišvengiamas nepakankamas rezultatas, kurį dabar siejame. Liūdna realybė yra ta, kad daugumai originalios įrangos gamintojų programinės įrangos atnaujinimai yra tik nepatogumas, be kurio jie galėtų išsiversti.
Mobiliojo ryšio sektorius dažniausiai įstrigo funkcinių telefonų mąstysenoje. Tai yra, kai įrenginys niekada negauna jokių atnaujinimų. Išbandykite vieną kartą, išsiųskite ir niekada nežiūrėkite atgal. Dėl šiuolaikinių išmaniųjų telefonų saugumo problemų ir visiško bendros paskirties operacinės sistemos su šimtais išorinių bibliotekų paleidimo sudėtingumo tai nebėra. Ar bent jau tai neturėtų būti. „Google“ ėmėsi tam tikrų veiksmų, kad tai ištaisytų, bent jau paskelbdama saugos biuletenius ir esamų leidimų pataisas „Android“ (atminkite, kad dar visai neseniai vienintelis būdas gauti saugos naujinimus buvo naudojant naują pagrindinę „Android“ OS versiją!)
Deja, to tikrai neužtenka. Nors „Google“ nuolat leidžia naujinimus, jūsų įrenginio saugumas vis tiek priklauso nuo SoC kūrėjo, nes SoC kūrėjai yra labai suakmenėję kas nors, sužinojęs, kaip įjungia porą šviesos diodų arba skleidžia garsą per garsiakalbį, siunčia didžiulius kiekius dvejetainių dėmių prietaisai. Šiose dėmėse yra gana siaubingai nesaugus kodas (jei manote, kad tai perdėta, tiesiog peržiūrėkite ankstesnius „Google“ saugos biuletenius!) ir juos reikia atnaujinti. Tai reiškia, kad reikia atnaujinti BSP.
Staliniai kompiuteriai (ir iš esmės nešiojamieji kompiuteriai) savo architektūra visiškai skiriasi nuo mobiliųjų įrenginių. Jūsų mobilusis telefonas arba planšetinis kompiuteris iš tikrųjų yra labai patentuotas silicio luitas, kurį skubiai sukūrė kai kurie žmonės, kurie nori gerai, bet neturi pakankamai laiko ką nors gero padaryti. Rinka juda taip greitai, kad jie vos spėja neatsilikti nuo tempo, kuriuo rinkodara reikalauja naujų produktų.
Tai reiškia, kad naudojami spartieji klavišai – jūsų telefono nepalaiko pagrindinis Linux branduolys, o kiekvienas telefonas turi skirtingą įkrovos būdą. Tačiau jūsų nešiojamajame ar staliniame kompiuteryje pardavėjai pasirinko kai kuriuos standartinius įkrovos būdus – anksčiau tai buvo MBR (pagrindinis įkrovos įrašas) su BIOS, o dabar UEFI. Šis standartizavimas leidžia paleisti tą pačią programinę įrangą kiekviename įrenginyje.
Nors pastaruoju metu buvo žengta tam tikrų žingsnių, ypač naudojant „Sony“ informavimo programą ir jų vieningas branduolys, daugumoje telefonų nepraktiška paleisti pagrindinį branduolį, nes kiekviename įrenginyje yra daugybė naujų, konkrečiam pardavėjui taikomų įsilaužimų.
Neteisingai prijungėte ausinių lizdą? Tiesiog įsilaužkite į tvarkykles! Gamybos projekte nėra laiko taisyti.
Gamybos komanda sumontavo fotoaparato modulį aukštyn kojomis 1 gamybos partijoje? Įsilaužkite, kad patikrintumėte vidinės versijos kodą, ir apverskite vaizdo įrašą, jei tai 1 versija!
Tokie įsilaužimai išsprendžia neatidėliotiną problemą, tačiau tik nubraukia keistų ir konkrečiam produktui vykstančių pokyčių paviršių. Po velnių, kartais dėl komercinių sprendimų skirtingose to paties telefono versijose yra visiškai skirtingų lustų. Tai veda prie tvarkyklių įsilaužimo ir keistų sprendimų, kurie tuo metu buvo prasmingi, kad telefonas veiktų, kad jį būtų galima išsiųsti kitą savaitę.
Nors vyksta darbas siekiant palaikyti pagrindinį 64 bitų ARM lustų palaikymą naudojant UEFI, iki šiol buvo nėra aiškaus judėjimo link labiau standartizuoto būdo paleisti ARM įrenginius. Ir tai liūdna, nes tai reiškia, kad telefonai ir toliau bus išmetami gerokai anksčiau, nei pasibaigs jų naudojimas darbingo gyvenimo, nes tiesiog per brangu išlaikyti techninę skolą ir naštą programinė įranga.
Kita vertus, jei originalios įrangos gamintojas uždirbs pinigų tik pardavęs įrenginį, ar jiems nereikia užtikrinti, kad žmonės ir toliau pirktų naujus telefonus? Ar asmeninių kompiuterių rinka pereitų prie šio modelio, jei nebūtų 30 metų pažangos ir senos programinės įrangos, naudojančios atvirą kompiuterio platformą ir standartą?
Tai sunkus klausimas be „Qualcomm“ vidinių žinių, kurių, deja, šiuo metu neturime. Tačiau kai kurios informacijos galime gauti iš 7.0 Android tvarkyklės API ir CTS reikalavimų. CTS reikalavimai nurodo, ko „Google“ tikisi iš įrenginio, kuriame veikia tam tikra programinė įranga. „Didysis plaktukas“, naudojamas šiems reikalavimams įgyvendinti, yra „Google“ licencija naudoti savo patentuotą „Google Play“ paslaugų paketą – jei nesilaikysite reikalavimų, negalėsite siųsti „Google Apps“ į įrenginį. Nors kai kuriems tai gali būti vertinamas kaip privalumas, akivaizdu, kad tai nėra tai, ko vartotojai nori ir tikisi iš įrenginio.
„Android 7.0“ nepadarė daug HAL ar tvarkyklių pakeitimų (kaip aprašyta aukščiau), todėl vargu ar gali kilti nesuderinamumas. Tačiau labiau tikėtina, kad problema bus a naujas reikalavimas Vulkan grafikos API arba GLES 3.1, būti pasiekiami norint išlaikyti CTS.
Šiuo metu daugelis „Systems-on-Chip“ (SoC) neturi „Vulkan“ palaikymo savo grafikos procesoriuje, įskaitant MSM8974. Taip pat greičiausiai čia iškils suderinamumo su „Android 7.0“ problema. Tačiau be vidinių žinių iš „Qualcomm“ ir jų ateities planų mums sunku pateikti galutinį pareiškimą jo nepateikus. Tačiau šiuo metu manome, kad tai yra „paprastas“ atvejis, kai Qualcomm nutraukia (jų akimis) senstantis MSM8974 mikroschemų rinkinys ir toje platformoje neteikiamas BSP (plokštės palaikymo paketas) 7.0. Jei taip būtų, tai reikštų, kad originalios įrangos gamintojai beveik neabejotinai nepateiks 7.0 įrenginyje – jie turėtų kažkaip rasti Vulkan arba GLEs 3.1 palaikymą savo GPU ir GPU šaltinį. kodas yra viena iš juokingai griežtai saugomų mobiliųjų stekelių dalių (be jokios priežasties pridėtume – žr. AMD, atviro šaltinio AMDGPU tvarkyklę darbalaukyje Linux). Deja, bet Vulkan ir pagreitinta (GLES) grafika apskritai yra šiek tiek sudėtingesnė nei paprastas šviesos diodas, todėl tai nėra kažkas, ko mes matysime, kad būtų galima įdiegti suderinamumą.
Kadangi 7.0 buvo išleistas neilgai, yra reali galimybė, kad kiti mikroschemų rinkiniai (išskyrus nedidelį skaičių pačioje AOSP) bus palikti atsilieka nuo 6.0 versijos dėl aparatinės įrangos ir tvarkyklės problemų (t. y. nėra atnaujinto BSP) arba dėl Vulkan arba GLES 3.1 SoC pardavėjo palaikymo trūkumo. API. Šiuo metu nei Snapdragon 800, nei 801 nepalaiko nė vieno iš jų.
Geriausia yra stebėti šią erdvę - XDA kūrėjai jau daro didelę pažangą naudodami neoficialius prievadus iki 7.0 daugeliui įrenginių, kurie negauna oficialaus 7.0 palaikymo iš Google. Tačiau jie nepalaiko Vulkan ar GLES 3.1 – galbūt žaidimų kūrėjai „Android“ tai pradės patiria nusivylimą dėl susiskaidymo, jei pakankamai vartotojų pradeda naudoti pasirinktinius ROM be Vulkan arba GLES 3.1 palaikyti?
„Apple“ linkusi palaikyti savo „iPhone“ liniją naujausioje „iOS“ versijoje maždaug 5 metus – „iPhone 4s“ buvo pristatytas 2011 m. spalį ir buvo nuolat atnaujintas iki „iOS 9“. Tačiau jis negaus būsimo „iOS 10“ naujinimo, kuris suteiktų telefono efektyvią tarnavimo laiką 5 metus, darant prielaidą, kad „iOS 10“ bus paleista maždaug spalį. Verta paminėti, kad „Apple“ ne visada palaiko grafikos API atgalinį prievadą – „iPhone 4s“ ir „iPhone 5“ to nedaro. turi „Apple“ metalinės grafikos API, kuri yra šiek tiek panašus į scenarijų, matomą naudojant „Android“. Vulkanas. Vienintelis skirtumas yra tas, kad „Apple“ ir toliau palaikė senesnius įrenginius be naujos grafikos API.
Ką tu manai? Ar įjungsite pasirinktinį ROM savo telefone, kad prailgintumėte jo tarnavimo laiką? Ar galite pasakyti toliau pateiktuose komentaruose.