Zum ersten Mal seit 13 Jahren: Neue APIs ohne Quellcode
Android bezeichnet sich gerne als eines der größten Open-Source-Projekte der Welt. Doch mit der Veröffentlichung von Android 17 QPR1 (Quarterly Platform Release 1) am 15. September 2026 vollzog Google einen Schritt, den es seit 2012 nicht mehr gegeben hatte: Entwicklern wurden neue Schnittstellen (APIs) bereitgestellt, ohne den dazugehörigen Quellcode im AOSP (Android Open Source Project) freizugeben. Diese neuen APIs laufen gegenwärtig ausschließlich auf hauseigenen Pixel-Smartphones; Dritthersteller wie Samsung, Xiaomi oder OPPO bleiben komplett außen vor.
Zuletzt war ein solcher Fall bei Android 3.x Honeycomb aufgetreten – jener reinen Tablet-Version, die niemals vollständig als Open Source veröffentlicht wurde. Nach Honeycomb investierte Google mehr als ein Jahrzehnt darin, der weltweiten Entwicklergemeinde zu beweisen, dass Android verlässlich quelloffen ist. Mit Android 17 versieht Google dieses Versprechen nun mit einem gravierenden Vorbehalt.
GrapheneOS schlägt öffentlich Alarm
Am 16. September machte das auf Privatsphäre und IT-Sicherheit spezialisierte alternative Betriebssystem GrapheneOS den Vorfall über das dezentrale Netzwerk Mastodon publik. Der Beitrag verbreitete sich rasch und verzeichnete 51 Boosts sowie 92 Favorisierungen. GrapheneOS enthüllte dabei ein besonders brisantes Detail: Das eigene Entwicklerteam hatte den Port auf Android 17 QPR1 bereits vor dem offiziellen Start am 15. September fertiggestellt, besaß jedoch „keine Freigabe zur Veröffentlichung“.
Abbildung: Offizieller Mastodon-Post von GrapheneOS zur Nichtveröffentlichung des Quellcodes von Android 17 QPR1 im AOSP. Quelle: GrapheneOS Mastodon-Kanal
Mit anderen Worten: Der Code war einsatzbereit, doch Google verweigerte die Genehmigung. GrapheneOS sah sich gezwungen, den umgekehrten Weg einzuschlagen – Firmware, Kernel-Treiber, Userspace-Treiber und Hardware-Abstraktionsschichten (HALs) aus Android 17 QPR1 mühsam auf das Standard-Android 17 zurückzuportieren. Andere Smartphone-Hersteller trifft es noch härter: Sie müssen bis zur Veröffentlichung von QPR2 im Dezember 2026 ausharren, um die entsprechenden Aktualisierungen zu erhalten. Google verschafft seinen Pixel-Geräten damit ein volles dreimonatiges Exklusivitätsfenster.
Zwar verpflichtet die GNU General Public License (GPL) Google rechtlich zur Offenlegung des Quellcodes modifizierter Komponenten, sie setzt jedoch keine Fristen für den Veröffentlichungszeitpunkt. GrapheneOS forderte bereits am 1. September den Quellcode für den Build CD1A.260905.001.A1 an, erhielt den Zugriff jedoch erst am 17. September – nach 16 Tagen Wartezeit. Die Lizenz besagt zwar, dass der Code bereitgestellt werden muss, nicht jedoch, dass dies unverzüglich zu geschehen hat.
Auch Sicherheits-Patches landen im Exklusivitätsfenster
Eine funktionale Exklusivität ließe sich zur Not noch als aggressive Vertriebsstrategie abtun. Das Zurückhalten sicherheitsrelevanter Fehlerbehebungen überschreitet jedoch eine fundamentale Grenze.
Wie GrapheneOS darlegte, enthält das Pixel Update Bulletin vom September 2026 zusätzliche Sicherheits-Patches für Standardkomponenten der Android-Plattform, die auch von Nicht-Pixel-Geräten genutzt werden. Diese geteilten Komponenten weisen auf Geräten von Drittherstellern exakt dieselben Schwachstellen auf. Dennoch wurden diese Patches weder in das allgemeine Android Security Bulletin für September 2026 aufgenommen noch über Preview-Patch-Pakete an Partner verteilt.
Abbildung: API-Diff-Dokumentation zwischen API-Level 37 und 37.1 auf der offiziellen Android-Entwicklerseite. Quelle: developer.android.com
GrapheneOS fand deutliche Worte: „Google sollte Sicherheits-Patches für den Standard-Plattformcode von Android nicht vor anderen OEMs zurückhalten, aber genau das tun sie jetzt.“ Weiter hieß es mit spürbarer Skepsis: „Es wäre interessant zu wissen, ob Googles Rechtsabteilung bewusst ist, dass sie Pixel-Geräten einen monatelangen Vorabzugang zu neuen Android-Funktionen und Fehlerbehebungen gewährt – einschließlich bestimmter wichtiger Sicherheits-Patches.“
Für den Wettbewerb bedeutet diese Verzögerung, dass die Pixel-Reihe drei Monate lang im Vorteil ist. Aus Nutzersicht bedeutet es, dass Milliarden Android-Geräte weltweit drei Monate länger als nötig bekannten Angriffsvektoren schutzlos ausgeliefert bleiben. Auf neue Komfortfunktionen kann man warten; Sicherheitslücken warten nicht.
Community fordert Hard Fork, doch wer stemmt den Entwicklungsaufwand?
Auf Hacker News löste die Entwicklung eine hitzige Debatte aus und erreichte 389 Punkte sowie 177 Kommentare. Der meistbeachtete Kommentar verknüpfte Googles jüngste Schritte – verzögerte Upstream-Patches, Quellcode-Embargos, verschärfte Hardware-Attestierung – und zog das bittere Fazit: „Google bereut schlichtweg, Android jemals als Open Source veröffentlicht zu haben.“ Ein anderer Kommentator plädierte für radikale Maßnahmen: Ein Hard Fork müsse jetzt sofort vollzogen werden, sonst gäbe es bald überhaupt keine Alternative mehr.
Doch solchen Rufen steht eine unerbittliche Realität der Softwareentwicklung entgegen. Eine echte Abspaltung von Android setzt voraus, dass eine unabhängige Community einen Entwicklungsaufwand bewältigen kann, der dem von Google kaum nachsteht: Treiberanpassungen für unzählige Chipsätze, monatliche Sicherheits-Rückportierungen, Validierung per Compatibility Test Suite (CTS) und die kontinuierliche Pflege des Ökosystems. Jeder dieser Bereiche verschlingt dauerhaft enorme finanzielle und personelle Ressourcen. Wenn es dem Linux-Desktop in zwei Jahrzehnten nicht gelang, Windows zu verdrängen, dürfte ein Fork von Android vor noch weitaus größeren Hürden stehen. GrapheneOS räumte selbst ein, dass Pixel-Telefone mittlerweile „deutlich schwieriger zu unterstützen“ seien. Der einst entscheidende Vorzug der Pixel-Reihe – die unmittelbare Nähe zum unveränderten AOSP – löst sich zusehends auf.
Open-Source-Lizenzen regeln den Code, nicht das Tempo
Dem Open-Source-Modell von Android lag von Beginn an eine oft übersehene Realität zugrunde: Google entschied sich 2008 nur deshalb für Open Source, weil der Konzern dringend Gerätehersteller benötigte, um den Markt flächendeckend zu erschließen. Samsung, Huawei und Xiaomi verhalfen Android zu einem weltweiten Marktanteil von über 70 Prozent. Nachdem die Vormachtstellung zementiert war, wandelte sich „Open Source“ von einem unumstößlichen Grundsatz zu einer verhandelbaren Manövriermasse. Android 17 QPR1 demonstriert diese Machtverschiebung mit aller Deutlichkeit: Neue Funktionen und Sicherheits-Patches verbleiben zunächst drei Monate exklusiv bei den Pixel-Geräten.
Für das nachgelagerte Ökosystem bleiben drei Optionen: Die Hersteller warten geduldig auf QPR2 im Dezember; Projekte wie GrapheneOS betreiben aufwendiges Reverse Engineering; oder Endnutzer wechseln direkt zu einem Pixel. Alle drei Pfade führen zum selben Ergebnis: Google bestimmt den Takt. Die Open-Source-Lizenz stellt zwar sicher, dass der Code letztlich veröffentlicht werden muss. Doch das dreimonatige Zeitfenster, das sich in diesem „letztlich“ verbirgt, reicht völlig aus, damit Pixel bei Funktionsumfang und Systemsicherheit uneinholbar vorauseilt.
Weiterführende Links:
- GrapheneOS Mastodon-Post
- Hacker News Diskussion
- Android Developer API-Diff-Dokumentation
- Android-Sicherheitsbulletin (September 2026)
