© Iurii Kovalenko, 123Rf

Ende Juni präsentierte Google auf seiner Hausmesse Google I/O einen Vorgeschmack auf die nächste Android-Version L. Die beerdigt Dalvik und will mit natürlich anmutendem “Material Design” gefallen.

Android ist nicht mehr gleich Android. Spätestens seit der Google I/O ist klar, dass es Android L in mehreren Varianten geben wird. Google will das riesige Android-Projekt splitten, um diverse Hardwareplattformen zu unterstützen, im 64-Bit-Zeitalter anzukommen und den unterschiedlichen Anforderungen an grafische Oberflächen zu genügen. Deshalb pflegt man in Mountain View ab sofort die folgenden fünf Zweige:

• Android für Smartphones und Tablets,
• Android One als Plattform für Provider und Low-Cost-Geräte,
• Android Wear für Smartwatches,
• Android TV für TV-Geräte,
• Android Auto für automobile Infotainment-Systeme.

Der Artikel stellt den ersten Zweig vor und wirft einen Blick auf die kommende Version Android L (siehe Kasten “Warum L?”), die wohl im Herbst 2014 den finalen Schliff erhält.

Aktuell gibt es Android L nur als Entwickler-Vorabversion (Abbildung 1) für das Nexus 5 und die Wifi-Variante des Nexus 7. Besitzer dieser Geräte können Apps für Android L entwickeln und auf echter Hardware testen. Da L jedoch auch die Grundlage für die fünf oben genannten Projekte bilden soll, treffen die meisten der hier zusammengetragenen Informationen auch auf Android Wear, One, TV sowie Auto zu.

Abbildung 1: Android L ist deutlich als Entwicklersoftware gekennzeichnet und noch nicht für den produktiven Einsatz gedacht.

Android L bringt zunächst vier zentrale Neuerungen gegenüber der aktuellen Version 4.4 (Kitkat) mit:

• Eine neue grafische Oberfläche basierend auf dem Material Design,
• ART löst Dalvik als Runtime ab,
• ein neues Benachrichtigungssystem (auch für Android Wear),
• dank Projekt Volta soll Android spürbar energieeffizienter sein.

Virtuell versus materiell

Dass es sich beim eingeführten Material Design nicht einfach um eine neue Ausgabe des von Android eingesetzten Holo-Theme handelt, erfährt der Smartphone-Nutzer auf Googles Übersichtsseite zum Design [1]. Das grafische System soll dank eigener Designsprache auf jedem Gerät und mit jeder Displaygröße funktionieren. Die Bedienung auf mobilen Geräten gehört dabei zwar zu den wichtigsten Faktoren, aber Eingaben über Touchscreens, Mikrofone, Mäuse oder Keyboards stellt Google gleichberechtigt daneben.

Das “Material” im Namen verstehen Googles Designer als Metapher: Trotz glatter Oberflächen aus Glas oder Kunststoff soll das Design für Touchgeräte, das in den Köpfen der Entwickler und Grafiker entsteht, sich an natürlichen Materialien orientieren. Die verfügen über eine raue Oberfläche, werfen Schatten und folgen physikalischen Gesetzen. Es geht darum, die grafischen Oberflächen nicht als flache UI-Elemente, sondern etwa als übereinandergelegte Holzscheiben oder Kartonplatten zu betrachten. Entwickler sollen also eine Z-Achse mitdenken.

Zweitens soll das Material Design sich an gängigen Zeitschriftenlayouts orientieren und Farben sowie spezielle Akzente bewusst so einsetzen, dass diese eine intuitive Bedienung fördern.

Der dritte Grundsatz betrifft Bewegungen und Animationen. Die sollen eine Bedeutung erhalten, und liege sie nur darin, dem Nutzer Feedback über erfolgreiche Fingertips zu geben.

Was sich auf dem Papier recht abstrakt anhört, verdeutlicht Google mit Beispielen auf seiner Design-Webseite [2], die zeigt, wie der Entwickler die Sache richtig oder falsch anpackt. Dank Material Design sollen die Benutzeroberflächen unter Android L und in allen künftigen Google-Anwendungen (Chrome OS) so natürlich wie möglich wirken (Abbildung 2), das Konzept dahinter liefert [3]. Das Ganze ist Work in Progress, bis zur Release im Herbst können sich Details ändern.

Abbildung 2: Die drei Grundprinzipien des Material Design: Material als Metapher, Magazinstil und Bewegung mit Bedeutung.

Erst ab Android L

In der Praxis könnte zurzeit nur die Entwicklerversion von Android L Anwendungen in waschechtem Material Design mitbringen, da allein sie die nötigen Programmierschnittstellen an Bord hat. Doch bislang finden Interessierte hier vornehmlich pure Kitkat-Apps von Gmail, Google Maps & Co. Allein Screenshots zeigen, wie diese in der finalen Version aussehen sollen (Abbildung 3).

Abbildung 3: So könnte wohl die Detailansicht eines Kontakts in Android L aussehen.

Und nicht nur das: Google selbst weist in seiner API-Übersicht zur Android-L-Entwicklerversion [4] darauf hin, dass man keine Apps im Play Store akzeptiere, die bereits von den neuen Möglichkeiten des Material Design Gebrauch machen. Die entsprechenden Features funktionieren selbst dann nicht unter Android 4.4 oder auf älteren Android-Versionen, wenn der Entwickler die minimale Buildversion künstlich nach unten schraubt. Apps, die er mit dem Preview-SDK, dem “API Level L”, baut, kann er nicht auf älteren Android-Versionen installieren.

Die einzige App, die eine Ausnahme davon macht (und die der Play Store auch für ältere Geräte anbietet), ist die Google I/O 2014 App [5]. Sie diente als Referenz auf Googles Hausmesse, nun steht der komplette Quellcode auf Github zum Download bereit [6]. Mit ihr machen sich Entwickler ein umfassendes Bild davon, wie sie die einzelnen Effekte später umsetzen.

Material Design für Entwickler

Wann genau Android L erscheint und wie es offiziell heißen wird, weiß nur Google. Viele rechnen mit Oktober, es kann aber auch Ende September oder erst im November so weit sein. Wer seine App bereits jetzt für die kommende Android-Version einrichten möchte, braucht zunächst die passende SDK-Version für Android L [7] und optimalerweise noch Android Studio (Abbildung 5, [8])als Entwicklungsumgebung. Letztere arbeitet am besten mit der Java Runtime von Oracle [9] zusammen, das Tool funktioniert aber auch mit Open JDK [10].

Abbildung 4: Die neue »RecyclerView« für Android L ergänzt die bisherige »ListView«-Ansicht um mehr Details.

Abbildung 5: Die Entwicklungsumgebung Android Studio arbeitet auch problemlos unter Linux.

Sind die Werkzeuge installiert, hangelt sich der Android-Entwickler zunächst durch den Abschnitt zum Material Design in der Entwicklerdokumentation [11]. Diese beschreibt nicht nur die beiden neuen Widgets »RecyclerView« (Abbildung 4) und »CardView« an Beispielen, sondern demonstriert auch die neuen Animationen und zeigt, was es mit der Z-Achse auf sich hat.

Eine weitere Seite, die konkreten Code (Abbildung 6)enthält, hostet Google auf Github [12]. Sie beleuchtet die Übergänge zwischen den Aktivitäten (»ActivitySceenTransitionBasic« ) oder verrät, wie ein Entwickler die Möglichkeiten der Z-Achse am besten nutzt (»ElevationBasic« und »ElevationDrag« ). Um das Material Design in eine bereits geschriebene App zu integrieren, genügt der in Listing 1 gezeigte Eintrag in der Datei »values/styles.xml« .

01 <resources>
02     <style name="AppTheme" parent="android:Theme.Material">
03         <!-- Customize your theme here -->
04     </style>
05 </resources>

Abbildung 6: Der kompilierte Samplecode lässt sich vom Studio aus direkt auf das Nexus 7 laden.

Eine weitere Quelle für Sample-Apps findet sich im SDK selbst, wenn der Entwickler die Checkbox bei »Samples for SDK« aktiviert. Er hat dabei zu beachten, dass die Samples mit Gradle in der Version 1.11 kompiliert sind, während sich das Android Studio aktuell Version 1.12 aus dem Netz zieht. Gibt der Buildprozess im Android Studio daher eine Fehlermeldung aus, laut der das Plugin nicht kompatibel sei, muss der Coder handgreiflich werden: Er löscht alle »*.iml« -Dateien im Sample-Verzeichnis sowie den Ordner ».idea« und ändert in der Datei »build.gradle« die Zeile mit der Gradle-Abhängigkeit von »com.android.tools.build:gradle:1.11.+« in »com.android.tools.build:gradle:1.12.+« .

Dalvik geht in Rente

Die zweite wichtige Android-L-Neuerung betrifft die zentrale Java-Runtime: Dalvik (siehe Kasten “Was ist Dalvik?”) geht in Rente, ART (Android Runtime) übernimmt die zentrale Aufgabe, Apps über Plattformen hinweg richtig flink zu machen (siehe Tabelle 1). Google hat ART so verbessert, dass die Android Runtime auf der x86-, Mips- und ARM-Architektur gleichermaßen arbeitet. Zugleich haben die Programmierer das System fit für den Sprung auf 64 Bit gemacht.

ART verwandelt den Code der in Java geschriebenen plattformunabhängigen Android-Apps in Maschinencode und macht sie so direkt lauffähig, allerdings zugeschnitten auf das Zielgerät. Diese Umwandlung passiert jedes Mal, wenn der User eine App auf dem Smartphone oder Tablet installiert. Als Compiler kommen der GNU Compiler (GCC) oder die Low Level Virtual Machine (LLVM, [13]) zum Einsatz.

Anders als Dalvik

Dalvik, Androids virtuelle Java-Runtime [14], besitzt seit Android 2.2 die spezielle Fähigkeit, Quellcode on the Fly in Maschinencode zu verwandeln. Dieses JIT-Feature (Just in Time) bringt bei einigen Apps recht hohe Geschwindigkeitsvorteile, geht aber zulasten des Hauptspeichers, da jeder Prozess, der den JIT-Compiler benötigt, rund 100 KByte Arbeitsspeicher in Beschlag nimmt. Dabei übersetzt Dalvik nicht gleich die komplette App, sondern jeweils nur den Teilbereich, den das System gerade anfordert.

Der Just-in-Time-Compiler galt 2010 als sehr fortschrittlich. Aktuell besitzen die meisten Android-Geräte allerdings so viel Power, dass es eigentlich unnötig ist, den Quellcode on the Fly zu optimieren. ART verzichtet auf dieses Feature und passt die Apps bei der Installation dem Android-System (genauer gesagt der CPU-Architektur und ihren speziellen Fähigkeiten) an.

Dieser Vorgang heißt – in Anlehnung an JIT – AOT (Ahead of Time) und verlangt deutlich mehr Rechenleistung auf dem Gerät, weil Android die komplette Anwendung übersetzt und nicht nur die benötigten Teile. Außerdem beanspruchen die Apps beim Start tendenziell mehr Arbeitsspeicher.

Vorzüge von ART

ART bringt zwei große Vorteile: Weil die JIT-Funktion wegfällt und Android die Apps beim Installieren in nativen Maschinencode übersetzt, arbeiten diese deutlich flotter (Abbildung 7). Mikrohänger – wie sie bis heute auch auf schnellen Android-Geräten vorkommen – sollten der Vergangenheit angehören.

Abbildung 7: Die neue Android Runtime (ART) schlägt Dalvik leistungsmäßig in praktisch allen Bereichen.

Die neue Android Runtime bringt Android-Apps also dank Maschinencode direkt auf die CPU/GPU, ohne die virtuelle Java-Maschine zu beanspruchen. Als Nachteil ließe sich anbringen, dass eine auf ARM optimierte App nun nicht mehr auf Android-Geräten mit Intel- oder Mips-CPU läuft. Dies war aber de facto ohnehin nicht der Fall, da kaum jemand Odex-Dateien von einem Gerät auf ein anderes kopiert, sondern üblicherweise die APK-Pakete. Die passt ART beim Installieren an das neue System an.

Wer die neue Runtime testen möchte, braucht kein Android-L-Gerät. Ein Smartphone oder Tablet mit der Android-Version 4.4 (Kitkat) genügt (Abbildung 8). Der Tester öffnet dazu die Entwicklereinstellungen, die er gegebenenfalls noch über siebenfaches Antippen der Buildnummer aktivieren muss, und wählt dann den Eintrag »Laufzeit festlegen« . Nach dem Wechsel bootet das System neu und übersetzt alle Apps. Dieser Vorgang dauert – abhängig von der Anzahl der vorinstallierten Apps – zwischen 10 und 20 Minuten.

Abbildung 8: Android 4.4 erlaubt es, die Runtime von Dalvik auf ART zu ändern.

Der Wechsel zurück auf Dalvik verläuft deutlich flotter: Hier startet das System in den gewohnten 1 bis 2 Minuten, schließlich muss Android keine Apps neu kompilieren. ART einzusetzen bereitet aktuell praktisch keine Probleme. Die meisten Entwickler haben ihre Apps seit der Release von Android 4.4 so angepasst, dass sie auch mit der neuen Runtime fehlerfrei arbeiten.

Wirklich umstellen müssen sich lediglich die ROM-Köche: Konnten sie Deodex-Dateien auf einem ROM bislang bearbeiten, um mal kurz eine Änderung auszuprobieren, ist das mit ART und OAT-Dateien nicht mehr möglich. Bei jeder Änderung müssen sie den Code neu kompilieren.

Smarte Benachrichtigungen

Als dritte Kernkomponente von Android L gelten die verbesserten Benachrichtigungen und die neue Ansicht der Schnelleinstellungen (Abbildung 9). Die Benachrichtigungsfunktion spielt ihre Stärken vor allem in Kombination mit den anderen Android-Systemen (Wear, TV und Auto) aus. Aber auch auf dem Smartphone und Tablet wird sich einiges ändern. Für Benachrichtigungen gibt es jetzt mehrere Stufen für die Sichtbarkeit: Public, Private, Secret. Ob der User also ein neues Posting bei Google Plus ohne das Entsperren des Lockscreen lesen kann, entscheidet nun nicht mehr nur die App selbst.

Abbildung 9: Google hat den Zugang zu den Benachrichtigungen und den Schnelleinstellungen deutlich überarbeitet und vereinfacht.

Des Weiteren kann der Nutzer Benachrichtigungen für einen bestimmten Zeitraum oder regelmäßig über Nacht ohne eine App von Drittanbietern deaktivieren. Android L schickt Mitteilungen zudem auf Wunsch an ein anderes Gerät, was bereits mit Android-Wear-Smartwatches und ab Version 4.4 klappt.

Schongang für den Akku

Nicht zuletzt hat Google mit Project Volta noch einmal stark am Stromverbrauch gedreht. Das Nexus 5 soll mit Android L rund 90 Minuten länger durchhalten, der Wechsel von Dalvik auf ART ebenfalls den Stromverbrauch senken. Android L schätzt beim Laden des Geräts, wie lange der Ladevorgang dauert, und errechnet beim Entladen ungefähr, wie viele Stunden und Tage verbleiben (Abbildung 10). Googles Stromsparfunktion L arbeitet dabei weniger radikal als die extremen Energiesparmodi, die Samsung, HTC oder LG (G3) einsetzen.

Abbildung 10: Android L zeigt nicht die bisherige Laufzeit an wie bei aktuellen Android-Geräten, sondern die noch zu erwartende.

Von Google selbst gibt es keine ausführliche Dokumentation, aber ein Artikel von Ron Amadeo auf Ars Technica [15] fasst die zentralen Komponenten gut zusammen. Demnach hat Google zum Beispiel festgestellt, dass die meisten Android-Geräte 2 Minuten im Stand-by-Modus bleiben, wenn der Besitzer nur kurz auf den Einschaltknopf drückt, etwa um für eine Sekunde die Uhrzeit abzulesen.

Ein neues Job-Scheduler-API erlaubt es, zeitlich unkritische Aufgaben auszuführen, wenn das Handy an der Steckdose hängt. Android L weckt nicht mehr unnötig Geräte für Netzwerkanfragen auf, obwohl kein Internet verfügbar ist. Für die meisten Neuerungen müssen Entwickler erst Gebrauchsmöglichkeiten finden, Codebeispiele liefert die Dokumentation zum Android-L-SDK [16].

Und sonst noch?

Ansonsten gibt es sehr viele Detailänderungen. Zum Beispiel findet sich nun im Teilen-Menü ein Eintrag, um Elemente via NFC (Android Beam) zu teilen, Wifi-Einstellungen lassen sich als QR-Code sichern, und Menschen mit Sehschwäche dürften sich über diverse Einstellmöglichkeiten für das Display freuen (invertierter Modus, farbenblinder Modus). Außerdem führt Google eine Sicherung gegen das Zurücksetzen auf die Werkseinstellungen ein. Wer bemerkt, dass sein Handy oder Tablet gestohlen wurde, kann so über den Android-Gerätemanager rechtzeitig das Zurücksetzen verhindern (Factory Reset Protection).

Von Samsung hat Google weite Bereiche von Knox übernommen, um das Android-System generell noch sicherer und fit für den Enterprise-Einsatz zu machen. Für mehr Sicherheit soll auch SE Linux sorgen, das bei Android L im Enforce-Modus zum Einsatz kommt [17]. Gamer dürfen sich über einen deutlich verbesserten Grafiksupport freuen. Google hat mit den Chipherstellern kooperiert, um den Android-Nutzern eine Grafik zu bieten, die es mit Direct-X 11 aufnimmt.

Ab 2015 interessant

Anhand der Entwicklerversion ist bereits jetzt zu sehen, dass Android L optisch und funktionell mehr als bloß eine Handvoll Neuerungen einführt. Wie immer stellt sich dabei für Entwickler die Frage, welche Geräte überhaupt die neue Version an Bord haben werden: Ziemlich sicher erhalten die Nexus-Geräte 4, 5 und 10 sowie das Nexus 7 (2013) sofort das Update auf Android L, vermutlich auch noch das Nexus 7 von 2012. Anschließend dürfte Motorola der erste Hersteller sein, der einigen seiner Smartphones Android L verpasst.

Für alle anderen Geräte steht die neue Version vermutlich frühestens 90 Tage nach der Veröffentlichung des Quellcodes zum Update bereit. Der Android-L-Marktanteil wird somit frühestens im Jahr 2015 von Bedeutung sein.