Google plaudert über Details zu Android 8.0, Teil 2
Google hat wahrlich viel zu erzählen zu Android 8.0 und Android im Allgemeinen
Logos: Google, Grafik/Montage: teltarif.de
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 Schwachstellen, was Google mit SafetyNet und Root-Nutzern vor hat - oder auch nicht - und warum eine Themes-Engine eine solch große Herausforderung darstellt.
Allerdings ist das nur ein Bruchteil dessen gewesen, worüber die Entwickler von Google gesprochen haben. Es gibt noch einiges mehr das von Interesse ist, aber wegen Platzgründen im letzten Artikel nicht mehr untergekommen ist.
Optik vs. AMOLED
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 vergleichsweise wenige Hersteller AMOLED-Displays in ihren Geräten, darunter Google mit den aktuellen Pixel-Modellen. Nun standen die Entwickler vor der Frage, ob die Navigationsleiste nicht auch in denselben Farben wie die Statusleiste erstrahlen sollte. Gerade mit Blick auf OLED/AMOLED bedarf es einer wohlüberlegten Entscheidung, um nicht leichtfertig eingebrannte Pixel zu riskieren.
Dieser Punkt und der Fakt, dass zu viele Farben hinter den Displaytasten zu sehr ablenken von der eigentlichen App, hat dazu geführt, dass die Navigationsleiste kurzerhand schwarz bleibt. Zumal nicht jede App die Statusleiste einfärbt, was wiederum gegen die Lösung spricht, die Navigations- an die Statusleiste anzupassen. Die Gefahr eines Burn-Ins einzelner Pixel, im schlimmsten Fall sogar mit Farbverlauf, 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öglichkeit wäre, die Navigationsleiste 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 Grafikarbeit bedeutet, da das komplette System einschließlich Ökosystem angepasst werden müsste. Eine Arbeit, die einfach zu aufwendig ist - auch wenn ein zeitgesteuerter Wechsel der Material-Design-Oberfläche googleintern eine sehr beliebte Spielerei war.
Unterm Strich bedarf es tiefgreifender Veränderungen in diversen Kern-Komponenten von Android und dem App-Framework, sodass weder die Themes-Engine noch ein einfacher Dark-Modus offiziell Bestandteil 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 Hintergrundlimitierungen hinzu. Da stellt sich natürlich die Frage, warum manche App-Entwickler versuchen, den Doze-Modus mit Nachdruck zu umgehen, worauf das Team keine Antwort lieferte.
Mit Marshmallow wollte Google jedenfalls einfach nur den Energieverbrauch 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 Hintergrundlimitierungen. "Intent Broadcast" ist ein Teil davon und mit Android 8.0 werden die Möglichkeiten für Entwickler, neue Broadcasts über ihre Apps im Doze-Modus zu verwenden, erheblich eingeschränkt.
Kurz gesagt ist das Aufrufen von Hintergrunddiensten 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 Hintergrundlimitierungen wird unter anderem auch dieses Verhalten von Apps ins Visier genommen und für manche unnötigen Hintergrunddienste kurzerhand eine entsprechende API-Schnittstelle angeboten. Ob jedoch Entwickler davon Gebrauch machen oder versuchen eine Frickellösung drumherum 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 Hintergrundlimitierungen 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 Infrastruktur 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 vergleichsweise selten signifikante Kernel-Updates, die bis ins letzte Detail angepasst sind. Insbesondere das ständige Testen bei jeder kleinen Änderung am Quellcode kostet Zeit, was wiederum Unternehmen vor allem Geld kostet.
Auf der anderen Seite bringt es dem Nutzer auch vergleichsweise 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 bestmö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 vielversprechende 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ößtenteils zum Einsatz kommt, hat Ext4 als Dateisystem 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 Dateisystem 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.