Minimal Reproduction: Bugs auf das Wesentliche reduzieren

Ein Bug, der „irgendwo in der App” auftaucht, ist schwer zu fixen. Ein Bug, der in fünfzig Zeilen Kotlin reproduzierbar ist, fast immer leicht. Genau dafür gibt es die Minimal Reproduction: Du reduzierst ein Problem so weit, dass nur noch das Nötigste übrig bleibt, was den Fehler zuverlässig auslöst. Diese Disziplin trennt erfahrene Android-Entwickler oft von Einsteigern – und sie ist eine Fähigkeit, die du bewusst trainieren kannst.

Was ist das?

Eine Minimal Reproduction (kurz „Repro” oder „MRE”, minimal reproducible example) ist das kleinstmögliche Beispiel, das einen Bug verlässlich zeigt. „Minimal” heißt: jede Zeile, die du weglassen könntest, ohne den Fehler zu verlieren, ist weg. „Reproducible” heißt: der Fehler tritt nicht zufällig auf, sondern bei klar definierten Schritten immer wieder.

Im Android-Kontext bedeutet das mehr als nur „weniger Code”. Eine gute Repro klammert auch das Drumherum sauber ein: Welches API-Level? Welches Gerät oder welcher Emulator? Welche Compose-Version? Welche Konfiguration in build.gradle.kts? Wenn ein Bug nur unter Android 13 auf einem Pixel auftritt, gehört diese Information zur Repro genauso wie der Code selbst.

Du wirst Minimal Reproductions an drei typischen Stellen brauchen: beim eigenen Debugging, wenn du in einem komplexen Projekt einen Fehler einkreisen willst; beim Melden von Bugs an Bibliotheks-Maintainer oder das Android-Team; und in Code-Reviews, wenn jemand fragt: „Kannst du mir zeigen, wann genau das schiefgeht?”. In allen drei Fällen ist die Repro die gemeinsame Sprache, mit der du und andere über das Problem reden.

Wie funktioniert es?

Hinter dem Begriff steckt ein simples mentales Modell: Halbieren, prüfen, wiederholen. Du startest mit einem Stück Code, in dem der Bug auftritt, und entfernst systematisch alles, was den Fehler nicht beeinflusst. Bleibt der Fehler bestehen, war der entfernte Teil unschuldig. Verschwindet er, hast du eine Spur. Das ist im Prinzip dieselbe Idee wie eine binäre Suche, nur eben angewandt auf deinen eigenen Code.

In der Praxis arbeitest du auf mehreren Ebenen gleichzeitig:

Code-Ebene

Du löschst Composables, ViewModels, Repository-Schichten, Dependency-Injection-Module – alles, was nicht direkt am Bug beteiligt ist. Häufig stellt sich dabei heraus, dass das Problem gar nicht in der Schicht liegt, in der du es vermutet hast. Compose-Recompositions, die du dem ViewModel angelastet hattest, entpuppen sich als Folge eines instabilen remember-Schlüssels. Ein Crash im Repository ist eigentlich ein Threading-Problem im aufrufenden Coroutine-Scope.

Daten-Ebene

Realistische Daten sind oft Ballast. Tausch Listen mit hundert Einträgen gegen drei aus. Ersetze Netzwerk-Antworten durch hartkodierte Strings. Wenn der Bug verschwindet, sobald du echte Daten weglässt, hast du einen Hinweis darauf, wo du genauer hinschauen musst – etwa auf eine bestimmte Eingabekombination.

Umgebungs-Ebene

Manche Bugs sind an Konfiguration gebunden: ProGuard/R8, bestimmte Build-Varianten, eine spezielle Compose-BOM, ein neuer AGP-Release. Wenn dein Code auf debug läuft, aber release crasht, gehört diese Differenz zur Repro. Hier hilft dir die offizielle Doku zu Application Fundamentals und Quality, die typische Stolperstellen rund um Lebenszyklus, Konfiguration und Release-Builds beschreibt.

Lebenszyklus-Ebene

Android-Bugs hängen oft am Activity- oder Composable-Lebenszyklus: Rotation, Prozess-Tod, Hintergrund-Wiederaufnahme, SavedStateHandle. Eine Repro, die diese Übergänge gezielt provoziert (etwa per „Don’t keep activities” in den Entwickleroptionen), ist Gold wert, weil sie zeigt, dass der Fehler nicht zufällig ist, sondern an einem bestimmten Übergang hängt.

Wichtig ist die Reihenfolge: Erst sicherstellen, dass du den Bug überhaupt zuverlässig auslösen kannst – also Schritte aufschreiben, ein-, zweimal nachvollziehen –, dann erst mit dem Reduzieren beginnen. Wer ohne stabile Wiederholung anfängt zu kürzen, jagt ein Phantom.

In der Praxis

Stell dir vor, dein Compose-Screen zeigt nach jedem Tab-Wechsel kurz die alten Daten der vorherigen Detailansicht, bevor die neuen geladen sind. In der echten App hängt das an Navigation, ViewModel-Scopes, einem Flow aus dem Repository und einem LaunchedEffect. Bevor du in dieser Komplexität herumstocherst, baust du eine Repro.

Ein typischer Repro-Composable könnte so klein sein:

@Composable
fun RepoScreen(id: String) {
    val state by produceState<String?>(initialValue = null, key1 = id) {
        value = null
        delay(300)
        value = "Daten für $id"
    }

    Column(Modifier.padding(16.dp)) {
        Text(text = state ?: "Lade ...")
    }
}

@Composable
fun RepoDemo() {
    var id by remember { mutableStateOf("A") }
    Column {
        Row {
            Button(onClick = { id = "A" }) { Text("A") }
            Button(onClick = { id = "B" }) { Text("B") }
        }
        RepoScreen(id = id)
    }
}

Das ist kein Produktionscode – und genau das ist der Punkt. Es gibt keine Navigation, kein Hilt, kein Repository, keine echte API. Trotzdem reicht es, um zu prüfen, ob das Problem wirklich am Übergang zwischen zwei IDs hängt oder doch woanders. Wenn der Bug hier auftritt, weißt du: das Muster „state hängt am Key, aber wird beim Wechsel nicht sofort zurückgesetzt” ist die eigentliche Wurzel. Wenn er nicht auftritt, weißt du: irgendetwas in deiner App-Architektur (Navigation, DI, Caching) macht den Unterschied – und du kannst gezielt einen Layer nach dem anderen wieder hinzunehmen, bis der Bug zurückkommt.

Eine konkrete Entscheidungsregel, die dir hilft: Wenn deine Repro länger als ein Bildschirm Code ist, ist sie noch nicht minimal. Streiche so lange, bis du sie ohne Scrollen vollständig siehst. Das ist eine grobe Faustregel, aber sie zwingt dich zur Disziplin.

Typische Stolperfallen

• Du reduzierst Code, aber nicht den Zustand. Eine Repro mit drei Composables, die aber noch eine 500-Zeilen-Datenklasse aus deinem Projekt zieht, ist nicht minimal. Bau die Datenklasse nach – mit zwei oder drei Feldern.
• Du behältst Bibliotheken, die nichts beitragen. Hilt, Room, Retrofit, Koin – wenn der Bug auch ohne sie auftritt, raus damit. Jede Abhängigkeit, die du in der Repro lässt, ist eine, die jemand anders auch verstehen muss.
• Du vergisst die Umgebung zu dokumentieren. Eine Repro ohne Angabe von Compile-SDK, Compose-Version, Geräte-API und Build-Typ ist halb so viel wert. Schreib es daneben.
• Du reduzierst, bis der Bug verschwindet, und stoppst dort. Klassischer Fehler: Du löschst eine Zeile, der Bug ist weg, du atmest auf – und hast den Fehler nie wirklich verstanden. Geh einen Schritt zurück und prüfe, warum genau diese Zeile den Unterschied macht.
• Du arbeitest direkt im Hauptprojekt. Spring lieber in ein leeres Projekt oder ein Compose-Preview-Modul. Dort gibt es keinen alten Cache, keine ProGuard-Regeln, keine versteckten Initializer, die deine Beobachtung verzerren.

Bewährt hat sich, eine Minimal Reproduction immer in Verbindung mit einem Test zu denken. Sobald du den Bug klein genug eingegrenzt hast, lässt er sich oft direkt in einen Unit-Test oder einen Compose-UI-Test gießen. Damit wird aus einem einmaligen Debug-Erlebnis ein bleibender Schutz: Die Android Testing Fundamentals beschreiben, wie du solche Tests in dein Build integrierst, sodass derselbe Fehler nie wieder unbemerkt zurückkehrt.

Im Release-Kontext schließt sich der Kreis: Bevor du einen Hotfix über einen Play-Release-Track ausspielst, willst du eine saubere Repro haben. Sonst weißt du nicht, ob du wirklich die Ursache behoben hast oder nur das Symptom verschoben. Die internen und geschlossenen Test-Tracks von Google Play sind genau dafür gedacht – aber sie sind nur so gut wie die Repro, mit der du dort prüfst.

Fazit

Minimal Reproduction ist keine Technik, die du einmal lernst und abhakst. Sie ist eine Denkweise: Bei jedem Bug fragst du dich „Was ist das kleinste Beispiel, mit dem ich diesen Fehler zeigen kann?”. Wer das verinnerlicht, debuggt nicht mehr durch Raten, sondern durch systematisches Eingrenzen – und schreibt dabei oft die Tests, die den Bug für immer fernhalten. Nimm dir beim nächsten Bug bewusst Zeit, eine Repro zu bauen, bevor du am Code drehst. Lade sie in ein leeres Projekt, lass sie auf einem zweiten Gerät laufen, zeig sie einer Kollegin im Code-Review. Wenn die Person ohne Vorwissen versteht, was kaputt ist, hast du es richtig gemacht – und du wirst merken, wie viel ruhiger du danach an den eigentlichen Fix herangehst.