close notice<\/p>\n
\n This article is also available in It was translated with technical assistance and editorially reviewed before publication.\n <\/p>\n \n Don\u2019t show this again.\n<\/p>\n Google hat der Custom-ROM-Community gewisserma\u00dfen einen Stock zwischen die Beine geworfen: Mit der Ver\u00f6ffentlichung von Android 16<\/a> hat das Unternehmen zwar den Quellcode der neuen OS-Version auch im Android Open Source Project (AOSP) freigegeben, mit dem unabh\u00e4ngige Entwickler ihre eigenen Forks des Betriebssystems unter der recht freiz\u00fcgigen Apache-2.0-Lizenz kompilieren k\u00f6nnen. Jedoch hat der Konzern die bislang gleichzeitig ver\u00f6ffentlichten Device-Trees f\u00fcr Pixel-Ger\u00e4te nicht mitgeliefert.<\/p>\n Google: AOSP lebt, aber …<\/p>\n Weder die Treiber-Bin\u00e4rdateien noch die vollst\u00e4ndige Kernel-Quellcode-Commit-Historie hat der Konzern ver\u00f6ffentlicht und weicht damit von seiner bisher \u00fcblichen Praxis ab. Diese Auslassung f\u00fchrte zu Spekulationen, dass Google wom\u00f6glich das AOSP-Programm g\u00e4nzlich einstellen k\u00f6nnte, wie etwa die Macher von GrapheneOS<\/a> meinten.<\/p>\n Doch so dramatisch ist es nicht. AOSP bleibt erhalten, wie Googles Vice President und General Manager der Android-Plattform, Seang Chau, auf X <\/a>versicherte: „AOSP wird NICHT verschwinden. AOSP wurde auf der Grundlage einer offenen Plattform f\u00fcr Ger\u00e4teimplementierungen, SoC-Anbieter und Befehlssatzarchitekturen entwickelt.“<\/p>\n Jedoch best\u00e4tigte der Manager, dass das Fehlen der Pixel-Device-Trees kein Fehler sei. Er erl\u00e4uterte, dass „AOSP ein Referenzziel ben\u00f6tigt, das flexibel, konfigurierbar und erschwinglich ist \u2013 unabh\u00e4ngig von einer bestimmten Hardware, einschlie\u00dflich der von Google“.<\/p>\n Statt AOSP-Builds auf Pixel-Ger\u00e4ten zu unterst\u00fctzen, zielt Google darauf ab, dass Entwickler das virtuelle Android-Ger\u00e4t „Cuttlefish“<\/a> als Referenz nutzen sollen. Cuttlefish l\u00e4uft auf PCs und erm\u00f6glicht es Google und Plattformentwicklern, neue Hardwarefunktionen zu testen. Ferner will Google weiterhin GSI-Targets unterst\u00fctzen, bei denen es sich um generische System-Images handelt, die auf nahezu jedem Android-Ger\u00e4t installiert werden k\u00f6nnen, erkl\u00e4rt Chau.<\/p>\n Die Begr\u00fcndung seitens Google klingt teilweise nachvollziehbar. Dennoch f\u00fchlen sich Custom-ROM-Entwickler vor den Kopf gesto\u00dfen. Denn seit Jahren nutzen sie Pixel-Smartphones als Entwicklungsplattformen oder verwenden den Quellcode als Referenz f\u00fcr andere Ger\u00e4te, um jede Android-Version zu aktualisieren, wie Nolen Johnson auf X schreibt<\/a>. Er wirkt seit Jahren an der Entwicklung von LineageOS mit.<\/p>\n Gegen\u00fcber Android Authority sagt Johnson<\/a>, dass die Entwicklung von Custom-ROMs k\u00fcnftig „schmerzhaft“ sein wird. Denn bisher machte Google es Entwicklern einfach, AOSP f\u00fcr Pixel-Ger\u00e4te zu erstellen. Entwickler konnten einfach die von Google bereitgestellten Konfigurationen nutzen, ihre eigenen Anpassungen hinzuf\u00fcgen und daraus ein Custom-ROM kompilieren.<\/p>\n Durch den Wegfall m\u00fcssen sie auf alte Device-Trees zur\u00fcckgreifen, die Google f\u00fcr Android 15 ver\u00f6ffentlicht hat und \u2013 so Johnson \u2013 „blind raten“ und aus den vorgefertigten Bin\u00e4rdateien mittels Reverse-Engineering analysieren, welche \u00c4nderungen jeden Monat erforderlich seien.<\/p>\n „Gro\u00dfer Schritt in die falsche Richtung“<\/p>\n F\u00fcr die Entwickler des geh\u00e4rteten GrapheneOS sieht die Situation noch ernster aus. Denn sie bieten ihr Custom-ROM ausschlie\u00dflich f\u00fcr Pixel-Ger\u00e4te an, da es bislang zum einen sehr einfach war, auf Pixel-Ger\u00e4ten Android-Alternativen zu installieren und auch wieder zur Originalsoftware zur\u00fcckzukehren. Zum anderen sorgt Google f\u00fcr seine Ger\u00e4te besser als viele andere Android-Hersteller f\u00fcr Sicherheitsupdates, was besonders f\u00fcr Graphene ein wichtiger Aspekt ist.<\/p>\n Die AOSP-\u00c4nderungen seitens Google stellen f\u00fcr GrapheneOS ein gro\u00dfes Hindernis dar, sodass die Kompilierung einer neuen Version auf Android 16 weit l\u00e4nger dauert als \u00fcblich. „Wir werden es trotzdem schaffen, aber nicht ann\u00e4hernd so schnell, wie wir es f\u00fcr akzeptabel halten“, schreiben die Entwickler auf Reddit<\/a>.<\/p>\n GrapheneOS war schon vor Googles neuer AOSP-Strategie gebeutelt, denn der aktivste und leitende Entwickler des Betriebssystems ist nicht verf\u00fcgbar. Er wurde offenbar im M\u00e4rz zum Wehrdienst eingezogen<\/a>, sodass die Arbeit am Custom-ROM langsamer als \u00fcblich vonstatten gehen muss.<\/p>\n Die neue Situation mit den Pixel-Ger\u00e4ten scheint Graphene dazu zu veranlassen, fr\u00fcher als geplant, eigene Hardware f\u00fcr Graphene zu entwickeln. „Wir verstehen nicht, warum diese \u00c4nderungen vorgenommen wurden, und es ist ein gro\u00dfer Schritt in die falsche Richtung“, so GrapheneOS auf Mastodon<\/a>.<\/p>\n Was auch immer die Beweggr\u00fcnde f\u00fcr Google waren, Custom-ROM-Entwicklern das Leben schwerer zu machen. Durch das Entfernen der Pixel-Dateien aus dem AOSP n\u00e4hert sich Google anderen Smartphone-Herstellern an, die den Zugang zu ihren Ger\u00e4te erschweren. Der einzige Unterschied ist, dass die Installation von Custom-ROMs dank eines leicht entriegelbaren Bootloaders auf Pixel-Smartphones bis auf Weiteres einfach bleibt.<\/p>\n
\n English<\/a>.<\/p>\n