Diese Seite wurde von der Cloud Translation API übersetzt.

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.