Google plant, ab 2023 auf ein „Upstream First“-Entwicklungsmodell für Linux-Kernel-Funktionen in Android umzusteigen. Lesen Sie weiter, um mehr zu erfahren.
Wenn Sie die Wörter „Android“ und „Fragmentierung“ im selben Satz sehen, springen Ihre Gedanken wahrscheinlich sofort zu dem Verteilungsdiagramm der Android-Version. Es gibt ein paar Dinge, auf die die meisten Leute mit dem Finger zeigen, wenn sie sich darüber beschweren, dass Android-Betriebssystem-Updates nur langsam auf breiter Front eingeführt werden, aber Google kann nur begrenzt etwas dagegen tun Gewalt OEMs können Updates schneller entwickeln und einführen. Was Google jedoch tun kann, ist, die Entwicklungszeit und damit die Kosten für die Einführung von Updates zu reduzieren.
Die erste große Initiative in Googles langfristigem Projekt zur Reduzierung der Entwicklungslasten ist 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 booten 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.
Aber was als nächstes kommt, ist noch wichtiger und wohl der wichtigste Teil der langfristigen Strategie von Google. Als wir zuvor darauf hingewiesen haben, wie Treble Android modularisiert hat, indem es das Betriebssystem-Framework vom Betriebssystem getrennt hat Bei der Anbieterimplementierung haben wir den „gerätespezifischen Linux-Kernel-Fork“ als Teil dieses Anbieters integriert Code. Jeder, der sich mit Linux auf Desktops auskennt, wird dort ein Problem erkennen: Warum wird es mit Closed-Source-Anbietercode in einen Topf geworfen? Das Problem besteht darin, dass Android-Geräte zwar mit dem Linux-Kernel ausgeliefert werden, dieser Kernel jedoch über einen verfügt viel von Out-of-Tree-Code.
Wie sind wir dorthin gekommen? Das Problem wurde vom Google-Softwareentwickler Todd Kjos unter beschrieben diesjährige Linux Plumbers Conference (über ArsTechnica), liegt daran, dass der Mainline-Linux-Kernel mehrere Male geforkt wird, bevor er auf einem Android-Gerät ausgeliefert wird. Google teilt jeden Mainline-Linux-Kernel in einen „Gemeinsamer Android-Kernel"-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 erstellen. 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.
Aufgrund dieser Änderungen „Bis zu 50 % des auf einem Gerät ausgeführten Codes ist Out-of-Tree-Code (nicht von Upstream-Linux- oder AOSP-Common-Kerneln).", so Google. Die große Menge an Out-of-Tree-Code auf diesen Geräten macht das Zusammenführen von Upstream-Änderungen zu einem langen und herausfordernden Prozess. Dies ist schädlich für die Gerätesicherheit, da OEMs härter arbeiten müssen, um Patches für Schwachstellen zu implementieren, die im Linux-Kernel entdeckt werden. Darüber hinaus verfügen die meisten Android-Geräte über Jahre alte Kernel-Releases, was bedeutet, dass ihnen neue Linux-Kernel-Funktionen fehlen.
Um dieses Problem zu lösen, arbeitet Google am Android Generic Kernel Image (GKI), bei dem es sich im Wesentlichen um einen Kernel handelt, der direkt aus einem ACK-Zweig kompiliert wird. 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.
Laut unseren Quellen sind Geräte, die mit starten Android 12 und mit Linux-Kernel 5.10 ausgeliefert werden, müssen ein von Google signiertes Boot-Image bereitstellen. Googles Eigenes Pixel 6 Die Serie wird standardmäßig mit Android 12 gestartet und mit dem Linux-Kernel 5.10 ausgeliefert, sodass die beiden Telefone möglicherweise die ersten Massenmarktgeräte sind, die mit einem GKI ausgeliefert werden.
Darüber hinaus gab Todd Kjos von Google bekannt, dass das Unternehmen plant, für neue Linux-Kernel-Funktionen auf ein „Upstream First“-Entwicklungsmodell umzusteigen. Dies wird Google dabei helfen, sicherzustellen, dass neuer Code zuerst im Haupt-Linux-Kernel landet, was künftige technische Schulden reduzieren wird, die durch die Landung von Out-of-Tree-Code auf Android-Geräten entstehen.
Auf der Linux Plumbers Conference diese Woche sagte Kjos: „Da Out-of-Tree-Module für unseren Anwendungsfall wirklich wichtig sind, gehen wir davon aus, dass wir immer eine Reihe von Exporten und einige Dinge haben, die sich von dem unterscheiden oder ergänzen Upstream, aber dieses ganze Projekt ist ein mehrjähriges Projekt, das darauf hinarbeitet, so viele Out-of-Tree-Patches wie möglich zu entfernen und sich so weit wie möglich daran anzupassen stromaufwärts.“ Google möchte seine Arbeiten zum Upstreaming bestehender Funktionen und zur Isolierung von Anbieteränderungen bis Ende 2022 abschließen und ab 2023 plant das Unternehmen, dieses „Upstream First“-Entwicklungsmodell einzuführen, um solche Probleme in der Zukunft zu vermeiden Zukunft.