Ausführliche Kapitulation darüber, warum SD801-Geräte von Nougat ausgeschlossen sind

Aktualisiert, um die Entweder-Oder-Vulkan- oder OpenGL ES 3.1-Anforderung für Android 7.0 widerzuspiegeln

In letzter Zeit wurden viele Artikel über Versionsaktualisierungen, die Interaktionen zwischen Anbieter und Chipsatzhersteller und deren Bedeutung für zukünftige Geräte geschrieben. Warum ist dieser Wert diese Woche gestiegen?

Nun, diese Woche stellte sich heraus, dass das ehrwürdige Nexus 5 das Update auf Android 7.0 (Nougat) nicht erhalten wird, und Qualcomm hat angekündigt, dass dies nicht der Fall sein wird Bereitstellung von Unterstützung für den MSM8974 (besser bekannt als Snapdragon 801) auf 7.0. Dieser Artikel wurde in Zusammenarbeit mit XDA Recognized verfasst Entwickler Hummel.

Das Thema hat auf verschiedenen Nachrichtenseiten großes Interesse geweckt, aber Vielen entgehen die subtilen Nuancen dessen, was sich wirklich hinter den Kulissen abspielt

S. In diesem Artikel erfahren Sie mehr über die Funktionsweise von Software-Updates. Dabei nutzen wir unsere Erfahrung in der Zusammenarbeit mit OEMs bei deren offiziellen Firmware-Updates. Wir erklären Ihnen, was sich hinter den Kulissen abspielt (und warum) und warum Sie am Ende möglicherweise nicht die neueste Software auf Ihrem Telefon haben.

Der erste Schritt im Leben eines Android-Firmware-Updates ist das Upstream-Update. Daran arbeitet Google intern. Im Gegensatz zu „offenen Arbeitsabläufen“ wird Android mit einem geschlossenen Arbeitsablauf entwickelt, bei dem der Quellcode etwa jedes Jahr über die Mauer geworfen wird, wenn eine neue Version herauskommt. Ursprünglich sagte Google, dies ziele darauf ab, eine Fragmentierung durch Benutzer zu verhindern, die aktuelle Versionen verwenden Während sich die Dinge in den frühen Tagen schnell weiterentwickelten, scheinen sie diese Politik beibehalten zu haben Ort.

Irgendwann, normalerweise vor der öffentlichen Ankündigung eines Updates (obwohl sich diese Zeitpläne mit der kürzlichen Einführung öffentlicher Betas verschieben), OEMs werden auf ein bevorstehendes Update aufmerksam gemacht. Sie erhalten den Quellcode dann zu einem zweiten Zeitpunkt für das finale Update (bisher war das der Fall). manchmal etwas früher als der Start, obwohl uns auch Fälle bekannt sind, in denen es keinen frühen Zeitpunkt gibt freigeben).

Die Upstream-AOSP-Repositorys enthalten Geräteunterstützung nur für eine begrenzte Anzahl von Geräten. Dies sind normalerweise Ihre Nexus-Geräte. Aus Gründen, die in Kürze klar werden, ist es jedoch wichtig zu beachten, dass Google keine vollständige Hardware-Kontrolle über diese Geräte hat; Die Geräte werden von einem OEM hergestellt und dieser OEM kauft ein System-on-Chip (SoC) von einem Chipsatzhersteller.

Sobald der Quellcode veröffentlicht ist, wird sich das Firmware-Team des OEM (im übertragenen Sinne) zurücklehnen und die Füße hochlegen. Der Hauptquellbaum von Android bietet keine Hardwareunterstützung für die unzähligen Chipsätze, die in Versandgeräten verwendet werden. Ihr Qualcomm-Chipsatz wird beispielsweise höchstwahrscheinlich nicht von AOSP unterstützt. Ihr Exynos ist das ganz sicher nicht. Mediatek oder HiSilicon? Vergiss es!

Das BSP enthält die Treiber und Hardware-Abstraktionsschichten (HALs), die zum Ausführen von Android erforderlich sind

Was jetzt benötigt wird, ist ein Board-Support-Paket (BSP). Hierbei handelt es sich um ein äußerst vertrauliches Paket proprietärer Komponenten, das von einem Chipsatzhersteller an einen OEM geliefert wird. Das BSP enthält den notwendigen Quellcode, damit OEMs Android erstellen können, sowie die notwendigen Treiber für ihr Gerät.

An dieser Stelle ist anzumerken, dass OEMs wie Qualcomm ihren OEM-Partnern nicht unbedingt völlig vertrauen – das BSP wird auf einer „Need-to-know“-Basis zur Verfügung gestellt. OEMs erhalten normalerweise keinen Zugriff auf den Quellcode für einige der streng geheimen Teile des Geräts (z. B. die Software, die auf dem Basisband läuft). Die Schließung dieses Teils birgt sicherlich auch potenzielle Probleme, wie die Nähe zeigt reichlich Und wiederkehrend ASN.1 Analyse von Schwachstellen.

Das BSP enthält die Treiber und Hardware-Abstraktionsschichten (HALs), die erforderlich sind, um Android auf Ihrem Gerät zum Laufen zu bringen. AOSP enthält eine Reihe von HALs, die als Definitionen dafür dienen, was das Betriebssystem von Ihren Treibern erwartet. Um ein lächerlich vereinfachtes (und zu Demonstrationszwecken erfundenes) Beispiel zu verwenden, stellen wir uns die Taschenlampe auf Ihrem Telefon vor.

Ein Beispiel für HAL – Ihre Taschenlampe

Stellen wir uns vor, Ihr Gerät hat eine Taschenlampe auf der Rückseite (wenn Sie ein Nexus 7 2013 haben, müssen Sie sich etwas mehr vorstellen als alle anderen – sorry!). Dies wird von einem Fahrer gesteuert. Nehmen wir für unser verrückt einfaches Beispiel an, dass der HAL v1 sagt, dass Sie eine Funktion namens „setLED“ haben sollten, die einen einzelnen Parameter übernimmt, den Zustand des Lichts. Es ist ein boolescher Wert – wahr oder falsch. In C würde das etwa so aussehen:

void setLED(bool ledState) {

// here is the actual code to turn on or off the LED, based on ledState

}

Diese Funktion ist im BSP-Quellcode definiert. Das BSP wird dann vom OEM während der ROM-Erstellung kompiliert und dieses wird zu einer der proprietären „.so“-Bibliotheken auf der Herstellerpartition oder dem Herstellerbereich Ihres Geräts. Dadurch kann ein OEM bestimmte Teile der Funktionsweise seines Geräts geheim halten. Nehmen wir zunächst an, dass sie verhindern wollen, dass jeder sieht, wie sie diese LED ein- und ausschalten.

Stellen Sie sich nun vor, Google veröffentlicht eine aktualisierte Version seiner HALs in einer zukünftigen Android-Version. Sie kommen nun zu dem Schluss, dass es schön wäre, Ihnen die Möglichkeit zu geben, die Helligkeit Ihrer LED zu aktualisieren, anstatt sie nur ein- oder auszuschalten. Vielleicht ist dies für adaptives Flash gedacht, oder vielleicht nur, um ein HAL-Update zu erzwingen und die Chipsatzhersteller im Geschäft zu halten? Wir lassen Sie als Leser Ihre eigene Meinung dazu bilden. Einige HAL-Updates haben eindeutige Vorteile (z. B. das neue Kamera-HAL, das Rohaufnahmen belichtet und ähnliches), während bei anderen der Zweck etwas weniger klar ist.

Nehmen wir an, Google sagt, dass Sie mit diesem neuen (fiktiven) HAL für Helligkeit erneut eine Funktion namens setLED verfügbar machen müssen, dieses Mal jedoch mit einer übergebenen Ganzzahl für die Helligkeit. Jetzt würde 0 es ausschalten und 255 würde es voll einschalten.

Wenn Sie der OEM sind, können Sie Ihren streng geheimen Code zum Einschalten dieser LED verwenden und ihn in diese neue Funktion einfügen. Sie könnten sogar die Pulsweitenmodulation verwenden, um die Helligkeit der LED basierend auf der Zahl anzupassen. Sie ändern die Funktion so, dass sie jetzt wie folgt aussieht:

void setLED(uint8_t ledBrightness) {

// some super-secret and ultra-confidential proprietary way to set LED brightness

}

Na und? Nun, diese neue Android-Version ist nicht mehr mit vorhandenen „Blobs“ kompatibel. Ihr OEM muss diese neuen Blobs verwenden, da das Android-Betriebssystem die neue Funktionsdefinition erwartet und die alte nicht „findet“, wenn es nach einer Möglichkeit zum Einstellen der LED sucht.

Lassen Sie uns an dieser Stelle eine kurze Pause einlegen, um zu betrachten, wie benutzerdefinierte ROMs (aus dem Quellcode erstellt) hier funktionieren. Das ist es, was die Klugen unter Ihnen gerade jetzt auf Ihren Bildschirm schreien werden – schließlich sind wir XDA, die Heimat der HTC HD2, das langlebigste Telefon der Welt... (Nur zur Veranschaulichung, die verrückten Genies da drüben rennen Android 6.0 auf dem HD2 heutzutage! Nicht schlecht für ein Telefon, das 2009 ursprünglich mit Windows Mobile 6.5 ausgeliefert wurde.

Hier werden verschiedene Ansätze verfolgt – manchmal hacken Entwickler im ROM herum und weisen das Betriebssystem an, die alten Funktionsdefinitionen zu verwenden. Das ist etwas chaotisch und erfordert viele Änderungen, die beibehalten werden müssen. Der andere Ansatz besteht darin, die OEM-Binärdatei zu „shimen“.

Der „Shim“-Ansatz besteht darin, selbst eine kleine neue Bibliothek zu schreiben und zu erstellen, die die erwartete Funktionsdefinition enthält – in unserem Beispiel würden wir die Ganzzahl für die Helligkeit unterstützen. Anschließend wird dies innerhalb der Unterlegscheibe so übersetzt, dass es den Anforderungen des alten HAL entspricht. Für unser Beispiel würden wir vielleicht sagen, dass jede gewünschte Helligkeit über 128 die LED einschaltet und jede Helligkeit darunter sie ausschaltet. Oder Sie könnten sagen, dass alles, was nicht Null ist, es einschaltet. Es liegt am Entwickler. Sie kompilieren den Shim und veranlassen Android, ihn anstelle des nativen zu verwenden. Der Shim ruft dann den OEM-Blob auf.

Ein kurzer „ADB-Push“ und ein Neustart sollten den Shim zum Laufen bringen und Ihnen die Steuerung Ihrer fiktiven LED ermöglichen, auch wenn Sie nur den alten HAL haben.

Das Problem besteht darin, dass es sich eindeutig um einen unvollkommenen Prozess handelt. Jetzt gibt es einige Besonderheiten: Dieses Gerät hat einen ziemlich schäbigen Blitz, der entweder ganz an oder ganz aus ist. Das ist nicht ideal – das Betriebssystem glaubt, dass es ein sehr sanftes Licht erzeugt, aber der eigentlichen LED wird mitgeteilt, dass sie an einem Wettbewerb mit künstlicher Sonne teilnimmt, und versucht, Sie zu blenden. Aber hey, das Leben ist nicht perfekt und Sie haben jetzt eine funktionierende LED an Ihrem alten Telefon!

(Ja, das ist einer der Gründe, warum es Macken und Fehler gibt, wenn XDA-Benutzer und -Entwickler ihre verrückten und wahnsinnigen Portierungskünste vollbringen. Ich meine, zum Teufel, das Galaxy S II ist scheinbar brauchbar Jetzt Android 6.0 ROM. Viele im letzten Jahr herausgebrachte Telefone verfügen immer noch nicht über 6.0!)

Kehren wir zurück zur OEM-Perspektive. Leider arbeiten die meisten OEMs bereits mindestens ein Telefon über unserem aktuellen Stand. Ihr Fokus liegt auf dem nächsten Telefon, das sie verkaufen wollen – man kann es ihnen nicht wirklich verübeln, da sie nur mit den Geräten, die sie verkaufen, Geld verdienen. Mit Geräten, die sie vor ein oder zwei Jahren verkauft haben, verdienen sie kein Geld, also müssen sie immer wieder neue Geräte auf den Markt bringen, um zu existieren. Dies ist einer der Gründe, warum HTC und Blackberry in Schwierigkeiten sind – es spielt keine Rolle, wie viele Führungskräfte ihr altes Blackberry Curve fest im Griff haben, da sie dort kein neues Gerät verkaufen.

Wenn der OEM kein BSP erhält, wird er nicht den XDA-Ansatz verfolgen, einen Build zusammenzuhacken. Warum? Also, Sie müssen diese Firmware für ihre Kunden unterstützen. Wenn sie eine Firmware veröffentlichen, die nur halbwegs funktioniert, werden die Benutzer sie hassen, schimpfen und toben und dafür sorgen, dass ihre Support-Hotlines tagelang klingeln.

OEMs müssen sich auch mit Netzbetreibern auseinandersetzen, zumindest in außereuropäischen Märkten. Netzbetreiber möchten nicht, dass Kunden Probleme mit Software-Updates haben. Tatsächlich möchten Netzbetreiber oft lieber keine Software-Updates veröffentlichen.

Um dies zu verstehen, stellen Sie sich Ihre Großtante Alice vor. Sie ist diejenige, die Sie zu ungünstigen Tageszeiten anruft und um Hilfe bei „dieser Computersache“ bittet. Sie beschreiben dann, wie Sie auf das „Startmenü“ klicken, müssen es als „große Flagge in der unteren linken Ecke“ identifizieren und stoßen auf Verwirrung. Ungefähr 45 Minuten (und viel Frustration) später stellt sich heraus, dass Tante Alice ihr Startmenü an den rechten Bildschirmrand gezogen hat und es einfach zurückziehen musste. Ja, mit der linken Maustaste!

Stellen Sie sich nun vor, Sie hätten tausend Tante Alice. Sie alle rufen Ihren Kundensupport an, können Candy Crush nicht auf ihrem Telefon finden und befürchten, dass ein Hacker es von ihrem Telefon gelöscht hat. Oh, und die Symbole sehen jetzt etwas anders aus – vielleicht ist der Hacker immer noch in ihrem Telefon?

Ja, das soll ein bisschen unbeschwerter Humor sein, aber solange Sie nicht erfahren, warum Menschen ihren Mobilfunkanbieter anrufen, um Unterstützung zu erhalten, werden Sie nicht glauben, welche Probleme sie haben. Ein Software-Update, das die Funktionsweise des Telefons oder den Standort ändert, verursacht einen erheblichen Supportaufwand. Zumindest ist eine Umschulung des Support-Personals erforderlich (da die meisten von ihnen leider nicht Ihre begeisterten XDA-Leser sind).

Sobald der OEM das BSP erhält, portiert er sein ROM und wendet alle Änderungen auf das ROM an. Sie stapeln ihre Bloatware und fügen einen schrecklichen Cartoon-ähnlichen Skin hinzu, der besser in den Anime eines Teenagers passen würde. Dann werden sie es testen.

Eine Menge.

Es gibt alle möglichen Anforderungen, die Ihr Telefon erfüllen muss. Die Mobilfunknetze sind darauf ausgelegt, darauf zu vertrauen, dass sich die Benutzerausrüstung (wir nennen sie das Telefon) korrekt verhält. Das bedeutet, dass viele Tests erforderlich sind, um das Gerät zu genehmigen. Bei Softwareaktualisierungen besteht die Gefahr, dass sich das Verhalten ändert. Daher müssen die Dinge erneut getestet werden. Aus diesem Grund werden Ihnen häufig Informationen über bevorstehende Software-Updates von Sony von externen Testdiensten angezeigt, die bestätigen, dass die Firmware den Testanforderungen entspricht.

Jetzt... Was passiert nach ein oder zwei Updates (oder in manchen Fällen auch keinem)? Der SoC-Hersteller wird dem OEM kein aktualisiertes BSP geben. Schließlich wird der SoC-Hersteller davon nicht viel haben. Der OEM verdient mit Ihrem Telefon kein Geld mehr, seit es verkauft wurde. Und zu diesem Zeitpunkt erhält Ihr Telefon keine weiteren Hauptversionsaktualisierungen.

Die Reduzierung der Anzahl der BSPs, die der OEM liefern möchte, ist eine großartige Möglichkeit, Geld zu sparen – wenn Sie nur das aktuelle benötigen und nicht vorhaben, eine größere Version zu liefern Dies spart Geld beim anfänglichen SoC-Kauf und bei der Lizenzierung, allerdings auf Kosten einiger verärgerter Nerds auf XDA, die sich später wundern, warum sie keinen SoC bekommen haben aktualisieren.

Updates sind komplex. An der Kette sind viele verschiedene Personen beteiligt. Nichts davon entschuldigt OEMs vor dem derzeitigen mangelnden und erbärmlichen Stand der Android-Updates. Dennoch gibt es hier einige echte Herausforderungen.

Viele OEMs sind dafür verantwortlich, dass sie zu viel versprechen unvermeidliche Unterlieferung, die wir jetzt assoziieren. Die traurige Realität ist, dass Software-Updates für die meisten OEMs nur ein Ärgernis sind, auf das sie verzichten könnten.

Der Mobilfunksektor ist größtenteils in der Denkweise der Feature-Phones verankert. Das heißt, ein Gerät erhält nie Updates. Testen Sie es einmal, versenden Sie es und schauen Sie nie zurück. Angesichts der Sicherheitsprobleme moderner Smartphones und der schieren Komplexität der Ausführung eines vollständigen Allzweckbetriebssystems mit Hunderten externer Bibliotheken ist dies keine Option mehr. Oder zumindest es sollte nicht Sei. Google hat einige Schritte unternommen, um dieses Problem zu beheben, indem es zumindest Sicherheitsbulletins und Patches für bestehende Versionen veröffentlicht hat von Android (denken Sie daran, dass bis vor Kurzem die einzige Möglichkeit, Sicherheitsupdates zu erhalten, über eine neue Hauptversion des Android-Betriebssystems war!)

Leider reicht das jedoch nicht wirklich aus. Auch wenn Google ständig Updates veröffentlicht, hängt die Sicherheit Ihres Geräts immer noch vom SoC-Hersteller ab – da SoC-Hersteller große Angst davor haben Wenn jemand herausfindet, wie er ein paar LEDs einschaltet oder über einen Lautsprecher einen Ton erzeugt, schickt er riesige Mengen binärer Blobs auf sich Geräte. Diese Blobs enthalten ziemlich schrecklich unsicheren Code (werfen Sie einfach einen Blick auf frühere Google-Sicherheitsbulletins, wenn Sie das für übertrieben halten!) und müssen aktualisiert werden. Das bedeutet, dass aktualisierte BSPs erforderlich sind.

Desktop-Computer (und damit auch Laptops) haben eine völlig andere Architektur als mobile Geräte. Ihr Mobiltelefon oder Tablet ist praktisch ein stark proprietärer Siliziumklumpen, der in aller Eile von Leuten entworfen wurde, die es gut meinen, aber nicht annähernd genug Zeit haben, etwas Gutes zu machen. Der Markt bewegt sich so schnell, dass sie kaum mit der Geschwindigkeit mithalten können, mit der das Marketing die Einführung neuer Produkte fordert.

Dies bedeutet, dass Verknüpfungen verwendet werden – Ihr Telefon wird nicht vom Mainline-Linux-Kernel unterstützt und Sie werden feststellen, dass jedes Telefon eine andere Art zum Booten hat. Auf Ihrem Laptop oder Desktop haben sich die Anbieter jedoch auf einige Standardmethoden zum Booten geeinigt – früher war es MBR (Master Boot Record) mit BIOS und jetzt ist es UEFI. Diese Standardisierung ermöglicht es, auf jedem Gerät die gleiche Software auszuführen.

Zwar gab es in letzter Zeit einige Schritte in diese Richtung, insbesondere mit dem Outreach-Programm von Sony und ihren einheitlicher Kernel, ist es auf den meisten Telefonen nicht praktikabel, einen Mainline-Kernel auszuführen, da auf jedem Gerät eine Vielzahl neuer herstellerspezifischer Hacks eingeführt werden.

Kopfhöreranschluss falsch herum verkabelt? Hacken Sie es einfach in die Treiber! Es bleibt keine Zeit, das Problem im Produktionsdesign zu beheben.

Das Fertigungsteam hat das Kameramodul in Produktionscharge 1 verkehrt herum montiert? Führen Sie einen Hack ein, um den internen Versionscode zu überprüfen, und drehen Sie das Video um, wenn es Version 1 ist!

Hacks wie diese lösen das unmittelbare Problem, kratzen aber nur an der Oberfläche der seltsamen und produktspezifischen Änderungen, die gerade stattfinden. Aufgrund kommerzieller Entscheidungen gibt es manchmal sogar völlig unterschiedliche Chips in verschiedenen Versionen desselben Telefons. Dies führte zu Hacks in den Treibern und seltsamen Entscheidungen, die zu diesem Zeitpunkt nur Sinn machten, um das Telefon zum Laufen zu bringen, damit es in der nächsten Woche versendet werden kann.

Zwar wird derzeit an der Mainline-Unterstützung für 64-Bit-ARM-Chips zum Booten mit UEFI gearbeitet, dies ist jedoch bisher der Fall Es gibt keine klare Entwicklung hin zu einer standardisierten Methode zum Booten von ARM-Geräten. Und das ist traurig, denn es bedeutet, dass Telefone weiterhin lange vor dem Ende ihrer Lebensdauer weggeworfen werden Arbeitsleben, weil es einfach zu teuer ist, die technischen Schulden und Belastungen aufrechtzuerhalten Software.

Wenn ein OEM jedoch nur mit dem Verkauf eines Geräts Geld verdient, muss er dann nicht sicherstellen, dass die Leute weiterhin neue Telefone kaufen? Würde der PC-Markt auf dieses Modell umsteigen, wenn es nicht bereits 30 Jahre Dynamik und Legacy-Software gäbe, die die offene PC-Plattform und den Standard nutzt?

Ohne Insiderwissen von Qualcomm, über das wir derzeit leider nicht verfügen, ist dies eine schwierige Frage. Wir können jedoch einige Informationen aus der 7.0 Android-Treiber-API und den CTS-Anforderungen ziehen. Die CTS-Anforderungen legen fest, was Google von einem Gerät erwartet, auf dem eine bestimmte Firmware ausgeführt wird. Der „große Hammer“, der zur Durchsetzung dieser Anforderungen eingesetzt wird, ist die Lizenzierung von Google zur Nutzung seines proprietären Google Play Services-Pakets – Wenn Sie sich nicht daran halten, können Sie Google Apps nicht auf dem Gerät bereitstellen. Während dies für einige der Fall ist könnte als Vorteil angesehen werden, das ist offensichtlich nicht das, was Benutzer von einem Gerät wollen und erwarten.

Android 7.0 hat nicht viel an HAL oder Treibern geändert (wie oben beschrieben), daher ist es unwahrscheinlich, dass eine Inkompatibilität speziell von dort herrührt. Problematisch dürfte jedoch die Einführung eines sein neue Anforderung entweder für die Vulkan-Grafik-API oder GLES 3.1, verfügbar sein, um CTS zu bestehen.

Derzeit verfügen viele Systems-on-Chip (SoCs) nicht über Vulkan-Unterstützung auf ihren Grafikprozessoren, darunter auch der MSM8974. Hier wird höchstwahrscheinlich auch das Problem der Kompatibilität mit Android 7.0 auftreten. Allerdings ist es für uns ohne Insiderwissen von Qualcomm und deren Zukunftspläne schwierig, eine endgültige Aussage zu treffen, ohne sie zu qualifizieren. Im Moment halten wir es jedoch für wahrscheinlich, dass es sich hierbei um den „einfachen“ Fall handelt, dass Qualcomm den Support für einstellt den (in ihren Augen) veralteten MSM8974-Chipsatz und kein BSP (Board Support Package) für 7.0 auf dieser Plattform. Wenn das der Fall wäre, würde das bedeuten, dass OEMs fast sicher nicht 7.0 auf dem Gerät ausliefern würden – sie müssten irgendwie Vulkan- oder GLEs 3.1-Unterstützung für ihre GPU und GPU-Quelle finden Code ist einer der lächerlich streng gehüteten Teile der mobilen Stacks (ohne wirklichen Grund, würden wir hinzufügen – sehen Sie sich AMD an, das seinen eigenen AMDGPU-Treiber als Open-Source-Lösung für den Desktop anbietet). Linux). Leider sind Vulkan und beschleunigte (GLES) Grafiken im Allgemeinen jedoch etwas komplexer als eine einfache LED, daher werden wir hier keine Unterlegscheiben sehen, um Kompatibilität herzustellen.

Da 7.0 noch nicht lange auf dem Markt ist, besteht die reale Möglichkeit, dass andere Chipsätze (abgesehen von der kleinen Anzahl innerhalb von AOSP selbst) übrig bleiben hinter 6.0 zurück, entweder aufgrund von Hardware- und Treiberproblemen (d. h. kein aktualisiertes BSP) oder mangelnder SoC-Anbieterunterstützung in Bezug auf Vulkan oder GLES 3.1 API. Derzeit unterstützen weder der Snapdragon 800 noch der 801 eines davon.

Am besten beobachten Sie diesen Raum - Entwickler auf XDA machen bereits gute Fortschritte mit inoffiziellen Portierungen auf 7.0 für viele Geräte, die keine offizielle 7.0-Unterstützung von Google erhalten. Diese unterstützen jedoch weder Vulkan noch GLES 3.1 – möglicherweise werden Entwickler von Spielen auf Android damit beginnen Erleben Sie Frustration durch Fragmentierung, wenn genügend Benutzer beginnen, benutzerdefinierte ROMs ohne Vulkan oder GLES 3.1 auszuführen Unterstützung?

Apple unterstützt seine iPhone-Reihe in der Regel seit etwa fünf Jahren auf der neuesten iOS-Version – das iPhone 4s kam im Oktober 2011 auf den Markt und wurde bis iOS 9 auf dem neuesten Stand gehalten. Allerdings wird es das kommende iOS 10-Update nicht erhalten, was dem Telefon eine effektive Lebensdauer von fünf Jahren geben würde, vorausgesetzt, dass iOS 10 etwa im Oktober auf den Markt kommt. Es ist erwähnenswert, dass Apple die Grafik-API-Unterstützung nicht immer zurückportiert – das iPhone 4s und das iPhone 5 tun dies nicht verfügen über die Metal-Grafik-API von Apple, ein ähnliches Szenario wie bei Android in Vulkan. Der einzige Unterschied besteht darin, dass Apple die älteren Geräte weiterhin ohne die neue Grafik-API unterstützt.

Was denken Sie? Werden Sie ein benutzerdefiniertes ROM auf Ihrem Telefon flashen, um dessen Lebensdauer zu verlängern? Haben Sie in den Kommentaren unten gesagt?