Das Generic Kernel Image von Google ist der nächste Schritt zur Lösung des Fragmentierungsproblems von Android

Google arbeitet seit Jahren daran, die Fragmentierung auf Android zu reduzieren, obwohl ein Teil der Ursache dafür in der inhärenten Natur von Android und dem zweischneidigen Schwert der Wahl und Freiheit liegt. Es gibt unzählige OEMs, die in diesem Bereich aktiv sind, und alle möchten ihre eigenen Modifikationen für ihre eigenen Geräte vornehmen. Das Problem besteht dann darin, dass es so aussieht, als würden Android-Betriebssystem-Updates nur langsam auf breiter Front eingeführt, aber Google kann tatsächlich nicht viel tun, um OEMs zu zwingen, ihre Geräte zu aktualisieren. Daher besteht das nächstbeste, was Google tun kann, darin, den Aktualisierungsprozess so einfach und reibungslos wie möglich zu gestalten.

Linderung der Android-Update-Probleme

Die erste große Initiative in Googles Langzeitprojekt zur Reduzierung der Entwicklungslast war

Projekt Treble. Project Treble wurde 2017 zusammen mit Android 8.0 Oreo angekündigt und modularisierte Android durch die Trennung des Betriebssystem-Frameworks von der Anbieterimplementierung (HALs und der gerätespezifische Linux-Kernel-Fork). Dies machte es für Android-OEMs einfacher, ihre Betriebssysteme auf das neueste AOSP-Framework umzustellen, da sie die neueste Version starten konnten, ohne aktualisierten Code von Anbietern zu benötigen. Dadurch könnten OEMs ihre benutzerdefinierten Android-Forks schneller als zuvor fertigstellen und damit auch größere Betriebssystem-Updates schneller einführen.

Der nächste Schritt in Googles Plänen bestand darin, die Bereitstellung von Updates für wichtige Android-Komponenten zu optimieren. Google hat diese Initiative aufgerufen Projekt Mainline als es 2019 zusammen mit Android 10 eingeführt wurde. Google übernahm im Wesentlichen die Kontrolle über wichtige Betriebssystemkomponenten und verbot OEMs, diese zu modifizieren. Anschließend richteten sie einen Bereitstellungsmechanismus über Google Play ein, sodass sie Updates für diese Schlüsselkomponenten aus der Ferne bereitstellen konnten, ohne darauf warten zu müssen, dass die OEMs die Patches selbst anwenden. Mainline hat die Geschwindigkeit, mit der Geräte aktualisierte Versionen wichtiger Betriebssystemkomponenten erhalten, erheblich verbessert und damit die Sicherheit des Android-Ökosystems insgesamt verbessert.

Wenn es um Treble geht, sollte der Linux-Kernel jedoch realistischerweise nicht mit Closed-Source-Anbietercode in einen Topf geworfen werden. Todd Kjos bei diesjährige Linux Plumbers Conference hat in der Vergangenheit die Schwierigkeiten erläutert, mit denen man bei der Fragmentierung auf Android konfrontiert ist, und ein Großteil davon dreht sich jetzt um den Linux-Kernel, den OEMs mit ihren Geräten ausliefern. Zum Kontext: Google teilt jeden Mainline-Linux-Kernel in einen „Gemeinsamer Android-Kernel” (ACK)-Zweig, der die Hauptversion genau verfolgt, aber einige Android-spezifische Patches hinzufügt. SoC-Anbieter wie Qualcomm, MediaTek und Samsung teilen sich dann auf Das Kernel für jeden SoC, den sie herstellen. OEMs nehmen dann diesen SoC-spezifischen Kernel und fügen zusätzliche Patches hinzu, um Unterstützung für die spezifische Hardware zu implementieren, die sie ausliefern möchten.

Das obige Diagramm zeigt, wie der Kernel eines Geräts mehrere Änderungsebenen durchläuft, die ihn weit vom Linux LTS-Kernel abstrahieren. Zur Vereinfachung beginnen wir mit dem Linux-Kernel und dieser wird mit ein paar Änderungen in den Android Common Kernel integriert. Von dort aus wird der Android Common Kernel mit seinen eigenen Modifikationen und Änderungen in einen Anbieterkernel (Qualcomm, MediaTek usw.) zusammengeführt. Schließlich wird der Kernel des Herstellers mit dem gerätespezifischen Kernel eines OEM zusammengeführt. Zu diesem Zeitpunkt ist der Kernel eines Geräts weit von dem Linux-LTS-Kernel entfernt, mit dem es begonnen hat.

Aufgrund all dieser Forks handelt es sich bei bis zu 50 % des auf einem Android-Gerät ausgeführten Codes um Out-of-Tree-Code, was bedeutet, dass er nicht von Upstream-Linux- oder AOSP-Kerneln stammt. Dies macht es unglaublich schwierig (ganz zu schweigen davon, dass es zeitaufwändig und kostspielig ist), vorgelagerte Änderungen zusammenzuführen. Für OEMs besteht kein Anreiz dazu, aber diese Praxis kann der Gerätesicherheit schaden. Dies ist auch der Grund, warum viele Android-Geräte auf älteren LTS-Kernel-Versionen belassen werden, was den Nebeneffekt hat, dass Geräte keinen Zugriff auf neue Linux-Kernel-Funktionen haben.

Android ist fragmentiert und Google weiß das

Google weiß genau, dass dies ein Problem ist, und hat sogar einen Abschnitt namens „Die Kosten der Fragmentierung" in der Android-Entwicklerdokumentation. Google sagt das „Die meisten Flaggschiff-Geräte werden mit einer Kernel-Version ausgeliefert, die bereits mindestens 18 Monate alt ist“. Schlimmer noch, Google sagt das auch „Android 10 unterstützt die Kernel 3.18, 4.4, 4.9, 4.14 und 4.19, die in einigen Fällen seit Android 8 im Jahr 2017 nicht mehr um neue Funktionen erweitert wurden.“ Dies erschwert das Hinzufügen von Funktionen, die neue Linux-Kernelversionen erfordern. Der Linux-Kernel 3.18 wurde im Dezember 2014 veröffentlicht, damals war Android 5.0 Lollipop die neueste Version von Android. Das ist eindeutig ein Problem und kann die Plattform bremsen.

Beispielsweise hostet das Code Aurora Forum, kurz CAF, den Quellcode für verschiedene Qualcomm Snapdragon SoCs. Qualcomm als SoC Der Hersteller verteilt eine abgespaltene Version des Linux-Kernels an OEMs/ODMs, und diese Unternehmen fügen dann beim Versand gerätespezifische Änderungen hinzu Geräte. Dadurch werden mehrere Ebenen der Fragmentierung hinzugefügt. Darüber hinaus nimmt Qualcomm Änderungen am AOSP-Framework vor, um Android für jede der mobilen Snapdragon-Plattformen des Unternehmens zu optimieren. Qualcomm vertreibt seinen modifizierten Linux-Kernel, das AOSP-Framework und andere Softwaretools privat als Teil eines Board Support Package (BSP) an seine Partner. CAF ist der Ort, an dem Qualcomm diese Linux-Kernel-Änderungen und AOSP-Framework-Änderungen öffentlich veröffentlicht.

Diese CAF-Version kann für benutzerdefinierte ROM-Entwickler nützlich sein, die sie als Ausgangspunkt anstelle von reinem AOSP verwenden möchten, weshalb Sie manchmal sehen „CAF-basierte“ ROMs in unseren Foren. Erinnern Sie sich an den Snapdragon 625, der scheinbar jahrelang so viele Mittelklasse-Smartphones antreibt? Dies wurde mit Linux Kernel 3.18 eingeführt, und erst gegen Ende 2018 (zwei Jahre nach der Einführung des Chipsatzes) aktualisierte Qualcomm die Kernel-Quellen und veröffentlichte sie auf CAF für msm8953 (der Chipsatzname des Snapdragon 625) mit Unterstützung für Linux Kernel 4.9. Das Problem ist, dass die meisten OEMs wird zwei Jahre nach der Veröffentlichung des Chips keine Telefone auf diese neue Linux-Kernel-Version aktualisieren, insbesondere keine Mittelklasse-Telefone freigegeben. Zugegebenermaßen kommt es sehr selten vor, dass ein solches großes Kernel-Update überhaupt überhaupt stattfindet, aber der Punkt ist, dass es so ist hat ist passiert, also ist es nicht nur ein unmögliches Szenario.

Alles in allem ist die aktuelle Fragmentierung in Android, gelinde gesagt, ein Chaos. Die neuesten Versuche von Google, diese Fragmentierung zu beheben, erfolgen in Form des Generic Kernel Image oder GKI.

Einführung des generischen Kernel-Images

Um dieser Fragmentierung entgegenzuwirken, hat Google am Android Generic Kernel Image (GKI) gearbeitet. Dabei handelt es sich im Wesentlichen um einen Kernel, der direkt aus einem ACK-Zweig kompiliert wurde. Das GKI isoliert SoC-Anbieter- und OEM-Anpassungen auf Plugin-Module, eliminiert Out-of-Tree-Code und ermöglicht es Google, Kernel-Updates direkt an den Endbenutzer zu übertragen. Seit über einem Jahr arbeitet Google an einer Möglichkeit, GKI-Updates über den Play Store bereitzustellen. durch den Einsatz eines Mainline-Moduls.

Daher müssen Geräte, die mit Android 12 starten und auf denen der Linux-Kernel 5.10.43 oder höher läuft, einen der folgenden Schritte ausführen: laut Mischaal Rahman.

• Stellen Sie ein von Google signiertes Boot-Image bereit

ODER

• Stellen Sie ein Boot-Image mit einem Kernel bereit, der ein KMI (Kernel Module Interface) exportiert, das eine Teilmenge des vom GKI exportierten KMI ist. exportiert eine Userspace-API, die eine Obermenge der von der GKI bereitgestellten UAPI darstellt und alle Funktionen der entsprechenden GKI unterstützt Ausführung

Anbieter können Module erstellen, die sich in die GKI einbinden lassen, aber die Idee der GKI ist, dass Google die Verantwortung für die Handhabung von Kernel-Änderungen übernimmt. Die Kernel-Modul-Schnittstelle (oder KMI, mehr dazu in den späteren Teilen des Artikels) ist praktisch der Ort, an dem Out-of-Tree-Code abgelegt werden soll.

Die Google Pixel 6-Serie wurde mit Android 12 und dem Linux-Kernel 5.10 auf den Markt gebracht und ist das erste Telefon, das mit einem GKI ausgeliefert wird. Da Google den Kernel möglicherweise über den Play Store aktualisieren könnte, werden wir möglicherweise sogar häufige Kernel-Updates sehen. da LTS-Kernel-Updates normalerweise wöchentlich veröffentlicht werden. In jedem Fall ist es ein viel besseres System als die derzeit umständliche Methode der Aktualisierung über OTA, obwohl dies bedeutet, dass es von Natur aus an das GMS-Framework gebunden ist.

Google definiert den GKI einfach wie folgt:

• Es wurde aus den ACK-Quellen erstellt.
• Es handelt sich um eine Single-Kernel-Binärdatei plus zugehörige ladbare Module pro Architektur und LTS-Version (derzeit nur arm64 für android11-5.4 Und android12-5.4).
• Es wurde mit allen Android-Plattformversionen getestet, die für das zugehörige ACK unterstützt werden. Während der gesamten Lebensdauer einer GKI-Kernelversion gibt es keine veralteten Funktionen
• Es stellt Fahrern innerhalb eines bestimmten LTS einen stabilen KMI zur Verfügung.
• Es enthält keinen SoC- oder Board-spezifischen Code.

Google will bis 2023 sogar in der Lage sein, ein „Upstream First“-Entwicklungsmodell zu übernehmen. Dies wird Google dabei helfen, sicherzustellen, dass neuer Code zuerst im Haupt-Linux-Kernel landet, und so die „technischen Schulden“ reduzieren, die durch Out-of-Tree-Code auf Android-Geräten entstehen.

Die Kernel-Modul-Schnittstelle (KMI)

Das Kernel Module Interface (KMI) ist Teil von Googles Lösung für die anhaltende Fragmentierung in Android. Im Wesentlichen befinden sich SoC und Board-Unterstützung nicht mehr im Kernel, sondern werden stattdessen in ladbare Module verschoben. Sowohl der Kernel als auch die Module können dann unabhängig voneinander aktualisiert werden, während die Module aktualisiert werden /lib/modules. Die GKI selbst soll so sauber und generisch wie möglich sein, was durch die Auslagerung des nun Out-of-Tree-Codes in separate Module ermöglicht wird.

Als Ted Kjos erklärt unter Bei der diesjährigen Linux Plumbers Conference besteht der große mehrjährige Vorstoß darin, den gesamten hardwarespezifischen Code aus dem generischen Kernel in die Herstellermodule zu integrieren. Wir müssen eine stabile Schnittstelle zwischen diesen Anbietermodulen und dem generischen Kernel haben, damit sie asynchron versendet werden können.“ GKI 1.0 ist im Wesentlichen ein „Compliance-Test“.

Tatsächlich bedeutet GKI-Kompatibilität, dass das Gerät die VTS- und CTS-on-GSI+GKI-Tests mit dem Generic System Image (GSI) besteht. und der GKI-Kernel wird installiert, indem das GKI-Boot-Image in die Boot-Partition und das GSI-System-Image im System geflasht wird Partition. Die Vendor Test Suite (VTS) ist ein automatisierter Test, den alle Geräte bestehen müssen, um als mit Project Treble kompatibel zu gelten. Für den Zugriff auf die Anwendungssuite von Google ist die Compatibility Test Suite (CTS) erforderlich.

Geräte können mit einem anderen Produktkernel ausgeliefert werden und ladbare Module verwenden, die GKI nicht bereitstellt. Allerdings müssen sowohl der Produkt- als auch der GKI-Kernel Module von denselben Vendor_boot- und Vendor-Partitionen laden. Daher müssen alle Produktkerne über die gleiche binäre Kernelmodulschnittstelle (KMI) verfügen.

Das obige Diagramm zeigt, was Google will zu tun, und erklärt, wie sie dies erreichen will. Die Generic Kernel- und GKI-Module werden Teil von AOSP sein, und die GKI kann mit dem Android-Framework und dem Hardware Abstraction Layer (HAL) kommunizieren, die ein Anbieter möglicherweise implementiert. Der spezifische proprietäre Code, den ein Anbieter im Kernel haben möchte (z. B. Kameratreiber), wird stattdessen in ein Anbietermodul gepusht, das über das KMI zu einer Erweiterung des GKI wird.

Wie die GKI zur Lösung des Fragmentierungsproblems von Android beitragen kann

Google hat viel Arbeit in die Rationalisierung des Entwicklungsprozesses von Smartphones gesteckt. Jeder OEM möchte eine eigene Markenidentität und jeder OEM möchte Eigentümer seiner Geräte sein. Im Gegensatz zum Android One-Programm können Android-Smartphones so ziemlich alles sein, was sie wollen, solange sie sich an die Regeln halten, die Google für den Erhalt einer GMS-Lizenz aufstellt. Allerdings hat Google in der Vergangenheit nicht viel getan, um die Entwicklung von Android-Geräten zu kontrollieren Änderungen wie Project Treble, Mainline und jetzt sind die GKI in Android viel neuer Geschichte.

Aber wird es helfen? Das sollte der Fall sein, obwohl es wahrscheinlich eine mehrjährige Angelegenheit sein wird, die später sichtbare Früchte trägt. Dies gilt nur für Geräte, die mit Android 12 starten, was bedeutet, dass wir in den kommenden Jahren Geräte sehen werden, die kein GKI haben. Das war auch eine Kritik an Project Treble, als es angekündigt wurde, obwohl es offensichtlich von allen heute auf den Markt gebrachten Geräten unterstützt wird. Diese Dinge brauchen Zeit, und da Google langsam die Kontrolle über Android übernimmt, wird der Entwicklungsprozess für alle OEMs vereinfacht das Android-Ökosystem, auch wenn einige von ihnen lieber die volle Kontrolle über den Linux-Kernel behalten möchten, der auf Android verwendet wird Smartphones.