Projektübersicht

Ein Projekt in Android Studio enthält alles, was Ihren Arbeitsbereich für eine App definiert, vom Quellcode und den Assets bis hin zu Testcode und Build-Konfigurationen.

Wenn Sie ein neues Projekt starten, erstellt Android Studio die erforderliche Struktur für alle Ihre Dateien und macht sie im Fenster Project (Projekt) in Android Studio sichtbar. Wählen Sie Ansicht > Toolfenster > Projekt aus, um das Fenster zu öffnen.

Auf dieser Seite finden Sie einen Überblick über die wichtigsten Komponenten Ihres Projekts.

Module

Ein Modul ist eine Sammlung von Quelldateien und Build-Einstellungen, mit denen Sie Ihr Projekt in einzelne Funktionseinheiten unterteilen können. Ihr Projekt kann ein oder mehrere Module haben und ein Modul kann ein anderes als Abhängigkeit verwenden. Sie können jedes Modul unabhängig erstellen, testen und debuggen.

Zusätzliche Module sind nützlich, wenn Sie Codebibliotheken in Ihrem eigenen Projekt erstellen oder verschiedene Code- und Ressourcensätze für verschiedene Gerätetypen wie Smartphones und Wearables erstellen möchten, aber alle Dateien im selben Projekt behalten und Code teilen möchten.

Wenn Sie Ihrem Projekt ein neues Modul hinzufügen möchten, klicken Sie auf Datei > Neu > Neues Modul.

Android Studio bietet verschiedene Arten von Modulen:

Android-App-Modul
Bietet einen Container für den Quellcode, die Ressourcendateien und die Einstellungen auf App-Ebene Ihrer App, z. B. die Build-Datei auf Modulebene und die Android-Manifestdatei. Wenn Sie ein neues Projekt erstellen, heißt das Standard-App-Modul „app“.

Android Studio bietet die folgenden Arten von App-Modulen:

  • Smartphone und Tablet
  • Automotive
  • Wear OS
  • TV
  • Baseline Profile Generator
  • Benchmark

Jedes Modul enthält wichtige Dateien und einige Codevorlagen, die für die entsprechende App oder den entsprechenden Gerätetyp geeignet sind.

Weitere Informationen zum Hinzufügen eines Moduls finden Sie unter Modul für neues Gerät hinzufügen.

Funktionsmodul
Stellt eine modulare Funktion Ihrer App dar, für die Play Feature Delivery genutzt werden kann. Mit Funktionsmodulen können Sie Ihren Nutzern beispielsweise bestimmte Funktionen Ihrer App auf Anfrage oder als Instant-Funktionen über Google Play Instant zur Verfügung stellen.

Android Studio bietet die folgenden Arten von Funktionsmodulen:

  • Dynamisches Funktionsmodul
  • Modul „Instant Dynamic Feature Library“

Weitere Informationen finden Sie unter Play Feature Delivery.

Bibliotheksmodul
Bietet einen Container für Ihren wiederverwendbaren Code, den Sie als Abhängigkeit in anderen App-Modulen verwenden oder in andere Projekte importieren können. Strukturell ist ein Bibliotheksmodul mit einem App-Modul identisch. Beim Erstellen wird jedoch eine Codearchivdatei anstelle eines APK erstellt, sodass es nicht auf einem Gerät installiert werden kann.

Im Fenster Create New Module (Neues Modul erstellen) bietet Android Studio die folgenden Arten von Bibliotheksmodulen an:

  • Android-Bibliothek:Enthält alle Dateitypen, die in einem Android-Projekt unterstützt werden, mit Ausnahme von nativem C++-Code, einschließlich Java- und Kotlin-Quellcode, Ressourcen und Manifestdateien. Das Build-Ergebnis ist eine AAR-Datei (Android Archive), die Sie als Abhängigkeit für Ihre Android-App-Module hinzufügen können.
  • Android Native Library:Enthält alle Dateitypen, die in einem Android-Projekt unterstützt werden, ähnlich wie eine Android-Bibliothek. Native Android-Bibliotheken können jedoch auch nativen C++-Quellcode enthalten. Das Build-Ergebnis ist eine AAR-Datei (Android Archive), die Sie als Abhängigkeit für Ihre Android-App-Module hinzufügen können.
  • Java- oder Kotlin-Bibliothek:Enthält nur Kotlin- oder Java-Quelldateien. Das Build-Ergebnis ist eine JAR-Datei (Java Archive), die Sie als Abhängigkeit für Ihre Android-App-Module oder andere Kotlin- oder Java-Projekte hinzufügen können.

Module werden manchmal auch als Unterprojekte bezeichnet, da Gradle auch Module als Projekte bezeichnet.

Wenn Sie ein Bibliotheksmodul erstellen und es Ihrem Android-App-Modul als Abhängigkeit hinzufügen möchten, müssen Sie es so deklarieren:

Groovy

dependencies {
    implementation project(':my-library-module')
}

Kotlin

dependencies {
    implementation(project(":my-library-module"))
}

Projektdateien

Standardmäßig werden Ihre Projektdateien in Android Studio in der Ansicht Android angezeigt. Diese Ansicht spiegelt nicht die tatsächliche Dateihierarchie auf dem Laufwerk wider. Stattdessen ist es nach Modulen und Dateitypen organisiert, um die Navigation zwischen den wichtigsten Quelldateien Ihres Projekts zu vereinfachen. Bestimmte Dateien oder Verzeichnisse, die nicht häufig verwendet werden, werden ausgeblendet.

Zu den strukturellen Unterschieden zwischen der Android-Ansicht und der Struktur auf dem Laufwerk gehören:

  • Hier werden alle buildbezogenen Konfigurationsdateien des Projekts in einer übergeordneten Gruppe Gradle Script angezeigt.
  • Zeigt alle Manifestdateien für jedes Modul in einer Gruppe auf Modulebene an, wenn Sie unterschiedliche Manifestdateien für verschiedene Produktvarianten und Buildtypen haben.
  • Alle alternativen Ressourcendateien werden in einer einzigen Gruppe anstelle in separaten Ordnern pro Ressourcenqualifizierer angezeigt. So werden beispielsweise alle Versionen Ihres Launcher-Symbols nebeneinander angezeigt.

Innerhalb jedes Android-App-Moduls werden Dateien in den folgenden Gruppen angezeigt:

manifests
enthält die Datei AndroidManifest.xml.
java
Enthält die Kotlin- und Java-Quellcodedateien, getrennt nach Paketnamen, einschließlich JUnit-Testcode.
res
Enthält alle nicht codierten Ressourcen wie UI-Strings und Bitmap-Bilder, unterteilt in entsprechende Unterverzeichnisse. Weitere Informationen zu möglichen Ressourcentypen finden Sie unter App-Ressourcen – Übersicht.

Projektansicht

Wenn Sie die tatsächliche Dateistruktur des Projekts sehen möchten, einschließlich aller Dateien, die in der Ansicht Android ausgeblendet sind, wählen Sie oben im Fenster Projekt die Option Projekt aus.

Wenn Sie die Ansicht Projekt auswählen, sehen Sie viele weitere Dateien und Verzeichnisse, darunter:

module-name/
build/
Enthält Build-Ausgaben.
libs/
Enthält private Bibliotheken.
src/
 Enthält alle Code- und Ressourcendateien für das Modul in den folgenden Unterverzeichnissen:
androidTest/
Enthält Code für Instrumentierungstests, die auf einem Android-Gerät ausgeführt werden. Weitere Informationen finden Sie unter In Android Studio testen.
cpp/
Enthält nativen C- oder C++-Code mit dem Java Native Interface (JNI). Weitere Informationen finden Sie in der Android NDK-Dokumentation.
main/
Enthält die „Haupt“-Quelldateien: den Android-Code und die Ressourcen, die von allen Buildvarianten gemeinsam genutzt werden (Dateien für andere Buildvarianten befinden sich in übergeordneten Verzeichnissen, z. B. src/debug/ für den Debug-Buildtyp):
AndroidManifest.xml
Beschreibt die Art der Anwendung und jede ihrer Komponenten. Weitere Informationen finden Sie in der Übersicht zum App-Manifest.
java/
Enthält Kotlin- oder Java-Codequellen oder beides, wenn Ihre App sowohl Kotlin- als auch Java-Quellcode enthält.
kotlin/
Enthält nur Kotlin-Codequellen.
res/
Enthält Anwendungsressourcen wie drawable-Dateien und UI-Stringdateien. Weitere Informationen finden Sie in der Übersicht App-Ressourcen.
assets/
Enthält Dateien, die unverändert in eine APK-Datei kompiliert werden. Dies ist beispielsweise ein guter Speicherort für Texturen und Spieldaten. Sie können sich in diesem Verzeichnis wie in einem normalen Dateisystem mithilfe von URIs bewegen und Dateien mit AssetManager als Bytestream lesen.
test/
Enthält Code für lokale Tests, die auf Ihrer Host-JVM ausgeführt werden.
build.gradle oder build.gradle.kts (Modul)
Hier werden die modulspezifischen Buildkonfigurationen definiert. build.gradle ist der richtige Dateiname, wenn Sie Groovy als Build-Script-Sprache verwenden, und build.gradle.kts, wenn Sie Kotlin-Script verwenden.
build.gradle oder build.gradle.kts (Projekt)
Hier wird die Build-Konfiguration definiert, die für alle Module gilt. build.gradle ist der richtige Dateiname, wenn Sie Groovy als Build-Script-Sprache verwenden, und build.gradle.kts, wenn Sie Kotlin-Script verwenden. Diese Datei ist ein wesentlicher Bestandteil des Projekts. Daher sollten Sie sie zusammen mit dem gesamten Quellcode in der Versionskontrolle verwalten.

Informationen zu anderen Build-Dateien finden Sie unter Build konfigurieren.

Einstellungen für die Projektstruktur

Wenn Sie verschiedene Einstellungen für Ihr Android Studio-Projekt ändern möchten, klicken Sie auf Datei > Projektstruktur, um das Dialogfeld Projektstruktur zu öffnen. Sie enthält die folgenden Abschnitte:

  • Projekt:Hier legen Sie die Version für Gradle und das Android-Gradle-Plug-in und den Namen des Repository-Speicherorts fest.
  • SDK-Speicherort:Hier legen Sie den Speicherort des JDK, des Android SDK und des Android NDK fest, die in Ihrem Projekt verwendet werden.
  • Variablen:Hier können Sie Variablen bearbeiten, die in Ihren Build-Scripts verwendet werden.
  • Module:Hier können Sie modulspezifische Build-Konfigurationen bearbeiten, einschließlich des Ziel- und Mindest-SDKs, der App-Signatur und der Bibliotheksabhängigkeiten. Die Seite mit den Einstellungen jedes Moduls ist in die folgenden Tabs unterteilt:
    • Properties (Eigenschaften): Hier werden die Versionen des SDKs und die Build-Tools angegeben, die zum Kompilieren des Moduls verwendet werden sollen.
    • Signatur:Gibt das Zertifikat an, mit dem Ihre App signiert werden soll.

  • Abhängigkeiten:Hier werden die Bibliotheks-, Datei- und Modulabhängigkeiten für dieses Modul aufgelistet. In diesem Bereich können Sie Abhängigkeiten hinzufügen, ändern und löschen. Weitere Informationen zu Modulabhängigkeiten finden Sie unter Buildvarianten konfigurieren.

  • Build-Varianten:Hiermit können Sie verschiedene Flavors und Build-Typen für Ihr Projekt konfigurieren.

    • Varianten: Sie können mehrere Build-Varianten erstellen, wobei für jede Variante eine Reihe von Konfigurationseinstellungen angegeben wird, z. B. die Mindest- und Ziel-SDK-Version des Moduls sowie der Versionscode und der Versionsname.

      Sie können beispielsweise eine Variante mit einer Mindest-SDK-Version von 21 und einer Ziel-SDK-Version von 29 und eine andere Variante mit einer Mindest-SDK-Version von 24 und einer Ziel-SDK-Version von 33 definieren.

    • Build-Typen:Hier können Sie Build-Konfigurationen erstellen und ändern, wie unter Build-Varianten konfigurieren beschrieben. Standardmäßig hat jedes Modul die Buildtypen debug und release. Sie können nach Bedarf weitere definieren.