Googles Kontrolle über Android wächst

Google hat seinen Ansatz für die Entwicklung von Android, dem weltweit dominantesten mobilen Betriebssystem, grundlegend geändert. Dieser Schritt verlagert den gesamten Entwicklungsprozess hinter verschlossene Türen und stellt eine signifikante Abkehr vom bisherigen, teilweise öffentlichen Modell dar. Während der Quellcode weiterhin veröffentlicht wird, hat diese strategische Neuausrichtung weitreichende Konsequenzen für die Transparenz, die Sicherheit und insbesondere für die Zukunft unabhängiger Android-Versionen.

AOSP: Der bisherige "offene" Entwicklungsprozess

Um die Tragweite der Änderung zu verstehen, muss man den bisherigen Entwicklungsprozess kennen. Das Herzstück von Android ist das Android Open Source Project (AOSP). Es stellt die quelloffene Basis dar, die unter der permissiven Apache-2.0-Lizenz veröffentlicht wird. Diese Lizenz erlaubt es jedem, den Code zu nutzen, zu verändern und zu verbreiten, was die weite Verbreitung von Android und die Entstehung unzähliger Derivate, von Samsung's One UI bis zu spezialisierten IoT-Systemen, erst ermöglichte.

Bisher fand ein Teil der Entwicklung öffentlich statt. Über das webbasierte Code-Review-System AOSP Gerrit konnten Entwickler, Sicherheitsforscher und Enthusiasten Commits und Code-Änderungen in Echtzeit verfolgen. Zwar wurden große Teile des Betriebssystems, insbesondere die Kern-Frameworks, schon immer in internen Google-Branches entwickelt. Komponenten wie der Bluetooth-Stack, das Build-System, die SELinux-Konfiguration oder das Virtualization-Framework wurden jedoch "AOSP-first" entwickelt – also vollständig transparent und öffentlich.

Dieses hybride Modell bot eine gewisse Balance: Google behielt die Kontrolle über das Kernprodukt, während die Community Einblick in Teile der Entwicklung hatte und auf einer stets aktuellen Codebasis aufbauen konnte.

Die erste Wende: Entwicklung nur noch intern

Im März 2025 kündigte Google eine weitreichende Änderung an: Die gesamte Entwicklung des Android-Betriebssystems wird fortan ausschließlich in internen Branches stattfinden. Die öffentlichen AOSP-Gerrit-Instanzen, die bisher einen stetigen Fluss an Commits zeigten, werden damit für die Betriebssystem-Entwicklung obsolet.

Der Quellcode wird zwar weiterhin nach jedem stabilen Release – etwa für neue Android-Versionen oder vierteljährliche Sicherheitsupdates – als "Code-Drop" im AOSP veröffentlicht. Der Prozess der Entstehung bleibt jedoch vollständig verborgen. Damit vollzieht Google einen Wandel vom Modell des "Basars" zum Modell der "Kathedrale", bei dem Software hinter verschlossenen Türen gebaut und nur das fertige Produkt der Öffentlichkeit präsentiert wird.

Googles Begründung: Effizienz und Merge-Konflikte

Offiziell begründet Google diesen Schritt mit einer Steigerung der Effizienz. Die parallele Pflege eines öffentlichen und eines internen Entwicklungszweigs (main branch) habe zu erheblichem Mehraufwand geführt. Da der interne Branch oft einen anderen Feature-Stand aufwies als der öffentliche AOSP-Branch, kam es regelmäßig zu komplexen Merge-Konflikten, wenn Änderungen aus dem AOSP in den internen Code integriert werden mussten.

Ein konkretes Beispiel war ein Patch, der eine Bildschirmlupe für die Navigationsleiste hinzufügte. Die neue Einstellung wurde am Ende einer Liste von Bedienungshilfen platziert. Da diese Liste im internen Branch von Google jedoch bereits andere, zusätzliche Einträge enthielt, führte dies unweigerlich zu einem Merge-Konflikt, der manuell aufgelöst werden musste.

Durch die Zentralisierung der Entwicklung in einem einzigen internen Branch will Google solche Konflikte vermeiden und den Entwicklungsprozess optimieren. Kritiker sehen darin jedoch nur einen vorgeschobenen Grund, um die Kontrolle über das Ökosystem weiter zu zementieren.

Die zweite Wende: Wo ist der Pixel-Code?

Die wahre Tragweite der neuen Strategie wurde erst im Juni 2025 mit der Veröffentlichung des AOSP-Source-Codes für Android 16 deutlich. Entwickler von Custom ROMs wie CalyxOS stellten schockiert fest, dass ein entscheidender Teil fehlte: der gerätespezifische Quellcode für aktuelle Pixel-Smartphones.

Bisher waren Googles eigene Pixel-Geräte (und davor die Nexus-Reihe) die Referenz für AOSP. Der vollständige Code, um AOSP auf einem Pixel zu kompilieren und zu starten, wurde stets mitveröffentlicht. Mit Android 16 änderte sich das. Während der generische Plattform-Code weiterhin verfügbar ist, fehlen die entscheidenden Puzzleteile, um ihn auf echter Hardware lauffähig zu machen.

Was sind gerätespezifische Sourcen und warum sind sie entscheidend?

Für ein lauffähiges Betriebssystem reicht der generische AOSP-Code nicht aus. Es braucht spezifische Anpassungen für die jeweilige Hardware. Dazu gehören vor allem:

• Device Tree: Dies sind Konfigurationsdateien, die dem Linux-Kernel mitteilen, wie die Hardware-Komponenten eines Geräts (z.B. der SoC, Speichercontroller, Peripheriegeräte) miteinander verbunden sind und angesprochen werden müssen. Ohne den Device Tree weiß der Kernel nicht, welche Hardware überhaupt vorhanden ist.
• Kernel-Sourcen: Jedes Gerät benötigt einen speziell angepassten Linux-Kernel. Google pflegt für seine Pixel-Geräte eigene Kernel-Forks, die Treiber und Optimierungen für die verbaute Hardware enthalten.
• Vendor-Blobs: Dies sind proprietäre, also Closed-Source-Treiber von Drittherstellern (z.B. Qualcomm für die GPU oder das Mobilfunkmodem). Diese waren zwar nie quelloffen, aber Google lieferte bisher den notwendigen "Klebstoff" in Form von HALs (Hardware Abstraction Layers) und Konfigurationen, um diese Blobs in ein AOSP-Build zu integrieren.

Das Fehlen dieser Komponenten bedeutet, dass AOSP für moderne Pixel-Geräte nicht mehr "out of the box" gebaut werden kann. Die Pixel-Smartphones verlieren damit ihren Status als offene Referenzplattform für die Android-Community und werden damit genauso wertlos für die Entwicklung wie z.B. Samsung oder Huawei.

Das neue "Referenzziel": Cuttlefish statt echter Hardware

Als Reaktion auf die wachsende Besorgnis in der Community erklärte Seang Chau, Android VP bei Google, dass AOSP keineswegs eingestellt werde. AOSP benötige jedoch ein Referenzziel, das "unabhängig von jeglicher spezieller Hardware, einschließlich der von Google" sei.

Als solches Referenzziel nennt Google Cuttlefish, einen virtuellen Android-Emulator, sowie Generic System Images (GSI).

Für die Entwickler von Custom ROMs ist das ein schwacher Trost. Cuttlefish ist ein Werkzeug für App-Entwickler, um ihre Anwendungen auf einer generischen Android-Umgebung zu testen. Es ist jedoch kein Ersatz für ein echtes Smartphone, das man im Alltag nutzen kann. Die Entwicklung für eine virtuelle Maschine ist fundamental anders als die Anpassung an die Eigenheiten und Fehler einer physischen Hardware-Plattform.

Die Konsequenzen: Ein Schlag für die Community

Die Auswirkungen dieser Änderungen sind vielfältig und treffen unterschiedliche Gruppen:

• Custom-ROM-Entwickler (LineageOS, GrapheneOS, CalyxOS): Für sie ist dies der größte Rückschlag. Pixel-Geräte waren bisher die ideale Basis, da die offene Code-Verfügbarkeit eine schnelle und stabile Portierung neuer Android-Versionen ermöglichte. Nun müssen die Entwickler – wie bei Smartphones anderer Hersteller – aufwendig Treiber und Konfigurationen aus den offiziellen Factory Images extrahieren und per Reverse Engineering anpassen. Dies verzögert die Entwicklung, erhöht die Fehleranfälligkeit und macht die Projekte von einer kleinen Gruppe von Spezialisten abhängig.
• Sicherheitsforscher: Die fehlende Transparenz im Entwicklungsprozess erschwert es, potenzielle Sicherheitslücken frühzeitig zu erkennen. Änderungen werden erst mit dem fertigen Release sichtbar, was das Zeitfenster für unabhängige Analysen verkürzt.
• Normale Anwender: Kurzfristig sind die Auswirkungen minimal. Langfristig schwächt dieser Schritt jedoch das gesamte Open-Source-Ökosystem um Android. Weniger unabhängige Entwicklung bedeutet weniger Alternativen, weniger Innovation von außen und eine noch stärkere Abhängigkeit von Google.

Fazit

Google festigt mit diesen Schritten seine Kontrolle über das Android-Ökosystem und treibt die Transformation von einer offenen Plattform zu einem streng kontrollierten Produkt weiter voran. Obwohl Android lizenztechnisch "Open Source" bleibt, wird die praktische Umsetzung für die "Open Source"-Community massiv erschwert. Die Offenheit verkommt von einem Entwicklungsprinzip zu einem reinen Release-Artefakt, was die Zukunft unabhängiger Android-Forks und die Vielfalt des Ökosystems nachhaltig gefährdet.