Dein erstes Android-Projekt: Template, Package Name und App-Modul verstehen

Wenn du Android Studio zum ersten Mal öffnest und ein neues Projekt anlegst, fühlt sich das schnell überwältigend an. Du siehst Dropdowns für Templates, ein Feld für den Package Name, eine Auswahl der minimalen API-Version und eine Sprache, die schon auf Kotlin steht. Direkt danach erzeugt die IDE Dutzende Dateien und Ordner, von denen du auf den ersten Blick keinen einzigen brauchst. Genau hier setzt dieser Artikel an: Du lernst, was beim ersten Projekt wirklich zählt, welche drei Begriffe du verstehen musst und welche Dateien dein Einstiegspunkt sind.

Was ist das?

Ein Android-Projekt ist die strukturierte Sammlung aller Dateien, die Android Studio braucht, um aus deinem Code eine installierbare App zu machen. Das umfasst deinen Kotlin-Code, Layout- und Bildressourcen, Konfigurationsdateien für den Gradle-Build und das AndroidManifest, das dem System mitteilt, wie deine App heißt, welche Komponenten sie hat und welche Berechtigungen sie braucht.

Drei Begriffe tauchen schon im Anlegen-Dialog auf und begleiten dich durch deine gesamte Karriere als Android-Entwickler. Das Template ist die Vorlage, die Android Studio nimmt, um die ersten Dateien zu erzeugen. Es entscheidet, ob du mit einer leeren Activity, einer Tab-Navigation oder einer Karten-Ansicht startest. Der Package Name ist die eindeutige ID deiner App, etwa de.androidcoden.meinerstes. Diese ID identifiziert deine App im Play Store, im Dateisystem des Geräts und im System-Log. Sie lässt sich nach der Veröffentlichung praktisch nicht mehr ändern. Das App-Modul ist der Ordner app/, in dem dein eigentlicher App-Code liegt. Ein Modul ist die kleinste Einheit, die Gradle für sich allein bauen kann, und in deinem ersten Projekt gibt es genau eines: das App-Modul.

Diese drei Begriffe gehören zusammen, weil sie die Grundannahmen deines Projekts festlegen. Das Template entscheidet über die Startstruktur, der Package Name über die Identität und das App-Modul über den Aufbau. Wer das versteht, liest jede neue Android-Codebase deutlich schneller.

Wie funktioniert es?

Wenn du im Dialog New Project auf Empty Activity klickst, kopiert Android Studio eine Vorlage aus seinem internen Template-Repository in dein Zielverzeichnis und ersetzt Platzhalter durch die Werte, die du eingegeben hast. Aus ${packageName} wird zum Beispiel de.androidcoden.meinerstes, aus ${applicationName} wird der Name deiner App. Anschließend startet Gradle einen ersten Sync, lädt fehlende Abhängigkeiten und erzeugt die Build-Konfiguration.

Das Ergebnis hat immer denselben groben Aufbau. Auf der obersten Ebene findest du die Dateien settings.gradle.kts, build.gradle.kts (Projekt-Ebene), gradle.properties und den gradle/-Ordner mit dem Wrapper. Diese Dateien gehören zum Projekt als Ganzes. Daneben liegt der Ordner app/, dein App-Modul. Darin steckt nochmal eine build.gradle.kts-Datei, diesmal auf Modul-Ebene. Sie definiert, welche Plugins genutzt werden, welche compileSdk- und minSdk-Versionen gelten, wie der applicationId heißt und welche Bibliotheken eingebunden sind. Die applicationId ist standardmäßig identisch mit deinem Package Name, kann aber unabhängig davon gesetzt werden — wichtig zu wissen, sobald du verschiedene Build-Varianten brauchst.

Innerhalb von app/src/main/ findest du drei Schlüsselbereiche. Der Ordner java/ (auch wenn du Kotlin schreibst, heißt er so) enthält deinen Quellcode, organisiert nach deinem Package Name. Hier liegt die MainActivity.kt, der Einstiegspunkt deiner App. Der Ordner res/ enthält Ressourcen wie Strings, Farben, Themes und Drawables. Direkt darüber liegt die AndroidManifest.xml. Diese Datei ist die offizielle Beschreibung deiner App gegenüber dem Android-System: Welche Activities gibt es, welche davon ist die Launcher-Activity, welche Berechtigungen werden verlangt, welches Theme gilt? Ohne korrekten Eintrag im Manifest taucht eine Activity nicht auf und lässt sich nicht starten.

Der Package Name lebt an mehreren Stellen gleichzeitig. Er ist der Ordnerpfad unter java/, er steht als namespace in der Modul-build.gradle.kts, und er bestimmt die applicationId. Wenn du diese drei Stellen gedanklich verknüpfst, verstehst du, warum eine spätere Umbenennung so unangenehm ist: Du musst Code, Build-Konfiguration und Veröffentlichungs-Identität gleichzeitig anfassen.

Welche Dateien du zuerst öffnest

Wenn du ein frisches Projekt vor dir hast, öffne in dieser Reihenfolge: erst MainActivity.kt, dann AndroidManifest.xml, dann die Modul-build.gradle.kts. So siehst du Code, Konfiguration und Build-Setup in einem logischen Fluss. Den Rest darfst du beim ersten Durchgang ignorieren.

In der Praxis

Ein typisches erstes Projekt mit dem Template Empty Activity und Compose hat eine MainActivity.kt, die etwa so aussieht:

package de.androidcoden.meinerstes

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.material3.Surface
import androidx.compose.material3.Text
import de.androidcoden.meinerstes.ui.theme.MeinErstesTheme

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MeinErstesTheme {
                Surface {
                    Text("Hallo Android")
                }
            }
        }
    }
}

Der Package-Name am Anfang spiegelt deinen Ordnerpfad wider. ComponentActivity ist die moderne Basisklasse für Compose-Apps. setContent { ... } ist der Punkt, an dem dein Compose-UI an die Activity gehängt wird. Im AndroidManifest.xml steht dieselbe Activity nochmal als <activity>-Eintrag mit einem <intent-filter>, der MAIN und LAUNCHER deklariert — genau dieser Filter macht die Activity zum Startpunkt im App-Drawer.

Für den Package Name gilt eine einfache Entscheidungsregel: Verwende eine umgedrehte Domain, die du tatsächlich besitzt oder kontrollierst. Wenn deine Domain androidcoden.de ist, beginnt der Package mit de.androidcoden. Danach hängst du den App-Namen an, also etwa de.androidcoden.taskliste. Verwende keine generischen Präfixe wie com.example, sobald du mehr als nur experimentierst — der Play Store akzeptiert com.example.* nicht für Veröffentlichungen, und du musst sonst später migrieren.

Die typische Stolperfalle für Einsteiger ist, den Package Name nachträglich „mal eben” ändern zu wollen. Du klickst im Project-Panel auf den Ordner, drückst F6, und schon hast du Code-Pfade umgestellt. Aber: Die applicationId in der build.gradle.kts und der namespace-Eintrag bleiben dabei oft auf dem alten Wert. Das Projekt baut weiter, aber im Play Store gilt nach wie vor die alte ID. Wenn du eine App schon veröffentlicht hast, ist die applicationId unveränderlich — eine neue ID ist im Store eine komplett neue App, ohne Updates und ohne Bewertungen. Lege dich also vor dem ersten Veröffentlichen fest und prüfe nach jeder Umbenennung in der Modul-build.gradle.kts, ob namespace und applicationId noch stimmen.

Ein zweites Detail, das früh wichtig wird: Im Anlegen-Dialog stellst du die Minimum SDK ein. Dieser Wert legt fest, ab welcher Android-Version deine App installierbar ist. API 24 (Android 7.0) deckt heute weit über 95 % aller aktiven Geräte ab und ist eine gute Default-Wahl. Wählst du zu hoch, schließt du Geräte aus; zu niedrig, und du musst dich mit alten APIs herumschlagen, die du gar nicht brauchst. Das Template trägt deinen Wert in die Modul-build.gradle.kts als minSdk ein.

Und dann gibt es noch eine ganz banale Sache, die viele übersehen: Lass das Projekt direkt nach dem Anlegen einmal komplett bauen und auf dem Emulator laufen, bevor du irgendeine Zeile Code änderst. Wenn du erst eine Stunde lang Code schreibst und dann der Build wegen eines unabhängigen Konfigurationsproblems scheitert, weißt du nicht, ob dein Code oder dein Setup schuld ist. Ein sauberer „Hallo-Welt”-Lauf vorab schützt dich vor genau dieser Verwirrung.

Fazit

Dein erstes Android-Projekt ist weniger ein Code-Problem als ein Strukturproblem. Wenn du verstanden hast, dass das Template nur die Startvorlage ist, der Package Name die dauerhafte Identität deiner App im Play Store festlegt und das App-Modul der Container für deinen Code, deine Ressourcen und deine Build-Konfiguration ist, hast du das geistige Gerüst, an dem du alles Weitere aufhängen kannst. Lege jetzt selbst ein neues Projekt mit Empty Activity an, vergib einen Package Name nach dem Domain-Schema, lass den Build durchlaufen und öffne danach MainActivity.kt, AndroidManifest.xml und die Modul-build.gradle.kts nacheinander. Lies, ohne zu ändern, und finde die Stellen, an denen dein Package Name auftaucht. Wenn du die drei Vorkommen sicher zeigen kannst, bist du bereit für den nächsten Schritt im Roadmap-Pfad.