- Google hat den Quellcode von Android 16 in AOSP veröffentlicht, das Pixel-Hardware-Repository jedoch nicht freigegeben
- Da Pixel-Gerätebäume und zugehöriger Code nicht veröffentlicht wurden, kamen in Teilen der Community Vermutungen über ein „Ende von AOSP“ auf
- Google wies dies offiziell zurück und erklärte, „AOSP wird nicht eingestellt“, zugleich wurde bekräftigt, dass der AOSP-Quellcode auch künftig veröffentlicht und aktualisiert wird
- Künftig soll AOSP auf Referenzziele setzen, die nicht an bestehende Hardware gebunden sind, und sich stärker auf virtuelle Geräte bzw. verallgemeinerte Geräte wie 'Cuttlefish' und GSI konzentrieren, die flexibel und kostengünstig sind
- Für Custom-ROM-Entwickler und Sicherheitsforscher könnte es dadurch schwieriger werden, OS-Updates umzusetzen und Forschung zu betreiben
Veröffentlichung von Android 16 und Probleme rund um den Quellcode
- Zeitgleich mit dem Release von Android 16 hat Google den Code für das Pixel-Hardware-Repository und die Device-Tree-Strukturen nicht veröffentlicht
- Zuvor wurde zusammen mit AOSP auch Code für Pixel-Hardware bereitgestellt, der für die Entwicklung von Custom-Android-ROMs eine wesentliche Rolle spielte
- Dadurch dürften Custom-ROM-Entwickler und Sicherheitsforscher bei der Entwicklung eigener Betriebssysteme, bei aktuellen Android-Updates und bei der Forschung zu Sicherheitslücken auf Schwierigkeiten stoßen
Googles offizielle Position zu AOSP
- In Teilen der Community kursierte das Gerücht, „AOSP werde eingestellt“, doch Seang Chau, VP im Android-Bereich, wies dies offiziell zurück
- „AOSP verschwindet nicht“
- „Wir bleiben AOSP-Updates weiterhin verpflichtet“
- Die offizielle Antwort des Android-Teams deutet jedoch darauf hin, dass Dinge wie Pixel-Gerätebäume künftig nicht mehr bereitgestellt werden
- Das von AOSP bereitgestellte Referenzziel soll künftig unabhängig von bestimmter Hardware sein
- Angestrebt wird ein flexibles, konfigurierbares und günstiges Referenzgerät, das nicht an bestimmte Hardware gebunden ist – auch nicht an die von Google
- Seit Jahren nutzt die Community Cuttlefish (Referenzgerät) und GSI-Ziele, die aus dem Quellcode gebaut werden, für Tests und Entwicklung
- Diese Referenzgeräte sollen Entwicklern weiterhin zur Verfügung gestellt werden
Auswirkungen auf die Custom-ROM- und Sicherheits-Community
- Google betont offiziell seinen Willen zur fortlaufenden Unterstützung von AOSP
- Da jedoch die direkte Hardware-Unterstützung entfällt, dürfte die Entwicklungshürde und Einstiegsschwelle für die Erstellung und Wartung von Custom-ROMs sowie für Sicherheitsforschung deutlich steigen
1 Kommentare
Hacker-News-Kommentare
Ihr haltet mich vielleicht für seltsam, aber der einzige Grund, warum ich mir kürzlich ein Pixel gekauft habe, war die Absicht, direkt nach dem Kauf sofort GrapheneOS zu installieren. Bisher war ich mit dem Ergebnis wirklich sehr zufrieden. Alles, was mit Google zu tun hat und nicht arbeitsbezogen ist, versuche ich möglichst zu vermeiden. Es gibt einfach zu viele Dinge, die ich an Google nicht mag. Natürlich ist Google nicht verpflichtet, solche Binary Blobs weiterhin bereitzustellen, aber dass etwas, das sie lange Zeit getan haben, plötzlich ohne Vorankündigung eingestellt wird, ist wieder einmal enttäuschend. Wie bei so vielen eingestellten Diensten hätte es meiner Meinung nach im Voraus eine ausreichende Ankündigung geben müssen. Ich verstehe natürlich, dass die weitere Verteilung der Binärdateien und die Garantie ihrer Funktionsfähigkeit zusätzlichen Aufwand bedeuten. Gleichzeitig müssen sie diese Arbeit intern ohnehin erledigen. Ich vermute, dass Google strategisch entschieden hat, bei einigen GrapheneOS-Nutzern Geräteverluste in Kauf zu nehmen und sich stattdessen auf sekundäre Einnahmequellen wie ein geschlossenes Ökosystem, Data Mining oder Werbung zu konzentrieren
Ich habe mir aus genau demselben Grund ein Pixel gekauft. Inzwischen weiß jeder, dass heute auf fast allen Ebenen Tracking stattfindet, deshalb halte ich es für die vernünftigste Entscheidung, ein Pixel zu kaufen und sofort GrapheneOS darauf zu flashen. Alle Telefone in unserem Haushalt, das meiner Frau und meines, nutzen wir genauso. Um Play Services, Google-Apps oder Facebook muss man sich überhaupt nicht kümmern. Ich möchte nicht, dass mein Leben Teil zielgerichteter Werbung wird oder von Daten, die irgendwann für irgendetwas verwendet werden. Fast erstaunlicher finde ich, wie viele Menschen gegenüber ihrer Privatsphäre so gleichgültig sind
Sehr großzügige Bewertung. Ich mache genau dasselbe
Ich sehe die Behauptung „Google hat die Bereitstellung der Binärdateien ohne ausreichende Vorankündigung eingestellt“ etwas anders. Sich auf undokumentiertes Verhalten zu verlassen und sich dann zu beschweren, wenn es geändert wird, ist seltsam. Für Software Engineers sollte es selbstverständlich sein, sich nicht auf so etwas zu verlassen. Wenn jemand zum Beispiel ein Pixel als Türstopper benutzt hätte und es wegen des Kamera-Bumps nicht mehr dafür taugt, wäre es aus meiner Sicht genauso abwegig, dafür dem Unternehmen die Schuld zu geben
Ich erinnere mich noch daran, wie dankbar ich dafür war, dass man echte Consumer-Hardware wie Pixel oder früher Nexus kaufen, AOSP und die proprietären Blobs herunterladen und dann ohne großen Aufwand einen Build erstellen konnte, bei dem die komplette Hardware funktionierte. Cuttlefish mag als Referenzgerät effektiver sein, aber das ist etwas anderes als die vielseitige Nutzbarkeit eines Pixel-Geräts etwa für Projekte wie GrapheneOS. Android, das ich selbst gebaut habe, direkt auf echter Hardware in der Hand laufen zu lassen, hat für mich einen Reiz, den eine VM nicht ersetzen kann
Ich finde, GrapheneOS hat die Situation überzogen dargestellt und sich damit selbst geschadet, so nach dem Muster des „Jungen, der Wolf rief“. Kritik, die offensichtlich falsch ist, lässt sich aus Unternehmenssicht leicht zurückweisen. Aussagen wie „Google is killing AOSP“ ziehen zwar Aufmerksamkeit auf sich, aber sie sind für das Unternehmen viel zu leicht zu entkräften. Was hier tatsächlich passiert, ist, dass GrapheneOS Binary Blobs auf Basis von Googles Goodwill erhalten hat, Google dazu aber in keiner Weise verpflichtet war und die Bereitstellung nun aus eigenen Gründen eingestellt hat. Dass GrapheneOS dann auch noch rechtliche oder monopolbezogene Kontroversen erwähnt, führt nur dazu, dass Entwickler sich gar nicht erst einmischen und das Ganze direkt bei der Rechtsabteilung landet
Mich würde konkret interessieren, was daran überzogen gewesen sein soll. Was genau war falsch, ob GrapheneOS das früher schon gemacht hat und welche konkreten Punkte problematisch gewesen sein sollen
Ich denke, dass GrapheneOS durch diese Sache dazu kommen wird, künftig auch eine breitere Geräteauswahl jenseits von Pixel zu unterstützen. Ehrlich gesagt hätte das meiner Meinung nach ohnehin schon passieren sollen, und selbst ohne diese spezielle Hardware-Unterstützung ist es immer noch deutlich sicherer als Stock Android
Ich finde nicht, dass man Google aktiv verteidigen muss, nur weil das Unternehmen faktisch einer von zwei Quasi-Monopolisten ist
Ich habe mich immer darum gesorgt, dass es für Custom-Android-ROMs sehr schwierig wird, OS-Updates zu entwickeln, wenn es keine Pixel-Hardware-Repositories mehr gibt, also Device Trees, Treiber-Binärdateien und ähnliches. Das könnte sich auch auf die Sicherheitsforschung auswirken
Ohne GrapheneOS würde ich wahrscheinlich zu einem iPhone wechseln. Ich nutze GrapheneOS schon lange und mag dieses leichte, einfache Gefühl ohne unnötige Google-Bestandteile sehr. Ein offizielles Pixel von Google passt jetzt nicht mehr zu mir
Wieder ein weiterer Eintrag für den Google Graveyard. Wenn ich nicht mehr selbst die Kontrolle haben kann, sehe ich keinen Grund mehr, ein Pixel zu nutzen. Ich werde wohl wieder ein iPhone ausprobieren, seine Nachteile in Kauf nehmen und dafür viele Vorteile mitnehmen
Mir kommt sofort die Gegenrede in den Sinn: „AOSP lebt doch weiter, notfalls kann man den Emulator nutzen.“ Im Artikel heißt es, „seit Jahren haben Entwickler Cuttlefish (siehe GitHub-Referenz) und GSI-Ziele aus dem Source-Code gebaut und als Referenzziele verwendet. Diese werden auch künftig für Test- und Entwicklungszwecke bereitgestellt.“ Ich bin bei AOSP noch Anfänger und frage mich aus Community-Sicht, ob solche Referenzgeräte für die Entwicklung von Custom-ROMs tatsächlich praktisch nutzbar sind oder ob das eher eine Behauptung für die Außendarstellung ist
Ich frage mich, ob das nicht genau der Grund war, warum GrapheneOS auf dem Pixel so gut lief. Wenn die ersten Hürden einmal genommen sind und man die zentralen Änderungen versteht, könnte das am Ende vielleicht sogar zu einer Ausweitung auf mehr Geräte führen
Das stimmt nur teilweise. Laut offiziellem FAQ sind die Hauptgründe (1) erstklassige Hardware-Sicherheitsfunktionen wie Memory Tagging, (2) schnelle Bereitstellung von Patches und (3) langfristiger offizieller Support
Oder diese Änderung führt dazu, dass GrapheneOS künftig überhaupt keine neuen Geräte mehr unterstützt
GrapheneOS war der einzige Grund, überhaupt ein Pixel zu kaufen
Etwas redundant verwandter Link