Dein erster App-Start ist ein Triumph – bis das Logcat in Flammen steht. Willkommen im Android-Dschungel.
Es beginnt immer gleich: Du sitzt vor deinem Rechner, die Finger kribbeln, das Android Studio ist frisch installiert. Vielleicht hast du eben noch ein Tutorial auf YouTube geschaut, in dem jemand mit irritierend ruhiger Stimme versichert, dass „Mobile Development ganz einfach ist“. Vielleicht trägst du sogar eine Entwicklerbrille, obwohl du gar keine brauchst. Heute wird dein Tag.
Du klickst auf „New Project“. Du fühlst dich wie ein Architekt, der gerade ein Hochhaus plant. Du nennst das Projekt „MyFirstApp“, weil du insgeheim weißt: Es wird auch deine Letzte sein. Du wählst eine leere Activity, klickst dich durch die nächsten Dialoge, die so klingen, als wären sie aus einem dystopischen Gesellschaftsspiel entnommen: „Minimum SDK?“, „Use legacy support libraries?“ – Was auch immer das bedeutet, denkst du, und klickst einfach auf „Next“.

Dann der große Moment: Finish.
Dein Bildschirm friert kurz ein. Die Lüfter deines Laptops heulen auf, als würde er versuchen, aus dem Fenster zu fliegen. Und dann erscheint sie, diese wunderschöne, klinisch sterile Benutzeroberfläche: Das Projekt. Dein Baby. Das Hello World.
Du klickst auf den grünen Play-Button. Und dann passiert… nichts.
Erst nach einer Ewigkeit erscheint der Emulator. Zumindest theoretisch. Praktisch handelt es sich um ein graues Rechteck, das aussieht, als hätte jemand ein altes Nokia-Handy aus dem Jahr 2002 in einen Bildschirmschoner verwandelt. Du wartest. Und wartest. Und wartest. Nebenbei googelst du: „Emulator Android slow fix“ – 7.290.000 Ergebnisse. Beruhigend.
Doch plötzlich tut sich etwas. Ein Bildschirm. Ein Ladevorgang. Und dann: “Hello World”. Es steht da, weiß auf grau, wie eine Grußkarte aus der Hölle. Du hast es geschafft. Du bist offiziell Android-Entwickler.
Für exakt 1,7 Sekunden.

Dann schließt sich die App. Einfach so. Kein Fehlerdialog, keine Warnung. Nur ein kurzer Moment der Hoffnung – und dann: Stille.
Du öffnest das Logcat. Ein Textstrom prasselt auf dich ein, schneller als du lesen kannst.
Wörter wie E/AndroidRuntime, FATAL EXCEPTION, NullPointerException und java.lang.something.horrifying. Dein Bildschirm sieht aus wie ein Manifest des Untergangs. Und irgendwo mittendrin: dein Projektname. Wie ein Schuldiger, der sich nicht rechtzeitig verstecken konnte.
Du suchst nach der Ursache. Eine TextView, die eigentlich gar nicht existiert. Eine Activity, die nie wirklich geboren wurde. Vielleicht hast du auch versehentlich ein Komma gelöscht. Oder Android hat einfach beschlossen, heute keine Apps mehr auszuführen. Es passiert.
Du versuchst es erneut. Und wieder. Und wieder. Jede neue Fehlermeldung ist wie ein Schlag ins Gesicht – manchmal mit dem Handrücken, manchmal mit einem Ziegelstein.
Du gehst zurück ins XML-Layout. Du hattest dort nichts verändert, aber vielleicht – nur vielleicht – liegt genau dort das Problem. Du fügst ein android:layout_margin=”8dp” ein. Kein Unterschied. Du entfernst es. Jetzt crasht die App schneller.
Du erinnerst dich an einen Forenbeitrag, der sagte: „Wenn alles schiefgeht, mach ein Clean und Rebuild.“ Du folgst diesem Rat.
Android Studio denkt drei Minuten nach. Dann passiert… nichts. Wieder.
Du versuchst, das Projekt zu „Invalidate Caches / Restart“. Der Button klingt so, als könnte er dein Betriebssystem aus dem 21. Jahrhundert befördern. Du klickst trotzdem.

Der Rechner startet neu. Android Studio lädt. Dein Projekt ist noch da. Immerhin.
Du öffnest das MainActivity.kt. Du verstehst kein Wort. Woher kommen all diese onCreate()s und setContentView()s? Warum braucht man so viele Klammern? Du bist sicher, dass Kotlin schöner sein sollte als Java. Aber gerade fühlt es sich eher an wie ein Sudoku in kyrillischer Schrift.
Du versuchst, das „Hello World“ zu ändern. Vielleicht zu „Hallo, Android!“. Ein kleiner Schritt für den Code, ein großer Schritt für deinen Stolz. Du klickst erneut auf „Run“.
„App has stopped.“
Diesmal gibt es wenigstens eine Benachrichtigung. Android zeigt dir gnädig den Fehler an. Du klickst auf „App info“, dann auf „Force Stop“. Du bist jetzt selbst Android-Administrator. Du kontrollierst Dinge. Zumindest theoretisch.
Du versuchst, die App zu deinstallieren. Der Emulator friert ein. Du frierst innerlich mit.
Dein Kaffee ist kalt. Du bist nicht mal sicher, wann du das letzte Mal geblinzelt hast.

Und dann denkst du plötzlich: „Warum mache ich das überhaupt?“ Du könntest etwas Einfacheres machen. Eine Website bauen. Excel-Makros schreiben. Romane tippen. Aber nein – du hast dich für Android entschieden. Weil du naiv warst. Weil du geglaubt hast, ein Betriebssystem, das auf Kühlschränken läuft, sei auch für dich geeignet.
Aber du gibst nicht auf. Du atmest tief durch. Du löscht dein Projekt. Du erstellst ein neues. Diesmal nennst du es „TryAgainApp“. Der Emulator startet schneller. Das Layout sieht besser aus. Du hast gelernt.
Und dann, ein kleines Wunder: Die App läuft. Kein Crash. Kein Stacktrace. Kein Fluch.
Ein weißes „Hallo, Android!“ auf schwarzem Grund.

Du fühlst dich wie ein Held. Ein Überlebender. Ein Krieger im Kampf gegen NullPointerException. Du weißt, es war nur der Anfang. Der erste Schritt in einem langen, dunklen Tal voller Abgründe namens FragmentManager, RecyclerView, und – Gott bewahre – Jetpack Compose.
Aber du hast „Hello World“ gemeistert. Und du bist nicht gestorben.
Noch nicht.
Über das Buch „Schöner sterben mit Android“
Ein satirischer Ratgeber für alle, die mutig genug sind, Android-Apps zu entwickeln – und dabei regelmäßig an Emulatoren, Lifecycles und Gradle zerbrechen. Mit bitterem Humor und liebevollem Spott schildert das Buch die kleinen Katastrophen des Entwickleralltags. Ideal für alle, die beim Debuggen lieber lachen als weinen wollen. Die Kapitel und Inhalte dieses Buches wurden mit der Unterstützung von KI erstellt.
Um das nächste Kapitel nicht zu verpassen, abonniere den Newsletter, oder schau auf meinem YouTube Kanal vorbei, um die Podcast-Variante nebenbei zu hören.