Android 7.0 Nougat im Test: Googles Mobil-Betriebssystem war noch nie so produktiv

Veränderungen unter der Haube

Zu den neben Doze weiteren Veränderungen unter der Haube von Android 7.0 zählt die Unterstützung der Vulkan-API. Die von dem Industriekonsortium der Khronos Group, zu dessen größten Mitgliedern neben Google auch AMD, Apple, ARM, Intel, Nvidia, Qualcomm und Samsung zählen, entwickelte Vulkan-API bringt plattformübergreifenden Low-Level-Zugriff auf die Grafik-Hardware, verursacht weniger CPU-Overhead und soll bei korrekter Umsetzung durch App-Entwickler eine höhere Leistung oder einen niedrigeren Energieverbrauch ermöglichen. Für Entwickler ist die Grafik-API auch deshalb interessant, weil sie anders als Metal nicht an Apple oder im Falle von DirectX 12 an Windows 10 gebunden ist. Obwohl Android 7.0 für sechs Google-Geräte zur Verfügung gestellt wird, funktioniert Vulkan nur mit dem Nexus 5X, 6, 6P, Nexus Player und dem Pixel C. Die Hardware des Nexus 9 würde Vulkan eigentlich ebenso unterstützen, es mangelt hier aber schlichtweg am Support durch Google.

Im Benchmark-Vergleich finden sich mangels Verfügbarkeit noch keine Vulkan-Tests.

VR-Modus für Daydream und Cardboard

Mit Daydream arbeitet Google derzeit an einem ambitionierten VR-Projekt, das weit über die Fähigkeiten von Google Cardboard hinausgeht und qualitativ hochwertiges VR auch mit Controllern ermöglichen soll. Zur I/O 2016 hatte Google ein Referenzdesign für eine VR-Brille und für eine Fernbedienung gezeigt. An passenden Daydream-Apps können Entwickler bereits seit Mai arbeiten. Das neue VR SDK für Android unterstützt dafür neben dem neuen Daydream auch noch das alte Cardboard. Ein in Android 7.0 integriertet VR-Modus soll während der VR-Nutzung eine höhere Leistung als bisher ermöglichen. Dafür wird VR-Anwendungen unter anderem exklusiver Zugriff auf einen CPU-Kern gewährleistet. Android 7.0 unterstützt zudem intelligentes Head-Tracking und zeigt auch im VR-Modus korrekt gerenderte Systembenachrichtigungen an. Außerdem verspricht Google im VR-Modus sehr niedrige Latenzen bei der Grafikverarbeitung.

Hohe Systemleistung dauerhaft abrufen

App-Entwickler können unter Android 7.0 einen speziellen Leistungsmodus abrufen, bei dem versucht wird, für das aktive Fenster eine dauerhaft hohe Systemleistung zur Verfügung zu stellen, ohne dass zu hohe Temperaturen der Hardware die Leistung bremsen. Damit dieser „sustained performance mode“ korrekt genutzt werden kann, müssen von den Geräteherstellern spezifische Hinweise für die Grenzen der Hardware im System hinterlegt werden, die Entwickler aufgreifen können, um ihre Anwendung für eine vorhersehbar dauerhaft hohe Leistung zu optimieren. Anstatt zum Beispiel das absolute Maximum an Leistung kurzfristig abzurufen nur um wenig später in durch Überhitzung verursachtes Throttling des SoCs zu laufen, können Entwickler eine hohe Leistung abrufen, bei der durch den OEM definiert kein Throttling auftritt. In der Spitze ist die Leistung dann zwar niedriger, dafür kommt es aber nicht mehr zu Einbrüchen.

Nahtlose Updates ohne nervige Wartezeit

Ab Version 7.0 unterstützt Android nahtlose Updates ohne Wartezeit für den Nutzer. Wie bei Chrome OS verfügt das neue Betriebssystem über zwei System-Partitionen, von denen eine im laufenden Betrieb aktualisiert werden kann, ohne dass der Nutzer dies im Alltag mitbekommt. Nach einem Neustart wird dann zur aktualisierten Partition gewechselt und die alte für das nächste potenzielle Update zur Seite gestellt. Die bisher nach einem Systemupdate auftretende Wartezeit beim Neustart, währenddessen alle installierten Anwendungen optimiert werden mussten, fällt damit endlich weg.

Apps nehmen weniger Platz ein und sind schneller installiert

Google hat die mit Android 5.0 Lollipop vollständig eingeführte Android Runtime (ART) außerdem um einen Just-in-time-Compiler (JIT) erweitert. Apps werden nun nicht mehr während der Installation in nativen Code kompiliert. Stattdessen wird die App während der Laufzeit durch den JIT-Compiler übersetzt. Besonders oft aufgerufene („heiße“) Methoden werden durch den immer noch vorhandenen Ahead-of-time-Compiler (AOT) bereits im Voraus kompiliert und in einem Cache gespeichert, dieser springt aber nur an, wenn das Gerät im Leerlauf und an eine Stromquelle angeschlossen ist.

Durch die Optimierungen der Android Runtime kann die Leistung in einigen Anwendungen um bis zu 600 Prozent ansteigen. App-Installationen gehen dank der weggefallenen AOT-Kompilierung potenziell um bis zu 75 Prozent schneller vonstatten und der belegte Speicherplatz sinkt im besten Fall um maximal 50 Prozent.

	Android 7.0		Android 6.0.1
	Build-Nummer	Belegter Speicher	Build-Nummer	Belegter Speicher
Nexus 5X	NRD90M	1,40 GB von 24,89 GB	MTC20F	2,47 GB von 24,89 GB
Nexus 6P		1,23 GB von 53,67 GB		2,36 GB von 53,67 GB
Nexus 9		2,32 GB von 11,05 GB	MOB30W	3,10 GB von 11,05 GB

Android 7.0 belegt weniger Speicher nach Neuinstallation

Neuinstallationen von Android 7.0 Nougat auf dem Nexus 5X (32 GB), Nexus 6P (64 GB) und Nexus 9 (16 GB, WLAN) belegen weniger Speicher als Neuinstallationen von Android 6.0.1 Marshmallow. In beiden Fällen wurden zunächst die Factory Images aufgespielt und dann alle vorinstallierten Apps über den Play Store aktualisiert.

Direct Boot & Verschlüsselung

Android 7.0 verfügt über einen sogenannten Direct Boot, der vor allem im Zusammenspiel mit der neuen dateibasierten Verschlüsselung zum Tragen kommt. Direct Boot soll zum einen die Bootzeit verkürzen, aber insbesondere bei verschlüsselten Geräten eine Teilfunktion des Betriebssystems gewährleisten. Bei der vollständigen Datenträgerverschlüsselung kann ein Gerät nach einem ungewollten Neustart keinen Wecker auslösen, Anrufe oder Nachrichten empfangen.

Bei der dateibasierten Verschlüsselung unterscheidet Google nun zwischen einem verschlüsselten Gerätespeicher für Systemdateien und speziell freigegeben Daten sowie nutzerspezifischen verschlüsselten Daten, die erst nach Authentifizierung offengelegt werden. Beim Direct Boot startet das System in einem eingeschränkten Modus und hat nur Zugriff auf den verschlüsselten Gerätespeicher, um zum Beispiel den Nutzer nach einem ungewollten Neustart trotzdem noch über den gestellten Wecker wecken zu können.

Direct Boot und die dateibasierte Verschlüsselung sind auf ab Werk mit Android 7.0 ausgelieferten Geräten standardmäßig aktiviert. Geräte, auf denen Android 7.0 per Update installiert wurde, müssen jedoch manuell umgestellt werden, was nur einhergehend mit der Löschung des Gerätes möglich ist. Außerdem handelt es sich bei der dateibasierten Verschlüsselung noch um eine Alpha-Version, wie die selbst im finalen Android 7.0 noch in den Entwickleroptionen versteckte Einstellung warnt.