Die Sprache ist schnell gelernt, die Plattform nicht
Lebenszyklus, Prozesstod und begrenzte Hintergrundarbeit entscheiden darüber, ob deine App auf tausend verschiedenen Geräten stabil bleibt oder nur auf deinem.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Auf deinem Gerät läuft alles, im Feld nicht
Android verteilt sich über sehr viele Hersteller, Geräteklassen und Systemfassungen. Dazu kommen herstellereigene Eingriffe in die Energieverwaltung, die Hintergrundarbeit stärker beschneiden als das System selbst. Eine App, die auf einem aktuellen Gerät mit viel Speicher entwickelt wurde, verhält sich auf einem drei Jahre alten Modell mit knappem Speicher anders, und zwar nicht nur langsamer.
Der häufigste Grund für Abstürze ist nicht die Sprache, sondern der Umgang mit dem Lebenszyklus. Ein Bildschirm wird bei einer Drehung, bei einem Sprachwechsel oder bei Speicherdruck neu erzeugt, und der Prozess kann im Hintergrund vollständig beendet werden. Wer den Zustand im Bildschirm hält, verliert ihn an dieser Stelle, und das äußert sich als leere Ansicht, doppelte Anfrage oder Absturz beim Zurückkehren.
Sichtbar wird das erst nach der Veröffentlichung, wenn Absturzberichte aus dem Feld eintreffen. Bis dahin hat niemand im Team den Fehler gesehen, weil er von einer Kombination aus Gerät, Systemfassung und Zeitpunkt abhängt. Genau deshalb ist die Struktur einer Android-App keine Geschmacksfrage.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Weg in sechs Schritten
Die Schritte vier und fünf sind der Teil, den Einsteiger überspringen und der später jeden Absturzbericht erklärt. Nimm sie ernst, bevor die App wächst.
- 1
Kotlin lernen, auch wenn du Java kannst
Nullsicherheit im Typsystem, Datenklassen, versiegelte Typen für Zustände, Erweiterungsfunktionen. Wer aus Java kommt, schreibt am Anfang Java in Kotlin-Schreibweise und verschenkt genau die Mittel, die Fehler vermeiden. Google hat Kotlin seit Jahren zur bevorzugten Sprache für Android erklärt, im Bestand triffst du Java trotzdem.
Geschafft, wenn: du modellierst einen Ladezustand als versiegelten Typ statt mit drei Wahrheitswerten
- 2
Eine erste App auf ein echtes Gerät bringen
Projektaufbau, Gradle, Berechtigungen im Manifest, Signatur für den Test, Installation auf dem eigenen Telefon. Dieser Schritt ist unspektakulär und der häufigste Abbruchpunkt, weil die Werkzeugkette am Anfang mehr Zeit kostet als der Code.
Geschafft, wenn: deine App startet auf deinem eigenen Gerät, nicht nur im Emulator
- 3
Oberflächen mit Compose beschreiben
Ansichten ergeben sich aus dem Zustand, und Zustand gehört nicht in die Ansicht. Bau eine Liste mit Nachladen, eine Detailansicht und ein Formular mit Prüfung der Eingaben. Im Bestand triffst du daneben weiterhin auf Oberflächen aus XML-Layouts, beides läuft in derselben App nebeneinander.
Geschafft, wenn: eine Zustandsänderung zeichnet genau den Teil neu, der sich geändert hat
- 4
Den Lebenszyklus in die Struktur einbauen
Halte den Zustand in einem Anzeigemodell, das eine Neuerzeugung des Bildschirms übersteht, und sichere das Nötige zusätzlich für den Fall, dass das System den Prozess beendet. Dreh das Gerät und schick die App in den Hintergrund, bis das System sie abräumt, und sieh nach, was danach fehlt.
Geschafft, wenn: nach Drehung und Rückkehr steht die App an derselben Stelle
- 5
Nebenläufigkeit mit Koroutinen
Netzaufrufe und Datenbankzugriffe laufen im Hintergrund, das Ergebnis kommt im Hauptstrang an. Binde jede Aufgabe an einen Gültigkeitsbereich, damit sie abgebrochen wird, wenn der Bildschirm verschwindet. Für Arbeit, die auch ohne geöffnete App laufen soll, gibt es einen eigenen Weg, denn das System und die Hersteller beschneiden freie Hintergrundprozesse.
Geschafft, wenn: kein Aufruf schreibt mehr in einen Bildschirm, den es nicht mehr gibt
- 6
Schneiden, testen, veröffentlichen
Trenn Oberfläche, Anwendungsfälle und Datenzugriff, damit die Logik ohne Gerät prüfbar wird. Prüf auf mehreren Geräteklassen und Systemfassungen. Für den Play Store gilt außerdem, dass neue Fassungen ein aktuelles Ziel-API-Level angeben müssen, und diese Grenze zieht Google jedes Jahr nach.
Geschafft, wenn: die Logik läuft im Test ohne Emulator, und die Auslieferung wird angenommen
Sechs Stufen von der ersten App zur stabilen Anwendung
- 01 Kotlin mit Nullsicherheit und Datenklassen lernen.
- 02 Eine erste App vom leeren Projekt auf ein echtes Gerät bringen.
- 03 Oberflächen mit Compose aus dem Zustand heraus beschreiben.
- 04 Zustand so ablegen, dass er den Lebenszyklus übersteht.
- 05 Hintergrundarbeit mit Koroutinen sauber starten und abbrechen.
- 06 In Schichten schneiden und auf verschiedenen Geräten prüfen.
Was du am Ende dieses Wegs kannst
Der Weg ist kurz beschrieben und in der Umsetzung anspruchsvoll: Sprache, Oberfläche, Struktur, Nebenläufigkeit. Die Reihenfolge lohnt sich, weil jeder Schritt den nächsten erklärt.
Kotlin mit seinen Stärken
Du arbeitest mit Nullsicherheit, Datenklassen, versiegelten Typen und Erweiterungsfunktionen und weißt, warum diese Mittel in einer App weniger Fehlerquellen lassen als die frühere Java-Schreibweise.
Oberflächen aus dem Zustand
Du beschreibst Ansichten mit Compose, hältst den Zustand außerhalb der Ansicht und erkennst, warum eine Ansicht zu oft oder gar nicht neu gezeichnet wird.
Den Lebenszyklus einplanen
Du legst den Zustand dorthin, wo er eine Neuerzeugung des Bildschirms übersteht, und weißt, was beim Beenden des Prozesses im Hintergrund verlorengeht und wie du es wiederherstellst.
Nebenläufig arbeiten
Du startest Hintergrundarbeit mit Koroutinen im passenden Gültigkeitsbereich, brichst sie ab, wenn niemand mehr auf das Ergebnis wartet, und blockierst nie den Hauptstrang.
In Schichten schneiden
Du trennst Oberfläche, Anwendungsfälle und Datenquellen so, dass die Logik ohne Gerät getestet werden kann und ein Wechsel der Schnittstelle nicht durch die ganze App wandert.
Auf Vielfalt prüfen
Du testest auf verschiedenen Geräteklassen und Systemfassungen, liest Absturzberichte aus dem Feld und kennst die Wirkung herstellereigener Energiesparfunktionen auf Hintergrundarbeit.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was den Alltag ausmacht, und was Leute falsch erwarten
Erwartet wird das Gestalten von Bildschirmen. Der Alltag besteht zu großen Teilen aus dem Umgang mit Unsicherheit: Das Netz ist weg, die Anmeldung abgelaufen, der Nutzer hat eine Berechtigung verweigert, das System hat die App im Hintergrund beendet, ein Hersteller hat die Hintergrundarbeit gestoppt. Für jeden dieser Fälle braucht es eine bewusste Antwort in der App.
Ein zweiter Teil ist die Auswertung dessen, was im Feld passiert. Absturzberichte kommen mit Gerät, Systemfassung und Stelle im Code, und die Muster darin sind die eigentliche Fehlerquelle. Wer sie regelmäßig durchgeht, findet Zusammenhänge, die im eigenen Test nie auftreten, etwa eine bestimmte Hersteller-Oberfläche oder eine sehr große Schriftgröße.
Unterschätzt wird der Aufwand für Berechtigungen und Datenschutz. Standort, Kamera, Benachrichtigungen und Zugriff auf Dateien werden zur Laufzeit erfragt, und die Anforderungen an die Erklärung dieser Zugriffe sind über die Jahre gestiegen. Das ist kein Nebenthema, sondern ein Grund, aus dem Auslieferungen abgelehnt werden.
Der Weg hinein, und was im Gespräch zählt
Die Einstiege kommen fast immer aus einer anderen Entwicklungsrichtung, häufig aus Java, aus dem Web oder aus einem Studium mit Programmieranteil. Die Ausstattung ist niedriger als bei iOS: Ein Rechner mit genug Speicher und ein Testgerät reichen, und die Anmeldung als Entwickler im Play Store ist eine einmalige Gebühr statt einer jährlichen.
Zertifikate gibt es für Android, sie sind aber deutlich weniger verbreitet als etwa im Testbereich, und in Ausschreibungen wird selten danach gefragt. Was zählt, ist eine App, deren Code jemand ansehen kann, und die Fähigkeit, deren Aufbau zu begründen: Wo liegt der Zustand, warum dort, und was passiert, wenn das System den Prozess beendet.
Nützlich ist ein Blick auf die Bestandsseite. Sehr viele Firmen-Apps sind älter als Compose, teilweise älter als Kotlin, und der Einstieg besteht darin, in einem solchen Projekt neue Teile daneben zu setzen. Wer im Gespräch sagen kann, wie beide Oberflächenwelten in einer App zusammenlaufen, hebt sich von Bewerbungen ab, die nur das neueste Vorgehen kennen.
Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden
Der erste Unterschied ist der Zustand. Die eine hält ihn an einer Stelle und leitet die Oberfläche daraus ab, der andere verteilt ihn über Bildschirme und Hilfsklassen. Nach einem Jahr hat die eine eine App, in der ein neuer Bildschirm zwei Tage kostet, und der andere eine, in der jede Änderung an drei Stellen Wirkung zeigt.
Der zweite ist der Umgang mit Nebenläufigkeit. Wer jede Hintergrundaufgabe an einen Gültigkeitsbereich bindet, hat keine Aufrufe, die in verschwundene Bildschirme schreiben, und keine doppelten Anfragen nach einer Drehung. Das ist erlernbar und wird in Kursen selten so deutlich gemacht, wie es der Alltag verlangt.
Der dritte ist die Bereitschaft, auf schlechten Geräten zu prüfen. Ein altes Testgerät mit wenig Speicher und einer älteren Systemfassung findet in einer Stunde mehr Fehler als eine Woche Prüfung auf dem aktuellen Modell. Wer eines im Schreibtisch hat und regelmäßig benutzt, liefert stabilere Fassungen aus.
Wohin die Rolle führt
Drei Richtungen sind üblich. Die Vertiefung in die Plattform, also Hintergrundverarbeitung, Sensorik, Verbindungen zu Geräten und Anwendungen außerhalb des Telefons, etwa auf Fahrzeugsystemen oder Kassen. Die Verbreiterung auf beide mobilen Systeme. Und der Weg in Richtung Architektur, sobald mehrere Apps eines Hauses gemeinsame Bausteine brauchen.
Eine vierte Möglichkeit entsteht dort, wo Android nicht auf Telefonen läuft: in Fahrzeugen, an Kassensystemen, auf Steuerungen und Anzeigen im industriellen Umfeld. Diese Stellen verlangen zusätzlich Verständnis für die Geräte selbst und liegen näher an der eingebetteten Entwicklung als an der klassischen App.
Zur Zahl weiter unten: Das Anforderungsniveau Spezialist beschreibt den Zuschnitt der Stelle und nicht deine Berufsjahre. Es sind Bruttomonatswerte in Vollzeit ohne Sonderzahlungen, dein Jahresverdienst liegt mit Weihnachts- und Urlaubsgeld also über dem Zwölffachen. Nimm dabei den Median als Vergleichsgröße, weil wenige sehr hohe Verdienste den Durchschnitt anheben.
Dazu passende Kurse
Wenn dich die Werkzeugkette am Anfang aufhält, helfen Kurse, in denen du deine erste App vom leeren Projekt bis zum Gerät bringst .
Die amtlichen Zahlen zu dieser Rolle
Für App-Entwicklung führt die amtliche Statistik keine eigene Berufsgattung, weshalb hier dieselbe Zelle steht wie bei fast allen Entwicklungsrollen. In dieser Zelle stecken damit auch Backend-, Web- und Fachanwendungsentwicklung, und ein Unterschied zwischen Android und anderen Spezialisierungen ist darin nicht erkennbar. Das Anforderungsniveau Spezialist beschreibt außerdem den Zuschnitt der Stelle und nicht deine Berufserfahrung, ein Wechsel nach fünf Jahren führt also nicht automatisch in eine andere Zeile.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43413, Durchschnitt 6.238 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Muss ich Java können, bevor ich Kotlin lerne?
Compose oder XML-Layouts lernen?
Wie gehe ich mit der Gerätevielfalt um?
Lohnt sich ein plattformübergreifender Ansatz statt Android pur?
Passt thematisch dazu
Wer eine App in Schichten trennt, arbeitet mit einem festen Vorrat an Lösungen, und es hilft zu wissen, welche Muster hinter einem Schichtenschnitt stecken .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Struktur entscheidet, ob die App im Feld hält
Bei cmt gehst du von Kotlin über Compose bis zum Schnitt einer App und siehst dabei, welche Fehler der Lebenszyklus verzeiht und welche nicht.