Vom Laden zum Regal: Eine detaillierte Darstellung, warum MSM8974-Geräte von Nougat ausgeschlossen sind

Aktualisiert, um die Anforderungen von Vulkan oder OpenGL ES 3.1 für Android 7.0 zu erfüllen

In letzter Zeit wurde eine Vielzahl von Artikeln über Versionsaktualisierungen, die Interaktionen zwischen Hersteller und Chipsatzhersteller und die damit verbundenen Auswirkungen auf Geräte verfasst. Warum ist dies diese Woche so weit fortgeschritten?

Nun, es ist diese Woche herausgekommen, da das ehrwürdige Nexus 5 das Update auf Android 7.0 (Nougat) nicht erhalten wird und Qualcomm angekündigt hat, das MSM8974 (allgemein bekannt als Snapdragon 801) auf 7.0 nicht zu unterstützen. Dieser Artikel wurde in Zusammenarbeit mit Recognized Developer bumble-bee verfasst.

Das Thema hat auf verschiedenen Nachrichtenseiten einiges Interesse geweckt, aber viele verpassen die subtilen Nuancen dessen, was wirklich hinter den Kulissen vor sich geht. In diesem Artikel wird die Funktionsweise von Softwareupdates anhand unserer Erfahrungen mit OEMs bei offiziellen Firmware-Updates erläutert. Wir zeigen Ihnen, was sich hinter den Kulissen abspielt (und warum) und warum Sie möglicherweise nicht die neueste Software auf Ihrem Telefon erhalten.

Der erste Schritt im Leben eines Android-Firmware-Updates ist das Upstream-Update. Daran arbeitet Google intern. Im Gegensatz zu „offenen Workflows“ wird Android mithilfe eines geschlossenen Workflows entwickelt, bei dem der Quellcode jedes Jahr über die Wand geworfen wird, wenn eine neue Version herauskommt. Ursprünglich sagte Google, dies solle die Fragmentierung von Leuten verhindern, die auf dem neuesten Stand der Technik waren, während sich die Dinge in den frühen Tagen rasant weiterentwickelten, aber sie schienen diese Richtlinie beibehalten zu haben.

Zu einem bestimmten Zeitpunkt, normalerweise vor der öffentlichen Ankündigung eines Updates (obwohl sich mit der Einführung der öffentlichen Betas diese Zeitskalen verschieben), werden OEMs auf ein bevorstehendes Update aufmerksam gemacht . Sie erhalten dann den Quellcode zu einem zweiten Zeitpunkt für das endgültige Update (in der Vergangenheit war dies manchmal ein wenig vor dem Start, obwohl uns auch Fälle bekannt sind, in denen es keine vorzeitige Veröffentlichung gibt).

Die Upstream-AOSP-Repositorys enthalten Geräteunterstützung für nur eine begrenzte Anzahl von Geräten. Dies sind normalerweise Ihre Nexus-Geräte. Aus Gründen, die in Kürze klar werden, ist jedoch 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 Hardware-Unterstützung für die Vielzahl von Chipsätzen, die in Versandgeräten verwendet werden. Ihr Qualcomm-Chipsatz wird beispielsweise in AOSP höchstwahrscheinlich nicht unterstützt. Dein Exynos ist es definitiv nicht. Mediatek oder HiSilicon? Vergiss es!

"Das BSP enthält die Treiber und Hardware-Abstraktionsschichten (HALs), die für die Ausführung von Android erforderlich sind."

Was jetzt benötigt wird, ist ein Board Support Package (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 erforderlichen Quellcode, damit OEMs Android und die erforderlichen Treiber für ihr Gerät erstellen können.

An dieser Stelle ist anzumerken, dass OEMs wie Qualcomm ihren OEM-Partnern nicht unbedingt voll vertrauen - das BSP wird auf der Basis von „Need to Know“ zur Verfügung gestellt. OEMs erhalten normalerweise keinen Zugriff auf den Quellcode für einige der überaus geheimen Teile des Geräts (z. B. die auf dem Basisband ausgeführte Software). Das Abschließen dieses Teils birgt sicherlich auch potenzielle Probleme, wie die nahezu reichlichen und wiederkehrenden ASN.1-Parsing-Schwachstellen zeigen.

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 Definition dafür dienen, was das Betriebssystem von Ihren Treibern erwartet. Um ein lächerlich vereinfachtes (und zum Zweck der Demonstration ausgedachtes) Beispiel zu verwenden, stellen wir uns die Taschenlampe auf Ihrem Telefon vor.

Ein Beispiel 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 die v1 HAL besagt, dass Sie eine Funktion namens „setLED“ haben sollten, die einen einzelnen Parameter, den Lichtzustand, übernimmt. Es ist ein Boolescher Wert - wahr oder falsch. In C würde dies ungefähr so ​​aussehen:

void setLED (bool ledState) {

// hier ist der eigentliche Code zum Ein- oder Ausschalten der LED, basierend auf ledState

}

Diese Funktion ist im BSP-Quellcode definiert. Der BSP wird dann vom OEM beim Erstellen des ROM kompiliert und wird zu einer der proprietären ".so" -Bibliotheken auf der Partition des Anbieters oder im Bereich Ihres Geräts. Auf diese Weise kann ein OEM bestimmte Teile der Funktionsweise seines Geräts geheim halten. Nehmen wir vorerst an, sie möchten verhindern, dass alle sehen, wie sie diese LED ein- und ausschalten.

Stellen Sie sich nun vor, Google veröffentlicht eine aktualisierte Version seiner HALs in einer zukünftigen Version von Android. Sie entscheiden nun, dass es schön wäre, die Helligkeit Ihrer LED zu aktualisieren, anstatt sie nur ein- oder auszuschalten. Vielleicht ist dies für adaptives Flash gedacht oder nur, um ein HAL-Update zu erzwingen und die Chipsatzhersteller im Geschäft zu halten? Wir lassen Sie, den Leser, Ihre eigene Meinung dazu abgeben. Einige HAL-Aktualisierungen haben deutliche Vorteile (wie die neue Kamera HAL zur Belichtung von Rohaufnahmen und Ähnlichem), während andere in ihrem Zweck etwas weniger klar sind.

Nehmen wir an, dass Sie mit diesem neuen (fiktiven) HAL für Helligkeit die Funktion setLED erneut verfügbar machen müssen, diesmal jedoch mit einer Ganzzahl für Helligkeit. Jetzt würde 0 es ausschalten und 255 würde es voll aufsetzen.

Wenn Sie der OEM sind, können Sie Ihren Super-Secret-Code verwenden, um diese LED einzuschalten und in diese neue Funktion zu integrieren. Sie können sogar die Pulsweitenmodulation verwenden, um die Helligkeit der LED basierend auf der Anzahl anzupassen. Du änderst die Funktion so, dass sie jetzt so aussieht:

void setLED (uint8_t ledBrightness) {

// Eine supergeheime und äußerst vertrauliche Methode zum Einstellen der LED-Helligkeit

}

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

Lassen Sie uns an dieser Stelle einen kurzen Blick darauf werfen, wie benutzerdefinierte ROMs (die aus dem Quellcode erstellt wurden) hier verwaltet werden. Das ist es, was die Schlauen unter Ihnen gerade auf Ihrem Bildschirm schreien werden - schließlich sind wir das Zuhause des HTC HD2, des langlebigsten Telefons der Welt… (nur zur Veranschaulichung, die verrückten Genies dort laufen mit Android 6.0 auf dem HD2 in diesen Tagen! Nicht schlecht für ein Telefon, das ursprünglich mit Windows Mobile 6.5 im Jahr 2009 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 ein bisschen chaotisch und es müssen viele Änderungen vorgenommen werden. Der andere Ansatz besteht darin, die OEM-Binärdatei zu „shimen“.

Der „Shim“ -Ansatz besteht darin, selbst eine winzige 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. Im Shim wird dies dann übersetzt, um die Anforderungen des alten HAL zu erfüllen. In unserem Beispiel würden wir also vielleicht sagen, dass jede Helligkeit, die über 128 angefordert wird, die LED einschaltet und alles, was darunter liegt, sie ausschaltet. Oder Sie könnten sagen, dass alles, was nicht Null ist, es einschaltet. Es liegt an dem Entwickler. Sie kompilieren das Shim und bringen Android dazu, es anstelle des nativen zu verwenden. Das Shim ruft dann den OEM-Blob auf.

Ein schneller "adb push" und Neustart sollte das Shim zum Laufen bringen und Sie können Ihre fiktive LED steuern, obwohl Sie nur die alte HAL haben.

Das Problem ist, dass dies eindeutig ein unvollkommener Prozess ist. Sie werden jetzt Macken bekommen - dieses Gerät wird einen ziemlich miesen Blitz haben, der entweder ganz an oder ganz aus ist. Das ist nicht ideal - das Betriebssystem glaubt, dass es ein sehr sanftes Licht abgibt, aber der tatsächlichen LED wird mitgeteilt, dass sie an einem künstlichen Sonnenwettbewerb teilnimmt und versucht, Sie zu blenden. Aber hey, das Leben ist nicht perfekt und du hast jetzt eine funktionierende LED auf deinem alten Handy!

(Ja, dies ist einer der Gründe, warum es Macken und Bugs gibt, wenn Benutzer und Entwickler ihre verrückten und wahnsinnigen Talente beim Portieren bewältigen. Ich meine, das Galaxy S II verfügt derzeit über ein anscheinend verwendbares Android 6.0-ROM. Viele Letztes Jahr erschienene Handys haben immer noch nicht 6.0!)

Kehren wir zur Perspektive des OEM zurück. Leider arbeiten die meisten OEMs bereits mindestens 1 Telefon vor dem aktuellen Standort. Sie konzentrieren sich auf das nächste Telefon, das sie verkaufen werden - Sie können es ihnen nicht wirklich vorwerfen, da sie nur mit den von ihnen verkauften Geräten Geld verdienen. Sie verdienen kein Geld mit Geräten, die sie vor ein oder zwei Jahren verkauft haben, und müssen daher weiterhin neue Geräte freigeben, 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 ihre alte Blackberry-Kurve im Griff haben, da sie dort keinen Verkauf neuer Geräte erhalten.

Wenn der OEM kein BSP erhält, wird er den Ansatz, einen Build zusammen zu hacken, nicht vernachlässigen. Warum? Nun, sie müssen diese Firmware für ihre Kunden unterstützen . Wenn sie eine Firmware herausbringen, die nur zur Hälfte funktioniert, hassen sie die Benutzer, toben und toben und lassen ihre Support-Linien tagelang läuten.

OEMs müssen sich zumindest in außereuropäischen Märkten mit Carriern auseinandersetzen . Carrier möchten nicht, dass Kunden Probleme mit Software-Updates haben. In der Tat würden 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. Anschließend beschreiben Sie, wie Sie auf das „Startmenü“ klicken und es als „große Flagge in der linken unteren Ecke“ kennzeichnen müssen, und stoßen auf Verwirrung. Ungefähr 45 Minuten (und viel Frust) 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 vor, Sie haben tausend Tante Alice. Sie rufen alle beim Kundensupport an und können Candy Crush nicht auf ihrem Telefon finden. Sie sind besorgt, dass ein Hacker sie von ihrem Telefon gelöscht hat. Oh, und die Icons sehen jetzt ein bisschen anders aus - vielleicht ist der Hacker noch in ihrem Handy?

Ja, das soll ein bisschen unbeschwerter Humor sein, aber bis Sie die Gründe erfahren, warum die Leute ihre Spedition zur Unterstützung anrufen, werden Sie den Problemen, die sie haben, nicht glauben. Ein Software-Update, das die Funktionsweise des Telefons oder den Standort ändert, verursacht einen erheblichen Support-Aufwand. Zumindest ist eine Umschulung des Support-Personals erforderlich (da die meisten von ihnen leider nicht Ihr begeisterter Leser sind).

Sobald der OEM den BSP erhält, portiert er sein ROM und wendet alle Änderungen auf das ROM an. Sie stapeln ihre Bloatware und fügen eine schreckliche Cartoon-artige Haut hinzu, die im Anime eines Teenagers mehr zu Hause aussieht. Dann werden sie es testen.

Viel.

Es gibt alle Arten von Anforderungen, die Ihr Telefon erfüllen muss. Die Mobilfunknetze sind so konzipiert, dass sie darauf vertrauen, dass sich die Benutzergeräte (wie wir sie nennen) korrekt verhalten. Dies bedeutet, dass viele Tests erforderlich sind, um das Gerät zuzulassen. Softwareupdates können das Verhalten ändern, daher müssen die Dinge erneut getestet werden. Aus diesem Grund werden häufig Informationen zu bevorstehenden Software-Updates von Sony von externen Testdiensten angezeigt, die bestätigen, dass die Firmware den Testanforderungen entspricht.

Nun ... was passiert nach einem oder zwei Updates (oder in einigen Fällen auch keinem)? Der SoC-Hersteller gibt dem OEM kein aktualisiertes BSP . Schließlich wird der SoC-Hersteller nicht viel davon haben. Der OEM verdient mit Ihrem Telefon kein Geld mehr, seit es verkauft wurde. Zu diesem Zeitpunkt erhält Ihr Telefon keine größeren Versionsaktualisierungen mehr.

Das Reduzieren der Anzahl der vom OEM gewünschten BSPs ist eine hervorragende Möglichkeit, um Geld zu sparen. Wenn Sie nur die aktuelle Version benötigen und keine größeren Versionserhöhungen vornehmen möchten, können Sie beim erstmaligen Kauf und bei der Lizenzierung von SoCs Geld sparen, aber auf Kosten einiger verärgerter Nerds, die sich fragten, warum sie kein Update bekommen hatten.

Updates sind komplex. An der Kette sind viele verschiedene Personen beteiligt. Keiner dieser Gründe entschuldigt OEMs des gegenwärtigen und erbärmlichen Zustands von Updates auf Android. Dennoch gibt es hier einige echte Herausforderungen.

Viele OEMs sind verantwortlich für zu vielversprechende und unvermeidliche Unterlieferungen, die wir jetzt in Verbindung bringen. Die traurige Realität ist, dass für die meisten OEMs Software-Updates nur ein Ärgernis sind, auf das sie verzichten könnten.

Der Mobilsektor ist meistens in der Denkweise von Funktionstelefonen stecken geblieben. Das heißt, ein Gerät erhält niemals Updates. Teste es einmal, versende es und schaue niemals zurück. Angesichts der Sicherheitsprobleme moderner Smartphones und der Komplexität der Ausführung eines Allzweckbetriebssystems mit Hunderten externer Bibliotheken ist dies keine Option mehr. Zumindest sollte es nicht so sein. Google hat einige Schritte unternommen, um dieses Problem zu beheben, indem zumindest Sicherheitsbulletins und Patches für vorhandene Android-Versionen veröffentlicht wurden (denken Sie daran, dass Sicherheitsupdates bis vor kurzem nur über eine neue Hauptversion des Android-Betriebssystems abgerufen werden konnten!).

Leider ist dies jedoch nicht wirklich genug. Auch wenn Google weiterhin Updates veröffentlicht, hängt die Sicherheit Ihres Geräts immer noch vom SoC-Hersteller ab. Da SoC-Hersteller so versteinert sind, dass jemand entdeckt, wie sie ein paar LEDs einschalten oder über einen Lautsprecher einen Sound erzeugen, werden riesige Mengen von Binärblobs versendet auf ihren Geräten. Diese Blobs enthalten einen ziemlich schrecklich unsicheren Code (werfen Sie einen Blick auf frühere Google-Sicherheitsbulletins, wenn Sie dies für eine Übertreibung halten!) Und müssen aktualisiert werden. Daher sind aktualisierte BSPs erforderlich.

Desktop-Computer (und damit auch Laptops) unterscheiden sich in ihrer Architektur grundlegend von mobilen Geräten. Ihr Mobiltelefon oder Tablet ist praktisch ein stark proprietäres Stück Silikon, das von einigen Leuten in Eile entwickelt wurde, die es gut meinen, aber bei weitem nicht genug Zeit haben, um 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 vom Linux-Kernel nicht unterstützt, und Sie werden feststellen, dass jedes Telefon eine andere Art des Bootens hat. Auf Ihrem Laptop oder Desktop haben sich die Anbieter jedoch auf einige Standard-Boot-Methoden geeinigt - zuvor war es MBR (Master Boot Record) mit einem BIOS und jetzt ist es UEFI. Diese Standardisierung ermöglicht es, auf jedem Gerät dieselbe Software auszuführen.

In letzter Zeit wurden zwar einige Schritte in diese Richtung unternommen, insbesondere mit dem Outreach-Programm von Sony und dem vereinheitlichten Kernel. Auf den meisten Telefonen ist es jedoch nicht praktikabel, einen Hauptkernel auszuführen, da jedes Gerät über eine Vielzahl neuer herstellerspezifischer Hacks verfügt.

Haben Sie die Kopfhörerbuchse falsch herum angeschlossen? Hacken Sie es einfach in die Treiber! Es ist keine Zeit, dies im Produktionsdesign zu beheben.

Das Fertigungsteam hat das Kameramodul in Produktionscharge 1? Verkehrt herum montiert. Machen Sie einen Hack, 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, schaben aber nur die Oberfläche der seltsamen und produktspezifischen Veränderungen ab. Heck, es gibt sogar manchmal ganz unterschiedliche Chips in verschiedenen Revisionen des gleichen Telefons, aufgrund kommerzieller Entscheidungen. Diese führen zu Hacks in Fahrern und seltsamen Entscheidungen, die zu der Zeit nur Sinn machten, damit das Telefon funktioniert und in der nächsten Woche ausgeliefert werden kann.

Zwar wird daran gearbeitet, die Unterstützung von 64-Bit-ARM-Chips für das Booten mit UEFI zu verbessern, doch bisher gab es keine eindeutige Bewegung in Richtung einer standardisierteren Methode zum Booten von ARM-Geräten . Und das ist traurig, weil es bedeutet, dass Telefone noch lange vor dem Ende ihres Arbeitslebens weggeworfen werden, weil es einfach zu teuer ist, die technischen Schulden und die Belastung für ihre Software aufrechtzuerhalten.

Wenn ein OEM jedoch nur mit dem Verkauf eines Geräts Geld verdient, muss er dann nicht sicherstellen, dass die Kunden weiterhin neue Telefone kaufen? Würde der PC-Markt auf dieses Modell umsteigen, wenn es auf der Basis der offenen PC-Plattform und des offenen Standards noch keine 30-jährige Entwicklungs- und Legacy-Software gäbe?

Dies ist eine schwierige Frage ohne Insiderwissen von Qualcomm, die wir derzeit leider nicht haben. Wir können jedoch einige Informationen aus der 7.0-Android-Treiber-API und den CTS-Anforderungen entnehmen. Die CTS-Anforderungen geben an, was Google von einem Gerät mit einer bestimmten Firmware erwartet. Der „große Hammer“ bei der Durchsetzung dieser Anforderungen ist die Lizenzierung von Google für die Verwendung des proprietären Google Play Services-Pakets. Wenn Sie dies nicht tun, können Sie Google Apps nicht auf dem Gerät ausliefern . Während dies für einige als Vorteil angesehen werden kann, ist dies offensichtlich nicht das, was Benutzer von einem Gerät erwarten und wollen.

Android 7.0 hat aufgrund von Änderungen an der HAL oder den Treibern (wie oben beschrieben) nicht viel hinzugefügt, sodass es unwahrscheinlich ist, dass eine Inkompatibilität speziell von dort ausgeht. Was jedoch mit größerer Wahrscheinlichkeit ein Problem darstellt, ist die Einführung einer neuen Anforderung, dass entweder die Vulkan-Grafik-API oder GLES 3.1 verfügbar sein muss, um CTS zu bestehen.

Derzeit haben viele SoCs (Systems-on-Chip) keine Vulkan-Unterstützung für ihren Grafikprozessor, einschließlich des MSM8974. Dies ist auch am wahrscheinlichsten, wenn das Problem der Kompatibilität mit Android 7.0 auftritt. Ohne das Insiderwissen von Qualcomm und ihre zukünftigen Pläne fällt es uns jedoch schwer, eine endgültige Aussage zu machen, ohne sie einzuschränken. Im Moment halten wir es jedoch für wahrscheinlich, dass dies der „einfache“ Fall ist, dass Qualcomm die Unterstützung für den (in ihren Augen) veralteten MSM8974-Chipsatz einstellt und auf dieser Plattform kein BSP (Board Support Package) für 7.0 bereitstellt. Wenn dies der Fall wäre, würden OEMs mit ziemlicher Sicherheit 7.0 nicht auf dem Gerät ausliefern - sie müssten irgendwie die Unterstützung von Vulkan oder GLEs 3.1 für ihre GPU finden, und der GPU-Quellcode ist einer der lächerlich streng gehüteten Teile des mobilen Stacks (ohne wirklichen Grund würden wir hinzufügen - siehe AMD, Open-Sourcing-Treiber für AMDGPU auf dem Desktop für Linux). Leider sind Vulkan- und beschleunigte (GLES) Grafiken im Allgemeinen etwas komplexer als eine einfache LED. Daher werden wir hier keine Shims sehen, um Kompatibilität einzuführen.

Da 7.0 noch nicht lange auf dem Markt war, besteht die reale Möglichkeit, dass andere Chipsätze (mit Ausnahme der geringen Anzahl innerhalb von AOSP selbst) aufgrund von Hardware- und Treiberproblemen (dh kein aktualisiertes BSP) oder eines Mangels auf 6.0 zurückbleiben von SoC-Anbietersupport in Bezug auf die Vulkan- oder GLES 3.1-API. Derzeit unterstützen weder der Snapdragon 800 noch der Snapdragon 801 eine dieser Funktionen.

Am besten ist es, diesen Bereich zu beobachten. Die Entwickler von machen bereits gute Fortschritte mit inoffiziellen Ports auf 7.0 für viele der Geräte, die keinen offiziellen 7.0-Support von Google erhalten. Diese sind jedoch ohne Vulkan- oder GLES 3.1-Unterstützung - möglicherweise werden Entwickler von Spielen auf Android durch Fragmentierung frustriert, wenn genügend Benutzer anfangen, benutzerdefinierte ROMs ohne Vulkan- oder GLES 3.1-Unterstützung auszuführen?

Apple unterstützt seine iPhone-Produktlinie seit etwa 5 Jahren mit der neuesten iOS-Version. Das iPhone 4s wurde im Oktober 2011 auf den Markt gebracht und ist bis iOS 9 auf dem neuesten Stand. Es wird nicht das bevorstehende iOS 10-Update erhalten Dies würde dem Telefon jedoch eine effektive Lebensdauer von 5 Jahren verleihen, vorausgesetzt, iOS 10 wird etwa im Oktober herausgebracht. Es ist erwähnenswert, dass Apple die Grafik-API-Unterstützung nicht immer unterstützt. Das iPhone 4s und das iPhone 5 verfügen nicht über die Apple Metal-Grafik-API. Dies ist ein ähnliches Szenario wie bei Android in Vulkan. Der einzige Unterschied besteht darin, dass Apple die älteren Geräte ohne die neue Grafik-API weiterhin unterstützt.

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