Google erschwert Custom-ROMs für Pixel-Geräte

Die Custom-ROM-Gemeinschaft steht vor neuen Herausforderungen: LineageOS, GrapheneOS und andere Projekte müssen künftig deutlich mehr Aufwand betreiben, um aktuelle Android-Versionen auf Pixel-Geräte zu bringen. Grund dafür ist eine Entscheidung von Google.

Was sich geändert hat

Mit der Veröffentlichung des Quellcodes von Android 16 hat Google erstmals auf wichtige Komponenten verzichtet:

• Keine Device-Trees für Pixel-Geräte
• Keine Treiber-Binärdateien (Blobs)
• Kernel-Source nur mit eingeschränkter Commit-Historie

Bisher war es üblich, dass Google diese Daten zusammen mit dem AOSP-Quellcode veröffentlichte, wodurch Pixel-Geräte zu den „Referenzmodellen“ für Custom-ROMs wurden.

Warum sorgt das für Aufsehen

Bislang hat Google der Community mit den Device-Trees, Treibern und Kernel-Quellen eine Art „Bauanleitung“ für Pixel-Smartphones mitgegeben. Entwickler konnten diese Daten nehmen, anpassen und relativ einfach eine neue Android-Version als Custom-ROM zum Laufen bringen.

Jetzt fehlen diese offiziellen Grundlagen. Das heißt:

• Alte Device-Trees aus Android 15 übernehmen: Entwickler müssen versuchen, die Baupläne der Vorgängerversion weiterzuverwenden. Das ist aber fehleranfällig, weil sich bei jeder neuen Android-Version intern viel verändert. Alte Baupläne passen oft nicht mehr zu den neuen Strukturen.
• Binärdateien per Reverse Engineering analysieren: Viele Funktionen in Smartphones – Kamera, Fingerabdrucksensor, Funkmodul – hängen von proprietären Treibern ab, die Google bisher veröffentlicht hat. Ohne diese Treiber bleibt nur der umständliche Weg, die fertigen Dateien zu zerlegen und zu untersuchen, um herauszufinden, wie man sie unter Android 16 überhaupt nutzen kann.
• Eigene Device-Trees von Grund auf erstellen: Wenn beides nicht funktioniert, müssen Entwickler komplett neue Baupläne selbst schreiben – praktisch ein Nachbau der gesamten Gerätebeschreibung, ohne dass der Hersteller ihnen sagt, wie das Gerät genau arbeitet. Das ist extrem zeitaufwendig und erfordert tiefes Expertenwissen.

Für die Community bedeutet das:

• Mehr Aufwand – was früher Wochen dauerte, kann nun Monate verschlingen.
• Mehr Verzögerungen – neue Android-Versionen erscheinen später als Custom-ROM.
• Höhere Einstiegshürden – neue Entwickler, die sich in die Szene einarbeiten wollen, werden schneller abgeschreckt, weil der Einstieg ohne offizielle Hilfen kaum machbar ist.

Kurz gesagt: Google hat die Spielregeln geändert. Anstatt den Entwicklern den Schlüssel in die Hand zu geben, müssen sie sich nun durchs Kellerfenster zwängen.ler.

AOSP bleibt bestehen – aber mit verändertem Fokus

Google hat Spekulationen über ein mögliches Ende des Android Open Source Project (AOSP) sofort dementiert. Seang Chau, Vice President und General Manager der Android-Plattform, stellte auf X klar: „AOSP wird NICHT verschwinden.“

Stattdessen sieht Google künftig Cuttlefish, ein virtuelles Android-Referenzgerät, als Standard für AOSP. Für Entwickler heißt das: weniger Abhängigkeit von realer Hardware, aber auch weniger Transparenz für Geräte wie die Pixel-Serie.

Zwischen den Zeilen: Soll Custom-ROM-Entwicklung erschwert werden?

Offiziell begründet Google die Änderungen mit einer effizienteren internen Entwicklung und weniger Konflikten beim Code-Merging. Doch in der Community stellt sich die Frage:

• Ist das nur eine technische Neuausrichtung – oder steckt auch Kalkül dahinter?
• Will Google verhindern, dass Pixel-Geräte weiterhin die bevorzugte Basis für Custom-ROMs bleiben?

Denn eines ist klar: Je mehr Hürden Google aufbaut, desto weniger Entwickler werden sich die Mühe machen, eigene ROMs für Pixel-Smartphones zu pflegen. Für ein Unternehmen, das seine Geräte stärker in ein eigenes Ökosystem bindet, wäre das kein Nachteil.

Kontrolle vs. Offenheit

Auf den ersten Blick wirkt Googles Entscheidung auch rein technisch begründet – weniger Code-Zweige, effizientere Entwicklungsprozesse, einheitliche Referenzplattform (Cuttlefish). Doch wenn man etwas genauer hinschaut kann man auch folgendes daraus ableiten:

• Kontrolle über das Ökosystem:
  Mit jedem Schritt, der die Arbeit der Custom-ROM-Community erschwert, stärkt Google die Bindung von Nutzern an die hauseigenen Pixel-ROMs. Wer keine funktionierenden Alternativen mehr hat, bleibt automatisch länger im offiziellen Android-Ökosystem – inklusive Google-Diensten.
• Annäherung an Apples Modell:
  Apple kontrolliert sowohl Hardware als auch Software strikt. Google hat mit den Pixel-Geräten eine ähnliche Strategie aufgebaut, allerdings bislang mit mehr Offenheit für Entwickler. Das aktuelle Vorgehen könnte ein Schritt in Richtung stärker geschlossener Systeme sein.
• Sicherheits-Argument als politisches Werkzeug:
  Google könnte die Einschränkungen offiziell mit höheren Sicherheitsanforderungen begründen. Weniger Transparenz für Kernel und Treiber erschwert nicht nur Custom-ROMs, sondern auch den Zugriff für Sicherheitsforscher. Dadurch behält Google mehr Kontrolle darüber, welche Sicherheitslücken öffentlich sichtbar werden – ein zweischneidiges Schwert.
• Einfluss auf die Open-Source-Szene:
  Pixel-Geräte waren jahrelang eine Art "Schaufenster" für Android-Offenheit. Wenn selbst Google diese Referenzgeräte nicht mehr offenlegt, sendet das ein Signal an andere Hersteller: Offenheit ist optional, Kontrolle ist Standard. Das könnte die gesamte Landschaft der offenen Android-Entwicklung langfristig verändern.
• Wirtschaftliche Interessen:
  Custom-ROMs wie GrapheneOS oder CalyxOS sind vor allem deshalb beliebt, weil sie Google-Dienste teilweise ersetzen oder ganz entfernen. Wer Custom-ROMs erschwert, schützt indirekt das eigene Geschäftsmodell: Google verdient am Datenzugriff und an der Integration seiner Services – nicht daran, dass Nutzer sich davon befreien.

Fazit

Die Schlagzeilen vom „Ende der Custom-ROMs“ sind übertrieben – Custom-ROMs werden nicht verschwinden. Aber: Google hat mit dieser Entscheidung die Weichen gestellt, die Entwicklung zumindest deutlich mühsamer zu machen.

Ob dies nur eine Folge interner Umstrukturierungen ist oder ein gezielter Versuch, die Community auszubremsen, bleibt offen. Fakt ist: Die Custom-ROM-Szene wird überleben – aber sie wird härter kämpfen müssen als bisher.