Die Zahlen sprechen eine deutliche Sprache: Mit mehr als zwei Milliarden aktiv genutzten Geräten ist Android das zur Zeit mit Abstand erfolgreichste Betriebssystem. Bei Google scheint man sich davon allerdings nicht sonderlich beeindrucken zu lassen, und nimmt für Android 8 eine breite Palette an tiefgreifenden Änderungen vor. Unter dem Namen "Vitals" soll die eigene Software für die nächsten fünf bis zehn Jahre fit gemacht werden – und durch eine Reduktion des Ressourcenverbrauchs auch für die nächste Milliarde an Usern. Dabei schreckt man auch nicht davor zurück, App-Entwicklern Zusatzarbeit aufzuerlegen, um lange bestehende Problem auszuräumen. Was damit konkret gemeint ist, soll der folgende Artikel in aller Ausführlichkeit beleuchten.
Bevor es soweit ist, sei aber noch eine wichtige Anmerkung vorangestellt: An dieser Stelle soll es ausschließlich um die Basisumbauten für Android 8 gehen. Ein Test, der sich dann vornehmlich den für die User wirklich sichtbaren Änderungen widmen soll, folgt zu einem späteren Zeitpunkt.
Akkuversprechen
Kaum ein Thema frustriert Smartphone-Nutzer so sehr wie die – immer zu kurze – Akkulaufzeit ihrer Geräte. Entsprechend hat Google in dieser Hinsicht in den letzten Versionen bereits eine Reihe von Optimierungen vorgenommen, die vor allem die Standby-Zeit deutlich verbessert haben. Nun verschärft man diese Bemühungen noch einmal ganz gehörig: Mit Android 8 dürfen Apps nur mehr in Ausnahmefällen Hintergrunddienste starten, konkret wenn es einen verbundenen Dienst gibt, der im Vordergrund läuft. Als Beispiel nennt Google dabei etwa einen Musik-Player der mittels Benachrichtigung seine Aktivität anzeigt. Für alle anderen Apps werden Hintergrunddienste vom System unterbunden. App-Entwicklern empfiehlt künftig stattdessen den JobScheduler zu verwenden, der Background-Aufgaben systemweit bündelt, und so wesentlich effizienter erledigen kann.
Eine Änderung, die das Potential hat, massive Probleme mit bestehenden – also noch nicht angepassten – Apps auszulösen. Das weiß natürlich auch Google und beschränkt diese Änderung zunächst auf Apps, die bereits Android O als Zielversion adressieren. Das heißt aber natürlich auch, dass es eine Zeit dauern wird, bis sich das volle Potential der aktuellen Änderungen entfalten wird. Immerhin können so alte Apps vorerst auch weiterhin im Hintergrund unnötig Strom verbrauchen, ohne vom System zur Räson gebracht zu werden.
Für die Nutzer ein etwas unbefriedigender Umstand, für den sich Google aber ebenfalls etwas einfallen hat lassen: In Android 8 ist nämlich die Möglichkeit hinzugekommen, Apps den Betrieb von Hintergrunddiensten komplett zu verbieten – und das funktioniert sehr wohl auch mit älteren Apps. Zudem wird nun bei jeder App angezeigt, wie viel Akku die zugehörigen Hintergrunddienste verbrauchen. Und nicht zuletzt werden alle laufenden Background Services jetzt im Benachrichtigungsbereich offengelegt – samt dem passenden Link, um sie gleich zu deaktivieren. Hier gibt man den Usern also recht mächtige Möglichkeiten an die Hand, die schlimmsten Akkufresser selbst zu beschränken. Trotzdem sollte man diese Funktion nur mit Bedacht verwenden, immerhin könnte man dadurch Apps komplett funktionsunfähig machen. Auf App-Entwickler erhöht man damit jedenfalls deutlich den Druck ihre Erzeugnisse auf den aktuellsten Stand zu bringen.
Broadcasts und Standort
Eine zweite Akkusparmaßnahme ist das weitgehende Deaktivieren der sogenannten "Impliziten Broadcasts". Bisher können sich Apps vom System informieren lassen, wenn alle möglichen Systemevents eintreten. Eine mächtige Funktion, die allerdings unerwünschte Konsequenzen hat: Immerhin kann es dann schon einmal dazu kommen, dass einzelne Aktivitäten dutzende Apps aufwecken – mit verheerenden Auswirkungen für Akkuverbrauch und Performance. Bereits in Android 7 hat man denn auch die Impliziten Broadcasts für einzelne Events wie die Aufnahme von Fotos deaktiviert. Mit Android 8 sind solche Methoden nur mehr für wenige, ausgewählte Ereignisse erlaubt, also solche auf die tatsächliche alle Apps sofort reagieren müssen. Dazu zählt Google etwa das Ändern der Spracheinstellungen oder auch den Start eines Telefongesprächs und das Anstecken des Kopfhörers.
Die dritte große Stromsparmaßnahme in Android O ist die Beschränkung von Hintergrundzugriffen auf Ortsinformationen. Apps bekommen hier künftig nur mehr ein paar mal pro Stunde frische Daten geliefert, bisher konnten sie die Frequenz weitgehend selbst bestimmen – was einen erheblichen Stromverbrauch bedeuten kann. Ausnahmen macht man auch hier für Apps, die im Vordergrund laufen, Fitness-Tracker können so also auch weiterhin die genaue Route beim Morgenlauf aufzeichnen.
Größter Umbau in der Android-Geschichte
Die Änderungen in Hinblick auf den Akkuverbrauch mögen zu den wichtigsten Verbesserung von Android 8 gehören, die umfangreichsten Änderungen gibt es aber an anderer Stelle: Mit dem Project Treble nimmt Google den größten Umbau in der Geschichte Androids vor – und zwar einen der einen bedeutenden Teil der gesamten Entwicklungsressourcen für die neue Version verschlungen hat, wie der Softwarehersteller offen bekundet.
Hinter dem Codenamen verbirgt sich nämlich eine umfassende Reorganisation des Android-Quellcodes, die das Android Framework, also das eigentliche Betriebssystem, komplett von hardwarespezifischen Bestandteilen trennt. Treiber, Kernel und andere vom Chipsatz-Hersteller gelieferte, proprietäre Komponenten werden also ausgelagert, und kommunizieren künftig über standardisierte Schnittstellen mit dem restlichen System. Für die Erhaltung der Kompatibilität hat Google eine Vendor Test Suite (VTS) entwickelt, die jeder Hersteller erfolgreich durchlaufen muss.
All dies soll vor allem den Wartungsaufwand für OEMs und Chipsatz-Hersteller reduzieren – und sei auch auf expliziten Wunsch dieser Partner entstanden, betont Google. Während die Entwicklung eines Updates bisher ein komplexes Hin- und Her-Spiel zwischen allen möglichen Beteiligten (Chipentwickler, Smartphone-Hersteller und Netzbetreibern) ist, können die Arbeiten in Zukunft einfach parallel vorgenommen werden. Immerhin garantiert die VTS, dass neue Android-Framework-Updates mit allen unterschiedlichen Versionen der proprietären Bestandteile zusammenarbeiten.
Raschere Updates?
Potentiell könnte das Project Treble also bedeuten, dass es künftig deutlich mehr – und schneller – Updates für Android-Geräte geben könnte. Allerdings eben nur "potentiell". Immerhin hängt all dies weiter vom jeweiligen Hersteller ab. Google kann den Prozess der Entwicklung eines Updates noch so sehr vereinfachen, wenn ein Anbieter kein Interesse an der Auslieferung neuer Versionen zeigt, bringt das den Nutzern wenig. Zumindest gehen den Android OEMs damit zunehmend die Ausreden aus, warum sie keine monatlichen Sicherheitsaktualisierungen für ihre Geräte liefern.
Ob Googles Plan aufgeht, wird sich aber ohnehin erst langfristig zeigen. Immerhin ist Project Treble so ein massiver Umbau, dass die neue Aufteilung lediglich auf Geräten, die mit Android 8 ausgeliefert werden, vorgenommen wird – dort ist sie aber zumindest vorgeschrieben. Eine Ausnahme bilden lediglich Googles eigene Pixel-Smartphones, auf denen Project Treble entwickelt wurde, und die mit dem Update auf die neue Version umgestellt werden.
Sandboxing
Die ursprüngliche Motivation hinter Project Treble mag die Verbesserung der Update-Situation unter Android gewesen sein, der Umbau verspricht aber auch zentrale Sicherheitsvorteile. Laufen künftig doch all die Vendor-Bestandteile vom restlichen System durch eine Sandbox isoliert – genau genommen sogar durch eine Vielzahl von Sandboxes. Dies zeigt vor allem an zwei bekannten Problembereichen Auswirkungen: Dem Android System Server und dem Media Framework.
Mit Android 8 wurden rund 20 Hardware Abstraction Layer (HALs) – vom Fingerabdrucksensor über WLAN bis zu anderen Sensoren – aus dem System Server herausgenommen und in eine eigene Sandbox gepackt. Während noch unter Android 7 ein Fehler in einem der betreffenden Treiber einem Angreifer Zugriff auf den kompletten System Server gegeben hätte, bleibt er künftig in der Sandbox gefangen. Die Angriffsfläche wird so also erheblich reduziert. Im Media Framework nutzt man Treble wiederum dazu, um den Zugriff auf Audio, Kamera, DRM und Co. vom eigentlichen Mediaserver zu trennen, und auch hier die Ausnutzung von Sicherheitslücken wesentlich schwerer zu machen.
Diese neue Modularisierung hat laut Google aber noch eine weitere spannende Konsequenz: Ist es dadurch doch künftig theoretisch sogar möglich, den Grafiktreiber über den Play Store auf dem Laufenden zu halten. Ob man von dieser Gelegenheit Gebrauch machen wird, und welche Konsequenzen dies für Dritthersteller haben wird, muss sich natürlich erst zeigen.
Nebeneffekte?
Unklar bleibt derzeit noch eine andere Auswirkung von Treble: Eine solch starke Modularisierung – und Isolierung – erhöht natürlich den Overhead, da sämtlicher Austausch zwischen den einzelnen Komponenten über Binder, Androids Mechanismus zur Interprozesskommunikation, abgewickelt wird. Laut Google hat man für Android 8 zahlreiche Optimierungen an Binder vorgenommen, die dafür sorgen sollen, dass der Unterschied nicht merklich ist.
Am Rande noch ein weiteres interessantes Detail zu Project Treble: Google nutzt diesen Umbau auch gleich, um sanften Druck auf seine Partner auszuüben, künftig mehr des eigenen Codes in das Android Open Source Project (AOSP) zurückfließen zu lassen. Muss doch jedes Gerät die VTS-Tests nicht nur mit der eigenen Android-Variante des jeweiligen Herstellers sondern auch mit einer unmodifizierten AOSP-Version bestehen. Wer hier den Code abliefert, erspart sich also zusätzlichen Wartungsaufwand. So sind denn auch in Android 8 bereits einige Optimierungen für einzelne Netzbetreiber von Sony und Qualcomm eingeflossen.
Performance
Zu den "Vitals", die Google mit Android 8 zu adressieren versucht, gehört aber auch die Systemperformance. So hat man eine ganze Reihe an Optimierungen rund um die Android Runtime ART vorgenommen. In Summe versprechen diese eine Beschleunigung der App-Ausführung um den Faktor 2 bis 3, wie man am Beispiel von Google Sheets ermittelt hat. Zudem wurde aber auch der Speicherverbrauch von Android – beziehungsweise der Apps – reduziert.
Konkret wird jetzt jener JIT-Profiler, der mit der Vorgängerversion eingeführt wurde, auch dazu verwendet, um die Organisation der Android-DEX-FIles zu optimieren. Dies bedeutet, dass Funktionen, die öfter genutzt werden, im Binary näher zusammengeführt werden. Das beschleunige nicht nur den App-Start, im Test zeige sich zudem, dass beispielsweise Google Maps direkt nach dem Launch nur mehr 10 statt zuvor 16 MB RAM verbrauche.
Ebenfalls neu gestaltet wurde die Garbage Collection. Diese nimmt nun Compaction für alle Apps vor, in Android N war dies noch auf Hintergrund-Apps beschränkt. Das Ergebnis: Die Heap Size ist im Vergleich 32 Prozent kleiner. In Performance-Hinsicht ist der erzielte Gewinn noch größer, die Garbage Collection Pause Times wurden um 85 Prozent reduziert. Weitere signifikante Fortschritte haben Arbeiten am Inliner und der Class Hierarchy Analysis gebracht. Außerdem habe man die Ausführung von Schleifen massiv beschleunigt. Dies mag zwar nicht für alle Apps relevant sein, dort wo das Ganze greift, werde die aufgewendete Zeit aber auf einen Bruchteil reduziert.
Alltagseinschätzung
Wie immer gilt: Solche Low-Level-Verbesserungen schlagen sich natürlich nicht 1:1 in der subjektiv wahrgenommene Performance eines Geräts nieder, die noch von einer Fülle anderer Faktoren abhängig ist. Eine Ausnahme bildet hier eine weitere Optimierung für die neue Betriebssystemversion: Android 8 soll nämlich rund doppelt so schnell booten wie seine Vorgänger – und im Test erwies sich diese Aussage sowohl bei einem Pixel XL als auch beim Tablet Pixel C als zutreffend.
Allgemeine Sicherheitsverbesserungen
Neben den Konsequenzen aus dem Project Treble bietet Android 8 aber auch sonst eine Fülle an Sicherheitsverbesserungen. So wurde etwa die mit Android 7 eingeführte File Based Encryption mit Features wie Key Ejection gestärkt. Ganz neu ist der Support für eigene Sicherheitschips ähnlich wie sie in Kreditkarten – oder bei Apples iPhone – eingesetzt werden. Dies soll physische Attacken gegen die Lock-Screen-Sperre deutlich schwerer machen. Eine weitere Maßnahme wendet sich gezielt gegen Ransomware: Können doch Apps jetzt nicht länger den Lock Screen oder den Statusbar überlagern.
Auch Verified Boot, das sämtliche Modifikationen am System verhindern soll, wird noch einmal verschärft. Konkret wird künftig ein Downgrade auf ältere – und unsichere – Versionen des Betriebssystems unterbunden. Wie immer bei solchen Änderungen gilt, dass sie nur zum Tragen kommen, wenn der Bootloader des Geräts gesperrt ist. Apropos: Der Bootloader ist künftig nur mehr manuell entsperrbar, bisher konnte auch Software diesen Schritt initiieren, was zum Teil von Malware missbraucht wurde.
Webview
Gleich mehrere Verbesserungen gibt es bei der Einbindung von Web-Inhalten in Apps: Dank Multiprozess-Support laufen Webviews künftig isoliert vom restlichen Programm, ein Fehler in der Rendering Engine gibt also nicht mehr direkt Zugriff auf die eigentliche App und ihre Daten. Auch können App-Entwickler jetzt festlegen, dass Webviews ausschließlich via HTTPS kommunizieren dürfen. Zudem können Webviews jetzt das von Chrome bekannt Safe Browsing einsetzen, um den Schutz vor betrügerischen Webseiten weiter zu verschärfen.
Komplett aus Android gestrichen wurde der Support für das veraltete – und unsichere – SSLv3. Und bei allen Apps, die Android 8 adressieren, ist TLS Fallback nicht länger erlaubt.
Kernel-Härtung
Der in einem Android-Gerät laufende Linux-Kernel bietet üblicherweise eine Reihe von Funktionen, die das Betriebssystem gar nicht nutzt, aber trotzdem von Angreifern für ihre Zwecke zum Einsatz gebracht werden können. Über die Nutzung von Seccomp-Filtern begrenzt Android 8 diesen Zugriff nun, insgesamt werden auf ARM64-Geräten 17 von 271 solcher Syscalls blockiert. Für sauber entwickelte Apps sollte das kein Problem darstellen. Entwickler, die sich hingegen nicht offiziell unterstützter Tricks bedienen, müssen eventuell ihre Programme anpassen. Gleiches gilt für die Verwendung nativer Bibliotheken: Diese dürfen aus Sicherheitsgründen künftig keine Segmente mehr laden, die gleichzeitig ausführ- als auch schreibbar sind. In solchen Fällen bricht das System den Start einfach ab.
Eine wichtige Änderung bringt Android 8 außerdem für die Installation von Paketen aus "unbekannten Quellen" – also jenseits des Play Stores. Wurde dieses bisher über die Einstellungen generell systemweit erlaubt oder verboten, muss diese Berechtigung nun für jedes einzelne installierende Programm erteilt werden. Dies ermöglicht es etwa einen alternativen App Store am Gerät zu nutzen, ohne die Installation von Paketen auf anderen Wegen – etwa dem Browser – freizugeben.
Privacy
Den nächsten Schwerpunkt der aktuellen Verbesserungen bildet der Bereich Privacy. Nimmt Google App-Entwicklern mit der neuen Version doch einige Möglichkeiten zur Datensammlung. So gilt die für jedes Gerät erstellte ANDROID_ID nicht mehr systemweit, pro App wird künftig eine eigene ID vergeben. Dies soll verhindern, dass Entwickler ihre Nutzer über mehrer Apps hinweg identifizieren und tracken. Aus Kompatibilitätsgründen werden die frischen IDs aber nur bei einer Neuinstallation vergeben, bei einem Update auf Android 8 verändert sich also zunächst nichts. Analog dazu bekommt nun auch jede Webseite eine individuelle Widevine ID, wenn sie DRM-geschützte Inhalte (Videos, Musik) übertragen will.
Von anderen Systemen lernt Google, indem man die MAC-Adresse der Netzwerkkarte bei Scans zufällig verändert, bisher konnten Geräte auf diesem Weg recht eindeutig identifiziert werden. Auch der Hostname wird nun bei DHCP-Abfragen – also dem Bezug einer IP-Adresse – anonymisiert. Zudem wird der Zugriff auf die Seriennummer eines Smartphones oder Tablets blockiert. Wer diese haben will, muss sich künftig über die Telefonieberechtigung die explizite Erlaubnis der User einholen. Darüberhinaus beschränkt Android 8 den Zugriff auf Account-Informationen, die entsprechende Berechtigung reicht hier nicht mehr aus, Apps müssen auch noch einmal explizit für jeden einzelnen Account nachfragen. Eine Ausnahme gibt es nur für Apps vom selben Hersteller.
Farbmanagement
Deutliche Verbesserungen verspricht Android 8 für die Farbdarstellung: Erstmals gibt es ein offiziell ins System integriertes Farbmanagement. Dies soll vor allem die Kalibrierung neuer Geräte verbessern. Für bestehende Devices ändert sich dadurch allerdings zunächst wenig, da solche Anpassungen üblicherweise nur im Werk vorgenommen werden können. Damit einher geht die Unterstützung eines weiteren Farbraums und unterschiedlicher Farbprofile wie AdobeRGB, Pro Photo RGB oder auch DCI-P3.
Um die Isolierung einzelner Bereiche auf dem lokalen Datenträger zu gewährleisten, bedient sich Android bisher des von der Linux-Welt bekannten FUSE. Mit Android 8 wird dies nun durch sdcardfs ersetzt, das ursprünglich von Samsung entwickelt und bereits seit einiger Zeit auf den eigenen Geräten eingesetzt wird. Dieser Wechsel verspricht einen reduzierten Overhead bei Dateisystemzugriffen – also eine gesteigerte Performance.
Bluetooth
In Fragen Bluetooth bringt Android 8 zunächst die offizielle Unterstützung von Bluetooth LE 5.0. Zudem betont Google aber, dass man viele Optimierungen vorgenommen habe, um die Performance bei der Bluetooth-Übertragung zu verbessern, und dabei auch die Stabilität zu steigern – ein immer wieder kritisierter Problembereich von Android. Zudem soll Bluetooth Audio künftig aber auch besser klingen: Zu diesem Zweck hat Sony sein LDAC Codec beigesteuert, auch aptX wird mit der neuen Android-Generation jetzt unterstützt.
Und wenn wir schon bei Audio sind: Mit AAudio gibt es nun eine neue API, die gezielt auf die Verwendung von Android für professionelle Audio-Apps ausgelegt ist, und hohe Performance sowie geringe Latenzzeiten garantieren soll. Zusätzlich gibt es mit VolumeShaper jetzt auch einen standardisierten Weg für Fadeouts, Crossfades und andere Effekte.
Vermischtes
Verbesserungen gibt es bei der Unterstützung mehrerer Displays: Mit Android 8 können Apps nun festlegen, auf welchem Bildschirm eine einzelne Aktivität laufen soll. Die "Downloadable Fonts" ermöglichen wiederum, dass Apps einzelne Schriften herunterladen und mit anderen teilen können, anstatt dass sie in jedes einzelnen Paket aufgenommen werden müssen. Die Java-8-Unterstützung wird mit der neuen Version ebenfalls erweitert.
Dank des Wifi-Aware-Supports soll der drahtlose Austausch zwischen zwei oder mehreren Geräten im direkten Umfeld einfacher und flotter werden. Derzeit ist das aber noch pure Theorie, da hierfür die entsprechende Hardware benötigt wird. Und zu guter letzt wird auch bei der Tastaturunterstützung von Android einmal mehr nachgebessert: App-Entwickler können nun das User Interface in Cluster einteilen, zwischen denen über die Tastatur schnell gewechselt werden kann. Auch ist es jetzt möglich einen Default-Fokus-Bereich für eine App festzulegen.
Fazit
Der schiere Umfang an strukturellen Verbesserung, den Google mit Android 8 bringt, darf getrost als beeindruckend bezeichnet werden. Dass man sich dabei im aktuellen Zyklus auf die "Vitals" konzentriert, ist ebenfalls uneingeschränkt zu begrüßen. Android wird mit der neuen Generation schneller, sichere und stromsparender – und das ist allemal wichtiger als irgendwelche neuen Softwaregimmicks.
Die große Frage bleibt bei all dem aber natürlich, wie lange es dauern wird, bis die Nutzer auch wirklich etwas davon haben – und was die diversen Smartphone-Hersteller dann aus der Google-Vorlage machen. Viele der aktuell gesetzten Schritte werden zudem erst langfristig ihre volle Wirkung entfalten, allen voran die massiven Umbauten für einfachere Updates – was sie aber natürlich keine Spur weniger wichtig macht.
Ausblick
Android 8.0 soll bereits in wenigen Tagen offiziell freigeben werden. Damit geht dann auch die Auslieferung entsprechender Updates für Googles aktuell noch supportete Geräte einher – konkret Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P und Nexus Player. Wann die aktuelle Version schlussendlich auf anderen Smartphones und Tablets landet, lässt sich wie gewohnt natürlich nicht sagen, dies hängt voll und ganz vom Willen der jeweiligen Hersteller ab. (Andreas Proschofsky, 6.8.2017)