Projektübersicht

Ein Projekt in Android Studio enthält alles, was den 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 Projekt in Android Studio sichtbar. Wählen Sie zum Öffnen des Fensters View > Tool Windows > Project (Ansicht > Toolfenster > Projekt) aus.

Diese Seite bietet einen Überblick über die wichtigsten Komponenten in Ihrem Projekt.

Module

Ein Modul ist eine Sammlung von Quelldateien und Build-Einstellungen, mit denen Sie Ihr Projekt in separate Funktionseinheiten unterteilen können. Ihr Projekt kann ein oder mehrere Module enthalten und ein Modul kann ein anderes Modul 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 für verschiedene Gerätetypen (z. B. Smartphones und Wearables) verschiedene Code- und Ressourcensätze erstellen möchten, aber alle Dateien innerhalb desselben Projekts bleiben und Code gemeinsam nutzen möchten.

Klicken Sie auf File > New > New Module, um Ihrem Projekt ein neues Modul hinzuzufügen.

Android Studio bietet verschiedene Modultypen:

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

Android Studio bietet die folgenden Arten von App-Modulen:

  • Telefon und Tablet
  • Automotive
  • Wear OS
  • TV
  • Generator für Basisprofil
  • Benchmark

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

Weitere Informationen zum Hinzufügen eines Moduls findest du unter Modul für ein neues Gerät hinzufügen.

Funktionsmodul
Steht für eine modularisierte Funktion deiner App, die die Vorteile von Play Feature Delivery nutzen kann. So können Sie Ihren Nutzern beispielsweise mit Funktionsmodulen bestimmte Funktionen Ihrer App on demand oder als Instant-Funktion über Google Play Instant zur Verfügung stellen.

Android Studio bietet die folgenden Arten von Funktionsmodulen:

  • Dynamisches Funktionsmodul
  • Modul der Instant Dynamic Feature Library

Weitere Informationen finden Sie unter Play Feature Delivery.

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

Im Fenster Neues Modul erstellen bietet Android Studio die folgenden Arten von Bibliotheksmodulen:

  • 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 Android-Archivdatei (AAR), die Sie als Abhängigkeit für Ihre Android-App-Module hinzufügen können.
  • Native Android-Bibliothek: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 Android-Archivdatei (AAR), 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 Java-Archivdatei (JAR), die Sie als Abhängigkeit für Ihre Android-App-Module oder andere Kotlin- oder Java-Projekte hinzufügen können.

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

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

Groovig

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

Kotlin

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

Projektdateien

In Android Studio werden die Projektdateien standardmäßig in der Android-Ansicht angezeigt. Diese Ansicht spiegelt nicht die eigentliche Dateihierarchie auf der Festplatte wider. Er ist stattdessen nach Modulen und Dateitypen organisiert, um die Navigation zwischen den wichtigsten Quelldateien Ihres Projekts zu vereinfachen. Dabei werden bestimmte Dateien oder Verzeichnisse, die nicht häufig verwendet werden, ausgeblendet.

Hier einige der strukturellen Unterschiede zwischen der Ansicht Android und der Ansicht Android:

  • Zeigt alle Build-Konfigurationsdateien des Projekts in einer Gradle Script-Gruppe auf oberster Ebene an.
  • Zeigt alle Manifestdateien für jedes Modul in einer Gruppe auf Modulebene an, wenn Sie unterschiedliche Manifestdateien für unterschiedliche Produktvarianten und Build-Typen haben.
  • Zeigt alle alternativen Ressourcendateien in einer einzelnen Gruppe statt in separaten Ordnern pro Ressourcenqualifizierer an. So sind beispielsweise alle Versionen des Launcher-Symbols mit verschiedenen Dichten nebeneinander sichtbar.

In jedem Android-App-Modul werden die Dateien in den folgenden Gruppen angezeigt:

Manifeste
Enthält die Datei AndroidManifest.xml.
Java
Enthält die Kotlin- und Java-Quellcodedateien, getrennt durch Paketnamen, einschließlich JUnit-Testcode.
Auflösung
Enthält alle Nicht-Code-Ressourcen wie UI-Strings und Bitmapbilder, unterteilt in entsprechende Unterverzeichnisse. Weitere Informationen zu möglichen Ressourcentypen finden Sie in der Übersicht über Anwendungsressourcen.

Projektansicht

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

Wenn Sie die Ansicht Projekt auswählen, können Sie viel mehr Dateien und Verzeichnisse sehen, 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 findest du unter In Android Studio testen.
cpp/
Enthält nativen C- oder C++-Code, der das Java Native Interface (JNI) verwendet. Weitere Informationen finden Sie in der Android-NDK-Dokumentation.
main/
Enthält die „Haupt“-Quellsatzdateien: den Android-Code und die Ressourcen, die von allen Build-Varianten gemeinsam genutzt werden (Dateien für andere Build-Varianten befinden sich in gleichgeordneten Verzeichnissen, z. B. src/debug/ für den Build-Typ zur Fehlerbehebung):
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 beide, wenn deine App sowohl Kotlin- als auch Java-Quellcode hat.
kotlin/
Enthält nur Kotlin-Codequellen.
res/
Enthält Anwendungsressourcen wie Drawable-Dateien und UI-Stringdateien. Weitere Informationen finden Sie in der Übersicht zu Anwendungsressourcen.
assets/
Enthält Dateien, die unverändert zu einer APK-Datei kompiliert werden. Dies ist beispielsweise ein guter Speicherort für Texturen und Spieldaten. Sie können in diesem Verzeichnis genauso wie in einem typischen Dateisystem navigieren, indem Sie URIs verwenden und Dateien mit AssetManager als Stream von Byte lesen.
test/
Enthält Code für lokale Tests, die auf der Host-JVM ausgeführt werden.
build.gradle oder build.gradle.kts (Modul)
Damit werden die modulspezifischen Build-Konfigurationen definiert. build.gradle ist der richtige Dateiname, wenn Sie Groovy als Build-Skriptsprache verwenden, und build.gradle.kts, wenn Sie ein Kotlin-Skript verwenden.
build.gradle oder build.gradle.kts (Projekt)
Damit wird die Build-Konfiguration definiert, die für alle Module gilt. build.gradle ist der richtige Dateiname, wenn Sie Groovy als Build-Skriptsprache verwenden, und build.gradle.kts, wenn Sie ein Kotlin-Skript verwenden. Diese Datei ist ein wichtiger Bestandteil des Projekts. Daher sollten Sie sie zusammen mit allen anderen Quellcodes in der Versionsverwaltung 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, öffnen Sie das Dialogfeld Projektstruktur, indem Sie auf Datei > Projektstruktur klicken. Sie enthält die folgenden Abschnitte:

  • Projekt:Legt die Version für Gradle und das Android-Gradle-Plug-in sowie den Namen des Repository-Speicherorts fest.
  • SDK Location (SDK-Speicherort): Legt den Speicherort des JDK, des Android SDK und des Android-NDK fest, das Ihr Projekt verwendet.
  • Variablen: Damit können Sie Variablen bearbeiten, die in Ihren Build-Skripts verwendet werden.
  • Module:Hiermit können Sie modulspezifische Build-Konfigurationen bearbeiten, einschließlich des Ziel- und Mindest-SDK, der App-Signatur und der Bibliotheksabhängigkeiten. Die Seite mit den Einstellungen jedes Moduls ist in folgende Tabs unterteilt:
    • Properties:Gibt die Versionen des SDK und der Build-Tools an, die zum Kompilieren des Moduls verwendet werden sollen.
    • Signing (Signatur): Gibt das Zertifikat an, das zum Signieren Ihrer Anwendung verwendet werden soll.
  • Abhängigkeiten: Listet die Bibliotheks-, Datei- und Modulabhängigkeiten für dieses Modul auf. In diesem Bereich können Sie Abhängigkeiten hinzufügen, ändern und löschen. Weitere Informationen zu Modulabhängigkeiten finden Sie unter Build-Varianten konfigurieren.

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

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

      Beispielsweise könnten Sie eine Variante definieren, die mindestens 21 für das SDK und 29 als Ziel-SDK hat, und eine andere mit mindestens 24 und ein Ziel-SDK von 33.

    • Build-Typen: Ermöglicht das Erstellen und Ändern von Build-Konfigurationen, wie unter Build-Varianten konfigurieren beschrieben. Standardmäßig hat jedes Modul Build-Typen zum Debuggen und Release-Releases. Sie können bei Bedarf weitere Typen definieren.