Android-Build-Struktur

Android-Projekte enthalten viele build-bezogene Dateien und Verzeichnisstrukturen, Ihre Anwendungsquelle und -ressourcen organisieren. Bevor Sie sich mit den sehen wir uns die Gesamtstruktur und die Grundlagen was in die einzelnen Teile gehört.

In dieser Tabelle sind typische Dateien in einem Android-Projekt aufgeführt. In den Beschreibungen der einzelnen oder Verzeichnis enthält Hinweise dazu, welche Art von Inhalten dorthin gehört. Beste Praktiken entwickeln sich im Laufe der Zeit und diese Beschreibungen stimmen möglicherweise nicht die Sie aus dem Internet übernommen oder heruntergeladen haben.

Verwenden Sie beim Schreiben Ihrer Build-Dateien einen deklarativen Ansatz. Build-Logik und -Aufgaben sollten nur in Plug-ins angezeigt werden. Indem Sie die Build-Logik auf Plug-ins beschränken, Build-Dateien werden zu Datendeklarationen, die das Verständnis und Bearbeitung. Zukünftige Versionen können eine alternative Spezifikation wie diese enthalten: Deklarativer Gradle-Code, der die Build-Logik im -Dateien.

Ordner/Datei

Verwenden

.Gradle/

Cache-Verzeichnis des Gradle-Projekts

Wird von Gradle verwaltet und enthält die heruntergeladene Gradle-Distribution, den Projekt-Cache und die Konfigurationsdateien.

Ändern Sie in diesem Verzeichnis keine Dateien.

Ideen/

Android Studio-Projektmetadaten

Ändern Sie in diesem Verzeichnis keine Dateien.

build.gradle(.kts)

Stamm-Build-Datei

Sollte nur Plug-in-Deklarationen enthalten, um einen gemeinsamen Plug-in-Klassenpfad für Unterprojekte einzurichten.

Anderen Code sollte sich in den Einstellungen oder in verschachtelten Build-Dateien auf Projektebene befinden.

gradle.properties

Gradle-Ausführungskonfiguration

Enthält Gradle-Attribute, mit denen Aspekte der Gradle-Build-Umgebung gesteuert werden, z. B. Heap-Größe, Caching und parallele Ausführung.

Hier werden einige temporäre Android-Eigenschaften definiert, um Änderungen am AGP DSL zu reduzieren, wenn sie hinzugefügt und später entfernt werden.

gradlew (Linux, Mac)

gradlew.bat (Windows)

Gradle-Wrapper Datei

Bootstrapping Ihres Builds durch Herunterladen einer Gradle-Distribution und anschließendes Weiterleiten von Befehlen an diese. So können Sie Builds ausführen, ohne Gradle vorinstallieren zu müssen.

local.properties

Konfiguration lokaler Maschinen

Enthält Eigenschaften, die sich auf den lokalen Computer beziehen, z. B. den Speicherort des Android SDK.

Diese Datei aus der Versionsverwaltung ausschließen

settings.gradle(.kts) – Einstellungen.

Gradle-Build-Initialisierung

Enthält globale Build-Informationen zur Gradle-Initialisierung und -Projektkonfiguration, z. B.

  • Projektname
  • Liste der Unterprojekte, die in diesen Build einbezogen werden sollen
  • Repository-Spezifikationen zum Finden von Plug-ins und Abhängigkeiten
  • externe Versionskatalog-Importe.

Gradle/

🎬 libs.versions.toml

Versionskatalog

Definiert Variablen für Abhängigkeiten und Plug-ins, die in Ihrem Build verwendet werden. Sie geben hier an, welche Versionen Sie verwenden möchten, um für Konsistenz in allen Unterprojekten Ihres Projekts zu sorgen.

📣 Wrapper/

🎬 gradle‐wrapper.jar

Gradle-Bootstrapping ausführbar

Lädt die angegebene Gradle-Distribution herunter (falls sie nicht vorhanden ist) und führt sie aus. Dabei werden alle Argumente übergeben.

📣 gradle‐wrapper.properties

Konfiguration für Gradle-Wrapper

Gibt an, wo die Gradle-Distribution heruntergeladen werden soll (einschließlich der zu verwendenden Version).

App/

Verzeichnis des Unterprojekts

Unterprojekte (in Android Studio als "Module" bezeichnet) können Anwendungen oder Bibliotheken erstellen und von anderen Unterprojekten oder externen Abhängigkeiten abhängen.

app ist der konventionelle Name für ein Anwendungsunterprojekt der obersten Ebene. Dies ist jedoch nicht der erforderliche Name. Andere Unterprojekte haben ähnliche Strukturen mit unterschiedlichen Namen.

Jedes Verzeichnis kann ein Unterprojekt sein, muss mindestens eine build.gradle(.kts)-Datei enthalten und mit settings.gradle(.kts) in den Build aufgenommen werden.

GoDaddy build.gradle(.kts)

Build-Datei auf Unterprojektebene

Deklariert, wie dieses Unterprojekt erstellt wird. Jedes Unterprojekt erfordert eine separate Build-Datei und sollte

  • Plug-ins, die zum Erstellen dieses Unterprojekts verwendet werden
  • Für Plug-ins erforderliche Konfigurationsblöcke
  • Abhängigkeiten (Bibliotheken und Plattformen), die beim Erstellen dieses Unterprojekts enthalten sind

Sie sollten keine Build-Logik (z. B. Kotlin-Funktionsdefinitionen oder -Bedingungen) oder Aufgabendeklarationen in Ihre Build-Dateien aufnehmen. Build-Logik und -Aufgaben sollten nur innerhalb von Plug-ins enthalten sein.

🎬 src/

Quelldateien von Unterprojekten

Gruppiert Quelldateien (Anwendungscode und Ressourcen) in Quellsätze. Das Quellset main enthält Quelldateien, die für alle Varianten gelten, während andere Quellsätze spezifische Quelldateien für eine Variante enthalten.

Coursera Haupt-/

Haupt Quellensatz

Quellcode und Ressourcen, die für alle Build-Varianten gemeinsam sind. Diese Quelle dient als Basis für alle Builds und andere spezifischere Quellsätze werden dieser Quelle hinzugefügt oder überschrieben.

📣 Java/

🎬 Kotlin/

Kotlin- und Java-Quellcode

Das Verzeichnis java kann sowohl Java- als auch Kotlin-Quellcode enthalten. Wenn dieses Unterprojekt nur Kotlin-Code enthält, können Sie das Verzeichnis umbenennen, indem kotlin.

Android
eine Kotlin-First-Plattform ist. Die Quelle Java wird unterstützt, neue APIs sind jedoch auf die Sprache Kotlin ausgerichtet. Wir empfehlen, Kotlin für alle neuen Codes und größere Aktualisierungen vorhandenem Code zu verwenden.

📣 res/

Android-Ressourcendateien

Enthält Anwendungsressourcen wie XML-Dateien und Bilder. Alle Anwendungen verwenden einige grundlegende Ressourcen wie Launcher-Symbole. Viele dieser Ressourcen wie Layouts und Menüs werden jedoch nur in ansichtsbasierten Anwendungen verwendet. Compose-Anwendungen verwenden String-Ressourcen, die in diesem Verzeichnis definiert sind.

BidRequest AndroidManifest.xml

Android-Anwendungsmetadaten

Vom Android-Paketmanager lesen, um dem System mitzuteilen

  • Von Ihrer Anwendung definierte Komponenten
  • erforderliche Berechtigungen
  • Gerätekompatibilität
  • Android-Plattformeinschränkungen

🥳 androidTest/

Gerätetest Quellensatz

Enthält Quelle für Tests, die auf einem Android-Gerät oder Emulator ausgeführt werden. Diese Tests haben Zugriff auf eine echte Android-Umgebung, werden jedoch langsamer ausgeführt als Hosttests.

Alle Quelldateien im main-Quellsatz können unter androidTest von der Quelle verwendet werden.

🏆 Test/

Hosttest Quellsatz

Enthält die Quelle für Tests, die lokal in einer JVM ausgeführt werden, im Gegensatz zu Tests, die auf einem Gerät ausgeführt werden. Diese Tests lassen sich viel schneller ausführen als Gerätetests. Allerdings müssen alle Systemaufrufe (einschließlich der Lebenszyklen, die Ihre Anwendung ausführen) Simulationen, Fakes, Stubs oder anderweitig simuliert werden.

Alle Quelldateien im main-Quellsatz können von der zu testenden Quelle verwendet werden.

🎬 proguard-rules.pro

R8-Konfigurationsregeln

Definiert Regeln zur Steuerung der Verkleinerung, Optimierung und Verschleierung von Anwendungen. R8 entfernt nicht benötigten Code und Ressourcen, optimiert die Laufzeitleistung und minimiert Ihren Code weiter durch das Umbenennen von Kennungen.