W tym artykule badamy prawdę, dlaczego urządzenia ze Snapdragonem 801 nie otrzymują Androida Nougat. Od producentów chipsetów po dostawców, problemów jest wiele!
Zaktualizowano, aby odzwierciedlić wymagania Vulkan lub OpenGL ES 3.1 dla systemu Android 7.0
Ostatnio napisano wiele artykułów na temat aktualizacji wersji, interakcji między dostawcą a producentem chipsetów oraz tego, co to oznacza dla przyszłych urządzeń. Dlaczego liczba ta wzrosła w tym tygodniu?
Cóż, wyszło na jaw w tym tygodniu, biorąc pod uwagę, że czcigodny Nexus 5 nie otrzyma aktualizacji do Androida 7.0 (Nougat), a Qualcomm ogłosił, że nie będzie zapewniając obsługę MSM8974 (bardziej znanego jako Snapdragon 801) w wersji 7.0. Ten artykuł powstał we współpracy z XDA Recognized Deweloper trzmiel.
Temat wzbudził spore zainteresowanie różnych serwisów informacyjnych, ale wielu nie dostrzega subtelnych niuansów tego, co naprawdę dzieje się za scenąS. W tym artykule wyjaśnimy nieco więcej na temat działania aktualizacji oprogramowania, korzystając z naszego doświadczenia we współpracy z producentami OEM nad ich oficjalnymi aktualizacjami oprogramowania. Przeprowadzimy Cię przez proces, co dzieje się za kulisami (i dlaczego) oraz dlaczego możesz nie otrzymać najnowszego oprogramowania na swoim telefonie.
Pierwszym krokiem w życiu aktualizacji oprogramowania układowego Androida jest aktualizacja nadrzędna. Nad tym Google pracuje wewnętrznie. W przeciwieństwie do „otwartych przepływów pracy”, Android jest rozwijany w oparciu o zamknięty przepływ pracy, a kod źródłowy jest wyrzucany za ścianę mniej więcej co roku, gdy pojawia się nowa wersja. Pierwotnie Google twierdziło, że ma to na celu zapobieganie fragmentacji przez osoby korzystające z najnowocześniejszych wersji choć na początku sytuacja szybko się rozwijała, wydaje się jednak, że utrzymali tę politykę miejsce.
W pewnym momencie, zwykle przed publicznym ogłoszeniem aktualizacji (chociaż wraz z niedawnym wprowadzeniem publicznych wersji beta te ramy czasowe ulegają przesunięciu), Producenci OEM zostaną powiadomieni o nadchodzącej aktualizacji. Następnie otrzymają kod źródłowy w drugim momencie w celu ostatecznej aktualizacji (w przeszłości było to możliwe czasami trochę przed premierą, chociaż znamy również przypadki, w których nie ma wcześniej uwolnienie).
Repozytoria AOSP nadrzędne obsługują tylko ograniczoną liczbę urządzeń. Są to zazwyczaj Twoje urządzenia Nexus. Jednak z powodów, które wkrótce staną się jasne, należy zauważyć, że Google nie ma pełnej kontroli sprzętowej nad tymi urządzeniami; urządzenia są produkowane przez producenta OEM i ten producent OEM kupi system-on-chip (SoC) od producenta chipsetu.
Po opublikowaniu kodu źródłowego zespół oprogramowania OEM (w przenośni) usiądzie i podniesie nogi. Główne drzewo źródeł Androida nie obsługuje niezliczonej ilości chipsetów używanych w urządzeniach transportowych. Twój chipset Qualcomm najprawdopodobniej nie jest obsługiwany na przykład przez AOSP. Twój Exynos z całą pewnością taki nie jest. Mediatek czy HiSilicon? Zapomnij o tym!
BSP zawiera sterowniki i warstwy abstrakcji sprzętu (HAL) potrzebne do uruchomienia systemu Android
Teraz potrzebne jest Pakiet wsparcia płyty głównej (BSP). Jest to ściśle tajny pakiet zastrzeżonych komponentów dostarczany producentowi OEM przez producenta chipsetów. BSP zawiera niezbędny kod źródłowy umożliwiający producentom OEM tworzenie systemu Android oraz niezbędne sterowniki dla ich urządzeń.
Warto w tym miejscu zauważyć, że producenci OEM, tacy jak Qualcomm, niekoniecznie w pełni ufają swoim partnerom OEM — BSP jest udostępniany na zasadzie „wiedzy koniecznej”. Producenci OEM zwykle nie mają dostępu do kodu źródłowego niektórych supertajnych części urządzenia (takich jak oprogramowanie działające w paśmie podstawowym). Zamknięcie tej części z pewnością wiąże się również z potencjalnymi problemami, jak pokazano z bliska rzęsisty I powtarzający się ASN.1 analizowanie luk w zabezpieczeniach.
BSP zawiera sterowniki i warstwy abstrakcji sprzętu (HAL) potrzebne do uruchomienia systemu Android na Twoim urządzeniu. AOSP zawiera zestaw warstw HAL, które pełnią funkcję definicji tego, czego system operacyjny oczekuje od sterowników. Aby użyć absurdalnie uproszczonego (i wymyślonego na potrzeby demonstracji) przykładu, wyobraźmy sobie latarkę w telefonie.
Przykład HAL – Twoja latarka
Wyobraźmy sobie, że Twoje urządzenie ma z tyłu latarkę (jeśli masz Nexusa 7 2013, będziesz musiał wykazać się nieco większą wyobraźnią niż wszyscy inni – przepraszam!). Jest to kontrolowane przez sterownik. W naszym szalenie prostym przykładzie załóżmy, że HAL v1 mówi, że powinieneś mieć jedną funkcję o nazwie „setLED” pobierającą pojedynczy parametr, stan światła. Jest to wartość logiczna — prawda lub fałsz. W C wyglądałoby to mniej więcej tak:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Funkcja ta jest zdefiniowana w kodzie źródłowym BSP. BSP jest następnie kompilowany przez producenta OEM podczas tworzenia pamięci ROM i staje się jedną z zastrzeżonych bibliotek „.so” na partycji dostawcy lub obszarze Twojego urządzenia. Dzięki temu producent OEM może zachować w tajemnicy niektóre elementy działania swojego urządzenia. Na razie załóżmy, że chcą, aby wszyscy nie widzieli, jak włączają i wyłączają tę diodę LED.
Teraz wyobraź sobie, że Google wypuszcza zaktualizowaną wersję swoich warstw HAL w przyszłej wersji Androida. Teraz zdecydowali, że miło byłoby umożliwić aktualizację jasności diody LED, a nie tylko ją włączać lub wyłączać. Może chodzi o adaptacyjną pamięć flash, a może po prostu o wymuszenie aktualizacji HAL i utrzymanie producentów chipsetów w biznesie? Pozwolę Ci, czytelniku, wyrobić sobie własną opinię na ten temat. Niektóre aktualizacje HAL przynoszą wyraźne korzyści (np. nowy aparat HAL udostępniający surowe zdjęcia i tym podobne), podczas gdy inne mają nieco mniej jasny cel.
W przypadku tej nowej (fikcyjnej) warstwy HAL określającej jasność, załóżmy, że Google twierdzi, że należy ponownie udostępnić funkcję o nazwie setLED, ale tym razem z liczbą całkowitą przekazaną jako jasność. Teraz 0 wyłączyłoby to, a 255 ustawiłoby na pełne.
Jeśli jesteś producentem OEM, możesz użyć swojego supertajnego kodu, aby włączyć tę diodę LED i umieścić go w tej nowej funkcji. Można nawet użyć modulacji szerokości impulsu, aby dostosować jasność diody LED na podstawie liczby. Zmieniasz funkcję, aby teraz wyglądała tak:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Więc co? Cóż, teraz ta nowa wersja Androida jest niekompatybilna z istniejącymi „blobami”. Twój producent OEM musi używać tych nowych obiektów BLOB, ponieważ system operacyjny Android spodziewa się zobaczyć nową definicję funkcji i nie „znalezie” starej, szukając sposobu na ustawienie diody LED.
W tym momencie zróbmy krótką przerwę, aby przyjrzeć się, jak radzą sobie tutaj niestandardowe pamięci ROM (zbudowane ze źródła). To właśnie będą teraz krzyczeć mądrzy z Was na ekranie — w końcu jesteśmy XDA, domem HTCHD2, najdłuższy telefon na świecie... (tak dla jasności, szaleni geniusze tam biegają Obecnie Android 6.0 na HD2! Całkiem nieźle jak na telefon oryginalnie dostarczony z systemem Windows Mobile 6.5 w 2009 r.)
Stosowane są tutaj różne podejścia - czasami programiści włamują się do ROM-u i każą systemowi operacyjnemu używać starych definicji funkcji. Jest to trochę bałaganiarskie i wymaga wielu zmian do utrzymania. Inne podejście polega na „podkładce” pliku binarnego OEM.
Podejście „podkładkowe” polega na samodzielnym napisaniu i zbudowaniu małej nowej biblioteki, która zawiera oczekiwaną definicję funkcji - w naszym przykładzie wspieralibyśmy liczbę całkowitą dla jasności. Następnie w ramach podkładki jest to tłumaczone w celu spełnienia wymagań starego HAL. W naszym przykładzie moglibyśmy powiedzieć, że każda żądana jasność powyżej 128 spowoduje włączenie diody LED, a każda wartość poniżej spowoduje jej wyłączenie. Możesz też powiedzieć, że wszystko inne niż zero włączy to. To zależy od dewelopera. Kompilują podkładkę i sprawiają, że Android używa jej zamiast natywnej. Następnie podkładka wywołuje obiekt typu blob OEM.
Szybkie „adb push” i ponowne uruchomienie powinno uruchomić podkładkę i pozwolić ci kontrolować fikcyjną diodę LED, nawet jeśli masz tylko stary HAL.
Problem w tym, że jest to proces wyraźnie niedoskonały. Teraz będziesz miał pewne dziwactwa – to urządzenie będzie miało raczej kiepską lampę błyskową, która jest albo całkowicie włączona, albo całkowicie wyłączona. To nie jest idealne rozwiązanie — system operacyjny uważa, że emituje bardzo delikatne światło, ale w rzeczywistości dioda LED otrzymuje informację, że bierze udział w konkursie sztucznego słońca i próbuje Cię oślepić. Ale hej, życie nie jest idealne i masz teraz działającą diodę LED na swoim starym telefonie!
(Tak, jest to jeden z powodów, dla których występują dziwactwa i błędy, gdy użytkownicy i programiści XDA zarządzają swoimi szalonymi i szalonymi wyczynami w zakresie przenoszenia. Mam na myśli, do cholery, Galaxy S II to coś pozornie użytecznego Teraz Android 6.0 ROM. Wiele telefonów wydanych w zeszłym roku nadal nie ma wersji 6.0!)
Wróćmy do perspektywy producenta OEM. Niestety większość producentów OEM pracuje już co najmniej o 1 telefon szybciej niż my obecnie. Skupiają się na następnym telefonie, który mają zamiar sprzedać – naprawdę nie można ich winić, ponieważ zarabiają tylko na sprzedawanych przez siebie urządzeniach. Nie zarabiają na urządzeniach, które sprzedali rok czy dwa lata temu, więc muszą ciągle wypuszczać nowe urządzenia, żeby istnieć. Jest to jeden z powodów, dla których HTC i Blackberry mają kłopoty – nie ma znaczenia, ilu menedżerów nadal trzyma się swojego starego Blackberry Curve, ponieważ nie można tam kupić nowych urządzeń.
Jeśli producent OEM nie otrzyma BSP, nie zastosuje podejścia XDA polegającego na wspólnym hakowaniu kompilacji. Dlaczego? Dobrze, muszą obsługiwać to oprogramowanie sprzętowe dla swoich klientów. Jeśli wypuszczą oprogramowanie sprzętowe, które w połowie działa, użytkownicy będą ich nienawidzić, będą narzekać i zachwycać się, a ich linie wsparcia będą dzwonić przez wiele dni.
Producenci OEM muszą także walczyć z przewoźnikamiprzynajmniej na rynkach pozaeuropejskich. Operatorzy nie chcą, aby klienci mieli problemy z aktualizacjami oprogramowania. W rzeczywistości operatorzy często woleliby nie publikować aktualizacji oprogramowania.
Aby to zrozumieć, wyobraź sobie swoją cioteczną ciotkę Alicję. To ona dzwoni do Ciebie w nieodpowiednich porach dnia i prosi o pomoc w „tej sprawie z komputerem”. Następnie opisujesz, jak kliknąć „menu Start” i musisz zidentyfikować je jako „dużą flagę w lewym dolnym rogu”, co spotyka się z zamieszaniem. Około 45 minut później (i wiele frustracji) okazuje się, że ciocia Alicja przeciągnęła menu startowe do prawej krawędzi ekranu i po prostu musiała je przeciągnąć z powrotem. Tak, lewym przyciskiem myszy!
A teraz wyobraź sobie, że masz tysiąc ciotek Alicji”. Wszyscy dzwonią do Twojej obsługi klienta, nie mogąc znaleźć Candy Crush na swoim telefonie, bo martwią się, że haker usunął je z ich telefonu. Aha, i ikony wyglądają teraz nieco inaczej – może haker nadal jest w ich telefonie?
Tak, to ma być odrobina beztroskiego humoru, ale dopóki nie poznasz powodów, dla których ludzie dzwonią do swojego operatora w celu uzyskania pomocy, nie uwierzysz, jakie mają problemy. Aktualizacja oprogramowania, która zmienia sposób działania telefonu lub lokalizację, spowoduje znaczne zwiększenie kosztów wsparcia. Wymaga to co najmniej ponownego przeszkolenia personelu pomocniczego (ponieważ większość z nich nie jest twoim zagorzałym czytelnikiem XDA, niestety).
Gdy producent OEM otrzyma BSP, przeniesie swoją pamięć ROM i zastosuje w niej wszystkie zmiany. Będą gromadzić swoje nadęte oprogramowanie i dodawać przerażającą kreskówkową skórkę, która bardziej pasowałaby do anime dla nastolatków. Potem to przetestują.
Bardzo.
Jest mnóstwo wymagań, które musi spełniać Twój telefon. Sieci komórkowe zaprojektowano tak, aby ufały, że sprzęt użytkownika (nazywamy telefonem) będzie się zachowywał prawidłowo. Oznacza to, że aby urządzenie zostało zatwierdzone, należy przejść wiele testów. Aktualizacje oprogramowania wiążą się z ryzykiem zmiany zachowań, dlatego należy wszystko przetestować ponownie. Dlatego często pojawiają się informacje o nadchodzących aktualizacjach oprogramowania Sony pochodzące z zewnętrznych usług testowych, które potwierdzają zgodność oprogramowania sprzętowego z wymaganiami testowymi.
Teraz... co się stanie po aktualizacji lub dwóch (lub w niektórych przypadkach żadnej)? Producent SoC nie przekaże producentowi OEM zaktualizowanego BSP. W końcu twórca SoC niewiele na tym zyska. Producent OEM nie zarabia już na Twoim telefonie od czasu jego sprzedaży. W tym momencie Twój telefon nie otrzymuje już żadnych głównych aktualizacji wersji.
Ograniczenie liczby BSP, które chce dostarczyć producent OEM, to świetny sposób na zaoszczędzenie pieniędzy — jeśli potrzebujesz tylko bieżącego i nie zamierzasz dostarczać żadnej głównej wersji wzrośnie, pozwoli to zaoszczędzić pieniądze na początkowym zakupie SoC i licencjonowaniu, ale kosztem kilku wściekłych kujonów na XDA w dalszej kolejności, zastanawiających się, dlaczego nie dostali aktualizacja.
Aktualizacje są złożone. W łańcuchu zaangażowanych jest wiele różnych osób. Nic z tego nie usprawiedliwia producentów OEM z obecnego nędznego i żałosnego stanu aktualizacji dla Androida. Niemniej jednak istnieje tu kilka prawdziwych wyzwań.
Wielu producentów OEM jest winnych nadmiernych obietnic, a nieuniknione niedostateczne wykonanie, które obecnie kojarzymy. Smutna rzeczywistość jest taka, że dla większości producentów OEM aktualizacje oprogramowania są po prostu irytacją, bez której mogliby się obejść.
Sektor mobilny w większości utknął w sposobie myślenia o telefonach z internetem. Oznacza to, że urządzenie nigdy nie otrzymuje żadnych aktualizacji. Przetestuj raz, wyślij i nigdy nie oglądaj się za siebie. Biorąc pod uwagę problemy związane z bezpieczeństwem nowoczesnych smartfonów i samą złożoność obsługi pełnego systemu operacyjnego ogólnego przeznaczenia z setkami zewnętrznych bibliotek, nie jest to już możliwe. Albo przynajmniej to nie powinien Być. Firma Google poczyniła pewne kroki w celu naprawienia tego problemu, przynajmniej publikując biuletyny bezpieczeństwa i poprawki do istniejących wersji Androida (pamiętaj, że do niedawna jedynym sposobem na uzyskanie aktualizacji zabezpieczeń była nowa, główna wersja systemu operacyjnego Android!)
Niestety, to jednak naprawdę nie wystarczy. Mimo że Google stale publikuje aktualizacje, bezpieczeństwo Twojego urządzenia w dalszym ciągu zależy od producenta SoC – ponieważ twórcy SoC tak bardzo boją się ktoś odkrywa, jak włączają kilka diod LED lub wydają dźwięk przez głośnik, wysyłają na swoje ogromne ilości binarnych kropelek urządzenia. Te obiekty typu blob zawierają dość przerażająco niebezpieczny kod (po prostu spójrz na poprzednie biuletyny bezpieczeństwa Google, jeśli uważasz, że to przesada!) i wymagają aktualizacji. Oznacza to, że wymagane są zaktualizowane plany BSP.
Komputery stacjonarne (a co za tym idzie laptopy) różnią się architekturą zupełnie od urządzeń mobilnych. Twój telefon komórkowy lub tablet to tak naprawdę zastrzeżona bryła krzemu, zaprojektowana w pośpiechu przez ludzi, którzy chcą dobrze, ale nie mają wystarczająco dużo czasu, aby zrobić coś dobrego. Rynek porusza się tak szybko, że ledwo jest w stanie nadążać za tempem, w jakim marketing żąda wprowadzenia na rynek nowych produktów.
Oznacza to, że stosowane są skróty — Twój telefon nie będzie obsługiwany przez główne jądro Linuksa i przekonasz się, że każdy telefon ma inny sposób uruchamiania. Jednak w przypadku laptopa lub komputera stacjonarnego dostawcy zdecydowali się na kilka standardowych sposobów uruchamiania — poprzednio był to MBR (główny rekord rozruchowy) z BIOS-em, a teraz jest to UEFI. Ta standaryzacja umożliwia uruchomienie tego samego oprogramowania na każdym urządzeniu.
Chociaż ostatnio poczyniono pewne kroki w tym kierunku, zwłaszcza w związku z programem pomocy Sony i ich ujednolicone jądro, niepraktyczne jest uruchamianie jądra głównego na większości telefonów ze względu na ogromną liczbę nowych hacków specyficznych dla dostawców wprowadzanych do każdego urządzenia.
Podłączyłeś gniazdo słuchawkowe w złą stronę? Wystarczy włamać się do sterowników! Nie ma czasu na poprawianie tego w projekcie produkcyjnym.
W partii produkcyjnej 1 zespół produkcyjny zamontował moduł kamery do góry nogami? Wrzuć hack, aby sprawdzić wewnętrzny kod wersji i odwróć wideo, jeśli jest to wersja 1!
Tego typu hacki rozwiązują natychmiastowy problem, ale jedynie zarysowują dziwne i specyficzne dla produktu zmiany, które mają miejsce. Do licha, czasami w różnych wersjach tego samego telefonu znajdują się zupełnie różne chipy, ze względu na decyzje komercyjne. Prowadzi to do hacków w sterownikach i dziwnych decyzji, które miały sens tylko w tamtym momencie, aby telefon działał tak, aby można go było wysłać w następnym tygodniu.
Chociaż trwają prace nad obsługą 64-bitowych układów ARM w celu rozruchu przy użyciu UEFI, jak dotąd brak wyraźnego ruchu w kierunku bardziej ujednoliconego sposobu uruchamiania urządzeń ARM. To smutne, ponieważ oznacza to, że telefony będą nadal wyrzucane na długo przed końcem ich żywotności życia zawodowego, ponieważ utrzymanie długu technicznego i obciążeń dla nich jest po prostu zbyt kosztowne oprogramowanie.
Z drugiej jednak strony, jeśli producent OEM będzie zarabiał tylko na sprzedaży urządzenia, czy nie musi dopilnować, aby ludzie nadal kupowali nowe telefony? Czy rynek komputerów osobistych przeszedłby na ten model, gdyby nie było już 30 lat dynamiki i starszego oprogramowania korzystającego z otwartej platformy i standardu komputerów PC?
To trudne pytanie bez wewnętrznej wiedzy Qualcomma, której niestety w tej chwili nie mamy. Możemy jednak wyciągnąć pewne informacje z wymagań API sterownika Androida 7.0 i CTS. Wymagania CTS określają, czego Google oczekuje od urządzenia z danym oprogramowaniem. „Wielkim młotem” używanym do egzekwowania tych wymagań jest licencja Google na korzystanie z zastrzeżonego pakietu Usług Google Play – jeśli nie spełnisz tych wymagań, nie będziesz mógł dostarczyć Google Apps na to urządzenie. Chociaż dla niektórych to można uznać za zaletę, oczywiście nie jest to to, czego użytkownicy chcą i oczekują od urządzenia.
Android 7.0 nie dodał zbyt wiele poprzez zmiany w warstwie HAL lub sterownikach (jak opisano powyżej), więc jest mało prawdopodobne, aby jakakolwiek niezgodność wynikała właśnie stąd. Bardziej prawdopodobne jest jednak wprowadzenie problemu nowe wymagania dla API grafiki Vulkan lub GLES 3.1, być dostępnym, aby zdać egzamin CTS.
Obecnie wiele układów Systems-on-Chip (SoC) nie ma obsługi Vulkan w swoich procesorach graficznych, w tym MSM8974. Najprawdopodobniej w tym miejscu pojawi się również problem kompatybilności z Androidem 7.0. Ponownie jednak bez wewnętrznej wiedzy Qualcomm i ich planów na przyszłość trudno nam wydać ostateczne oświadczenie bez zastrzeżeń. W tej chwili jednak uważamy, że jest to prawdopodobne, że jest to „prosty” przypadek zaprzestania przez Qualcomm wsparcia dla (w ich oczach) starzejący się chipset MSM8974 i brak BSP (pakietu wsparcia płyty) dla wersji 7.0 na tej platformie. Gdyby tak było, oznaczałoby to, że producenci OEM byliby prawie pewni, że nie będą dostarczać wersji 7.0 na swoje urządzenia – musieliby w jakiś sposób znaleźć obsługę Vulkan lub GLE 3.1 dla swojego procesora graficznego i źródło GPU kod jest jedną z absurdalnie ściśle strzeżonych części stosów mobilnych (dodalibyśmy bez prawdziwego powodu – zobacz AMD, otwarte pozyskiwanie własnego sterownika AMDGPU na pulpicie dla Linuksa). Niestety jednak, Vulkan i grafika przyspieszona (GLES) są ogólnie nieco bardziej złożone niż zwykła dioda LED, więc nie będziemy widzieć podkładek zapewniających kompatybilność.
Ponieważ wersja 7.0 nie jest dostępna od niedawna, istnieje realna możliwość, że inne chipsety (inne niż niewielka liczba w samym AOSP) zostaną opuszczone opóźnienia w wersji 6.0 z powodu problemów ze sprzętem i sterownikami (tj. braku zaktualizowanego BSP) lub braku wsparcia dostawcy SoC w odniesieniu do Vulkan lub GLES 3.1 API. Obecnie ani Snapdragon 800, ani 801 nie obsługują jednego z nich.
Najlepiej będzie obserwować tę przestrzeń - programiści na XDA już robią duże postępy w zakresie nieoficjalnych portów do wersji 7.0 dla wielu urządzeń, które nie otrzymują oficjalnej obsługi wersji 7.0 od Google. Nie obsługują one jednak Vulkan ani GLES 3.1 – być może zaczną to robić twórcy gier na Androida doświadczysz frustracji spowodowanej fragmentacją, jeśli wystarczająca liczba użytkowników zacznie uruchamiać niestandardowe ROMy bez Vulkan lub GLES 3.1 wsparcie?
Apple zwykle wspiera swoją linię iPhone'ów w najnowszej wersji iOS przez około 5 lat - iPhone 4s został wprowadzony na rynek w październiku 2011 roku i był aktualizowany do iOS 9. Nie otrzyma jednak nadchodzącej aktualizacji iOS 10, co zapewniłoby telefonowi efektywną żywotność wynoszącą 5 lat, przy założeniu, że iOS 10 zostanie wydany około października. Warto zauważyć, że Apple nie zawsze obsługuje interfejsy API grafiki wstecznej – iPhone 4s i iPhone 5 tego nie robią obsługują interfejs API grafiki Metal firmy Apple, co jest nieco podobnym scenariuszem do tego obserwowanego w przypadku systemu Android Wulkan. Jedyna różnica polega na tym, że Apple nadal wspierał starsze urządzenia bez nowego interfejsu API grafiki.
Co myślisz? Czy będziesz flashować niestandardową pamięć ROM na swoim telefonie, aby przedłużyć jej żywotność? Czy powiedziałeś w komentarzach poniżej.