Project Treble: Google will Android-Updates revolutionieren
Aus Sicherheitsperspektive ist Android eine Katastrophe: Updates, die der Hersteller Google veröffentlicht, werden von den Hardware-Partnern nur sehr selten und viel zu langsam umgesetzt. Upgrades auf neue Versionen gibt es, wenn überhaupt, nur in einem sehr kleinen Rahmen. Schuld daran ist wohl der komplexe Aufbau des Android-Systems selbst, was Google nun mit einer stabilen Hardware-Schnittstelle überwinden will, wie es im Android-Developerblog(öffnet im neuen Fenster) heißt.
Standardisierte Hardware-API
Die Arbeiten an dieser Schnittstelle bezeichnet Google als Project Treble. Das Projekt sei unter anderem in Zusammenarbeit mit Sony und dem führenden SoC-Produzenten Qualcomm entstanden und bereits für die Vorabversionen des kommenden Android O umgesetzt. Das Ziel von Treble sei es, die gerätespezifische Low-Level-Software-Implementierung der Chipproduzenten aus dem Android-OS-Framework herauszutrennen.
Für den Zugriff auf die eigentlichen Hardware-Funktionen wird das sogenannte Vendor Interface eingeführt. Dieses soll, ähnlich wie die Java-API, für die Apps mit einem Test-Framework, der Vendor Test Suite (VTS), ausgestattet werden, um die Kompatibilität eines Gerätes und seiner Implementierung testen und gewährleisten zu können.
Der Aufbau mit der einheitlichen Hardware-Abstraktion hat dann den Vorteil, dass Android-Hersteller wie Sony, den Großteil ihres Systems unabhängig von der Hardware aktualisieren können und damit zum Beispiel schnell die monatlichen Updates von Google an ihre Nutzer verteilen können. Auch Upgrades der jährlichen Android-Versionen werden dadurch wohl etwas vereinfacht. In der Ankündigung heißt es allerdings, dass die Hersteller sich für diese Vorgehensweise "entscheiden" könnten. Verpflichtend sind die schnellen Updates mit Hilfe der Schnittstelle vorerst also nicht.
Komplexe Implementierungen erzwingen Standard-API
Die Einführung solch einer Schnittstelle löst Probleme im Aufbau und des Erstellungsprozesses von Android, von dem auch Google selbst betroffen ist. Denn die Chiphersteller schreiben ausgehend von einer Linux-Kernelversion, die Google für Android bestimmt, nicht nur einzelne Hardware-Treiber, sondern auch eine Vielzahl verschiedener Userspace-Komponenten, die oft sehr eng mit dem restlichen Android-Code verknüpft sind.
Zwar gibt es darauf aufbauend mit dem Hardware Abstraction Layer(öffnet im neuen Fenster) (HAL) bereits eine nach außen hin einheitliche Hardware-Schnittstelle, auf die Apps zugreifen können. Google schreibt seinen Partnern bisher aber nicht vor, wie diese HAL-Komponenten mit den eigentlichen Gerätetreibern und dem Kernel interagieren müssen. Ebenso kann das von den Herstellern genutzte Android-Framework intern an eigene Schnittstellen angepasst werden, etwa um spezifische Optimierungen vorzunehmen.
Die Implementierungen der Hersteller unterscheiden sich je nach gewähltem SoC und Zulieferer teils massiv und sind bei einigen Herstellern auch gerätespezifisch. Diese Code-Anpassungen sind dann allerdings so groß, dass der Aufwand zum Portieren neuer Android-Version oder auch nur der monatlichen Patches auf den eigenen Code einfach so aufwendig wird, dass viele Hersteller diesen schon aus Kostengründen scheuen.
Neues Android mit altem Kernel
Künftig kommen Updates des Android-OS-Frameworks dank des Vendor-Interface also vielleicht schneller bei den Nutzern an als bisher. Bestehen bleibt, zumindest aus Sicherheitsperspektive, wohl aber weiterhin das massive Problem mit den Hardwaretreibern und anderen Bestandteilen des Linux-Kernels, mit dessen Pflege die meisten Hersteller schon jetzt gänzlich überfordert sind.
So sind sehr viele Hardware-Treiber von den SoC-Produzenten ausschließlich für eine bestimmte Kernel-Version geschrieben worden. Außerdem sind die Kernel der Hersteller oft überhaupt nicht Teil des sogenannten Common-Kernel von Googles Android Open Source Project (AOSP). Der Code zur Unterstützung bestimmter Smartphones findet sich bisher auch fast nie im sogenannten Mainline-Kernel der Linux-Community, auf dem klassische Linux-Distributionen aufbauen.
Der Unterschied von Mainline-Kernel zu dem Kernel, der auf einem bestimmtem Gerät zum Einsatz kommt, beläuft sich so schnell auf mehrere Millionen Zeilen Quellcode. Hinzukommen proprietäre Bestandteile, die als klare Verletzung der GPL nicht offen gelegt werden oder nicht offen gelegt werden müssen, weil diese proprietäre Userspace-Bestandteile sind.
In Anbetracht dieser Umstände ist es leicht nachvollziehbar, warum etwa Samsung sich nicht in der Lage dazu sieht , seine Nutzer schnell vor einem Angriff zu schützen, der über den Treiber des Broadcom-WLAN-Chips ausgeführt wird und die vollständige Übernahme des Gerätes bewirkt.
Weniger Aufwand für neues Android
Sollte sich der Pflegeaufwand für die Android-Geräte dank des Vendor-Interface für die Hersteller allerdings deutlich reduzieren, könnte dies mittelfristig dazu führen, dass sich die Hersteller verstärkt dem Kernel zuwenden können, um die eben beschriebenen Probleme zu lösen.
Das gilt aber eben nicht nur für die Hersteller selbst, sondern auch für große Community-Projekte wie etwa Lineage OS. Deren Aufwand für eine Portierung oder ein Upgrade sollte für Geräte, die ab Android O auf das Vendor Interface setzen, wesentlich geringer ausfallen als bisher. Auch das setzt Kräfte frei, die für die Arbeit am Kernel gebraucht werden können.
Doch selbst wenn sich die Hersteller und die Community nicht dem Kernel zuwenden, wird es für Nutzer wohl einfacher, auch langfristig auf Projekte wie Lineage OS zu setzen und damit Android-Versionsupgrades zu erhalten. Auch wenn der Kernel dann nur mäßig gepflegt wird.
Die vollständige technische Dokumentation zu dem Vendor Interface will Google im Sommer mit der Veröffentlichung von Android O bereitstellen. Auf der Google-Konferenz I/O kommende Woche wird es wohl auch einige weitere Details zu dem System geben. Genutzt wird die neue Technik bereits in der Vorschau auf Android O, die für ausgewählte Geräte von Google bereitsteht.