Android Platform Overview: Wo deine App im System lebt

Bevor du dich in Compose, Coroutines oder Architecture Components stürzt, lohnt sich ein Schritt zurück: Wo genau lebt deine App eigentlich? Android ist nicht nur ein Framework, das du importierst, sondern ein komplettes Betriebssystem mit klaren Schichten, Regeln und Grenzen. Wenn du verstehst, wie diese Schichten zusammenspielen, wirst du Fehlermeldungen, Performance-Probleme und Lifecycle-Verhalten viel schneller einordnen können. Dieser Artikel gibt dir das mentale Modell, das du brauchst, bevor wir in den nächsten Roadmap-Themen tiefer in einzelne APIs einsteigen.

Was ist das?

Android ist ein quelloffenes Betriebssystem, das auf einem Linux-Kernel aufsetzt und speziell für mobile Geräte, Tablets, Wearables, Fernseher und Autos entwickelt wurde. Es besteht aus mehreren übereinanderliegenden Schichten, und deine App ist nur die oberste davon. Ganz unten liegt der Linux-Kernel, der sich um Speicher, Prozesse, Treiber und Sicherheit kümmert. Darüber sitzt die Hardware Abstraction Layer (HAL), die dem System einheitliche Schnittstellen zu Kamera, Sensoren, Bluetooth oder GPS liefert, egal welcher Hersteller das Gerät gebaut hat. Es folgen native C/C++-Bibliotheken wie SQLite, OpenGL oder Skia, dazu die Android Runtime (ART), die deinen kompilierten Kotlin- oder Java-Code ausführt. Erst darüber liegt das eigentliche Android-Framework mit den APIs, mit denen du als Entwickler arbeitest, und ganz oben deine App.

Wichtig ist die Einordnung: Eine Android-App ist kein klassisches Desktop-Programm mit einer einzigen main()-Funktion. Sie ist eine Sammlung von Komponenten, die das System bei Bedarf startet und beendet. Du gibst dem Framework also nicht Befehle, sondern reagierst auf die Lebenszyklen, die es dir vorgibt. Diese Umkehrung der Kontrolle, oft Inversion of Control genannt, ist der Kern dessen, was Android-Entwicklung von normaler Anwendungsentwicklung unterscheidet. Das Framework ruft dich, nicht umgekehrt.

Wie funktioniert es?

Wenn du deine App installierst, packt das System sie in ein eigenes Sandbox-Verzeichnis und vergibt eine eindeutige Linux-User-ID. Dadurch ist deine App auf Betriebssystemebene komplett von anderen Apps isoliert: Sie kann ohne explizite Berechtigung weder deren Daten lesen noch deren Prozesse beeinflussen. Beim Start erzeugt Android einen Linux-Prozess, in dem eine eigene Instanz der ART läuft. ART führt deinen Code aus, der vorab beim Installieren in ein optimiertes Format kompiliert wurde (AOT-Compilation), und ergänzt zur Laufzeit Just-in-Time-Optimierungen.

Das Android-Framework stellt dir vier zentrale Komponententypen zur Verfügung, die du in der Datei AndroidManifest.xml deklarierst. Eine Activity repräsentiert einen Bildschirm mit Benutzeroberfläche, etwa die Liste deiner Lieblingsrezepte. Ein Service läuft im Hintergrund, zum Beispiel um Musik abzuspielen oder Daten zu synchronisieren. Ein BroadcastReceiver reagiert auf systemweite Ereignisse wie „Gerät gebootet” oder „Akku schwach”. Ein ContentProvider stellt strukturierte Daten anderen Apps oder Systembereichen zur Verfügung, etwa deine Kontakte. Jede dieser Komponenten ist ein Einstiegspunkt, den das System unabhängig starten kann, oft ausgelöst durch einen Intent, eine Nachricht, die beschreibt, was passieren soll.

Über all dem schwebt das Konzept des Lifecycle. Activities und auch Compose-Screens durchlaufen Zustände wie onCreate, onStart, onResume, onPause und onDestroy. Das System ruft diese Methoden auf, wenn der Nutzer die App wechselt, das Gerät dreht oder Speicher knapp wird. Du musst dich darauf einstellen, dass dein Prozess jederzeit beendet werden kann, sobald deine App in den Hintergrund wandert. Genau dafür gibt es die Architecture Components: ViewModel überlebt Konfigurationsänderungen, SavedStateHandle rettet Zustand über Prozesstode hinweg, Lifecycle macht den aktuellen Zustand beobachtbar, und WorkManager plant Aufgaben, die auch dann laufen sollen, wenn deine App längst beendet ist. All das funktioniert nur, weil das Framework strenge Regeln vorgibt, an die sich deine App halten muss.

Ein weiterer wichtiger Baustein sind Permissions. Möchte deine App auf Kamera, Standort oder Kontakte zugreifen, musst du das im Manifest anmelden und zur Laufzeit eine Erlaubnis vom Nutzer einholen. Das System erzwingt diese Grenzen, du kannst sie nicht umgehen. Für Daten, Dateien und Netzwerk gilt dasselbe Prinzip: Scoped Storage, Network Security Config und der Berechtigungsdialog sind keine Schikane, sondern Sicherheitsmechanismen, die dich vor versehentlichen Datenschutzfehlern schützen.

In der Praxis

Im Alltag merkst du die Plattform vor allem dort, wo das Framework dein Verhalten steuert. Ein klassisches Beispiel: Du startest in einer Activity einen Netzwerk-Request, der Nutzer dreht das Gerät, die Activity wird zerstört und neu erzeugt. Ohne ViewModel beginnt der Request von vorn, deine Daten gehen verloren, der Nutzer sieht einen leeren Bildschirm. Die Plattform-konforme Lösung sieht so aus:

class RecipeViewModel : ViewModel() {
    private val _uiState = MutableStateFlow<UiState>(UiState.Loading)
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()

    init {
        viewModelScope.launch {
            _uiState.value = try {
                UiState.Success(repository.loadRecipes())
            } catch (e: IOException) {
                UiState.Error(e.message ?: "Unbekannter Fehler")
            }
        }
    }
}

@Composable
fun RecipeScreen(viewModel: RecipeViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()
    when (val current = state) {
        is UiState.Loading -> CircularProgressIndicator()
        is UiState.Success -> RecipeList(current.recipes)
        is UiState.Error -> ErrorMessage(current.message)
    }
}

Das ViewModel überlebt die Konfigurationsänderung, der viewModelScope bricht laufende Coroutines automatisch ab, sobald das ViewModel endgültig zerstört wird, und collectAsStateWithLifecycle sorgt dafür, dass die UI nur dann sammelt, wenn sie sichtbar ist. Du arbeitest also mit der Plattform statt gegen sie.

Eine typische Stolperfalle für Einsteiger ist der Versuch, App-Zustand in statischen Variablen oder Singletons abzulegen, ohne das Lebenszyklus-Modell zu beachten. Das funktioniert auf dem Emulator scheinbar gut, bricht aber sofort, sobald Android deinen Prozess im Hintergrund beendet, um Speicher freizugeben. Beim nächsten Start startet das System deine App wieder bei der zuletzt sichtbaren Activity und erwartet, dass du den Zustand wiederherstellst. Wenn du dich nur auf statische Felder verlassen hast, sind diese leer und deine App wirkt kaputt. Die Regel lautet: Behandle deinen Prozess als jederzeit zerstörbar. Persistiere wichtige Daten in einer Datenbank wie Room, lege UI-Zustand in ViewModel plus SavedStateHandle ab, und plane langlaufende Arbeit über WorkManager, nicht über einen handgebauten Background-Thread.

Eine zweite häufige Falle: Berechtigungen werden vergessen oder erst dann angefragt, wenn der Nutzer eine Funktion bereits angeklickt hat und der Code mit einer SecurityException abstürzt. Plane Berechtigungen früh ein, erkläre dem Nutzer im Voraus, wofür du sie brauchst, und baue immer einen Fallback ein, falls er ablehnt. Das Framework gibt dir mit ActivityResultContracts.RequestPermission einen sauberen Weg dafür.

Wenn du diese Mechaniken im Alltag einübst, kannst du dein Verständnis aktiv prüfen: Aktiviere in den Entwickleroptionen „Aktivitäten nicht behalten”, drehe das Gerät, schicke deine App in den Hintergrund und schau, ob der Zustand sauber zurückkommt. Schreibe Unit-Tests für deine ViewModels und Instrumented-Tests für den Lifecycle. Beobachte Logcat während eines Konfigurationswechsels und sieh, in welcher Reihenfolge onPause, onStop und onDestroy aufgerufen werden. So wird die Plattform vom abstrakten Schichtmodell zu etwas, das du wirklich greifen kannst.

Fazit

Android ist mehr als nur eine Sammlung von APIs: Es ist ein Betriebssystem mit klaren Schichten, das deinen Code in einer Sandbox laufen lässt, Lifecycle und Speicher kontrolliert und dir saubere Bausteine für Activities, Services, Receiver und Provider gibt. Wenn du dieses Modell verinnerlicht hast, wirst du Architekturentscheidungen bewusster treffen, Crashes leichter deuten und neue Jetpack-Bibliotheken schneller einordnen. Nimm dir jetzt eine kleine bestehende App vor, öffne ihre AndroidManifest.xml und finde heraus, welche Komponenten sie nutzt, welche Berechtigungen sie verlangt und wie ihr Lifecycle aussieht. Provoziere bewusst einen Konfigurationswechsel, beobachte den Logcat und prüfe im Debugger, wann dein ViewModel zerstört wird. Wer einmal selbst gesehen hat, wie das System eingreift, vergisst nie wieder, dass die Plattform mitspielt.