mobil.teltarif.de
zum Adventskalender
Suche Desktop-Version
Menü
11.08.2017 - 14:50
Android 8.0

Google plaudert über Details zu Android 8.0, Teil 2

Always-On-Display, Kernel-Updates und Sicherheit

Im ersten Teil waren bereits einige wichtige Dinge des kommenden Android-Updates angesprochen worden. Unter anderem was es mit Project Treble auf sich hat, einschließlich dessen Schwach­stellen, was Google mit SafetyNet und Root-Nutzern vor hat - oder auch nicht - und warum eine Themes-Engine eine solch große Heraus­forderung darstellt.

Allerdings ist das nur ein Bruch­teil dessen gewesen, worüber die Entwickler von Google gesprochen haben. Es gibt noch einiges mehr das von Interesse ist, aber wegen Platz­gründen im letzten Artikel nicht mehr unter­gekommen ist.

Optik vs. AMOLED

Android 8.0 O

Google hat wahrlich viel zu erzählen zu Android 8.0 und Android im Allgemeinen
Logos: Google, Grafik/Montage: teltarif.de

Bis auf Samsung verwenden vergleichs­weise wenige Hersteller AMOLED-Displays in ihren Geräten, darunter Google mit den aktuellen Pixel-Modellen. Nun standen die Entwickler vor der Frage, ob die Navigations­leiste nicht auch in denselben Farben wie die Status­leiste erstrahlen sollte. Gerade mit Blick auf OLED/AMOLED bedarf es einer wohl­überlegten Entscheidung, um nicht leicht­fertig eingebrannte Pixel zu riskieren.

Dieser Punkt und der Fakt, dass zu viele Farben hinter den Display­tasten zu sehr ablenken von der eigentlichen App, hat dazu geführt, dass die Navigations­leiste kurzer­hand schwarz bleibt. Zumal nicht jede App die Status­leiste einfärbt, was wiederum gegen die Lösung spricht, die Navigations- an die Status­leiste anzupassen. Die Gefahr eines Burn-Ins einzelner Pixel, im schlimmsten Fall sogar mit Farb­verlauf, würde sich mit einer grauen Leiste am besten in den Griff bekommen, aber auch das ist keine ideale Lösung findet Google.

Von daher wird das Team der Android-Entwickler noch einige internen Diskussionen führen, was denn nun eine gute Möglich­keit wäre, die Navigations­leiste in künftigen Versionen etwas aufzupeppen.

Dunkler Modus

Ein Stück weit gehört der mehrfach in Developer Previews verwendete Dark-Modus zum Bereich der Themes-Engine, wie auch Alan Viverette, Technical Lead Manager des Support-Library-Teams bei Google, erwähnte.

Kurz gesagt hätte ein Dark-Modus die doppelte Grafik­arbeit bedeutet, da das komplette System einschließlich Öko­system angepasst werden müsste. Eine Arbeit, die einfach zu aufwendig ist - auch wenn ein zeit­gesteuerter Wechsel der Material-Design-Oberfläche googleintern eine sehr beliebte Spielerei war.

Unterm Strich bedarf es tief­greifender Veränderungen in diversen Kern-Komponenten von Android und dem App-Framework, sodass weder die Themes-Engine noch ein einfacher Dark-Modus offiziell Bestand­teil von Android 8.0 wird.

Doze-Modus vs. App-Entwickler

Mit Android 6.0 Marshmallow hatte Google erstmals den sogenannten Doze-Modus eingeführt, der signifikant Energie im Leerlauf einsparen soll. Mit Android 7.0 Nougat wurde dieser Modus verbessert und mit Android 8.0 kommen die Hinter­grund­limitierungen hinzu. Da stellt sich natürlich die Frage, warum manche App-Entwickler versuchen, den Doze-Modus mit Nach­druck zu umgehen, worauf das Team keine Antwort lieferte.

Mit Marshmallow wollte Google jedenfalls einfach nur den Energie­verbrauch im Standby-Modus verringern und experimentierte, wie man mit Apps in diesem Zustand umgehen kann. Die gesammelten Daten flossen schließlich in den verbesserten Doze-Modus von Nougat ein und dessen Ergebnisse wiederum resultieren in den Hinter­grund­limitierungen. "Intent Broadcast" ist ein Teil davon und mit Android 8.0 werden die Möglich­keiten für Entwickler, neue Broad­casts über ihre Apps im Doze-Modus zu verwenden, erheblich eingeschränkt.

Kurz gesagt ist das Aufrufen von Hinter­grund­diensten mit einer der größten Verursacher für einen vollen RAM. Dabei werden zum Teil Dienste gestartet, die ein Nutzer gar nicht benötigt und letztlich den RAM zumüllen, den Garbage-Collector öfters laufen lassen und somit das Gerät gefühlt langsamer machen. Mit den Hinter­grund­limitierungen wird unter anderem auch dieses Verhalten von Apps ins Visier genommen und für manche unnötigen Hinter­grund­dienste kurzerhand eine entsprechende API-Schnittstelle angeboten. Ob jedoch Entwickler davon Gebrauch machen oder versuchen eine Frickel­lösung drum­herum zu finden, ist wieder eine ganz andere Frage, von den Whitelist-Implementierungen der OEM-Hersteller ganz zu schweigen.

Diane Hackborn, Android Framework Engineer bei Google, betrachtet Hinter­grund­limitierungen sogar als die radikalste Veränderung im App-Modell seit Android 1.0 und damit quasi in der kompletten Android-Geschichte.

Kernel-Updates für ältere Geräte

Nicht direkt mit Android 8.0 selbst zu tun hat die Frage, warum ältere Geräte nur selten bis überhaupt keine signifikant neueren Kernel-Versionen erhalten. Tim Urray, Technical Lead Manager für die Sicherheit von Android, erklärt es mit dem Aufwand für OEM-Hersteller. Jeder Kernel für die einzelnen Geräte respektive verwendeten Prozessoren hat seine eigene Infra­struktur zum Bauen und Chip-speziellen Treiber/Patches, was selbst sehr talentierte Kernel-Entwickler Monate kosten würde, um alle noch so kleinen Änderungen für den jeweiligen Prozessor anzupassen. Deswegen gibt es vergleichs­weise selten signifikante Kernel-Updates, die bis ins letzte Detail angepasst sind. Insbesondere das ständige Testen bei jeder kleinen Änderung am Quell­code kostet Zeit, was wiederum Unternehmen vor allem Geld kostet.

Auf der anderen Seite bringt es dem Nutzer auch vergleichs­weise wenig, wenn der Linux-Kernel zum Beispiel den Sprung von Version 3.18 auf Version 4.4 macht. Die erlebte Performance im Alltag wird sich dadurch nicht großartig verändern, so Tim Murray. Sollte es jedoch tatsächlich brauchbare Funktionen in neueren Kernel-Versionen geben, so wird Google versuchen, diese im Rahmen eines Backport best­möglich zu implementieren. Updates im Bereich der Sicherheit werden von Google hingegen ständig implementiert, sodass der Linux-Kernel in aktuellen Android-Versionen möglichst sicher vor Angreifern ist.

Schnelleres Dateisystem für Flash-Speicher

Eine durchaus interessante Frage ist, ob Google offiziell das Flash-Friendly File System kurz F2FS in absehbarer Zukunft zum Standard für Android erheben will. Die Antwort von Romain Guy, Technical Lead Manager für das Android-Grafik-Team, fällt dazu knapp aus. Kurz gesagt ist es eine viel­ver­sprechende Entwicklung, die allerdings noch im Bereich der Hardware-Verschlüsselung zu knabbern hat. Für eine Datei-basierte Verschlüsselung wie sie bei Android größten­teils zum Einsatz kommt, hat Ext4 als Datei­system noch die Nase vorn.

Allerdings zeigt sich F2FS als erheblich performanter, verglichen zu Ext4 und bietet noch andere Vorteile, da es speziell für Flash- und NAND-Speicher entwickelt wurde. Daher wird Google weiterhin mit F2FS experimentieren und es vermutlich irgendwann zum bevorzugten Datei­system machen. Bis dahin bleibt es jedoch rein optional.

In einem gesonderten Artikel klären wir Sie darüber auf, für welche Geräte mit einem Update auf Android 8.0 gerechnet werden kann.

Anzeige:
© by WhatsBroadcast

Mehr zum Thema Google Android

[Newsübersicht] RSS [Newsversand]