Projektstruktur-Tour: Wo dein Android-Code wirklich lebt

Wenn du ein neues Android-Projekt in Android Studio öffnest, wirkt der Verzeichnisbaum links zunächst überladen. Dabei folgt jeder Ordner einem festen Zweck. Sobald du die Struktur einmal durchschaut hast, findest du jede Datei in Sekunden — und du verstehst, warum der Build-Prozess so abläuft, wie er es tut. Diese Tour zeigt dir die wichtigsten Stationen.

Was ist das?

Die Projektstruktur eines Android-Projekts ist die feste Verzeichnis-Konvention, nach der Android Studio und das Build-System Gradle deinen Code, deine Ressourcen, dein Manifest und deine Tests organisieren. Sie ist kein Stilvorschlag, sondern eine harte Regel: Gradle erwartet bestimmte Dateien an bestimmten Orten. Liegt etwas am falschen Platz, wird es nicht kompiliert oder nicht ins APK gepackt. Im Android-Kontext heißt das: Du musst nicht bei jeder neuen Klasse überlegen, wo sie hingehört. Es gibt einen vorgegebenen Slot für UI-Code, einen für Strings, einen für Drawables, einen für Tests und einen für Build-Skripte. Gerade für Quereinsteiger ist das eine Erleichterung — du lernst eine Struktur und findest sie in jedem Open-Source-Projekt wieder.

Wie funktioniert es?

Ein typisches Projekt hat zwei Ebenen. Ganz oben liegt der Root-Ordner mit settings.gradle.kts, einem Top-Level build.gradle.kts, gradle.properties und dem gradle/-Ordner mit dem Wrapper. Hier wird das Projekt als Ganzes konfiguriert. Darunter liegt mindestens ein Modul, meistens app/. Jedes Modul hat sein eigenes build.gradle.kts, in dem Abhängigkeiten, SDK-Versionen und Plugins definiert werden.

Source Sets im Modul

Innerhalb von app/ findest du den src/-Ordner mit drei Standard-Source-Sets:

• src/main/ — produktiver Code und Ressourcen
• src/test/ — Unit-Tests, die auf der JVM laufen
• src/androidTest/ — Instrumented Tests, die auf Gerät oder Emulator laufen

Inhalte von src/main

Im src/main/-Ordner liegen wiederum:

• java/ (auch für Kotlin) — deine Pakete und Klassen
• res/ — Ressourcen wie Strings, Layouts, Drawables, Themes
• AndroidManifest.xml — die zentrale Konfigurationsdatei, in der du Activities, Services, Receiver, Permissions und Intent-Filter deklarierst

Das System nutzt das Manifest, um zu entscheiden, was deine App darf und welche Komponenten überhaupt existieren. Gradle nutzt die Source Sets, um zu wissen, was kompiliert wird, was als Test läuft und was am Ende im APK landet.

In der Praxis

Stell dir vor, du baust eine kleine Notiz-App. Deine Compose-Screens kommen nach app/src/main/java/de/coden/notes/ui/. Die Strings für Buttons und Titel landen in app/src/main/res/values/strings.xml, die Farben in colors.xml und das App-Icon in den mipmap-Ordnern. Eine neue Activity registrierst du im Manifest:

// app/src/main/java/de/coden/notes/MainActivity.kt
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent { NotesApp() }
    }
}

<!-- app/src/main/AndroidManifest.xml -->
<activity
    android:name=".MainActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Einen Unit-Test für deine ViewModel-Logik legst du nach app/src/test/java/de/coden/notes/NotesViewModelTest.kt. Einen UI-Test, der wirklich auf einem Emulator läuft, legst du nach app/src/androidTest/java/.... Diese Trennung ist wichtig, weil JVM-Tests deutlich schneller laufen und du sie ohne Gerät ausführen kannst.

Typische Stolperfallen

Anfänger legen neue Klassen oft an einer falschen Stelle ab oder fügen Permissions im Code hinzu statt im Manifest. Beides führt zu Laufzeitfehlern, die schwer zu finden sind. Eine zweite Falle: Manche kopieren ein Drawable nach res/drawable/ und vergessen, dass dichte-spezifische Varianten wie drawable-hdpi/ oder drawable-xxhdpi/ automatisch ausgewählt werden — wer das ignoriert, bekommt verpixelte Icons auf hochauflösenden Geräten.

Eine einfache Entscheidungsregel

Bevor du eine Datei anlegst, frag dich drei Dinge: Ist es Code, Ressource oder Konfiguration? Soll sie in den Release-Build, in einen Test oder in beide? Gehört sie zur App oder zum Build? Mit diesen drei Fragen findest du den richtigen Ordner praktisch immer.

Fazit

Die Projektstruktur ist das stille Fundament jeder Android-App. Wenn du sie verinnerlichst, sparst du dir täglich Sucharbeit und triffst bessere Entscheidungen, sobald dein Projekt wächst. Öffne als Übung ein leeres Android-Studio-Projekt, klicke jeden Ordner einmal an und beschreibe dir laut, wofür er da ist. Lege bewusst eine String-Ressource, eine Test-Klasse und eine zweite Activity an — und schau im Manifest nach, was sich dadurch ändert. Prüfe in einem Code-Review explizit, ob neue Dateien im richtigen Source Set liegen. So wird aus dem Verzeichnisbaum keine Hürde mehr, sondern eine Karte, die dir zeigt, wo jede neue Datei hingehört.