Mit Android 7.0 plant Google in Kürze eine neue Version seines mobilen Betriebssystems vorzustellen. Neben sichtbaren Neuerungen wie einem Split-Screen-Modus und einer grundlegenden Überarbeitung der Benachrichtungen bringt "Nougat" – so der Codename der neuen Release – auch wieder zahlreiche Umbauten an der Basis des Betriebssystems. Deren Entwicklung ist mittlerweile abgeschlossen, im Vergleich zur aktuellsten – und letzten geplanten – Testversion (Developer Preview 5) wird sich in dieser Hinsicht bis zur Freigabe von Android 7.0 also nichts mehr ändern. Insofern lohnt es schon jetzt einen etwas näheren Blick auf all die diesbezüglichen Änderungen von "Nougat" zu werfen. Doch zuerst noch ein kleiner Disclaimer vorab, damit keine falschen Erwartungen entstehen: Dies ist explizit kein vollständiger Test von Android 7.0, all den "oberflächlichen" Neuerungen von Nougat werden wir uns zu einem späteren Zeitpunkt in aller Ausführlichkeit widmen.

ART legt nach

Einer der wichtigsten Bestandteile von Android ist die Runtime ART, ist diese doch für die Ausführung (fast) aller Programme zuständig. Optimierungen an dieser Stelle haben insofern auch eine direkte Auswirkung auf eine Fülle unterschiedlicher Systembereiche. Mit Android 7.0 nimmt Google hier eine wichtige Änderung vor: Der bestehende Ahead-of-Time-Compiler (AOT) wird nämlich durch einen Just-In-Time-Compiler (JIT) mit Code Profiling ergänzt.

Um zu erklären, was Google damit erreichen will, ist es am besten zu einem konkreten Beispiel zu greifen, in dem die bisherige Lösung Probleme verursachte: Der App-Installation. Bisher wurde jedes Programmpaket zunächst heruntergeladen und dann mit dem AOT für das jeweilige System optimiert. Ziel dieses Ansatzes war es die Ausführungsgeschwindigkeit von Android-Apps zu erhöhen – was auch durchaus erfolgreich war. Allerdings hat dieser Ansatz auch zwei entscheidende Nachteile: Einerseits wird dadurch die Installation von Anwendungen erheblich langsamer, immerhin benötigt das lokale Kompilieren so seine Zeit. Andererseits wird aber auch der Speicherplatzverbrauch erhöht, schließlich müssen die zusätzlichen Daten auch irgendwo gespeichert werden.

Für Android 7.0 versucht man sich nun an einem hybriden Ansatz: Anstatt die Apps bereits bei der Installation zu kompilieren, analysiert ART diese jetzt bei der Ausführung und erstellt je nach Nutzung mithilfe der JIT/AOT-Kombination zielgerichtete Optimierungen. Dadurch wird der Speicherplatzverbrauch massiv reduziert, da etwa Teile der App, die nie benutzt werden, auch nicht optimiert und somit abgespeichert werden müssen. Gleichzeitig soll dadurch aber auch die Performance gesteigert werden, da ART diese Optimierungen nicht bloß einmal vornimmt sondern laufend anpasst. Auch der RAM-Verbrauch sinkt durch den reduzierten Overhead, was vor allem für Low-End-Geräte ein durchaus relevantes Thema ist.

Jene Konsequenz, die die Nutzer am deutlichsten bemerken werden, ist aber eben bei der App-Installation zu suchen. Und diese erfolgt nun tatsächlich um ein Vielfaches schneller als noch in Android 6.0. Besonders deutlich zeigt sich dies bei einem System-Update: Musste man zuletzt mehrere Minuten warten bis der "Optimizing Apps"-Schritt abgeschlossen wurde, entfällt diese Wartezeit mit Android 7.0 nun komplett.

Neues Update-System

Apropos Updates: Hier hat sich Google ebenfalls etwas Neues einfallen lassen: Mit Android 7.0 hält ein vollständig neues Update-System Einzug, und zwar eines für das man sich bei einem anderen Google-Betriebssystem bedient hat: Nicht nur das Konzept sondern auch der Code wurden direkt von Chrome OS übernommen. Die zentrale Idee dahinter ist, dass Android nun statt einer zwei – im Normalfall identische – Systempartitionen hat. Ist nun ein System-Update verfügbar, wird dieses künftig automatisch heruntergeladen und im Hintergrund auf die gerade nicht aktive Systempartition installiert. Beim nächsten Boot wechselt dann Android schlicht die Partition, von der es bootet – und das war es dann auch schon mit der Aktualisierung. Die gewohnte, lange Wartezeit entfällt, lediglich Änderungen an zentralen Komponenten wie dem Bootloader müssen noch direkt beim Reboot vorgenommen werden.

Der dadurch entstehende Overhead soll dank der Verwendung von SquashFS minimal bleiben, verspricht zumindest Google. Und auf dieses Versprechen muss man sich vorerst auch verlassen, wird es das neue Update-System doch nur für Geräte geben, die bereits von Haus aus mit Android 7.0+ ausgeliefert werden. Der Grund dafür ist wohl, dass dafür der Datenspeicher vollständig neu partioniert werden muss, was auf bestehenden Geräten über ein Update nicht umzusetzen wäre – zumindest nicht ohne einen kompletten Datenverlust. Und nur für jene Gruppe, die bereit ist manuell ein neues Factory Image zu installieren, will Google wohl den zusätzlichen Test- und Wartungsaufwand nicht übernehmen.

Direct Boot

Unter dem Namen "Direct Boot" bringt Android 7.0 aber noch eine dritte Neuerung, die indirekt Auswirkungen auf den Bereich Updates haben könnte. Konkret geht es hierbei darum, die Datenträgerverschlüsselung etwas flexibler zu gestalten, um so ein bestehendes Defizit zu bereinigen: Wird ein verschlüsseltes Android-System rebootet, bedarf es bislang der Passworteingabe, bevor auch nur die grundlegendsten Funktionen des Geräts verfügbar sind. Die Konsequenz daraus: Kommt es in der Nacht zu einem Problem und das Smartphone rebootet spontan, läutet der morgendliche Wecker nicht.

Mit Android 7.0 wird wird die Verschlüsselung nun flexibler. So sind zwar weiterhin alle Daten verschlüsselt gespeichert, ein Teil davon – also jene Dienste, die zwar essentiell aber für die Sicherheit nicht relevant sind – aber nur mehr mittels des fixen Hardwareschlüssels und nicht noch extra durch die Passphrase der User geschützt. Das bedeutet, dass eben Wecker oder SMS-Service schon laufen können, bevor die Nutzer das Gerät nach dem Reboot entsperren. Passend dazu gibt es ein neues API von Google, mit dem Entwickler Direct Boot für ihre eigenen Apps nutzen können.

Mit den Updates hat dies insofern etwas zu tun, weil dies automatisch durchgeführte System-Updates in die Nähe rücken lässt, da die Installation samt Reboot in der Nacht vorgenommen werden könnte, ohne dass dies nachteilige Auswirkungen auf die User hat. Und gerade aus einer Sicherheitsperspektive wären automatische System-Updates, um die sich die User nicht kümmern müssen, eine durchaus sinnvolle Idee. Immerhin ignorieren viele User System-Updates oft lange – oder spielen sie gleich gar nicht ein. Ob Google den Schritt zu Auto-Updates wirklich wagt, ist derzeit allerdings noch nicht bekannt.

Im Unterschied zum neuen System-Update-Mechanismus, lässt sich Direct Boot auch auf einigen bestehenden Geräten testen. Aus Googles eigenem Angebot sind dies derzeit das Nexus 5X, das Nexus 6P sowie das Pixel C. Allerdings ist der Prozess nicht ganz ohne Fallstricke: Muss dafür doch in den Entwicklereinstellungen der Punkt "File-based Encryption" aktiviert werden. Bevor man all zu eilig zu dieser Option greift, sei noch davor gewarnt, dass dabei sämtliche Nutzerdaten gelöscht werden, das Gerät also wieder frisch aufgesetzt werden muss.

Stromsparen

Bei einem sind sich so ziemlich alle Smartphone-Besitzer einig: Die Akkulaufzeit ist eigentlich immer zu kurz. Also tut auch Google sein bestes, softwareseitig das meiste aus den physischen Begrenzungen herauszuholen. Mit Android 6.0 wurde deswegen der "Doze"-Modus eingeführt, der bei Inaktivität nach und nach die erlaubten Hintergrundaktivitäten beschränkt und anstehende Aufgaben bündelt, um so Strom zu sparen. Dies hat vor allem in Hinblick auf die Standby-Zeit von Android-Geräten signifikante Verbesserungen gebracht.

Mit Android 7.0 geht man nun einen Schritt weiter – oder genauer genommen zwei. Zunächst wäre da einmal, dass einzelne Beschränkungen nun deutlich früher vorgenommen werden als bisher, konkret geht es dabei um Netzwerkzugriffe und Sync-Aufgaben. Desweiteren wird Doze jetzt auch angewandt, wenn das Gerät zwar nicht stationär ist, aber trotzdem gerade nicht benutzt wird – also etwa unterwegs in der Tasche. Auch hier werden aber nur die zwei erwähnten Services beschränkt anstatt die gesamte Doze-Palette zum Einsatz zu bringen, immerhin will man ja unterwegs nicht wichtige Sensoren deaktivieren.

Hintergrundservices

Dass man im Sinne von Performance- und Akkuverbesserungen durchaus auch gewillt ist, App-Entwicklern Zusatzarbeit zu bereiten, beweist Google an anderer Stelle. Kündigt das Unternehmen doch an, dass man in der Zukunft manch problematische – aber durchaus verbreitete – Methoden unterbinden will. Und mit Android 7.0 setzt man nun erste Schritte in diese Richtung.

Konkret geht es dabei um zwei Dinge: Dauernd laufende Hintergrundservices und die sogenannten "Implicit Broadcasts". Bei Zweiterem handelt es sich um eine Methode, mit der sich Apps umgehend über für sie interessante Neuerungen informieren lassen können – etwa wenn ein neues Foto aufgenommen wurde. Genau dieser Trick hat aber verheerende Auswirkungen auf Stromverbrauch, RAM-Hunger und Performance eines Geräts. Wird nun – um in dem Beispiel zu bleiben – ein neues Bild aufgenommen, werden damit unweigerlich sämtliche Apps, die sich via Implicit Broadcast informieren lassen, aufgeweckt. Dies führt spätestens wenn dies mehrere Apps gleichzeitig machen zu einem Ressourcen-Engpass, den die Nutzer durch Hänger und langsame Reaktionszeiten in ihrer Kamera-App bemerken.

Genau diese impliziten Broadcasts will Google auf Sicht vollständig loswerden, die App-Entwickler sollen stattdessen auf Lösungen wie den JobScheduler setzen, der solche Informationen organisiert und vernünftig geplant weiterreicht. Natürlich ist Google klar, dass man eine dermaßen grundlegende Änderung nicht von heute auf morgen vornehmen kann. Also spricht man zunächst einmal nur die grundlegende Absicht aus, und konzentriert sich in Android 7.0 auf drei konkrete Beschränkungen: Der implizite Broadcast der bei einer Änderung der Netzwerkverbindung anspringt, darf nicht mehr genutzt werden, wenn eine App die neue Android-Version als Zielplattform adressiert. Etwas forscher geht man es hingegen bei den Broadcasts für Foto- und Videoaufnahmen an, diese werden nämlich gleich ganz unterbunden. Apps die dies bisher nutzen, müssen also für Android 7.0 angepasst werden.

Die zweite Einschränkung betrifft Background Services im Allgemeinen: Diese sollen in Zukunft nur mehr dann erlaubt sein, wenn sie direkt mit einem Vordergrunddienst gekoppelt sind. Diese Änderung soll allerdings erst in einer späteren Android-Version folgen, mit "Nougat" ändert sich hier also zunächst einmal nichts. Trotzdem fordert Google die Entwickler dazu auf, ihre Apps schon jetzt ganz ohne "Implicit Broadcasts" und unnötige Hintergrunddienste zu entwickeln und Feedback zu liefern, wo sie dabei an Grenzen stoßen, damit man etwaige Verbesserungen für JobScheduler und Co. vornehmen kann. Für den Ressourcenverbrauch von Android könnten die anvisierten Beschränkungen jedenfalls ein echter Gewinn sein.

Java 8

Mit Android 7.0 vollzieht Google ein Änderung, die sich viele Entwickler wohl schon früher gewünscht hätten. Durch den Wechsel auf OpenJDK unterstützt Android nun endlich Java 8 – oder zumindest einen Teil davon. Die Entwickler können jetzt also einige zusätzliche Funktionen wie Lambda-Ausdrücke einsetzen. Dazu passend gibt es eine neue Toolchain: Jack löst javac ab, und ist Voraussetzung für die Nutzung der Java-8-Funktionen.

Vulkan

Vollkommen neu ist das Vulkan API, das eine Art freies, und offen spezifiziertes Pendant zu Apples Metal ist. Ziel ist es hier wie da eine hardwarenähere und modernere Alternative zu OpenGL (ES) zu schaffen. So ist Vulkan etwa von Grund auf auf die Nutzung von Mehrkernsystemen ausgerichtet. Erste Tests zeigen, dass sich damit zum Teil deutlich bessere Performance aus 3D-Anwendungen und -Spielen holen lässt. Vorausgesetzt natürlich die User haben die passende Hardware, in der Nexus-Welt heißt dies etwa, dass Vulkan erst aber der Nexus 5X / 6P-Generation unterstützt wird. Natürlich wird aber auch OpenGL ES nicht so schnell verschwinden, in Android 7.0 wurde dies auf die Version 3.2 aktualisiert.

Virtual Reality

Mit Daydream will Google einen neuen Standard für Virtual Reality-Anwendungen etablieren, mit Android 7.0 schafft man die Basis dafür. So gibt es hier nun etwa ein API, über das Apps kommunizieren können, welches Performance-Level sie dauerhaft halten können. Immerhin ist es für den VR-Eindruck wichtiger eine durchgängige Framerate halten zu können als die beste Darstellungsqualität zu wählen, die dann aber nur ein paar Minuten verfügbar ist. Parallel dazu wurden einige gezielte Performance-Optimierungen für Low-Latency-Grafik vorgenommen, auch Schnittstellen für Head Tracking sind hinzugekommen. All dies wird aber erst mit einer neuen Hardwaregeneration schlagend werden, Google hat bereits angekündigt, dass aktuelle Smartphones allesamt nicht "Daydream ready" sind.

Webview

Wer Webseiten in seine App einbinden will, greift meist zu einem Webview, und genau hier nimmt Google mit Android 7.0 eine wichtige Änderung vor. Wurde das Webview bisher in einem eigenen Paket ausgeliefert, nutzt "Nougat" nun einfach das Chrome-Paket für diese Aufgaben. Das spart Platz, weil nur mehr eine statt zwei Rendering Engines installiert werden müssen, bringt aber noch andere Verbesserungen mit sich. So gibt es nun Mehrprozess-Support, was konkret heißt, dass sämtliche Webviews durch eine Sandbox von einander isoliert laufen – ein Gewinn für die Systemsicherheit. Dazu passt, dass Geolocation-Anfragen mit Android 7.0 nun nur mehr über verschlüsselte Verbindungen abgewickelt werden dürfen, alle anderen werden vom System blockiert.

Sind mehrere Chrome-Versionen installiert, kann über die Entwicklereinstellungen ausgewählt werden, welche davon die Webview-Agenden übernehmen soll. Und Dritt-Anbieter können hier natürlich auch weiter ein eigenes Webview ausliefern, wenn ihnen das ein Anliegen ist.

Sicherheit

Kommen wir zum Bereich Sicherheit, hier bringt Android 7.0 nämlich – neben dem schon erwähnten – eine ganze Reihe von Verbesserungen. In Hinblick auf die schier endlosen Stagefright-Lücken sticht eine davon besonders heraus: Der Mediaserver von Android wird nämlich in mehrere Komponenten aufgeteilt, die allesamt mittels Sandbox voneinander getrennt sind. Der Vorteil: Jeder dieser Teilbereiche hat nur die für seine Aufgaben unbedingt notwendigen Berechtigungen. Taucht nun eine Sicherheitslücke auf, ist der erzielbare Schaden wesentlich geringer.

Auch dies lässt sich wieder am Besten mit einem Beispiel aus der Praxis illustrieren: Ein großer Teil sämtlicher in Stagefright gefundenen Sicherheitslücken befand sich beim Parsen von Dateiformaten und Codecs. Im alten, monolithischen Design konnte man mit einem Angriff an dieser Stelle unter anderem Zugriff auf Kamera, Mikrofon oder auch Bluetooth-Verbindungen erhalten. Mit dem modularen Aufbau hat der MediaCodecService jetzt aber nur mehr die Berechtigung zum Zugriff auf die GPU, an solch sensible Komponenten wie das Mikrofon kommt man auf diesem Weg also nicht mehr heran.

Einige Anstrengungen hat Google auch unternommen, um den mitgelieferten Linux-Kernel besser vor Angriffen abzusichern. So wurden einzelne Features von Haus aus deaktiviert, um die Angriffsfläche zu minimieren. Auch gibt es nun einen besseren Schutz gegen Stack Overflow-Angriffe und der direkte Zugriff des Kernel auf Userspace-Speicher wird nun unterbunden. Weiter Details liefert Google in einem eigenen Blogeintrag.

Verifiziert oder gar nicht

Mittels Verified Boot soll sichergestellt werden, dass das System nicht von Dritten manipuliert wurde. Diese Funktion gab es zwar schon in Android 6.0, dort wurde sie aber nur für einen Warnhinweis genutzt. Mit Android 7.0 geht Google nun einen Schritt weiter, und unterbindet den Boot komplett, wenn die Systemintegrität nicht gewährleistet ist. Um zu verhindern, dass dies für die Nutzer unerfreuliche Nebeneffekte hat, etwa wenn der lokale Flash-Speicher Probleme macht, hat man aber auch die Fehlerkorrektur verbessert, so dass Android Storage-Probleme zumindest im kleinen Ausmaß selbst korrigieren kann. Alles in Allem also ein wichtiger Schritt vorwärts für die Systemsicherheit, wird es doch etwa für Rootkits erheblich schwerer sich auf dem System einzunisten.

Dieser Schritt unterbindet übrigens nicht, dass die Nutzer eigene Modifikationen am System vornehmen – etwa mit Rooting-Tools. Damit dies möglich ist, muss allerdings der Bootloader entsperrt sein, insofern gilt mit "Nougat" noch verstärkt, was schon bei bisherigen Android-Versionen ein weiser Ratschlag war: Wer vorhat, mit der Systemsoftware seines Smartphones zu basteln, sollte sich vor dem Kauf wohl überlegen, welches Gerät angeschafft wird – nämlich eines mit entsperrbarem Bootloader.

Einen weiteren Angriffsvektor widmet sich Android im Netzwerkbereich: Android 7.0 akzeptiert nun von Haus aus keine von den Nutzern hinzugefügten Certificate Authorities mehr. Immer wieder wurden in der Vergangenheit gefälschte CAs für Man-in-the-Middle-Attacken gegen verschlüsselte Verbindungen genutzt. Trotzdem stößt diese Änderung aber nicht ausschließlich auf Begeisterung, beschränkt man damit doch auch die Möglichkeiten der Nutzer, ihren eigenen Netzwerkverkehr zu analysieren oder zu verändern. Zumindest gibt es aber für Apps die Möglichkeit, hier eine gezielte Ausnahme zu machen, um so für ihre Zwecke sehr wohl von den Nutzern installierte CAs zuzulassen.

Umgekehrt stehen Entwicklern mit Android 7.0 einige neue Möglichkeiten zur Verfügung, den Netzwerkverkehr ihrer Apps zusätzlich abzusichern. So können sie nun etwa festlegen, dass der Datentransfer auf keinen Fall unverschlüsselt erfolgen darf. Auch ist es jetzt möglich ein einzelnes SSL/TLS-Zertifikat fix in der App festzulegen, um zu verhindern, dass hier an anderer Stelle Modifikationen erfolgen können.

Für jene, die native Apps mithilfe des NDKs entwickeln, bringt Android 7.0 ebenfalls eine wichtige Änderung. Ist es damit doch jetzt untersagt, dynamisch gegen Systembibliotheken zu linken. Das Problem ist, dass solche Methoden bei System-Updates zu Problemen führen können, und die App dann im schlimmsten Fall gar nicht mehr läuft. Schon bisher hat Google immer empfohlen nur die offiziellen NDK APIs zu nutzen, nun greift man aber durch: Apps die das Android 7.0 (beziehungsweise das zugehörige API-Level 24) adressieren, dürfen solche Links nicht mehr setzen, sonst wird der App-Start schlicht mit einem Fehler abgebrochen.

Vermischtes

Zu all dem gesellen sich noch eine Reihe kleinerer Änderungen: So können Apps nun statt die gesamte Storage-Berechtigung anzufragen, auch nur den Zugriff auf einen bestimmten Folder im lokalen Speicher anfragen – aus einer Privacy-Perspektive ein echte Verbesserung. Vor allem für die Desktop-Nutzung ist das Custom Mouse Pointer API interessant, mit dem – wie der Name schon sagt – individuelle Mauszeiger gestaltet werden können. Sehr hilfreich ist auch, dass es jetzt ein zentrales API für das Blockieren von Telefonnummern gibt, damit alle diesbezüglichen Apps auf eine gemeinsame Liste zugreifen können. Und dann gab es natürlich wieder jede Menge Verbesserungen für den Enterprise-Bereich, oder wie es bei Google heißt: "Android for Work". Administratoren können jetzt etwa fix die Nutzung eines VPNs erzwingen, den Zugriff auf einzelne Apps temporär sperren oder auch Data Roaming auf Firmengeräten gänzlich verbieten.

Fazit

Während "Marshmallow" mit dem neuen Berechtigungssystem ein großes Highlight vorzuweisen hatte, zeichnet sich der Nachfolger durch die Summe all der Änderungen aus – die aber gemeinsam kaum weniger relevant sind. Vor allem der Fokus auf Performance und Akku-Laufzeit gefallen – und beides zeigt schon in den Preview-Versionen von Android 7.0 deutlich seine Wirkung. Zudem merkt man, dass sich Google die Kritik an so manchem Sicherheitsdefizit zu Herzen genommen hat, "Nougat" bringt auch in dieser Hinsicht wichtige Verbesserungen. Schon alleine deswegen bleibt zu hoffen, dass die neue Version flotter und weiter seine Verbreitung findet als der direkte Vorgänger. Immerhin bringt das beste Update wenig, wenn es die Nutzer nicht erhalten.

Die fertige Version von Android 7.0 soll nach aktuellen Informationen noch im August veröffentlicht werden. Die Release wird dabei wie immer mit der Freigabe des Source Codes und der Systemimages für aktuell von Google noch betreute Geräte der Nexus-Linie sowie das Pixel C einhergehen. Wann – und ob – andere Hersteller mit einem Update folgen, wird sich erst in den folgenden Wochen herausstellen. (Andreas Proschofsky, 7.8.2016)