Exklusiv Google beschließt, Open-Source-Android zu beenden

Zwecks Nachrichtenberichterstattung und rein interessanter Diskussionen hat Ai Faner verschiedene „Sandtischableitungen“ zu den Strategien bekannter Technologieunternehmen durchgeführt und sich viele Szenarien ausgedacht.

Aber ich hatte nicht damit gerechnet, dass Google tatsächlich die unwahrscheinlichste Situation passieren würde.

AOSP (Android Open Source Project) ist ein von Google geleitetes Open-Source-Projekt, das grundlegende Frameworks und Kernkomponenten für alle Betriebssysteme von Android-Geräten bereitstellt. Es entspricht einem „leeren Raum“, in dem Entwickler den Code frei herunterladen, ändern und verteilen und darauf basierende benutzerdefinierte Systeme erstellen können, darunter Xiaomi HyperOS, vivo OriginOS, ColorOS von OPPO und sogar das Android-System der Pixel-Telefone, alle auf AOSP-Basis.

Die Wartung von Android durch Google ist in zwei Wege unterteilt: Der öffentliche AOSP-Zweig steht Entwicklern auf der ganzen Welt offen, enthält reinen Open-Source-Code und umfasst keine proprietären Dienste von Google. Jeder Hersteller oder jede Einzelperson kann auf Basis dieser Branche ein System entwickeln. Der interne Closed-Source-Zweig steht nur Herstellern zur Verfügung, die die GMS-Vereinbarung (Google Mobile Services) unterzeichnet haben.

Konkret wird Google den derzeitigen öffentlichen Zweig von AOSP nicht mehr unterhalten, zugehörige Support-Ressourcen schrittweise schließen und möglicherweise die Aktualisierung des Quellcodes von Komponenten außerhalb der gesetzlichen Open-Source-Verpflichtungen (Code gemäß GPL und anderen Vereinbarungen) einstellen.

Die Android Authority aus Übersee berichtete erstmals über diese Situation, und auch Google bestätigte die Angelegenheit.

Ab nächster Woche wird die gesamte Android-Entwicklung ausschließlich in den internen Niederlassungen von Google erfolgen. Nach einer gewissen Zeit kann es sein, dass die Außenstelle nicht mehr öffentlich ist oder sogar ganz geschlossen wird. Außerdem werden möglicherweise auch die CI/CD-Tools und -Umgebungen von AOSP heruntergefahren, und sogar Android Gerrit (https://android-review.googlesource.com/) wird möglicherweise heruntergefahren. Von nun an können nur Mitarbeiter innerhalb von Google auf die internen Niederlassungen von AOSP zugreifen oder Code übermitteln. Der Entwicklungsprozess von Android wird nicht mehr transparent sein.

Aus übergeordneter Sicht wird Google die in AOSP enthaltenen Inhalte schrittweise reduzieren, bis AOSP nicht mehr als Open-Source-Projekt und als Konzept existiert.

Wenn man die Geschichte als Leitfaden nimmt, öffnete das OpenSolaris-Projekt (das heißt das Open-Source-Projekt, das dem Solaris-Betriebssystem entspricht) nach der Übernahme von Sun durch Oracle und der Ankündigung von „verzögertem Open Source“ für OpenSolaris nicht mehr als die Hälfte des Codes unter der CDDL-Lizenz, bis die Solaris-Entwicklungsabteilung aufgelöst wurde.

Niemand weiß, ob Googles Versprechen an die Android Authority, „Open Source weiterzuführen, es einfach aufzuschieben“, nur leere Worte sind – schließlich ist eine Verschiebung auf unbestimmte Zeit auch eine Art Verschiebung.

Nach dem Verständnis von Ai Faner besteht die Gesamtidee von Android Closed Source darin, letztendlich nur die Open-Source-Teile beizubehalten, die für die starke Infektionslizenz der GPL erforderlich sind, hauptsächlich Linux-Kernel-Statustreiber und -Patches. Andere Teile der mittleren und oberen Schichten, die zuvor lose Open-Source-Lizenzen verwendeten, wie z. B. Apache, werden irgendwann Closed-Source-Lizenzen sein ; Zukünftige Android-Versionen werden nach der Veröffentlichung des Quellcodes nicht mehr öffentlich veröffentlicht oder aktualisiert.

Die Entscheidungsebene in dieser Angelegenheit liegt auf der obersten Führungsebene von Google. Es wird davon ausgegangen, dass sie diese Entscheidung spätestens Anfang 2025 treffen werden. Die Umsetzung der gesamten Strategie wird sich über einen längeren Zeitraum, zumindest über mehrere Jahre, erstrecken, bis AOSP völlig seine Bedeutung verliert.

Das wahre Motiv für den Schritt von Google ist noch nicht klar, aber nach der Analyse und dem Verständnis von Ai Faner geht es vor allem darum, Ausgaben zu sparen und Einnahmen zu steigern :

AOSP verfügt über mehrere Code-Pipelines und eine große Anzahl von Zweigen in unterschiedlichen Dimensionen (z. B. Versionsnummer, Release-Fortschritt usw.). Unter Berücksichtigung der vor- und nachgelagerten Codes des Projekts und der Zusammenarbeit zwischen mehreren Unternehmen wird es noch komplizierter, was Wartung und Verwaltung sehr schwierig macht, was zu großen Rechenressourcen und Arbeitsstundenkosten führt. Möglicherweise möchte Google diese Kosten einsparen. Wenn man bedenkt, dass die Android-Abteilung allen Mitarbeitern die Möglichkeit einer „freiwilligen Kündigung“ Anfang 2025 eingeräumt hat, ist die Logik der Kostenkürzungen nicht schwer zu verstehen. Darüber hinaus sind Hersteller, die einen Partnerschaftsvertrag unterzeichnet haben, verpflichtet, Google-Dienste zu bündeln, um die Werbeeinnahmen für Google zu steigern, was wiederum den Gesamtumsatz des Unternehmens steigert.

Glücklicherweise sind die direkten Auswirkungen von Closed-Source-AOSP auf die Branche derzeit nicht katastrophal und die intuitiven Auswirkungen auf Endnutzer von Mobiltelefonen sind ebenfalls minimal.

Die meisten Mainstream-Mobiltelefonhersteller haben bereits verschiedene autorisierte Partnerverträge mit Google unterzeichnet. Hersteller im Rahmen der bestehenden Vereinbarungen können weiterhin den neuesten Android-Quellcode beziehen und verwenden, die Google GMS-Zertifizierung erhalten, in der Regel Dienste und Anwendungen wie Google Play und Gmail vorinstallieren und Support von Google erhalten. Alle Geschäfte bleiben wie gewohnt.

Die tatsächliche Wirkung wird nicht direkt sichtbar, sondern über einen längeren Zeitraum von der Seite reflektiert. Dies wird später im Detail erläutert.

AOSP, existiert nicht mehr?

Folgende Punkte bedürfen der Klärung:

1. Da der meiste AOSP-Code unter der Apache 2.0-Lizenz veröffentlicht wird, kann jeder eine Kopie erstellen. Es gibt auch verschiedene AOSP-Spiegel auf anderen Code-Service-Plattformen wie GitHub und der inländischen Android-Community. Google hat kein Recht, andere „inoffizielle“ AOSP-Codebasen offline zu nehmen. Was Open Source war, kann nicht widerrufen werden.
2. Mit anderen Worten: Solange es von anderen inoffiziellen Kanälen heruntergeladen werden kann, können Benutzer weiterhin den zuletzt aktualisierten AOSP-Code von Google verwenden und ihn entsprechend ihren eigenen Anforderungen ändern. Wenn Sie über genügend leistungsstarke Entwickler verfügen, können Sie im Prinzip das bisherige AOSP in Ihr eigenes System umwandeln, um es zu warten und zu aktualisieren.

Android/AOSP war nie ein echtes Open-Source-Projekt und Fundamentalisten in der Community haben es immer kritisiert.

Wie bereits erwähnt, läuft Android derzeit auf dem Linux-Kernel, der Open Source unter der GPL-Lizenz ist. Die GPL ist eine hoch ansteckende Lizenz, die verlangt, dass alle abgeleiteten Werke gemäß der GPL-Lizenz Open Source sein müssen, wodurch der Geist der unbegrenzten Open Source umgesetzt und die Community erweitert wird.

Um das Android-Geschäftsökosystem aufzubauen, hat Google ein Lizenzmodell entwickelt, das Open-Source- und kommerzielle Anforderungen in Einklang bringt. Google unterteilt die Android-Plattform in mehrere Teile: Der zugrunde liegende Linux-Kernel-Teil bleibt unter der GPL v2-Lizenz (je nach Bedarf), während der größte Teil des AOSP-Codes die freizügigere Apache 2.0-Lizenz übernimmt. Diese Lizenzstruktur ermöglicht es Geräteherstellern, Android zu modifizieren und anzupassen, ohne dass alle Modifikationen Open Source sein müssen, während Unternehmen gleichzeitig die Möglichkeit haben, proprietäre Apps und Dienste auf der Android-Plattform zu entwickeln. Googles eigener proprietärer Dienst GMS (Google Mobile Services) ist von AOSP getrennt und unterliegt anderen Lizenzbedingungen. Dieser hybride Ansatz schafft ein Modell, das Offenheit beibehält und gleichzeitig dem Ökosystem kommerzielle Flexibilität bietet.

Konkret basiert der Linux-Kernel auf der GPL-Lizenz. Obwohl das Kernelmodul laut GPL zwangsweise Open Source sein muss, sind Userspace-Anwendungen nicht von der Ansteckungsgefahr der GPL betroffen und müssen daher nicht Open Source sein. Einige Userspace-Anwendungen unterscheiden sich auch von herkömmlichen Linux-Distributionen, z. B. die Verwendung von Bionic Libc anstelle von Glibc, die Verwendung von Toybox anstelle von Busybox usw. Darüber hinaus verwendet Google auch den „Hardware Abstraction Layer“ (HAL), der es Herstellern ermöglicht, kommerzielle vertrauliche Informationen, die sie nicht offenlegen möchten, wie den Code und die Logik hinter einigen spezifischen proprietären Funktionen, auf dieser Schicht zu speichern, die eine stabile ABI (Application Binary Interface) bereitstellt, sodass Hersteller ihren proprietären Code unabhängig von der Android-Framework-Schicht aktualisieren können.

Natürlich war die Linux Foundation sehr unzufrieden mit Googles Vorgehensweise, die gegen den Geist von Open Source verstieß, und entfernte AOSP einst aus dem Linux-Open-Source-Projekt.

Das Ergebnis ist, dass die unterste Schicht von AOSP laut GPL Open Source ist und eine große Anzahl mittlerer Schichten laut Apache lose Open Source (teilweise geschlossene Quelle) ist. Darauf basierende Anwendungen können ihre eigenen Open- und Closed-Source-Attribute entsprechend den Wünschen des Entwicklers und kommerziellen Zwecken wählen.

Google selbst macht das. Tatsächlich sind seit Android 4.4 KitKat im Jahr 2013 nicht mehr alle Android-Versionen vollständig Open Source. Einige der Treiber, die Benutzeroberfläche und eine große Anzahl von Kernprodukten und -diensten in der Anwendungsschicht, die Google für das Android-System, auch bekannt als GMS-Suite, entwickelt hat, sind alle Closed Source.

AOSP existiert, aber es ist kein vollwertiges Android. Aus diesem Grund werden viele Systementwickler betonen, dass „natives Android“ (bezogen auf das Betriebssystem von Google Nexus/Pixel) nicht gleichbedeutend mit AOSP ist.

Obwohl AOSP ein Open-Source-Projekt ist, führt Google nicht oft Zusammenführungsanfragen von Dritten zusammen (das Zusammenführen von AOSP-Code erfordert die Zustimmung von Google-Mitarbeitern, und viele PRs sterben in Gerrit Review). Dies ist nach Ansicht vieler Entwickler auch der größte Unterschied zwischen AOSP und typischen Open-Source-Projekten. Es macht es den Teilnehmern schwer, ein echtes Gefühl der Teilnahme an AOSP zu entwickeln.

Auf der offiziellen Website des AOSP-Projekts hat Google diese „Governance-Philosophie“ geschrieben:

Google leitet AOSP, das für die Wartung und Weiterentwicklung von Android verantwortlich ist. Obwohl Android aus mehreren Teilprojekten besteht, wird AOSP streng projektverwaltet. Google behandelt und verwaltet Android als einzelnes, monolithisches Softwareprodukt und nicht als Veröffentlichung, Spezifikation oder Sammlung austauschbarer Teile. Google beabsichtigt, dass Gerätehersteller Android auf ihre Geräte portieren. Sie erzwingen keine Spezifikationen und kuratieren keine Veröffentlichungen.

Diese Passage beschreibt Googles Absichten deutlich genug. Wenn es sich bei AOSP um einen Arbeitsesel handelt, ist es an der Zeit, den Esel zu töten.

Welche Auswirkungen wird Androids Closed Source haben?

Das Wichtigste zum Mitnehmen: Mainstream-Telefonmarken und ihre Benutzer müssen sich keine Sorgen machen.

Sehen wir uns zunächst die Vereinbarung zwischen Google und Android OEM an:

1. AOSP: Jeder Hersteller kann AOSP ohne die Zustimmung von Google für die Entwicklung verwenden.
2. Android Compatibility Commitment Agreement ACC, Mobile Application Distribution Agreement MADA, Enterprise Device Supplementary Agreement EDLA usw., um nur einige zu nennen. Durch Vereinbarungen werden kommerzielle Beschränkungen zwischen Google und OEMs festgelegt. Nur OEMs, die die ACC-Vereinbarung unterzeichnet haben, können über AOSP Betriebssysteme entwickeln und diese Android-Betriebssysteme nennen und die Rechte zur Nutzung der Marke Android sowie andere Rechte erhalten.
3. Google Mobile Services GMS umfasst Back-End-Funktionen wie den Google Service Core und das Kontosystem sowie Front-End-Anwendungen wie Google Play Store, YouTube, Gmail und Kalender. Erst wenn das Unternehmen die oben genannte Vereinbarung unterzeichnet hat und das Mobiltelefonmodell den Kompatibilitätstest von Google bestanden hat, kann GMS vorinstalliert werden.

Die Kombination aus ACC, MADA/EDLA und anderen Protokollen stellt sicher, dass Google grundsätzlich die absolute Kontrolle über das Android-Betriebssystem hat.

Die meisten heutigen Android-Handymarken, darunter Xiaomi, vivo, OPPO, Samsung usw., haben Vereinbarungen mit Google unterzeichnet. Wenn es keine Überraschungen gibt, hätte Google sie kontaktieren sollen, um sie zu beruhigen und sicherzustellen, dass die zukünftige Zusammenarbeit wie gewohnt weitergeht.

In der Vergangenheit nutzten zahlreiche Geräte- und Chiphersteller AOSP zur Produktentwicklung, erhielten jedoch keine Android-Gerätezertifizierung von Google. Auf dem Gerät musste GMS Family Bucket nicht vorinstalliert werden und konnte die Zertifizierungsanforderungen von Google umgehen.

Es gibt Milliarden oder sogar Dutzende Milliarden nicht zertifizierter Android-Geräte. Durch dieses Closed-Source-AOSP kann Google nicht zertifizierte Gerätehersteller dazu bewegen, sich vor sich selbst zu beugen und die verschiedenen oben genannten Vereinbarungen zu unterzeichnen.

Eine sehr wahrscheinliche Situation besteht darin, dass der Code des auf AOSP basierenden Smart-Cockpit-Systems Herstellern auf der ganzen Welt möglicherweise nicht mehr kostenlos zur Verfügung gestellt wird. Solange Automobilhersteller keine Vereinbarung mit Google unterzeichnen, können sie den neuesten Code nicht erhalten. Natürlich können Automobilhersteller auch weiterhin alte Open-Source-Systementwicklungen nutzen.

Das ist keine Tatsache, sondern nur eine Möglichkeit. Die Entscheidung von Google, dieses Mal den Quellcode für Android zu schließen, schließt ein kleines Motiv nicht aus, den Markt für nicht zertifizierte Geräte zurückzugewinnen oder sich zumindest einen Anteil daran zu sichern. Obwohl dieser große Markt von den Geräteherstellern selbst geschaffen wurde, wäre er ohne AOSP nicht das, was er heute ist.

Aus dieser Perspektive könnten Verbraucher von nicht zertifizierten Android-Geräten betroffen sein, auch wenn dies natürlich nicht offensichtlich ist. Die Auswirkungen ergeben sich vor allem aus finanzieller Sicht: Wenn OEMs das Android-Betriebssystem weiterhin vorinstallieren wollen, müssen sie sich an die Richtlinien und Anforderungen von Google für Geräte halten. Diese Kosten werden natürlich an die Verbraucher weitergegeben, was zu höheren Preisen führt. Darüber hinaus können Verbraucher zum Herunterladen von Anwendungen nur Kanäle wie Google Play nutzen. Auch der Lebensraum von Drittanbieter-Anwendungsmärkten (wie F-Droid) ist kleiner geworden. Außerdem kann Google für alle In-App-Zahlungen eine Gebühr erheben.

Einige Hersteller sind möglicherweise nicht bereit, sich Google zu unterwerfen, und ihre Produkte werden vom Markt zurückgezogen, was die Auswahlmöglichkeiten der Verbraucher verringert. aber gleichzeitig kann jeder AOSP-Code, den Google vor der Schließung der Quelle veröffentlicht hat, theoretisch weiterhin verwendet werden. Hersteller können den Code nach Belieben teilen und ihn selbst entwickeln, aktualisieren und warten. Es wird geschätzt, dass es den Verbrauchern intelligenter Kühlschränke egal sein wird, ob auf dem Kühlschrank das neueste Android-Betriebssystem vorinstalliert ist.

Dies kann jedoch auf das Klischee der „Android-Fragmentierung“ zurückzuführen sein: Wenn nicht autorisierte Gerätehersteller weiterhin ihren eigenen Weg gehen und alten, nicht mehr offiziell gepflegten Code zur Entwicklung von Produkten verwenden, ist die Fragmentierung möglicherweise nicht so einfach wie eine Versionsnummer, sondern ähnelt möglicherweise dem heutigen China mit Push, Version, Funktion, Erscheinungsbild, Name, Erfahrung usw. Allround-Fragmentierung und ein seltsames Bild, das sich auf globale Ebene ausdehnen wird.

Verletzung von Entwicklerrechten

Die Closed Source von AOSP hat deutlichere Auswirkungen auf Drittanbieter-ROM-Entwickler von Android-Anwendungen.

Die Szene, in der hunderte Denkrichtungen über Android-ROMs von Drittanbietern kontrovers diskutierten, wird ebenfalls von der Geschichte begraben sein. Das beste Ergebnis für ROM-Entwickler besteht darin, die neueste aktualisierte Version von AOSP zu verwenden, um es zu ändern, und dann die aktuelle Version beizubehalten, bis sie langsam veraltet, bis sie das Projekt schließlich aufgeben.

Anwendungsentwickler können das SDK, das sie benötigen, immer noch von Google beziehen, und in der Post-AOSP-Ära dürfte es keine großen direkten Auswirkungen geben.

Zuvor mussten Entwickler jedoch aufgrund der erheblichen Fragmentierung von Android Systemcodes von verschiedenen Herstellern und Geräten als Testmaschinen beziehen, um sie an verschiedene Versionen des Systems und verschiedene Modellmarken anzupassen. Dies ist ein erheblicher Kostenfaktor für kleine und mittlere Unternehmen, insbesondere für unabhängige Entwickler. Es ist unklar, ob sich diese Situation in Zukunft verschärfen wird.

Wenn das Lebensumfeld kleiner und mittlerer Entwickler weiter eingeschränkt wird, wird der Übertragungseffekt darin bestehen, dass die Starken immer stark bleiben, Innovationen gebremst werden und mehr Monopole entstehen. Daher sollte Google, nachdem es getan hat, was es tun sollte, Folgepläne vorlegen, um das Überleben kleiner und mittlerer Entwickler zu sichern.

Der extremste, aber am wenigsten unerwartete Ansatz

Zuvor hatte sich Ai Faner im Zusammenhang mit der technologischen Entkopplung zwischen China und den Vereinigten Staaten mehrere Möglichkeiten für Android ausgedacht, um die Lieferungen an chinesische Mobiltelefonhersteller zu unterbrechen: das Verbot der Anzeige von Android-Marken auf im Ausland verkauften Mobiltelefonen, das Verbot der Vorinstallation von GMS, die „direkte“ Schließung von AOSP-Quellen für chinesische Hersteller und sogar die Aussetzung der Autorisierung dieser Hersteller und deren Löschung/Entfernung aus der OHA.

Von allen Möglichkeiten ist ein vollständig geschlossenes AOSP am unwahrscheinlichsten. Ai Faner meinte einmal, es sei zu beschämend, das zu tun.

In der Anfangsphase intelligenter mobiler Geräte entschied sich Google für Open-Source-Android, was nicht nur einen Ruf für offene Technologie erlangte, sondern zu dieser Zeit auch eine große Anzahl von Herstellern und Anwendern von Symbian, Windows Mobile, Nokia und BlackBerry überzeugte.

Natürlich gingen Nokia, BlackBerry und Microsoft jeweils Umwege, was maßgeblich zum Sieg von Google beitrug. Aber Googles Open-Source-Android ist zweifellos die richtigste Entscheidung auf dem Weg, heute über 70 % des Android-Anteils auf dem Markt für mobile Betriebssysteme zu erobern.

Es gibt immer noch Mitarbeiter bei Google, die die Bedeutung und den langfristigen Wert von Open Source für die Popularisierung von Technologie erkennen. Ob aus geschäftlichen und übergeordneten Anforderungen oder aus persönlichem Status, sie schreiben Code und führen Wartungsarbeiten für das Android-Projekt durch, und AOSP ist auch der Träger dieser Arbeiten. Allerdings ist der kommerzielle Wert von AOSP für Android und Google nicht mehr derselbe.

Obwohl die Hauptmotivation für diese Maßnahme darin besteht, Kosten zu sparen, wird sie auf lange Sicht auch Google dabei helfen, den Umsatz zu steigern. Schließlich war es für Google in der Vergangenheit schwierig, direkte Einnahmen oder indirekte Vorteile wie Daten von nicht zertifizierten Geräten mit AOSP-basierten Betriebssystemen zu erzielen.

Vor diesem Vorfall verdiente Google mit Android hauptsächlich dadurch Geld, dass es den OEMs im Rahmen einer Partnerschaftsvereinbarung Gebühren für die Autorisierung und Zertifizierung in Rechnung stellte. Um Android im Rahmen kommerzieller Compliance nutzen zu können, müssen Hersteller eine Vereinbarung unterzeichnen. Einzelheiten wie Inhalt und Art der einzelnen Vereinbarung können abweichen, die allgemeinen Regeln bleiben jedoch unverändert. Die Haupteinnahmequelle von Google sind Werbeeinnahmen und die gemeinsame Nutzung von Anwendungen, die über vorinstallierte Google-Anwendungen und -Dienste (Suche, Play Store usw.) erzielt werden.

Offensichtlich können nicht zertifizierte Geräte keine Einnahmen für Google generieren, aber die Existenz von AOSP ist „ein Hochzeitskleid für Menschen“. Wie jedes kommerzielle Unternehmen befürchte ich, dass es sich so schnell wie möglich von diesen Geräten und Herstellern trennen möchte.

# Willkommen beim offiziellen öffentlichen WeChat-Konto von Aifaner: Aifaner (WeChat-ID: ifanr). Weitere spannende Inhalte werden Ihnen so schnell wie möglich zur Verfügung gestellt.

Ai Faner | Ursprünglicher Link · Kommentare anzeigen · Sina Weibo