Man kann als Geek viele gute Gründe aufzählen, um von Android begeistert zu sein. Das letztendlich frei verfügbare, quelloffene und auf Linux basierende Betriebssystem hat den herstellerübergreifenden Erfolg von Smartphones und Tablets überhaupt erst ermöglicht und läuft mittlerweile auf fast 90% aller Geräte. Mit ein wenig Know-How lässt sich das OS von Google enorm anpassen, zudem lässt die Vielfalt an Apps nahezu keine Wünsche offen. Und dennoch: Android sucks, und zwar ganz gewaltig.
Das liegt zum einen an einem geheimnisvollen Effekt, der nahezu jedes Android-Smartphone nach einer nicht näher definierbaren Zeit verlangsamt. Irgendwann, meist nach wenigen Monaten, verlangsamt sich das System, es verhält sich ruckelig und weniger flüssig. Gelegentlich betrifft das nur einzelne Apps, häufiger das gesamte System. Wenn es soweit ist, hilft u.U. eine Bereinigung des Systems von ohnehin selten genutzten Apps. Doch in den meisten Fällen läuft es irgendwann auf einen vollständige Reset des Systems mit nachträglicher Neuinstallation aller Apps und Konten hinaus.
Wesentlich ärgerlicher ist jedoch die enorme Fragmentierung des Systems. Mit zunehmenden Alter und steigenden Versionsnummern kursiert Android nun in mehreren Ausgaben, die sich nicht nur funktional elementar voneinander unterscheiden. Viele dieser Versionen werden nicht mehr mit Support-Updates versorgt, sind inkompatibel zu neueren und sichereren Apps und sorgen sowohl bei Google als auch bei den Herstellern für einen enormen Support-Aufwand. Doch gerade die letztgenannten, die Hersteller, dürfen sich den Schuh anziehen.
Seit Jahren wird den kurz-, mittel- und langfristigen Updates und Upgrades des Betriebssystems kaum Aufmerksamkeit geschenkt. Dies betrifft bei weitem nicht nur Billig-Modelle, auch höherpreisige Smartphones werden – wenn überhaupt – oft erst sehr verspätet mit neuen Funktionen und Sicherheits-Aktualisierungen versorgt.
Während Apple in der luxuriösen Situation ist, bei einem geplanten Update nur eine begrenzte Zahl von Hardware-Konfigurationen auf ihre Kompatibilität prüfen zu müssen (und dabei gelegentlich trotzdem fulminant scheitert, Millionen von Geräten unbrauchbar macht, TouchIDs außer Kraft setzt oder sukzessive abgespeckte Teilversionen für ältere Modelle ausrollt), hat Google mit Android ein weitaus größeres Problem.
Das jeweils “neuste” Betriebssystem müsste auf einer theoretisch unendlich großen Zahl von Hardware-Konfigurationen funktionieren, die letztendlich nur jeder einzelne Hersteller überblicken kann. Die wiederum sollten eigentlich mit Google zusammenarbeiten, scheuen aber den Aufwand und die daraus resultierenden Kosten. Hinzu kommt, dass der ein oder andere Hersteller bereits von Google zur Zwangskopplung von “GApps” genötigt wurde und somit ein wenig bockig reagiert, wenn die Entwickler aus Mountain View mal wieder eine Developer Preview auf die Server lädt.
Leidtragender dieses Zwists ist letztendlich der Kunde, der bereits nach einem, zwei oder maximal drei Jahren ein Smartphone besitzt, das trotz der eigentlich vorhandenen Leistung nicht mehr in den Genuss neuer Funktionen kommt. Das wiederum mag man geplante Obsoleszenz nennen, doch mittlerweile schadet es dem Ruf der wenigen Premium-Hersteller und dem Presitige von Google bzw. Android.
Der Kollege Ron Amadeo von arstechnica.com hat nun im neu veröffentlichten Android Compatibility Definition Document (CDD) Hinweise auf einen Strategiewechsel von Google entdeckt, der die Fragmentierung des Systems endgültig aufhalten könnte.
In den Kompatibilitätsrichtlinien für Hersteller werden erstmals sogenannte “Android Extensions” erwähnt, mit denen Google ohne den lästigen Umweg über die Hersteller zukünftige Updates des Betriebssystems Over-the-Air ausrollen könnte. Google wäre nicht mehr darauf angewiesen, eine separate Komaptabilitätserklärung der Hersteller für ein bestimmtes Modell abzuwarten oder dem Hersteller das Update zur eigenen Verbreitung zu überlassen.
Stattdessen würden sich die Hersteller verbindlich verpflichten, bestimmte Rahmenbedingungen einzuhalten, so dass ein Update elementarer Services nicht mit dem existierenden System kollidiert. Kurzgefasst: es gäbe dann Code, den ein Hersteller nicht mehr individuell anpassen dürfte, wodurch sich dieser Code wiederum zentralisiert – durch Google – updaten liesse. Google schreibt:
‘3.1.1. Android Extensions Android includes the support of extending the managed APIs while keeping the same API level version. Android device implementations MUST preload the AOSP implementation of both the shared library ExtShared and services ExtServices with versions higher than or equal to the minimum versions allowed per each API level. For example, Android 7.0 device implementations, running API level 24 MUST include at least version 1.’ Google, CDD
Zum jetzigen Zeitpunkt sind nur wenige zusätzliche Informationen verfügbar, doch im Kontext klingt die Theorie von Ars Technica hierzu durchaus schlüssig.
‘We have a theory: “Android Extensions” is a plan to bring the easily updatable app model to the AOSP APIs. Like Google Play Services, we think this app will be a bundle of API shims that Google can update whenever it wants. The difference is that everything in Play Services is a closed-source Google API, while “Android Extensions” would be collections of fresh AOSP code delivered directly to your device via the Play Store. The CDD’s stipulation that OEMs “MUST preload the AOSP implementation” is telling. It says that 1) this is AOSP code, and 2) OEMs aren’t allowed to “customize” it.’ Ron Amadeo, ArsTechnica
Sollte Ron Amadeo damit richtig liegen, würde dies den Update-Prozess des Betriebssystems revolutionieren. Google könnte dann vergleichbar mit den jetzigen App-Updates zukünftige Aktualisierungen einfach über den Play Store ausrollen. Einmal implementiert bleibt die Funktion dauerhaft erhalten und würde dann auch für Versionen gelten, die keinen Versionssprung mitgemacht haben.
Das von Google bereitgestellte Dokument verrät noch weitere Details zu Vorgaben, nach denen sich die Hersteller in Zukunft richten sollen. So schreibt Google vor, dass kommende Modelle die Blockade von bestimmten Rufnummern unterstützen müssen. Andere Features wie beispielsweise die Implementierung von Multi-Windows werden ebenfalls reglementiert, aber auf einer optionalen Basis.
Besonders weitreichend sind Googles Pläne, den OEMs die Entwicklung eigener Ladestandards zu untersagen. Momentan kochen viele Hersteller hier ihr eigenes Süppchen, was zu einer langsam unüberschaubaren Zahl von Technologien (Qualcomm Quick Charge, OnePlus Dash Charge, Motorola Turbo Charging, Huawei SuperCharge, MediaTek Pump Express, and OPPO VOOC usw.) führt.
Die Hersteller werden sich wohl oder übel nach diesen Vorgaben richten, was zumindest in Teilbereichen nicht verkehrt ist. Die Frage, warum einige der Änderungen erst jetzt kommen und ob das Quasi-Monopol von Google dem Markt gut tut, steht auf einem anderen Blatt.
via 9to5google.com
