Politikum: Die Chromifizierung von Android

Wenn ich mir überlegen müsste, was ich das Unsympathischte an Android finde, würde ich auf die heimtückische Standardaktivierung des Tracken des Standortverlaufs, der umgebenden Funknetze und Senden der Daten an Google verweisen. Das geht gar nicht! Anscheinend aktiviert sich das Tracking durch bestimmte Google-Updates auch immer wieder selbst. Aber das ist nicht Android Open Source Project (AOSP), das sind die proprietären Play Services und sind Googles Erweiterungen.

Kapitel:
1 – Can’t put me finger on what lies in store,
But I fear what’s to happen all happened before.

2 – Die Play-Services-Verträge
3 – Proprietarisierung in Häppchen
4 – Warum „Chromifizierung“?
5 – Absoluter Kontrollwillen

1 – Can’t put me finger on what lies in store,
But I fear what’s to happen all happened before.

Ich habe um CyanogenMod gebangt, als es hieß, Google wolle das Unternehmen für 1 Mrd. Dollar aufkaufen. Dass sie auf das Angebot nicht eingegangen sind, spricht sehr für ihre Integrität! Denn was macht eigentlich CyanogenMod? Seit Google mit spätestens Kitkat (4.4) begonnen hat, mehr und mehr der vormals unter freier Lizenz mit offenen Quellcode stehenden integralen Systemkomponenten proprietär zu forken, mit Google-Diensten zu verknüpfen und sie als Standard-Apps auf ihren Nexus-Geräten zu pushen, ist das Team von CyanogenMod dabei, freie Alternativen für Googles proprietäre Apps zu schreiben und Android damit „Google wegzunehmen“, wie es der CEO formuliert hat.

Google hat einerseits seine durchaus berechtigten Anliegen, die Plattform möglichst homogen und mit den bestmöglichen Design zu gestalten. Dass Googles Android-Designer besser sind als die Teams der OEMs, müssen wir gar nicht erst ausdiskutieren. Google hat Interesse daran, seine Plattform in der besten Form an seine Nutzer zu bringen, nicht einer verhunzten Oberfläche und mit umständlichen Standard-Apps der OEMs. Der große Vergleich zur Android-Plattform ist iOS und Google hat größtes Interesse, dass sein System in Gänze und inklusive Standard-Apps – auf jedem Gerät – den Vergleich mit Apples Software standhalten kann. Das ist neben der festen Integration ihrer ‚Cloud‘-Dienste der eine Grund für ihre zunehmende Proprietarisierung von Android.

2 – Die Play-Services-Verträge
Über die Play-Services-Verträge werden den OEMs enge Auflagen gemacht, wie sie ihre Distribution/ROM zu gestalten haben – die Liste wächst jährlich und die Daumenschrauben werden enger. Ein Android-Gerät ohne Play Services ist in der westlichen Welt nichts wert.
Inbegriffen in den (nicht öffentlichen) Play-Services-Verträgen ist beispielsweise die Klausel, dass Googles strategisch relevanteste Apps im Standardbildschirm des Launchers sofort oder über einen Ordner erreichbar sein müssen.

Vom Play Store abgesehen kümmern sich die Play Services auf Android um eine ganze Menge Dienstleistungen, die im weitesten Sinne Netzkonnektivität fordern. Google Cloud Messaging (GCM) ermöglicht Apps das Pushen von Benachrichtigungen, anstatt dass die App selber in Intervallen einen Abgleich mit einer Adresse durchführen müsste. Die Maps-API integriert Googles Kartendienst unkompliziert in viele Apps, der Google Location Service stellt genauere und schnellere Ortung durch WLAN- und Funkmasten-Triangulation bereit, usw.. Die Finesse der Verträge und das Dilemma für die OEMs einmal nur am Beispiel des Location Services betrachtet: Der Vertrag schreibt ihnen die Standard-Nutzung von Googles Ortungsdienst vor, der durch jeden Nutzer automatisch (und in der Regel komplett ohne sein Wissen) auch noch verbessert wird. Würde ein OEM aus den Verträgen aussteigen, hätte er weder Anspruch auf Integration von Googles Ortungsdienst, zudem müsste er auch noch eine eigene weltweite Triangulations-Datenbank aufbauen, um vergleichbare Ergebnisse liefern zu können (Mozilla sind mit ihrem unabhängigem FirefoxOS die ersten, die versuchen, eine freie Datenbank zu schaffen). Wer ein AOSP-ROM ohne das „Sideloaden“ der Play Services betreiben möchte, steht sehr schnell deppert im Regen.

Kurze Strategieanalyse: Warum macht Google das? Es gab in den letzten Jahren vermehrt Gerätehersteller, die sich dem Diktat der Play-Services-Verwendung widersetzt haben. Dazu gehören Amazon, Xiaomi, nicht zuletzt das aufmüpfige Samsung, das gern mal mit dem ein oder anderen Gerät mit Tizen gedroht hat. Dass Samsung überhaupt ein so starkes Interesse an Tizen verfolgt, kommt auch nicht von ungefähr: Man wird unruhig, weil Google den OEMs nach und nach die Unterscheidbarkeit von Mitbewerbern nimmt, weil sie proprietäre Apps nicht mehr nach Gutdünken verunstalten können. Samsung wird in dieser Entwicklung ein Android-OEM von hunderten, teils günstiger produzierenden Smartphones, ohne sich von ihnen merklich differenzieren zu können. Ein Bein in einem alternativen OS zu haben, ist einerseits wirksames Verhandlungsmittel mit Google, andererseits der Notfallplan, falls es Google einmal übertreibt. LG verfolgt mit dem Aufkauf von webOS übrigens dieselbe Taktik. Ein bisschen vergleichbar hierzu ist, wie Apple seit NeXTStep x86-Builds von Darwin (dem Unterbau von OS X) gepflegt hat und den x86-Wechsel von PPC schließlich 2005 relativ schmerzfrei über die Bühne ziehen konnte, als IBMs Architektur an ihre Grenzen kam. Es ist eine Sicherheit, nicht zuletzt eine ökonomische.

Eine wertvolle Seitenepisode zum Verständnis von Samsungs Macht als größter Android-Gerätehersteller und Googles Kontrollwillen über die Plattform, ist die Spekulation, dass Motorola von Google nicht aus freien Stücken wieder verkauft wurde. Als in 2013 die Gerüchte und Hinweise von Samsung auf Tizen-Smartphones und ‚Wearables‘ stärker wurden, überraschte im Januar 2014 die Meldung, dass Samsung, nach Gesprächen mit Google, die eigenen Modifikationen an der Oberfläche zurückfahren und stattdessen auf mehr Apps und Dienste von Google setzen wolle. Einen Tag später wurde berichtet, dass Google Motorola wieder verkaufen wolle. Man sei ja nur an den Patenten interessiert gewesen. – Gar nicht daran, durch einen eigenen starken OEM im Fall des Bruches mit Samsung wenigstens einen Hersteller unter voller Kontrolle zu haben, der die eigene Android-Vision umsetzen und den man im Ernstfall durch die eigene Werbeplattformen stark pushen könnte.
Hier geschah ganz klar ein Deal. Beide Seiten sind extrem argwöhnisch voreinander: Google sieht seinen größten und daher wertvollsten OEM taktisch mit eigenen Apps und Diensten zündelnd drohen, Samsung sieht sich immer weiter unter einem Plattformdiktat, das es ihnen a) erschwert, durch ‚Mehrwertdienste‘ an ihren Geräten noch zusätzlich Geld zu machen, b) Unabhängigkeit unmöglich macht, sondern c) in absolute Abhängigkeit zu Google treibt. In Anbetracht dessen, dass Samsung gekuscht hat und seine Anpassungen in Folge schrittweise zurückgenommen hat – und dass Google durch den Verkauf von Motorola bei Beibehalten der Patente quasi kein Risiko eingegangen ist – sieht es nach außen aus, als ob Google hier einmal, mit größter Vorsicht, bei Samsung auf den Tisch gehauen hätte.

3 – Proprietarisierung in Häppchen
Für Android wartet Google auch noch den alten kargen AOSP-Browser, weil sie, nach eigener Aussage, einen freien Browser in Android erhalten wollen und Chrome proprietär ist (es gibt kein „Chromium“ für Android, nur die Engine, aber nicht die Oberfläche). Dasselbe Spiel läuft seit einer Weile mit vielen Apps: Die Bildergalerie soll durch G+ Fotos abgelöst werden, die proprietär ist, auch die AOSP-Kamera wird nicht weiterentwickelt, die haben sie geforkt und nennen das proprietäre Produkt nun Google Camera. Die AOSP-Music-App wurde seit Jahren nicht angefasst, nur noch die proprietäre Play-Music-App wird weiterentwickelt. So geht es auch bei Lollipop nun mit E-Mail und Kalender weiter: Sie lassen den alten AOSP-Mailclient fallen und integrieren dafür IMAP in die proprietäre Gmail-App. Analog betritt ein Google Calendar die Bühne. Diese „Chrome-ification“, wie sie in der Szene genannt wird, betrifft sogar bereits den Launcher: Ab spätestens Kitkat wurde dieser proprietär geforkt und integriert nun die Google-Suche auf der linkesten Spalte. Ein Google-Fork bedeutet jeweils gleichzeitig, die freien Komponenten nicht weiterzuentwickeln. Über kurz oder lang müssen OEMs (und Geeks) die Nutzung der freien Komponenten einstellen, oder sie mit mehr Aufwand selber weiterentwickeln.

Damit macht Google seinen OEMs das Leben schwer, denn die können nun nicht mehr einfach die hübsch von Google gewartete und weiterentwickelte AOSP-Kamera-App anpassen, sondern müssen eine eigene schreiben, die auch noch mit der aktuellen Systemversion kompatibel ist. Das erhöht die Entwicklungskosten signifikant und führt tendenziell dazu, dass OEMs den Aufwand scheuen und gleich auf Googles proprietäre Apps setzen – womit dann auch die Google-Dienste wieder mehr genutzt werden und in Googles Idealvorstellung die Plattform für ihre Nutzer unersetzlich wird.
Ziel ist es, Marktmacht bei sich zu zentralisieren. OEMs, die keine Play-Services-Verträge mit allen Lizenzbedingungen unterschreiben, bekommen die guten Apps nicht – Android wird für sie dadurch gewissermaßen ausgemergelt. Googles härteres Vorgehen lässt sich als direkte Reaktion auf die Android-Forks von Amazon („FireOS“) und Xiaomi („MIUI“) ohne Play Services verstehen.
Wir können nur darauf hoffen, dass CyanogenMod und Co. ausreichend Ressourcen finden werden, um die AOSP-Teile als freie Software weiterzuentwickeln, woran sie auch bereits sitzen.

Google ist deswegen nicht gleich ‚evil‘, aber das Unternehmen will eben mit seiner Plattform Geld verdienen und ungern durch Drittfirmen, die darauf aufbauen, die eigene Relevanz an Markt verlieren. Das ist sogar noch auf einer menschlichen Ebene nachvollziehbar.
Ein kleines schmutziges Detail ist hier der Machtkampf, der sich die letzten Jahre offenbar innerhalb Googles zwischen Andy Rubin, dem Gründer des ursprünglichen Android-Unternehmens, und Googles Führern ausgetragen hat. Rubin soll sich jahrelang für die Unabhängigkeit von AOSP eingesetzt haben, sich gegen die Zusammenarbeit mit anderen Abteilungen gewehrt und auch die Motorola-Übernahme nicht gutgeheißen haben. Dann wurde er gegangen. Ausgerechnet Sundar Pichai, der Projektleiter des Chrome-Teams, der sich wiederholt für die Proprietarisierung von Komponenten ausgesprochen hatte, ist auch zum neuen Kopf der AOSP-Entwicklung berufen worden. Zwei Monate zuvor wurde im Google Campus eine metallene Android-Statue montiert.

4 – Warum „Chromifizierung“?
„Chrome“ ist mehr als der Webbrowser des Unternehmens, den sie primär aus strategischem Antrieb entwickelt haben, um nicht Mozillas Suchmaschinen-Standardeinstellung-Verträgen auf Gedeih und Verderb ausgeliefert zu sein. Die Kontrolle über nutzerfreundliche Privatsphäreeinstellungen zu erhalten, ist ein willkommener Bonus. „Chrome“ ist mittlerweile eine Marke, die von mehr Nutzern direkt mit Google assoziiert wird als „Android“. „Chrome“ ist der Weg für Google, Nutzer tatsächlich an seine Dienste zu binden, bei denen ihnen schon im Vornherein klar ist, dass sie es mit Google zu tun haben, was einer direkteren Bindung entspricht.

Unter „Chromifizierung“ sammelt die F-/OSS-Community Strategieentscheidungen Googles, die der Chrome-Philosophie folgen und damit der Idee eines offenen Webs und offenem Systems widersprechen. Auf Android bezogen wäre das die oben angesprochene Vernietung von AOSP mit den proprietären Play Services, die durch raffinierte OEM-Verträge de facto ein vernünftig nutzbares AOSP ohne Play Services für alle Seiten ausschließt. Im Webbereich wird häufig die gefühlte Trägheit der Google-Dienste Gmail, YouTube und Co. in Firefox kritisiert, die bisweilen Mutmaßungen einer Absicht zulässt. Googles Vorstoß mit seinen „Chrome Apps“ ist eine ganz besonders deutliche Verletzung der Prinzipien des offenen Webs. Chrome Apps sind weniger Webseiten als Anwendungen, die nur in der Chrome-Runtime laufen. Mit Webtechnologien wurde eine Parallelplattform auf Basis von Chrome-APIs geschaffen – übrigens das Gegenteil dessen, wie Mozilla bei Firefox OS vorgeht. Googles Strategie entspricht damit mit frappierender Ähnlichkeit dem Credo „Embrace, Extend and Extinguish“, mit dem es Microsoft zu gerechter Berühmtheit bei den Kartellbehörden gebracht hat. Dabei darf nicht die wachsende Relevanz von ChromeOS vergessen werden. Noch weiter gedacht fragt der Analyst Benedict Evans in einem klugen Text: „This however leads to a deeper Android question – what will Google be offering in 5 years? Will we, say, be buying Chrome phones on which Android is a legacy run-time?“

Chromifizierung ist das äußerliche Darstellen als offen, obwohl innerlich Stein um Stein der proprietäre Grenzwall errichtet wird. Niemand hat die Absicht…

5 – Absoluter Kontrollwillen
Der Plattform-Branch „Android Wear“ ist nicht einmal freie Software. Android Wear ist ein proprietäres Produkt, basierend auf internen Forks von AOSP, die Google dank seiner Apache-Lizenz nicht öffnen muss. Alles, was Google bisher von Android Wear offengelegt hat, sind einige Happen modifizierter GPL-Code von Drittprojekten. Dasselbe gilt im Übrigen für Android Auto und Android TV.

Hier zeigt sich an einem Glanzbeispiel die Notwendigkeit von radikalen Copyleft-Lizenzen wie der GPL – die Google wie der Teufel das Weihwasser meidet. So nutzen sie sogar grundsätzlich bei AOSP die „Bionic“-Tools statt eines GNU-Userlands. Damit zeigen sie sich prinzipiell bereit, ihre Plattform bis in die Systemtools komplett zu proprietarisieren.
Der Linux-Kernel unter GPL 2 entzieht sich ihnen dabei, aber selbst der wäre durch ein BSD-Derivat austauschbar, Apple zeigt mit XNU auf iOS und OS X, dass das mit genügend Mitteln machbar ist. Dass Google den Schritt ginge, zeichnet sich momentan zwar noch nicht ab, ist aber technisch wohl leichter umsetzbar, als man meinen mag, wenn man sich vor Augen führt, dass kaum etwas bei AOSP typischen Linux-Protokollen entspricht. Von der Interprozesskommunikation, über den Display-Server, zu den Schnittstellen für GPU-Treiber – alles oberhalb des Linux-Kernels ist Googles Süppchen. – Bis heute noch in den essentiellen Komponenten mit freiem Rezept.

Aber so beunruhigend sich all das anhört: Letztlich zeigt es, dass das Prinzip freie Software bei AOSP bislang funktioniert und da lohnt es sich, die Sache mal aus der radikalen F-/OSS-Perspektive von Glyn Moody zu betrachten.
Nun will Microsoft in CyanogenMod investieren. Dass sie sonderlich viel Einfluss auf das Projekt haben werden, bezweifle ich, sie wollen offensichtlich vor allem Google ans Bein pinkeln. Für Normalnutzer und uns freiheitsliebende Nerds ist das im Endeffekt ein Geschenk.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.