Linux: Android-Geräte sollen künftig Standard-Kernel-API benutzen
Der von Google über das Android Open Source Project (AOSP) bereitgestellte Linux-Kernel weist nach einigen Jahren Arbeit nur noch wenige Unterschiede zu dem Hauptzweig des Linux-Kernels auf, wie Sandeep Patil in einem Vortrag auf der Linux Plumbers Conference(öffnet im neuen Fenster) (LPC) darlegt, über den das Magazin LWN.net ausführlich berichtet(öffnet im neuen Fenster) . Die tatsächlich genutzten Geräte-Kernel und hier vor allem die Treiber der Android-Hersteller weichen vom AOSP-Kernel jedoch immer noch massiv ab, was insbesondere Updates deutlich erschwert. Google will das mit neuen Vorgaben und technischer Hilfe aber ändern.
Grafiktreiber als Anfang
Eine der wohl wichtigsten Neuerungen bei diesen Arbeiten ist der Umbau der Grafikarchitektur von Android, den der Google-Entwickler Alistair Strachan ebenfalls in einem Vortrag auf LPC(öffnet im neuen Fenster) beschreibt. Bisher stammen die Grafiktreiber der Geräte üblicherweise vom Hersteller selbst, sind nicht in den Community-Kernel integriert und nutzen entweder völlig eigene Schnittstellen oder die veraltete Framebuffer-Schnittstelle. Die darauf aufbauenden Userspace-Komponenten sind ebenfalls meist eigene Implementierungen.
Das führt zu einer unübersichtlichen Anzahl von Schnittstellen, doppelten Code für eigentlich gleiche Funktionen sowie zu dem Problem, dass ein Wechsel auf eine neue Kernel-Version oft so viel Aufwand verursacht, dass die Gerätehersteller dies nicht umsetzen. Einheitliche Tests und Debug-Werkzeuge sind so auch nicht umsetzbar.
Doch wie bereits Anfang dieses Jahres angekündigt, arbeitet Google an einer Mainline-Unterstützung für das Qualcomm-SOC Snapdragon 845 , das die Standard-Grafikschnittstelle DRM (Direct Rendering Manager) des Linux-Kernels benutzt. Aktiv eingesetzt wird dies laut Strachan offenbar bereits in Googles Pixel 3. Die Vorarbeiten dazu und die notwendigen Änderungen im Hauptzweig des Linux-Kernels begannen demnach aber offenbar viel früher und reichen sogar bis ins Jahr 2013 zurück.
Mit Hilfe der DRM-Schnittstelle, die künftig auf allen Android-Geräten verfügbar sein soll, sollen dann auch die wichtigen Userspace-Bestandteile Gralloc sowie der DRM-Hwcomposer vereinheitlicht werden. Die Userspace-Implementierungen für Schnittstellen wie OpenMAX für die Videobeschleunigung sowie EGL, OpenGL ES oder auch Vulkan sollen zwar auch weiterhin proprietär und dem Hersteller überlassen bleiben. Diese bauen aber auf den festgelegten Standardschnittstellen des Kernels selbst auf und bieten wiederum selbst eine nach außen ebenfalls klar festgelegte API, so dass Probleme mit Updates, Tests und Debug-Möglichkeiten deutlich reduziert werden sollten.
Dass dieser Aufbau prinzipiell funktioniert, hat das Android-Team bereits mit seinem Tablet Pixel C bewiesen . Das Pixel 3 soll wohl nun außerdem anderen Herstellern als positives Beispiel dienen, um den Umbau der Architektur zu akzeptieren und umzusetzen. Die für das kommende Android Q geplanten Kernel-Versionen 4.9, 4.14 und 4.19 verfügen außerdem über alle Voraussetzungen, um den DRM-Stack benutzen zu können. Die Nutzung der Standardschnittstellen soll darüber hinaus aber noch erweitert werden.
Künftig feste Kernel-Schnittstelle
Zusätzlich dazu plant Google wohl aber weitere Änderungen in Bezug auf den Kernel, die vor allem im Zusammenhang mit dem Projekt Treble stehen, das Android-Updates erleichtern soll, wie aus dem Vortrag von Patil hervorgeht, den das Magazin LWN.net zusammenfasst. Neben dem Bestreben, die noch verbliebenen Unterschiede zwischen AOSP-Kernel und dem Hauptzweig zu reduzieren, in dem abweichender Code noch eingepflegt wird, soll auch die Treble-Schnittstelle verändert werden.
Die Idee von Treble ist es bisher, eine Art generische Hardware-Abstraktion für Android bereitzustellen. Diese Abstraktionsschicht ist klar definiert und muss von den Herstellern umgesetzt werden. Das hat den Vorteil, dass alle darüberliegenden Bestandteile und hier vor allem das Android OS Framwork unabhängig von den Herstellerbestandteilen ausgetauscht und aktualisiert werden können.
Dieser Aufbau wiederum führte zu dem sogenannten Generic System Image(öffnet im neuen Fenster) (GSI), das direkt aus dem Android-Quellcode gebaut werden kann und theoretisch auf jedem beliebigen Gerät gestartet werden können müsste, das die Treble-Hardware-Abstraktion richtig umsetzt. Bis jetzt gehört der Kernel allerdings noch zu dem von den Herstellern kontrollierten Bereich von Treble.
Generisches Image mit Mainline-Kernel
Laut Patil plant Google jedoch, auch den Mainline-Kernel in das GSI als festen Bestandteil aufzunehmen, so dass die Geräte der Hersteller dieses Image mit dem Hauptzweig des Kernels starten können müssen. Dafür müssen die Hersteller ihre eigenen Anpassungen und Treiber zur Hardware-Unterstützung jedoch als Kernel-Module umsetzen, die wiederum die klar festgelegten Schnittstellen des Mainline-Kernels nutzen.
Dafür sind zwar auch im Mainline-Kernel selbst wohl noch einige Änderungen notwendig und diese Kernel-Module sind auch weiter nicht im Hauptzweig des Linux-Kernels eingepflegt. Die klar definierte Schnittstelle für die Module hätte jedoch den Vorteil, dass die Hersteller nicht mehr beliebige Bestandteile des Kernels für ihre eigenen Zwecke ändern könnten. Ebenso müssten die externen Module wohl auch stärker an das übliche Verhalten des Mainline-Kernels angepasst werden. Letzteres könnte dafür sorgen, dass die Module viel leichter in den Hauptzweig eingepflegt werden könnten.
In Bezug auf das Beispiel der Grafiktreiber könnten Kernel und Userspace in dem GSI zum Beispiel die Verwendung der DRM-Schnittstelle voraussetzen. Die Hersteller wären also gezwungen, einen DRM-Treiber zu erstellen, der dann möglicherweise einfacher als bisher in den Mainline-Kernel eingepflegt werden kann. Statt diesen Treiber selbst zu bauen, könnte dieser auch direkt vom SOC-Hersteller geliefert werden, wie dies nun etwa in Zusammenarbeit mit Qualcomm versucht wird.
Langfristig könnten mit diesen Bestrebungen die großen technischen Schwierigkeiten des Android-Systems mit seinem Linux-Unterbau wohl zufriedenstellend gelöst werden. Ein prinzipielles Problem bleibt bei dem Aufbau aber weiterhin bestehen. Die internen Schnittstellen des Linux-Kernels, auch jene für Module, können sich zwischen Kernel-Versionen ändern, so dass die externen Kernel-Module der Hersteller bei Upgrades darauf angepasst werden müssen. Mit der forcierten Nähe zum Hauptzweig des Kernels sollte das aber deutlich weniger Aufwand sein als bisher und möglicherweise sogar von einer interessierten Community umgesetzt werden können.