Jetpack — was es ist, Architekturkomponenten

Was ist Android Jetpack?

Android Jetpack ist eine Sammlung von Bibliotheken, Tools und Architekturempfehlungen von Google, die 2018 auf der Google I/O vorgestellt wurde. Jetpack ersetzte die Support Library und Android Architecture Components und führte sie zu einem einzigen Ökosystem zusammen. Vor Jetpack wurde jede Android-Bibliothek unabhängig aktualisiert, was zu Versionskonflikten führte. Jetpack synchronisierte die Versionen unter einer einzigen AndroidX-Kennung und führte ein Modell stabiler Hauptversionen mit Nebenpatches ein.

Jetpack-Bibliotheken werden in vier Kategorien unterteilt: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Jede Kategorie adressiert Aufgaben einer bestimmten Anwendungsschicht — von der Datenverwaltung bis zur Benutzeroberfläche.

Jetpack-Philosophie

Google fördert drei Jetpack-Prinzipien: accelerate development (weniger Boilerplate, mehr Geschäftslogik), eliminate boilerplate (ViewModel eliminiert manuelles Zustandsspeichern, Room eliminiert das Schreiben von SQLiteOpenHelper) und build with confidence (jede Bibliothek durchläuft vor der Veröffentlichung über 15.000 Tests). Laut Android Developers (2026) haben Apps mit Jetpack 30% weniger lebenszyklusbedingte Abstürze.

AndroidX als Grundlage

Alle Jetpack-Bibliotheken werden unter der Kennung AndroidX (Artefakte wie androidx.*) vertrieben. AndroidX ersetzte die Support Library (Artefakte wie com.android.support.*) und teilte die monolithische Bibliothek in modulare Artefakte mit unabhängiger Versionierung auf. Die Migration zu AndroidX erfolgt über die Option android.useAndroidX=true in der gradle.properties — Android Studio konvertiert die Importe automatisch.

Architekturkomponenten: ViewModel, Lifecycle, LiveData

ViewModel ist die zentrale Komponente der Jetpack-Architektur, die UI-Daten speichert. Im Gegensatz zu einer Activity, die bei Bildschirmdrehung zerstört wird, bleibt ViewModel im Speicher. Der Benutzer füllt ein Formular aus, dreht das Telefon — die Daten gehen nicht verloren. ViewModel wird automatisch gelöscht, wenn der LifecycleOwner (Activity oder Fragment) seinen Lebenszyklus endgültig beendet (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Bildschirm gestartet")
    }
}

LiveData — ein beobachtbarer Datencontainer, der den Lebenszyklus respektiert. Wenn der Bildschirm nicht sichtbar ist (onStop), sendet LiveData keine Aktualisierungen — dies verhindert Speicherlecks und Abstürze beim Versuch, eine nicht vorhandene Activity zu aktualisieren. Lifecycle — eine Klasse, die den aktuellen Zustand (CREATED, STARTED, RESUMED) speichert und anderen Komponenten ermöglicht, sich auf Zustandsänderungen zu abonnieren. Zusammen bilden ViewModel, LiveData und Lifecycle die Grundlage der reaktiven Android-Architektur.

ViewModelScope und Coroutinen

viewModelScope — ein integrierter CoroutineScope, der an den Lebenszyklus von ViewModel gebunden ist. Alle in diesem Bereich gestarteten Coroutinen werden automatisch abgebrochen, wenn ViewModel gelöscht wird. Dies eliminiert die manuelle Verwaltung von Disposable und CompositeDisposable in jedem ViewModel. Für die Arbeit mit viewModelScope ist die Abhängigkeit androidx.lifecycle:lifecycle-viewmodel-ktx erforderlich.

Room: Arbeiten mit Datenbanken auf Android

Room ist eine Jetpack-ORM-Bibliothek, die eine abstrakte Schicht über SQLite bereitstellt. Anstatt rohe SQL-Abfragen zu schreiben und Cursor manuell in Objekte zu konvertieren, deklariert der Entwickler eine Entity (Tabelle), DAO (Data Access Object) und Database (Einstiegspunkt). Room überprüft SQL-Abfragen zur Kompilierzeit über die Annotation @Query — wenn Tabellen oder Spalten nicht existieren, schlägt der Build mit einem klaren Fehler fehl.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Die Entity User beschreibt eine Tabelle mit drei Spalten. Das DAO deklariert suspend-Funktionen für die Arbeit mit Coroutinen — die Abfrage wird automatisch auf einem Hintergrundthread ausgeführt. Room unterstützt Migrationen über die Annotation @Migration: Der Entwickler beschreibt das SQL-Skript für den Übergang zwischen Versionen, und Room führt es ohne Datenverlust aus. Ohne Migration wirft Room IllegalStateException — das schützt Projekte vor versehentlichem Datenverlust bei Schemaaktualisierungen.

TypeConverter und Beziehungen

Room speichert nur primitive Typen und deren Wrapper. Zum Speichern von Listen, Date oder benutzerdefinierten Objekten wird @TypeConverter verwendet — eine statische Methode, die einen Typ in String (JSON) oder Long (timestamp) konvertiert. Beziehungen zwischen Tabellen werden über verschachtelte Objekte mit der Annotation @Relation und Hilfs-POJO-Klassen mit @Transaction für effiziente Join-Abfragen modelliert.

Navigation Component: Graphen und Argumente

Navigation Component — eine Jetpack-Bibliothek zur Verwaltung von Übergängen zwischen Bildschirmen. Anstatt manuell FragmentTransaction aufzurufen, erstellt der Entwickler einen Navigationsgraphen (XML-Datei mit Zielknoten), und das System generiert eine Directions-Klasse mit typsicheren Übergangsmethoden. Navigation Component gewährleistet die korrekte Funktion des Back Stacks, von Deep Links und der Argumentübergabe zwischen Bildschirmen.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// Im Fragment-Code:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Die Argumente userId werden im Navigationsgraphen mit Typangabe (integer) und Standardwert übergeben. Die Klasse ProfileFragmentArgs wird automatisch vom Navigation Safe Args Plugin generiert — sie enthält alle Argumente mit den korrekten Kotlin-Typen. Deep Links werden im Graphen konfiguriert: app:deepLink="app://profile/{userId}". Navigation Component analysiert die URL und erstellt den Back Stack, als ob der Benutzer durch die Oberfläche navigiert wäre.

Bottom Navigation und bedingte Navigation

Navigation Component integriert sich über NavController in BottomNavigationView: Jeder Menüpunkt wird mit einem Ziel im Graphen verknüpft. Das Wechseln zwischen Tabs erstellt das Fragment nicht neu — Navigation Component bewahrt den Zustand über NavBackStackEntry. Für bedingte Navigation (Login anzeigen, wenn nicht authentifiziert) wird navController.navigate(condition) mit einer Überprüfung in onCreate verwendet.

AndroidX: die Support Library der nächsten Generation

AndroidX ist eine neu gestaltete Architektur der Support Library, bei der jede Bibliothek ein eigenes Artefakt mit unabhängiger Version erhielt. Anstelle einer einzigen com.android.support:appcompat-v7:28.0.0 bietet AndroidX androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 und so weiter. Dadurch wurde das Problem beseitigt, dass verschiedene Abhängigkeiten unterschiedliche Versionen der Support Library anzogen und Konflikte verursachten.

Die Migration zu AndroidX erfolgt automatisch in Android Studio 3.2+ über das Menü Refactor → Migrate to AndroidX. Studio ersetzt alle Importe in Java-/Kotlin-Dateien, Manifesten und Ressourcen. Die Abwärtskompatibilität ist der Hauptvorteil von AndroidX: Die Bibliotheken funktionieren auf Android 5.0 (API 21) und höher und decken laut Google Play Console (2025) 97% der aktiven Geräte ab.

Wichtige AndroidX-Artefakte

Die am häufigsten verwendeten Artefakte: appcompat (dunkles Thema, Material Design auf alten APIs), recyclerview (adaptive Listen mit ViewHolder), constraintlayout (flexibler Container mit flacher Hierarchie), cardview (Material Design-Karten), preference (Einstellungsbildschirm mit Material-Stil). Jedes Artefakt wird unabhängig versioniert, was die Bereitstellung von Korrekturen beschleunigt, ohne das gesamte Paket aktualisieren zu müssen.

Weitere wichtige Jetpack-Bibliotheken

Neben Architecture und AndroidX enthält Jetpack viele spezialisierte Bibliotheken für typische mobile Entwicklungsaufgaben. WorkManager — für Hintergrundaufgaben mit garantierter Ausführung (Synchronisation, Log-Upload), unterstützt periodische und verzögerte Aufgaben sowie Netzwerk- und Batterieeinschränkungen. DataStore — ein Ersatz für SharedPreferences basierend auf Coroutinen, der typisierte Eigenschaften (Preferences DataStore) und Protocol Buffers (Proto DataStore) unterstützt.

• Hilt — ein Dagger-basiertes DI-Framework, das die Abhängigkeitsinjektion durch die Annotationen @HiltViewModel, @Inject, @Module vereinfacht. Integrierte Integration mit ViewModel und Navigation.
• Paging 3 — eine Bibliothek für paginierte Datenladung aus Netzwerk/DB mit Unterstützung für RemoteMediator (Netzwerk + Cache), StateFlow und Compose.
• CameraX — eine API für die Arbeit mit der Kamera, die Herstellerunterschiede (Samsung, Xiaomi, Honor) über eine einheitliche CameraController-Schnittstelle abstrahiert.
• Security Crypto — Datenverschlüsselung über EncryptedSharedPreferences und EncryptedFile basierend auf AES-256 mit einem Masterschlüssel im Android Keystore.

Jede Bibliothek hat ihr eigenes minimales SDK und Artefakt. Google veröffentlicht Hauptversionen einmal jährlich (zeitgleich mit dem Android-Release) und Sicherheitspatches vierteljährlich. Empfehlung — nur die benötigten Bibliotheken einbinden, um die APK-Größe nicht zu erhöhen. Die gesamte Jetpack-Sammlung (alle Artefakte) wiegt über 20 MB, aber eine typische App verwendet 5–7 Bibliotheken und fügt 3–5 MB zur APK hinzu.