Das Android-Build-System kompiliert App-Ressourcen und Quellcode und packt sie in APKs oder Android App Bundles, die Sie testen, bereitstellen, signieren und verteilen können.
In Gradle-Build – Übersicht und Android-Build-Struktur haben wir Build-Konzepte und die Struktur einer Android-App behandelt. Jetzt ist es an der Zeit, den Build zu konfigurieren.
Glossar für Android-Builds
Mit Gradle und dem Android-Gradle-Plug-in können Sie die folgenden Aspekte Ihres Builds konfigurieren:
- Build-Typen
-
Build-Typen definieren bestimmte Eigenschaften, die Gradle beim Erstellen und Verpacken Ihrer App verwendet. Build-Typen werden in der Regel für verschiedene Phasen des Entwicklungszyklus konfiguriert.
Der Debug-Buildtyp aktiviert beispielsweise Debugging-Optionen und signiert die App mit dem Debug-Schlüssel, während der Release-Buildtyp die App für die Verteilung verkleinern, verschleiern und mit einem Releaseschlüssel signieren kann.
Sie müssen mindestens einen Build-Typ definieren, um Ihre App zu erstellen. In Android Studio werden die Build-Typen „Debug“ und „Release“ standardmäßig erstellt. Informationen zum Anpassen der Verpackungseinstellungen für Ihre App finden Sie hier.
- Produktvarianten
- Produktvarianten stellen verschiedene Versionen Ihrer App dar, die Sie für Nutzer veröffentlichen können, z. B. kostenlose und kostenpflichtige Versionen. Sie können Produktvarianten anpassen, um unterschiedlichen Code und unterschiedliche Ressourcen zu verwenden, während Sie die Teile, die für alle Versionen Ihrer App gleich sind, gemeinsam nutzen und wiederverwenden. Produktvarianten sind optional und müssen manuell erstellt werden. Informationen zum Erstellen verschiedener Versionen Ihrer App finden Sie unter Produktvarianten konfigurieren.
- Build-Varianten
- Eine Build-Variante ist ein Cross-Produkt aus Build-Typ und Produktvariante und die Konfiguration, die Gradle zum Erstellen Ihrer App verwendet. Mit Build-Varianten können Sie während der Entwicklung die Debug-Versionen Ihrer Produktvarianten und für die Verteilung signierte Release-Versionen Ihrer Produktvarianten erstellen. Build-Varianten werden nicht direkt konfiguriert, sondern die Build-Typen und Produktvarianten, aus denen sie bestehen. Wenn Sie zusätzliche Build-Typen oder Produktvarianten erstellen, werden auch zusätzliche Build-Varianten erstellt. Informationen zum Erstellen und Verwalten von Build-Varianten finden Sie in der Übersicht zum Konfigurieren von Build-Varianten.
- Manifesteinträge
- Sie können Werte für einige Attribute der Manifestdatei in der Build-Variantenkonfiguration angeben. Diese Build-Werte überschreiben die vorhandenen Werte in der Manifestdatei. Das ist nützlich, wenn Sie mehrere Varianten Ihrer App mit einem anderen Anwendungsnamen, einer anderen Mindest-SDK-Version oder einer anderen Ziel-SDK-Version generieren möchten. Wenn mehrere Manifeste vorhanden sind, werden die Manifesteinstellungen mit dem Manifest-Merger-Tool zusammengeführt.
- Abhängigkeiten
- Das Build-System verwaltet Projektabhängigkeiten aus Ihrem lokalen Dateisystem und aus Remote-Repositories. Das bedeutet, dass Sie nicht manuell nach Binärpaketen Ihrer Abhängigkeiten suchen, diese herunterladen und in Ihr Projektverzeichnis kopieren müssen. Weitere Informationen finden Sie unter Build-Abhängigkeiten hinzufügen.
- Signieren
- Im Build-System können Sie Signierungseinstellungen in der Build-Konfiguration angeben. Ihre App kann dann während des Build-Prozesses automatisch signiert werden. Das Build-System signiert die Debug-Version mit einem Standardschlüssel und ‑zertifikat mit bekannten Anmeldedaten, um eine Passwortaufforderung zur Build-Zeit zu vermeiden. Das Build-System signiert die Release-Version nur, wenn Sie explizit eine Signaturkonfiguration für diesen Build definieren. Wenn Sie keinen Releaseschlüssel haben, können Sie einen wie unter App signieren beschrieben generieren. Signierte Release-Builds sind für die Verteilung von Apps über die meisten App-Shops erforderlich.
- Code- und Ressourcenkomprimierung
- Im Build-System können Sie für jede Build-Variante eine andere ProGuard-Regeldatei angeben. Beim Erstellen Ihrer App wendet das Build-System die entsprechenden Regeln an, um Ihren Code und Ihre Ressourcen zu verkleinern. Dazu werden integrierte Tools wie R8 verwendet. Durch das Verkleinern von Code und Ressourcen kann die Größe Ihres APKs oder AABs reduziert werden.
- Unterstützung für mehrere APKs
- Mit dem Build-System können Sie automatisch verschiedene APKs erstellen, die jeweils nur den Code und die Ressourcen enthalten, die für eine bestimmte Bildschirmdichte oder Application Binary Interface (ABI) erforderlich sind. Weitere Informationen finden Sie unter Mehrere APKs erstellen. Es wird jedoch empfohlen, nur ein AAB zu veröffentlichen, da es neben der Aufteilung nach Bildschirmdichte und ABI auch die Aufteilung nach Sprache ermöglicht und das Hochladen mehrerer Artefakte bei Google Play vermieden wird. Alle neuen Apps, die nach August 2021 eingereicht werden, müssen AABs verwenden.
Java-Versionen in Android-Builds
Unabhängig davon, ob Ihr Quellcode in Java, Kotlin oder beiden Sprachen geschrieben ist, müssen Sie an mehreren Stellen ein JDK oder eine Java-Sprachversion für Ihren Build auswählen. Weitere Informationen finden Sie unter Java-Versionen in Android-Builds.
Build-Konfigurationsdateien
Wenn Sie benutzerdefinierte Build-Konfigurationen erstellen möchten, müssen Sie Änderungen an einer oder mehreren Build-Konfigurationsdateien vornehmen. Diese Nur-Text-Dateien verwenden eine domänenspezifische Sprache (DSL), um die Build-Logik mit Kotlin-Script zu beschreiben und zu bearbeiten. Kotlin-Script ist eine Variante der Kotlin-Sprache. Sie können Ihre Builds auch mit Groovy konfigurieren, einer dynamischen Sprache für die Java Virtual Machine (JVM).
Sie müssen kein Kotlin-Script oder Groovy kennen, um mit der Konfiguration Ihres Builds zu beginnen, da das Android-Gradle-Plug-in die meisten DSL-Elemente einführt, die Sie benötigen. Weitere Informationen zur DSL des Android-Gradle-Plug-ins finden Sie in der DSL-Referenzdokumentation. Kotlin-Skript basiert auch auf der zugrunde liegenden Gradle Kotlin DSL.
Wenn Sie ein neues Projekt starten, erstellt Android Studio automatisch einige dieser Dateien und füllt sie mit sinnvollen Standardwerten. Eine Übersicht über die erstellten Dateien finden Sie unter Android-Build-Struktur.
Die Gradle-Wrapper-Datei
Der Gradle-Wrapper (gradlew) ist eine kleine Anwendung, die in Ihrem Quellcode enthalten ist und Gradle herunterlädt und startet.
Dadurch wird die Ausführung von Builds konsistenter. Entwickler laden den Anwendungsquellcode herunter und führen gradlew aus. Dadurch wird die erforderliche Gradle-Distribution heruntergeladen und Gradle wird gestartet, um Ihre Anwendung zu erstellen.
Die Datei gradle/wrapper/gradle-wrapper.properties enthält die Property distributionUrl, die beschreibt, welche Version von Gradle zum Ausführen Ihres Builds verwendet wird.
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Die Gradle-Einstellungsdatei
Die Datei settings.gradle.kts (für die Kotlin DSL) oder settings.gradle (für die Groovy DSL) befindet sich im Stammverzeichnis des Projekts. In dieser Einstellungsdatei werden Repository-Einstellungen auf Projektebene definiert und Gradle wird mitgeteilt, welche Module beim Erstellen Ihrer App einbezogen werden sollen. Bei Projekten mit mehreren Modulen muss jedes Modul angegeben werden, das in den endgültigen Build aufgenommen werden soll.
Bei den meisten Projekten sieht die Datei standardmäßig so aus:
Kotlin
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include(":app")
Groovy
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include ':app'
Die Build-Datei der obersten Ebene
Die build.gradle.kts-Datei (für die Kotlin DSL) oder die build.gradle-Datei (für die Groovy DSL) der obersten Ebene befindet sich im Stammverzeichnis des Projekts. Darin werden in der Regel die gängigen Versionen von Plug-ins definiert, die von Modulen in Ihrem Projekt verwendet werden.
Im folgenden Codebeispiel werden die Standardeinstellungen und DSL-Elemente im Build-Skript der obersten Ebene nach dem Erstellen eines neuen Projekts beschrieben:
Kotlin
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id("com.android.application") version "8.11.0" apply false id("com.android.library") version "8.11.0" apply false id("org.jetbrains.kotlin.android") version "2.1.20" apply false }
Groovy
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id 'com.android.application' version '8.11.0' apply false id 'com.android.library' version '8.11.0' apply false id 'org.jetbrains.kotlin.android' version '2.1.20' apply false }
Die Build-Datei auf Modulebene
Die Datei build.gradle.kts auf Modulebene (für die Kotlin DSL) oder build.gradle (für die Groovy DSL) befindet sich in jedem project/module/-Verzeichnis. Damit können Sie Buildeinstellungen für das jeweilige Modul konfigurieren, in dem sich die Datei befindet. Wenn Sie diese Buildeinstellungen konfigurieren, können Sie benutzerdefinierte Verpackungsoptionen wie zusätzliche Build-Typen und Produktvarianten angeben und Einstellungen im main/-App-Manifest oder im Build-Skript der obersten Ebene überschreiben.
Android SDK-Einstellungen
Die Build-Datei auf Modulebene für Ihre Anwendung enthält Einstellungen, die die beim Kompilieren verwendeten Android SDK-Versionen, die Auswahl von Plattformverhalten und die Angabe der Mindestversion angeben, auf der Ihre Anwendung ausgeführt wird.
-
compileSdk -
Mit dem
compileSdkwird festgelegt, welche Android- und Java-APIs beim Kompilieren Ihres Quellcodes verfügbar sind. Wenn Sie die neuesten Android-Funktionen nutzen möchten, verwenden Sie beim Kompilieren das aktuelle Android SDK.Einige Android-Plattform-APIs sind möglicherweise nicht in älteren API-Levels verfügbar. Sie können die Verwendung neuerer Funktionen bedingungsweise schützen oder AndroidX-Kompatibilitätsbibliotheken verwenden, um neuere Funktionen mit niedrigeren Android-API-Levels zu nutzen.
Jedes Android SDK bietet eine Teilmenge von Java-APIs, die in Ihrer Anwendung verwendet werden können. In der Tabelle unter Welche Java-APIs kann ich in meinem Java- oder Kotlin-Quellcode verwenden? sehen Sie, welche Java-API-Ebene basierend auf der Android SDK-Version verfügbar ist. Die neueren Java-APIs werden in früheren Android-Versionen durch Desugaring unterstützt, das in Ihrem Build aktiviert sein muss.
In Android Studio werden Warnungen angezeigt, wenn Ihr
compileSdkmit der aktuellen Version von Android Studio, AGP oder den Bibliotheksabhängigkeitsanforderungen Ihres Projekts in Konflikt steht. -
minSdk -
minSdkgibt die niedrigste Android-Version an, die von Ihrer App unterstützt werden soll. Wenn SieminSdkfestlegen, wird eingeschränkt, auf welchen Geräten Ihre App installiert werden kann.Die Unterstützung niedrigerer Android-Versionen erfordert möglicherweise mehr bedingte Prüfungen in Ihrem Code oder eine stärkere Nutzung von AndroidX-Kompatibilitätsbibliotheken. Sie sollten die Wartungskosten für die Unterstützung niedrigerer Versionen gegen den Prozentsatz der Nutzer abwägen, die diese niedrigeren Versionen noch verwenden. Die aktuellen Prozentsätze für die Versionsnutzung finden Sie im Assistenten für neue Projekte von Android Studio.
Wenn Sie Ihren Code in Android Studio bearbeiten oder während des Builds Prüfungen ausführen, werden Sie von Lint vor APIs gewarnt, die Sie verwenden und die in der
minSdknicht verfügbar sind. Sie sollten diese beheben, indem Sie neuere Funktionen bedingt machen oderAppcompatfür die Abwärtskompatibilität verwenden. -
targetSdk -
Die
targetSdkerfüllt zwei Zwecke:- Sie legt das Laufzeitverhalten Ihrer Anwendung fest.
- Sie gibt an, mit welcher Android-Version Sie die App getestet haben.
Wenn Sie Ihre App auf einem Gerät mit einer höheren Android-Version als der in Ihrem
targetSdkangegebenen Version ausführen, wird sie in einem Kompatibilitätsmodus ausgeführt, der sich ähnlich wie die niedrigere Version verhält.targetSdkAls mit API 23 das Berechtigungsmodell für die Laufzeit eingeführt wurde, waren beispielsweise nicht alle Apps bereit, es sofort zu übernehmen. Wenn SietargetSdkauf 22 festlegen, können diese Apps auf Geräten mit API 23 ausgeführt werden, ohne Laufzeitberechtigungen zu verwenden, und Funktionen nutzen, die in der neuestencompileSdk-Version enthalten sind. Die Google Play-Vertriebsrichtlinie enthält zusätzliche Richtlinien zum Ziel-API-Level.Der Wert von
targetSdkmuss kleiner oder gleich dem Wert voncompileSdksein.
Hinweis:Die Werte von compileSdk und targetSdk müssen nicht identisch sein. Beachten Sie die folgenden Grundsätze:
compileSdkbietet Zugriff auf neue APIstargetSdklegt das Laufzeitverhalten Ihrer App fest.targetSdkmuss kleiner oder gleichcompileSdksein
Beispiel für ein Build-Skript für ein App-Modul
In diesem Beispiel-Build-Script für ein Android-App-Modul werden einige der grundlegenden DSL-Elemente und ‑Einstellungen beschrieben:
Kotlin
/** * The first section in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id("com.android.application") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace = "com.example.myapp" /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk = 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId = "com.example.myapp" // Defines the minimum API level required to run the app. minSdk = 21 // Specifies the API level used to test the app. targetSdk = 33 // Defines the version number of your app. versionCode = 1 // Defines a user-friendly version name for your app. versionName = "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ getByName("release") { isMinifyEnabled = true // Enables code shrinking for the release build type. proguardFiles( getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" ) } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store or an Android device simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions += "tier" productFlavors { create("free") { dimension = "tier" applicationId = "com.example.myapp.free" } create("paid") { dimension = "tier" applicationId = "com.example.myapp.paid" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation(project(":lib")) implementation("androidx.appcompat:appcompat:1.7.1") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
Groovy
/** * The first line in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id 'com.android.application' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace 'com.example.myapp' /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdk 21 // Specifies the API level used to test the app. targetSdk 33 // Defines the version number of your app. versionCode 1 // Defines a user-friendly version name for your app. versionName "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ release { minifyEnabled true // Enables code shrinking for the release build type. proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store or an Android device simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions "tier" productFlavors { free { dimension "tier" applicationId 'com.example.myapp.free' } paid { dimension "tier" applicationId 'com.example.myapp.paid' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation project(":lib") implementation 'androidx.appcompat:appcompat:1.7.1' implementation fileTree(dir: 'libs', include: ['*.jar']) }
Gradle-Attributdateien
Gradle enthält außerdem zwei Eigenschaftendateien im Stammverzeichnis Ihres Projekts, mit denen Sie Einstellungen für das Gradle-Build-Toolkit selbst angeben können:
-
gradle.properties - Hier können Sie projektweite Gradle-Einstellungen konfigurieren, z. B. die maximale Heap-Größe des Gradle-Daemons. Weitere Informationen finden Sie unter Build-Umgebung.
-
local.properties -
Konfiguriert Eigenschaften der lokalen Umgebung für das Build-System, einschließlich der folgenden:
ndk.dir: Pfad zum NDK. Dieses Attribut wird nicht mehr unterstützt. Alle heruntergeladenen Versionen des NDK werden im Verzeichnisndkim Android SDK-Verzeichnis installiert.sdk.dir: Pfad zum Android SDK.cmake.dir: Pfad zu CMake.ndk.symlinkdir: In Android Studio 3.5 und höher wird ein Symlink zum NDK erstellt, der kürzer als der installierte NDK-Pfad sein kann.
NDK einem kürzeren Pfad zuordnen (nur Windows)
Unter Windows haben Tools im installierten NDK-Ordner, z. B. ld.exe, lange Pfade. Die Tools unterstützen lange Pfade nicht gut.
Wenn Sie einen kürzeren Pfad erstellen möchten, legen Sie in local.properties die Property ndk.symlinkdir fest, um anzufordern, dass das Android-Gradle-Plugin einen Symlink zum NDK erstellt. Der Pfad dieses Symlinks kann kürzer sein als der vorhandene NDK-Ordner.
ndk.symlinkdir = C:\ führt beispielsweise zu folgendem symbolischen Link:
C:\ndk\19.0.5232133
Projekt mit Gradle-Dateien synchronisieren
Wenn Sie Änderungen an den Build-Konfigurationsdateien in Ihrem Projekt vornehmen, müssen Sie die Projektdateien in Android Studio synchronisieren, damit die Änderungen an der Build-Konfiguration importiert und einige Prüfungen durchgeführt werden können, um sicherzustellen, dass Ihre Konfiguration keine Build-Fehler verursacht.
Wenn Sie Ihre Projektdateien synchronisieren möchten, klicken Sie in der Benachrichtigungsleiste, die nach einer Änderung angezeigt wird, auf Jetzt synchronisieren (siehe Abbildung 2) oder klicken Sie in der Menüleiste auf Projekt synchronisieren 
. Wenn Android Studio Fehler in Ihrer Konfiguration findet, z. B. wenn in Ihrem Quellcode API-Funktionen verwendet werden, die nur in einem API-Level höher als compileSdkVersion verfügbar sind, wird das Problem im Fenster Messages beschrieben.
Source-Sets
In Android Studio werden Quellcode und Ressourcen für jedes Modul logisch in Quellsätzen gruppiert. Wenn Sie ein neues Modul erstellen, wird in Android Studio ein main/-Quellsatz im Modul erstellt. Das main/-Quellset eines Moduls enthält den Code und die Ressourcen, die von allen Build-Varianten verwendet werden.
Zusätzliche Quellsetverzeichnisse sind optional und werden von Android Studio nicht automatisch erstellt, wenn Sie neue Build-Varianten konfigurieren. Wenn Sie jedoch Quellsets erstellen, ähnlich wie main/, können Sie Dateien und Ressourcen organisieren, die Gradle nur beim Erstellen bestimmter Versionen Ihrer App verwenden soll:
-
src/main/ - Dieses Quellset enthält Code und Ressourcen, die für alle Build-Varianten gelten.
-
src/buildType/ - Erstellen Sie dieses Quellset, um Code und Ressourcen nur für einen bestimmten Build-Typ einzuschließen.
-
src/productFlavor/ -
Erstellen Sie dieses Quellset, um Code und Ressourcen nur für eine bestimmte
Produktvariante einzuschließen.
Hinweis:Wenn Sie Ihren Build so konfigurieren, dass mehrere Produktvarianten kombiniert werden, können Sie Quellsetverzeichnisse für jede Kombination von Produktvarianten zwischen den Variantendimensionen erstellen:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Erstellen Sie dieses Quellset, um Code und Ressourcen nur für eine bestimmte Build-Variante einzuschließen.
Wenn Sie beispielsweise die Version „fullDebug“ Ihrer App generieren möchten, führt das Build-System Code, Einstellungen und Ressourcen aus den folgenden Quellsets zusammen:
-
src/fullDebug/(die Build-Varianten-Quellgruppe) -
src/debug/(das Quellset für den Build-Typ) -
src/full/(die Quellgruppe für Produktvarianten) -
src/main/(die Hauptquellgruppe)
Hinweis:Wenn Sie in Android Studio eine neue Datei oder ein neues Verzeichnis erstellen, verwenden Sie die Menüoptionen Datei > Neu, um sie für einen bestimmten Quellsatz zu erstellen. Die Quellsets, die Sie auswählen können, basieren auf Ihren Build-Konfigurationen. Android Studio erstellt die erforderlichen Verzeichnisse automatisch, falls sie noch nicht vorhanden sind.
Wenn verschiedene Quellsätze unterschiedliche Versionen derselben Datei enthalten, verwendet Gradle die folgende Prioritätsreihenfolge, um zu entscheiden, welche Datei verwendet werden soll. Mit Quellsets auf der linken Seite werden die Dateien und Einstellungen von Quellsets auf der rechten Seite überschrieben:
build variant > build type > product flavor > main source set > library dependencies
So kann Gradle Dateien verwenden, die speziell für die Build-Variante sind, die Sie erstellen möchten, und gleichzeitig Aktivitäten, Anwendungslogik und Ressourcen wiederverwenden, die für andere Versionen Ihrer App üblich sind.
Beim Zusammenführen mehrerer Manifeste verwendet Gradle dieselbe Prioritätsreihenfolge, sodass für jede Build-Variante unterschiedliche Komponenten oder Berechtigungen im endgültigen Manifest definiert werden können. Weitere Informationen zum Erstellen benutzerdefinierter Quellgruppen
Versionskataloge
Wenn Ihr Build mehrere Module mit gemeinsamen Abhängigkeiten enthält oder Sie mehrere unabhängige Projekte mit gemeinsamen Abhängigkeiten haben, empfehlen wir, ein Versionsverzeichnis oder eine Stückliste (Bill of Materials, BOM) zu verwenden, um die gemeinsamen Versionen anzugeben.
Andere Build-Systeme
Android-Apps mit Bazel zu entwickeln, ist möglich, wird aber nicht offiziell unterstützt. Android Studio unterstützt Bazel-Projekte nicht offiziell.
Weitere Informationen zu den aktuellen Einschränkungen beim Erstellen mit Bazel finden Sie unter Bekannte Probleme.