Das Android-Build-System kompiliert App-Ressourcen und Quellcode und verpackt sie in APKs oder Android App Bundles, die du testen, bereitstellen, signieren und verteilen kannst.
Android Studio verwendet Gradle, ein erweitertes Build-Toolkit, um den Build-Prozess zu automatisieren und zu verwalten und gleichzeitig flexible, benutzerdefinierte Build-Konfigurationen zu definieren. Jede Build-Konfiguration kann einen eigenen Code und eigene Ressourcen definieren und dabei die Teile wiederverwenden, die für alle Versionen Ihrer App gelten. Das Android-Gradle-Plug-in arbeitet mit dem Build-Toolkit zusammen, um Prozesse und konfigurierbare Einstellungen für das Erstellen und Testen von Android-Apps bereitzustellen.
Gradle und das Android-Gradle-Plug-in werden unabhängig von Android Studio ausgeführt. Das bedeutet, dass Sie Ihre Android-Apps in Android Studio, über die Befehlszeile auf Ihrem Computer oder auf Computern erstellen können, auf denen Android Studio nicht installiert ist, z. B. Continuous-Integration-Server.
Wenn Sie Android Studio nicht verwenden, können Sie Ihre App über die Befehlszeile erstellen und ausführen. Die Ausgabe des Builds ist unabhängig davon, ob Sie ein Projekt über die Befehlszeile, auf einem Remote-Computer oder mit Android Studio erstellen.
Hinweis:Da Gradle und das Android-Gradle-Plug-in unabhängig von Android Studio ausgeführt werden, müssen Sie die Build-Tools separat aktualisieren. In den Versionshinweisen erfahren Sie, wie Sie Gradle und das Android-Gradle-Plug-in aktualisieren.
Dank der Flexibilität des Android-Build-Systems können Sie benutzerdefinierte Build-Konfigurationen erstellen, ohne die zentralen Quelldateien Ihrer App zu ändern. Auf dieser Seite wird erklärt, wie das Android-Build-System funktioniert und wie du damit mehrere Build-Konfigurationen anpassen und automatisieren kannst. Weitere Informationen zum Bereitstellen Ihrer App finden Sie unter App erstellen und ausführen. Wie Sie benutzerdefinierte Build-Konfigurationen mit Android Studio sofort erstellen, erfahren Sie unter Build-Varianten konfigurieren.
Der Build-Prozess
Der Build-Prozess umfasst viele Tools und Prozesse, die Ihr Projekt in ein Android Application Package (APK) oder Android App Bundle (AAB) konvertieren.
Ein Großteil des Build-Prozesses wird vom Android-Gradle-Plug-in übernommen. Es kann jedoch hilfreich sein, bestimmte Aspekte des Build-Prozesses zu verstehen, damit Sie den Build an Ihre Anforderungen anpassen können.
Unterschiedliche Projekte können unterschiedliche Build-Ziele haben. Beispielsweise werden mit dem Build für eine Bibliothek eines Drittanbieters Bibliotheken für Android Archive (AAR) oder Java Archive (JAR) erstellt. Eine Anwendung ist jedoch der häufigste Projekttyp. Der Build für ein Anwendungsprojekt erzeugt ein Debug- oder Release-APK oder AAB Ihrer Anwendung, das Sie für externe Nutzer bereitstellen, testen oder freigeben können.
Diese Seite konzentriert sich auf die Anwendungsentwicklung, aber viele der Build-Schritte und -Konzepte sind bei den meisten Build-Typen üblich.
Android-Build-Glossar
Mit Gradle und dem Android-Gradle-Plug-in können Sie die folgenden Aspekte Ihres Builds konfigurieren:
- Build-Typen
-
Build-Typen definieren bestimmte Attribute, die Gradle beim Erstellen und Packen Ihrer App verwendet. Build-Typen werden in der Regel für verschiedene Phasen des Entwicklungslebenszyklus konfiguriert.
Der Build-Typ „Debug“ aktiviert beispielsweise Fehlerbehebungsoptionen und signiert die App mit dem Fehlerbehebungsschlüssel, während der Build-Typ des Release Ihre App für die Verteilung verkleinern, verschleiern und mit einem Releaseschlüssel signieren kann.
Du musst mindestens einen Build-Typ definieren, um deine App zu erstellen. In Android Studio werden die Build-Typen für die Fehlerbehebung und den Release standardmäßig erstellt. Informationen zum Anpassen der Paketeinstellungen für Ihre Anwendung finden Sie unter Build-Typen konfigurieren.
- Produktaromen
- Die Produktvarianten repräsentieren verschiedene Versionen deiner App, die du für Nutzer veröffentlichen kannst, z. B. kostenlose und kostenpflichtige Versionen. Sie können Produktvarianten so anpassen, dass sie unterschiedlichen Code und andere Ressourcen verwenden. Gleichzeitig können Sie die Teile, die in allen Versionen Ihrer App verwendet werden, gemeinsam nutzen und wiederverwenden. Produktvarianten sind optional und müssen manuell erstellt werden. Hier erfährst du, wie du Produktvarianten konfigurieren, um verschiedene Versionen deiner App zu erstellen.
- Varianten erstellen
- Eine Build-Variante ist eine produktübergreifende Build-Typ- und Produkt-Flavor und die Konfiguration, mit der Gradle Ihre App erstellt. Mit Build-Varianten können Sie die Debug-Version Ihrer Produktvarianten während der Entwicklung und signierte Releaseversionen Ihrer Produktvarianten für den Vertrieb erstellen. Obwohl Sie Build-Varianten nicht direkt konfigurieren, konfigurieren Sie 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 unter Build-Varianten konfigurieren.
- Manifesteinträge
- Sie können in der Konfiguration der Build-Variante Werte für einige Attribute der Manifestdatei angeben. Diese Build-Werte überschreiben die vorhandenen Werte in der Manifestdatei. Dies ist nützlich, wenn Sie mehrere Varianten Ihrer App mit einem anderen Anwendungsnamen, einer anderen SDK-Mindestversion oder einer anderen SDK-Zielversion generieren möchten. Wenn mehrere Manifeste vorhanden sind, führt das Tool für die Manifestzusammenführung die Manifesteinstellungen zusammen.
- Abhängigkeiten
- Das Build-System verwaltet Projektabhängigkeiten von Ihrem lokalen Dateisystem und von Remote-Repositories. Das bedeutet, dass Sie die Binärpakete der Abhängigkeiten nicht manuell suchen, herunterladen und in Ihr Projektverzeichnis kopieren müssen. Weitere Informationen finden Sie unter Build-Abhängigkeiten hinzufügen.
- Unterschreiben
- Mit dem Build-System können Sie Signatureinstellungen in der Build-Konfiguration festlegen und Ihre Anwendung während des Build-Prozesses automatisch signieren. Das Build-System signiert die Debug-Version mit einem Standardschlüssel und einem Standardzertifikat unter Verwendung bekannter Anmeldedaten, um eine Passwortabfrage bei der Build-Erstellung zu vermeiden. Das Build-System signiert die Release-Version nur, wenn Sie explizit eine Signaturkonfiguration für diesen Build definieren. Wenn du keinen Releaseschlüssel hast, kannst du einen generieren, wie unter App signieren beschrieben. Signierte Release-Builds sind für den Vertrieb von Apps über die meisten App-Shops erforderlich.
- Verkleinerung von Code und Ressourcen
- Im Build-System können Sie für jede Build-Variante eine andere ProGuard-Regeldatei angeben. Beim Erstellen der Anwendung wendet das Build-System die entsprechenden Regeln zum Verkleinern des Codes und der Ressourcen mit den integrierten Tools zum Schrumpfen an, z. B. R8. Wenn Sie den Code und die Ressourcen verkleinern, können Sie die APK- oder AAB-Größe verringern.
- Unterstützung mehrerer APKs
- Mit dem Build-System kannst du automatisch verschiedene APKs erstellen, die jeweils nur den Code und die Ressourcen enthalten, die für eine bestimmte Bildschirmdichte oder ein Application Binary Interface (ABI) erforderlich sind. Weitere Informationen findest du unter Mehrere APKs erstellen. Die Veröffentlichung eines einzelnen AAB ist jedoch der empfohlene Ansatz, da es neben Bildschirmdichte und ABI eine Aufteilung nach Sprache ermöglicht und dabei nicht mehrere Artefakte bei Google Play hochgeladen werden müssen. Alle neuen Anwendungen, 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 beidem geschrieben ist, müssen Sie an mehreren Stellen eine JDK- oder 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 Domain Specific Language (DSL), um die Build-Logik mithilfe eines Kotlin-Skripts zu beschreiben und zu bearbeiten. Dies ist eine Variante der Kotlin-Sprache. Sie können auch Groovy verwenden, eine dynamische Sprache für die Java Virtual Machine (JVM), um Ihre Builds zu konfigurieren.
Sie benötigen weder Kotlin-Script noch Groovy, um mit der Konfiguration Ihres Builds zu beginnen, da das Android-Gradle-Plug-in die meisten der benötigten DSL-Elemente enthält. Weitere Informationen zum Android-Gradle-Plug-in DSL finden Sie in der DSL-Referenzdokumentation. Das Kotlin-Skript basiert außerdem auf dem zugrunde liegenden Gradle Kotlin DSL.
Wenn Sie ein neues Projekt starten, erstellt Android Studio automatisch einige dieser Dateien für Sie und füllt sie basierend auf sinnvollen Standardwerten aus. Die Projektdateistruktur hat das folgende Layout:
└── MyApp/ # Project
├── gradle/
│ └── wrapper/
│ └── gradle-wrapper.properties
├── build.gradle(.kts)
├── settings.gradle(.kts)
└── app/ # Module
├── build.gradle(.kts)
└── build/
├── libs/
└── src/
└── main/ # Source set
├── java/
│ └── com.example.myapp
├── res/
│ ├── drawable/
│ ├── values/
│ └── ...
└── AndroidManifest.xml
Es gibt einige Gradle-Build-Konfigurationsdateien, die Teil der Standard-Projektstruktur für eine Android-App sind. Bevor Sie mit der Konfiguration Ihres Builds beginnen können, müssen Sie den Umfang und Zweck der einzelnen Dateien sowie die grundlegenden DSL-Elemente kennen, die sie definieren.
Gradle-Wrapper-Datei
Der Gradle-Wrapper (gradlew) ist eine kleine Anwendung, die in Ihrem Quellcode enthalten ist und mit der Gradle heruntergeladen und gestartet wird.
Dies sorgt für eine einheitlichere Build-Ausführung. Entwickler laden die Anwendungsquelle herunter und führen gradlew aus. Dadurch wird die erforderliche Gradle-Distribution heruntergeladen und Gradle gestartet, um Ihre Anwendung zu erstellen.
Die Datei gradle/wrapper/gradle-wrapper.properties enthält das Attribut distributionUrl, das beschreibt, mit welcher Version von Gradle Ihr Build ausgeführt 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
Gradle-Einstellungsdatei
Die Datei settings.gradle.kts (für Kotlin-DSL) oder settings.gradle (für Groovy DSL) befindet sich im Stammverzeichnis des Projekts. In dieser Datei mit den Einstellungen sind die Repository-Einstellungen auf Projektebene definiert. Außerdem wird Gradle mitgeteilt, welche Module beim Erstellen Ihrer App enthalten sein sollen. In 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. The code below
* defines 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")
Groovig
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. The code below
* defines 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'
Build-Datei der obersten Ebene
Die Datei build.gradle.kts der obersten Ebene (für Kotlin-DSL) oder build.gradle (für Groovy DSL) befindet sich im Stammverzeichnis des Projekts. Sie definiert in der Regel die gängigen Versionen von Plug-ins, die von Modulen in Ihrem Projekt verwendet werden.
Im folgenden Codebeispiel werden die Standardeinstellungen und DSL-Elemente im Build-Skript der obersten Ebene beschrieben, nachdem ein neues Projekt erstellt wurde:
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.3.0" apply false
id("com.android.library") version "8.3.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}
Groovig
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.3.0' apply false
id 'com.android.library' version '8.3.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}
Build-Datei auf Modulebene
Die build.gradle.kts-Datei (für Kotlin-DSL) oder die build.gradle-Datei (für Groovy DSL) auf Modulebene befindet sich in jedem project/module/-Verzeichnis. Sie können damit Build-Einstellungen für das jeweilige Modul konfigurieren, in dem es sich befindet. Wenn Sie diese Build-Einstellungen konfigurieren, können Sie benutzerdefinierte Paketoptionen bereitstellen, z. B. zusätzliche Build-Typen und Produktvarianten, und die Einstellungen im App-Manifest main/ oder im Build-Script auf oberster Ebene überschreiben.
Android SDK-Einstellungen
Die Build-Datei auf Modulebene für Ihre App enthält Einstellungen für die Android SDK-Versionen, die beim Kompilieren verwendet werden, sowie die Auswahl des Plattformverhaltens und die Mindestversion, auf der Ihre App ausgeführt wird.
-
compileSdk -
compileSdkbestimmt, welche Android- und Java APIs beim Kompilieren des Quellcodes verfügbar sind. Verwende beim Kompilieren das neueste Android SDK, um die neuesten Android-Funktionen nutzen zu können.Einige APIs der Android-Plattform sind in älteren API-Ebenen möglicherweise nicht verfügbar. Du kannst die Nutzung neuerer Funktionen bedingt einschränken oder AndroidX-Kompatibilitätsbibliotheken verwenden, um neuere Funktionen mit niedrigeren Android API-Levels zu nutzen.
Jedes Android SDK stellt eine Teilmenge von Java APIs zur Verwendung in Ihrer Anwendung bereit. In der Tabelle Welche Java APIs kann ich in meinem Java- oder Kotlin-Quellcode verwenden? sehen Sie, welches Java API-Level je nach Android SDK-Version verfügbar ist. Die neueren Java APIs werden in früheren Android-Versionen durch das Desugaring unterstützt. Dies muss in Ihrem Build aktiviert sein.
In Android Studio werden Warnungen angezeigt, wenn
compileSdkmit der aktuellen Version von Android Studio, AGP oder den Anforderungen an Bibliothekenabhängigkeiten Ihres Projekts in Konflikt steht. -
minSdk -
minSdkgibt die niedrigste Android-Version an, die deine App unterstützen soll. Mit der EinstellungminSdkwird eingeschränkt, auf welchen Geräten deine App installiert werden kann.Die Unterstützung niedrigerer Versionen von Android erfordert möglicherweise mehr bedingte Prüfungen in Ihrem Code oder eine vermehrte Verwendung 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 Prozentsätze für die aktuelle Versionsnutzung finden Sie im Versionsdiagramm 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, warnt Lint vor von Ihnen verwendeten APIs, die nicht in der
minSdkverfügbar sind. Du solltest diese Probleme beheben, indem du neuere Funktionen bedingt machst oderAppcompatfür die Abwärtskompatibilität verwendest. -
targetSdk -
targetSdkdient zwei Zwecken:- Damit wird das Laufzeitverhalten der Anwendung festgelegt.
- Es bestätigt, mit welcher Android-Version Sie getestet haben.
Wenn du ein Gerät mit einer höheren Android-Version als
targetSdkverwendest, führt Android deine App in einem Kompatibilitätsmodus aus, der sich ähnlich verhält wie die niedrigere Version, die intargetSdkangegeben ist. Als mit API 23 beispielsweise das Laufzeitberechtigungsmodell eingeführt wurde, waren nicht alle Anwendungen bereit, es sofort anzuwenden. Wenn dutargetSdkauf 22 setzt, können diese Apps auf API 23-Geräten ohne Laufzeitberechtigungen ausgeführt werden und die in der neuestencompileSdk-Version enthaltenen Funktionen nutzen. Die Google Play-Verteilungsrichtlinie erzwingt zusätzliche Richtlinien auf dem Ziel-API-Level.Der Wert von
targetSdkmuss kleiner oder gleich dem voncompileSdksein.
Hinweis: Die Werte von compileSdk und targetSdk müssen nicht identisch sein. Beachten Sie die folgenden Grundprinzipien:
compileSdkbietet Zugriff auf neue APIstargetSdklegt das Laufzeitverhalten der App festtargetSdkmuss kleiner oder gleichcompileSdksein.
Beispiel-Build-Script für App-Modul
In diesem Beispielskript für das Erstellen eines Android-App-Moduls 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.6.1")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Groovig
/**
* 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.6.1'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Gradle-Attributdateien
Gradle enthält außerdem zwei Attributdateien im Stammverzeichnis des Projekts, mit denen Sie Einstellungen für das Gradle-Build-Toolkit selbst festlegen 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 die Attribute der lokalen Umgebung für das Build-System, darunter:
ndk.dir: Pfad zum NDK. Dieses Attribut wurde eingestellt. Alle heruntergeladenen Versionen des NDK werden im Verzeichnisndkdes Android SDK-Verzeichnisses installiert.sdk.dir– Pfad zum Android SDKcmake.dir– Pfad zu CMake.ndk.symlinkdir: Erstellt in Android Studio 3.5 und höher einen Symlink zum NDK, der kürzer als der installierte NDK-Pfad sein kann.
Ordnen Sie den NDK einem kürzeren Pfad zu (nur Windows)
In Windows haben Tools im installierten NDK-Ordner, z. B. ld.exe, lange Pfade. Lange Pfade werden von den Tools eher schlecht unterstützt.
Wenn Sie einen kürzeren Pfad erstellen möchten, legen Sie in local.properties das Attribut ndk.symlinkdir fest. Damit wird angefordert, dass das Android-Gradle-Plug-in einen Symlink zum NDK erstellt. Der Pfad dieses Symlinks kann kürzer sein als der vorhandene NDK-Ordner.
Beispielsweise ergibt ndk.symlinkdir = C:\ den folgenden Symlink: C:\ndk\19.0.5232133
Projekt mit Gradle-Dateien synchronisieren
Wenn Sie Änderungen an den Build-Konfigurationsdateien in Ihrem Projekt vornehmen, müssen Sie in Android Studio Ihre Projektdateien synchronisieren, damit Ihre Build-Konfigurationsänderungen importiert und einige Prüfungen durchgeführt werden können, um sicherzustellen, dass Ihre Konfiguration keine Build-Fehler verursacht.
Klicken Sie zum Synchronisieren Ihrer Projektdateien in der Benachrichtigungsleiste, die angezeigt wird, wenn Sie eine Änderung vornehmen, auf Jetzt synchronisieren (siehe Abbildung 1) oder klicken Sie in der Menüleiste auf Projekt synchronisieren 
. Wenn Android Studio Fehler in Ihrer Konfiguration findet – z. B. wenn im Quellcode API-Funktionen verwendet werden, die nur auf einer API-Ebene verfügbar sind, die höher als compileSdkVersion ist –, wird das Problem im Fenster Messages beschrieben.
Quellsätze
Android Studio gruppiert Quellcode und Ressourcen für jedes Modul logisch in Quellsätze. Wenn Sie ein neues Modul erstellen, erstellt Android Studio eine main/-Quelle innerhalb des Moduls. Der Quellsatz main/ eines Moduls enthält den Code und die Ressourcen, die von allen Build-Varianten verwendet werden.
Zusätzliche Quellsatzverzeichnisse sind optional und werden von Android Studio nicht automatisch für Sie erstellt, wenn Sie neue Build-Varianten konfigurieren. Das Erstellen von Quellsätzen, ähnlich wie bei main/, hilft jedoch dabei, Dateien und Ressourcen zu organisieren, die Gradle nur zum Erstellen bestimmter Versionen Ihrer Anwendung verwenden sollte:
-
src/main/ - Dieser Quellcode enthält Code und Ressourcen, die alle Build-Varianten gemeinsam haben.
-
src/buildType/ - Erstellen Sie diesen Quellsatz so, dass er Code und Ressourcen nur für einen bestimmten Build-Typ enthält.
-
src/productFlavor/ -
Erstellen Sie diese Quellgruppe so, dass sie Code und Ressourcen nur für eine bestimmte Produktvariante enthält.
Hinweis: Wenn Sie Ihren Build so konfigurieren, dass mehrere Produktvarianten kombiniert werden, können Sie Quellsatzverzeichnisse für jede Kombination von Produktvarianten zwischen den Flavor-Dimensionen erstellen:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Erstellen Sie diesen Quellsatz, damit er Code und Ressourcen nur für eine bestimmte Build-Variante enthält.
Um beispielsweise die Version „fullDebug“ Ihrer Anwendung zu generieren, führt das Build-System Code, Einstellungen und Ressourcen aus den folgenden Quellsätzen zusammen:
-
src/fullDebug/(Quellsatz der Build-Variante) -
src/debug/(Quellsatz des Build-Typs) -
src/full/(der Quellsatz für Produktgeschmack) -
src/main/(Hauptquellsatz)
Hinweis: Wenn Sie eine neue Datei oder ein neues Verzeichnis in Android Studio erstellen, verwenden Sie die Menüoptionen Datei > Neu, um die Datei oder das Verzeichnis für einen bestimmten Quellsatz zu erstellen. Die Quellsätze, aus denen Sie auswählen können, basieren auf Ihren Build-Konfigurationen. Android Studio erstellt die erforderlichen Verzeichnisse automatisch, sofern 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. Quellsätze auf der linken Seite überschreiben die Dateien und Einstellungen der Quellsätze auf der rechten Seite:
Build-Variante > Build-Typ > Produkt-Flavor > Hauptquellsatz > Bibliotheksabhängigkeiten
So kann Gradle Dateien verwenden, die für die Build-Variante, die Sie erstellen möchten, spezifisch sind. Gleichzeitig werden Aktivitäten, Anwendungslogik und Ressourcen, die in anderen Versionen Ihrer App verwendet werden, wiederverwendet.
Beim Zusammenführen mehrerer Manifeste verwendet Gradle dieselbe Prioritätsreihenfolge, sodass mit jeder Build-Variante unterschiedliche Komponenten oder Berechtigungen im endgültigen Manifest definiert werden können. Weitere Informationen zum Erstellen benutzerdefinierter Quellsätze finden Sie unter Quellsätze erstellen.
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 die Verwendung eines Versionskatalogs oder einer Stückliste, um die gemeinsamen Versionen anzugeben.
Andere Build-Systeme
Das Erstellen von Android-Apps mit Bazel ist möglich, wird aber nicht offiziell unterstützt. Android Studio unterstützt offiziell keine Qwiklabs-Projekte.
Weitere Informationen zu den aktuellen Einschränkungen beim Erstellen von Builds mit Looker finden Sie in den bekannten Problemen.