1.2    Systemarchitektur 

Vielleicht fragen Sie sich, was das Wort Plattform im Zusammenhang mit Android bedeutet. Handelt es sich nicht einfach um ein Betriebssystem für mobile Geräte, für das Sie Programme in Java oder Kotlin schreiben?

1.2.1    Überblick 

Aus der Sicht des Endanwenders bildet Android eine mittlerweile sehr große Gruppe von mobilen und stationären Geräten, beispielsweise Smartphones, Tablets, Medienabspielgeräten, TV-Settop-Boxen und Armbanduhren. Zahlreiche Hersteller bieten Modelle in unterschiedlichsten Ausstattungsvarianten an. Neben preisgünstigen Einsteigerprodukten finden sich im Hochpreissegment Geräte mit viel Arbeitsspeicher, großen, auflösungsstarken Bildschirmen und hoher Prozessorleistung. Auf all solchen Produkten können Versionen von Android laufen. Dennoch ist Android nicht nur ein Betriebssystem, weil zu Android standardmäßig noch mehr gehört, beispielsweise ein Anwendungsstarter mit Unterstützung für Widgets, eine Kontaktdatenbank, eine Uhr mit Weckfunktion, ein Browser und ein E-Mail-Client. Und natürlich der Play Store zum Kaufen und Herunterladen von Apps.

Android und Java

Ebenfalls ein Bestandteil von Android, allerdings für den Endanwender nicht sichtbar, ist die Laufzeitumgebung ART (Android Runtime). Sie bildet den Rahmen für die Ausführung aller Programme, die der Benutzer auf einem Android-System startet. Dies betrifft die weiter oben genannten Standardanwendungen, aber auch selbst geschriebene Programme, von denen die meisten in Java entwickelt wurden. Wenn Sie mit dieser Technologie bereits Erfahrung haben, fragen Sie sich vielleicht, ob Android für die Ausführung der Programme dann nicht eine virtuelle Maschine enthalten müsste, denn schließlich wird Java-Code üblicherweise in Bytecode umgewandelt.

Android hatte von der ersten Version an eine virtuelle Maschine an Bord. Allerdings hat diese Dalvik genannte Komponente nie den Bytecode verstanden, der vom Standard-Java-Compiler erzeugt wird, weil Dalvik seinen eigenen Befehlssatz hat. Auch die registerbasierte Architektur weicht von einer klassischen Java Virtual Machine ab, die einen Kellerautomaten realisiert. Dennoch war javac lange Zeit der erste Schritt vom Quelltext hin zur ausführbaren App. Der erzeugte Bytecode wurde von dem Tool dx in ein Dalvik Executable (.dex) genanntes Format umgewandelt, das von Dalvik verstanden wird. Hierin liegt der Hauptgrund, warum Android-Entwickler immer recht lange auf die Nutzung neuer Java-Sprachfeatures in ihren Apps warten mussten. Beispielsweise führten die beliebten Lambda-Ausdrücke zu neuen Konstrukten im Bytecode, die dx kennen und zu sinnvollen Dalvik-Anweisungen umformen musste.

Dalvik wurde erst mit Android 5 vollständig abgelöst. Schon in Android 4.4 war der Nachfolger ART enthalten und konnte auf Wunsch aktiviert werden. Seit Android 5, Lollipop, werden Apps schon während der Installation in Maschinensprache übersetzt. Android Nougat allerdings stellte ART wieder einen Just-in-time-Compiler zur Seite (Dalvik besaß zeitweise auch einen). Dieser nutzt Code Profiling, um das Laufzeitverhalten einer App kontinuierlich zu verbessern. Hierzu wird mithilfe von Profilen entschieden, wann welche Teile des Codes übersetzt werden: Schlüsselfunktionen einer App werden so schnell wie möglich abgearbeitet.

Eine Zeit lang hat Google eine andere Strategie bei der Umwandlung von Java-Quellcode in .dex-Dateien verfolgt. An die Stelle von javac und dx trat der neue Compiler Jack. Mit ihm kam der sehnlichst erwartete Support für eine ganze Reihe von Java-8-Sprachfeatures, unter anderem für Lambda-Ausdrücke, Methodenreferenzen und Typannotationen. Diese waren sogar unter älteren Android-Versionen nutzbar, Default- und statische Interface-Methoden sowie wiederholbare Annotationen hingegen nur ab API-Level 24. Jack musste in der Datei build.gradle aktiviert werden. Unglücklicherweise ließen sich Tools von Drittanbietern nicht gut in die neue Toolkette integrieren. Mit Android Studio 3 wurde Jack deshalb abgelöst.

Erweiterungen der Syntax waren aber nur ein Teil der Neuerungen von Java 8. Auch die Standardklassenbibliothek hat eine Vielzahl neuer Pakete und Klassen erhalten, unter anderem java.util.stream und java.util.function. Dass diese auch unter Android verwendet werden können, hat mit einem fundamentalen Wechsel zu tun: Bis einschließlich Android 6 basierte die Klassenbibliothek der Plattform in weiten Teilen auf Code des Open-Source-Projekts Apache Harmony der Apache Software Foundation. Ziel dieses im Mai 2005 angekündigten und im November 2011 beendeten Projekts war die Schaffung einer frei verfügbaren, quelloffenen Java-Implementierung einschließlich Compiler und virtueller Maschine. Die Notwendigkeit hierfür ist schon frühzeitig, nämlich mit der Veröffentlichung von Java als Open Source Ende 2006, entfallen. Daher hat Harmony für Android nie große Bedeutung erlangt – außer eben durch die Nutzung seiner Klassenbibliothek durch Android.

Harmony war als Implementierung von Java 5 und 6 gedacht. Konsequenterweise fehlen alle Klassen und Pakete, die Sun und Oracle erst mit späteren Java-Versionen hinzugefügt haben. Google hatte zwar an einigen Stellen »nachgebessert«. Für die Nutzung des Java-7-Features try-with-resources ist beispielsweise das Interface java.lang.AutoCloseable nötig, das seit API-Level 19 enthalten ist. Andere Neuigkeiten hingegen wurden nie übernommen. Ab Android 7 wird deshalb die Bibliothek des OpenJDK verwendet.

Kotlin

Seit Android Studio 3.0 (2017) mussten Apps nicht mehr zwingend in Java geschrieben werden. Die Entwicklungsumgebung bot ab dieser Version offiziell Unterstützung für die Programmiersprache Kotlin. Diese wurde nicht speziell für Android entwickelt. Vielmehr hat sie den Anspruch, eine moderne, schlanke Alternative zu Java zu sein. Erfinder der Sprache ist die in Sankt Petersburg ansässige Firma JetBrains. Von ihr stammt auch die Basis von Android Studio, IntelliJ IDEA. Auf seiner Entwicklerkonferenz I/O 2019 hatte Google bekannt gegeben, dass Kotlin die primäre Sprache für die Android-App-Entwicklung werden soll. Seitdem wurde viel Arbeit in die Anpassung der vorhandenen Programmierschnittstellen und Bibliotheken an die modernen Sprachfeatures gesteckt. Vereinfacht ausgedrückt geht in Kotlin vieles eleganter und einfacher als mit Java.

Auch wenn man weiterhin Apps in Java schreiben kann, sollten neue Projekte auf jeden Fall mit Kotlin realisiert werden. Dieses Buch trägt dem Rechnung. Alle Beispiele sind in dieser Programmiersprache geschrieben. Falls Sie noch keinen Kontakt zu Kotlin hatten, empfehle ich eine Einführung in Kotlin als begleitende Lektüre. Anhang A stellt Ihnen die wichtigsten Konzepte und Sprachkonstrukte kompakt vor. Buch-Vorschläge entnehmen Sie bitte der Literaturliste in Anhang D.

Schichten

Das Fundament der in Abbildung 1.1 dargestellten Low-Level-Systemarchitektur von Android[ 3 ](https://source.android.com/devices/architecture) bildet ein Linux-Kern. Er kümmert sich um die Prozesssteuerung, die Speicherverwaltung, die Netzwerkkommunikation sowie um das Thema Sicherheit. Die Peripherie (Audio, Kamera, Kommunikation etc.) ist über entsprechende Kerneltreiber angebunden. Über diesem Fundament liegt eine Hardwareabstraktionsschicht (engl. Hardware Abstraction Layer, HAL). Sie wird von Android-Systemdiensten beim Zugriff auf die Gerätetreiberschicht aufgerufen und kapselt gerätespezifische Implementierungen.

Abbildung 1.1    Schematische Darstellung der Systemarchitektur

Systemdienste fungieren als Bindeglieder zwischen der Framework-Schicht und der Hardware. Android kennt zwei Gruppen von Systemdiensten, System und Media. Beispielsweise kümmert sich der Activity Manager um die Verwaltung von Activities, einem der zentralen Anwendungsbausteine. Der Camera Service koordiniert Zugriffe auf die Kamerahardware.

Binder IPC ist ein leichtgewichtiges Kommunikationsmittel über Prozessgrenzen hinweg. Die Framework-Schicht verwendet es, um mit Systemdiensten zu kommunizieren, und auch die Nutzung durch Anwendungen ist möglich und sinnvoll. Anwendungen kommunizieren mit dem System ausschließlich über die im folgenden Abschnitt vorgestellte Framework-Schicht.

1.2.2    Application Framework 

Mithilfe des Application Frameworks lassen sich äußerst komfortable, ästhetische und leicht bedienbare mobile Anwendungen mit großem Funktionsumfang erstellen. Sie haben Zugriff auf die Gerätehardware, zum Beispiel Kamera, Netzwerk und Sensoren, und auch das Lesen und Schreiben von Kontaktdaten oder Terminen ist bequem möglich. Ein ausgefeiltes, einfach zu handhabendes Rechtesystem steuert hierbei, was ein Programm tun darf. Leider fordern viele Apps nach wie vor zu viele Berechtigungen an. Dies erzeugt Unmut bei den Benutzern, weil sie sich ausspioniert und beobachtet fühlen. Versuchen Sie deshalb bitte, Ihre Apps zu fokussieren. Es ist nachvollziehbar, dass eine Kameraanwendung Zugriff auf die passende Hardware haben muss. Aber braucht ein Taschenrechner eine Standortbestimmung oder Zugriff auf das Telefonbuch?

Eines der Kernkonzepte des Application Frameworks ist, dass Anwendungen ihre Funktionen veröffentlichen, also anderen Programmen verfügbar machen können. Da Anwendungen von Drittanbietern den Android-Standardanwendungen gleichgestellt sind, kann der Benutzer sehr leicht den Webbrowser, den E-Mail-Client oder den Mediaplayer austauschen. Auch das Ersetzen von einzelnen Programmfunktionen (beispielsweise das Verfassen einer SMS) ist möglich. Selbstverständlich können Programme umgekehrt auch Funktionen anderer Anwendungen anfordern. Auch dies wird über das bereits erwähnte Rechtesystem gesteuert.

Kernbestandteile des Application Frameworks sind unter anderem:

• Views: Sie bilden die Basis für alle Benutzeroberflächen. Android bietet zahlreiche Standardbedienelemente, wie etwa Textfelder, Schaltflächen, Ankreuzfelder und Listen. Bestehende Views können durch sogenannte Themes und Styles nahezu beliebig angepasst werden. Auch vollständig eigenentwickelte Views sind realisierbar.

• Content Provider: Sie gestatten Anwendungen den Zugriff auf Daten anderer Programme. Auch das Bereitstellen der eigenen Anwendungsdaten ist auf diese Weise leicht möglich.

• Resource Manager: Er gewährt Zugriff auf lokalisierte Zeichenketten, auf Grafiken und auf Layoutdateien.

• Notification Manager: Er bietet Anwendungen den Zugriff auf die Android-Statuszeile. Mit ihm können auch kleine Pop-up-Nachrichten erzeugt werden.

• Activity Manager: Er steuert den Lebenszyklus einer Anwendung.

Alle hier aufgeführten Bestandteile werden in den folgenden Kapiteln ausführlich vorgestellt.

1.2.3    AndroidX und Jetpack 

Vor allem in den frühen Jahren sind unzählig viele Geräte mit Android auf den Markt gekommen. Deren Hersteller haben sich mit dem Update auf neue Versionen aber immer schwergetan. Und selbst heute dauert es oft mehrere Monate, bis ein Gerät aktualisiert wird. Die Folge war, dass es sehr lange gedauert hat, bis neue Features von den Entwicklern auch wirklich verwendet wurden. Gerade im Bereich Sicherheit ist das natürlich eigentlich eine Katastrophe. Aber verständlich. Denn um die Funktion einer App auf neuen und alten Geräten sicherzustellen, musste man mit aufwendigen und fehleranfälligen if-Abfragen prüfen, ob das Smartphone oder Tablet die gewünschte API überhaupt anbietet.

Google hat deshalb schon 2011 begonnen, Kompatibilitätsbibliotheken zur Verfügung zu stellen. Der Entwickler nutzt deren Klassen und Methoden, statt direkt die Android-API zu nutzen. Ist ein Feature (beispielsweise Fragmente oder Laufzeit-Berechtigungen) in einer Plattform-Version vorhanden, wird deren Implementierung genutzt, sonst ein möglichst kompatibler Nachbau. Eigentlich also eine sehr gute Idee. Unglücklicherweise hat Google bei der Namensgebung der Bibliotheken immer mal wieder geschludert: Für Entwickler war oft nicht klar, wann welche Version verwendet werden musste.

Das auf Googles Hausmesse I/O 2018 vorgestellte AndroidX ist sozusagen ein Neustart dieses Konzepts, ein sogenanntes Refactoring. Alle Bibliotheken folgen nun einer einheitlichen Namensgebung, sind semantisch versioniert und unabhängig voneinander aktualisierbar. Kombiniert mit Nutzungsempfehlungen (Best Practices) und (Architektur-)Dokumentation wird daraus Jetpack – wenn Sie so möchten, ein Marketingname. Jetpack-Komponenten lassen sich grob in vier Gruppen einteilen:

1. Foundation enthält unter anderem Android KTX (Sprachunterstützung für Kotlin) und AppCompat (Support unterschiedlicher Plattform-Versionen).

2. Architecture beinhaltet beispielsweise WorkManager (Hintergrundverarbeitung) und Data Binding.

3. Behavior bietet unter anderem CameraX (eine vereinfachte Schnittstelle zu Kameras), Notifications, Permissions und Preferences (Einstellungsseiten für Apps).

4. UI schließlich enthält unter anderem Fragment und Layout.

Außer den genannten Komponenten gibt es eine ganze Reihe weiterer. Im Gegensatz zu den alten Support-Bibliotheken bietet Jetpack also deutlich mehr Features und ist viel mehr als nur ein Satz an Kompatibilitätsbibliotheken. Aber bedeutet dies, dass Sie sich um Plattformfunktionen überhaupt nicht mehr kümmern müssen? In der Tat stehen Sie als Entwickler vor der Entscheidung, entweder direkt auf die Plattform zuzugreifen (und dann ggf. Versionsweichen einzubauen) oder stattdessen die Komponenten von Jetpack zu nutzen.

Die Verwendung von externen Komponenten ist immer mit Aufwand verbunden – und sei es nur ein erhöhter Pflegeaufwand für die Datei build.gradle. Hinzu kommt, dass Google Jetpack viel regelmäßiger aktualisiert als die Plattform. Nicht selten ändert sich dabei die API. In so einem Fall haben Sie nur die Wahl, mitzuziehen oder zunächst auf einem dann alten Bibliotheksstand zu verharren und die Änderungen später nachzuholen. Je länger Sie warten, umso umfangreicher können die Anpassungen ausfallen. Besonders deutlich zeigt sich dies bei Jetpack Compose. Diese Bibliothek wird, wenn sie stabil ist, den Bau von Oberflächen unter Android radikal verändern. Einen Vorgeschmack darauf gebe ich Ihnen in Anhang B. Noch kann ich deren Einsatz nicht mit gutem Gewissen empfehlen.

Meiner Ansicht nach ist für ein Verständnis von Jetpack das Wissen um die korrespondierenden nativen APIs zwingend erforderlich. Im weiteren Verlauf dieses Buches werden Sie deshalb beide Welten ausführlich kennenlernen. Im nächsten Abschnitt möchte ich Sie mit den Entwicklungswerkzeugen bekannt machen. Wie Sie bald sehen werden, sorgen diese für eine komfortable und effiziente Programmierarbeit.