Das Android-Build-System kompiliert App-Ressourcen, Quellcode und Pakete in APKs oder Android App Bundles umwandeln, die Sie testen, bereitstellen, signieren und zu verteilen.
Android Studio nutzt Gradle, ein erweitertes Build-Toolkit, um und den Build-Prozess verwalten und gleichzeitig flexible, benutzerdefinierte Build-Konfigurationen zu erstellen. Für jede Build-Konfiguration kann ein eigener Codesatz definiert werden und Ressourcen, während Sie die Teile wiederverwenden, die alle Versionen Ihrer App gemeinsam haben. Das Gradle-Plug-in für Android arbeitet mit dem Build-Toolkit Prozessen und konfigurierbaren Einstellungen für das Erstellen und Testen Android-Apps.
Gradle und das Android-Gradle-Plug-in laufen unabhängig von Android Studio. Dieses Das bedeutet, dass ihr eure Android-Apps in Android Studio, dem oder auf Geräten, auf denen Android Studio nicht z. B. auf Continuous-Integration-Servern.
Wenn Sie nicht In Android Studio erfahren Sie, wie Sie Ihre App über über die Befehlszeile. Die Ausgabe des Builds ist immer gleich, Erstellen eines Projekts über die Befehlszeile, auf einem Remote-Computer oder mithilfe von Android Studio
Hinweis:Da Gradle und das Android-Gradle-Plug-in unabhängig von Android Studio, müssen Sie die Build-Tools separat. In den Versionshinweisen erfahren Sie, wie Sie Gradle aktualisieren. und das Android-Gradle-Plug-in.
Dank der Flexibilität des Android-Build-Systems können Sie Sie können Konfigurationen erstellen, ohne die Hauptquelldateien Ihrer App zu ändern. Dieses erfahren Sie, wie das Android-Build-System funktioniert können Sie damit mehrere Build-Konfigurationen anpassen und automatisieren. Wenn Sie Weitere Informationen zum Bereitstellen Ihrer App finden Sie unter App erstellen und ausführen. So erstellen Sie ein benutzerdefiniertes Konfigurationen sofort erstellen mit Android Studio, siehe Build konfigurieren Varianten.
Der Erstellungsprozess
Der Build-Prozess umfasst viele Tools und Prozesse, die Ihr Projekt umwandeln in ein Android Application Package (APK) oder Android App Bundle (AAB).
Einen Großteil des Build-Prozesses übernimmt das Android-Gradle-Plug-in, ist es nützlich, bestimmte Aspekte des Build-Prozesses zu verstehen, damit Sie die Ihren Anforderungen entsprechen.
Verschiedene Projekte können unterschiedliche Build-Ziele haben. Der Build für eine Die Drittanbieterbibliothek produziert Android Archive (AAR) oder Java Archive (JAR) Bibliotheken. Eine Anwendung ist jedoch der häufigste Projekttyp und der Build für eine Anwendung ein Debug- oder Release-APK oder AAB Ihrer App erstellt, das Sie bereitstellen können. testen oder für externe Nutzer freigeben.
Auf dieser Seite geht es um die App-Entwicklung, aber viele der Build-Schritte und -Konzepte sind den meisten Build-Typen gleich.
Android-Build-Glossar
Mit Gradle und dem Android-Gradle-Plug-in können Sie die folgenden Aspekte konfigurieren: Ihres Builds:
- Build-Typen
-
Build-Typen definieren bestimmte Attribute, die Gradle beim Erstellen und der App-Paketerstellung. Build-Typen werden in der Regel für verschiedene Ihres Entwicklungslebenszyklus.
Der Build-Typ für die Fehlerbehebung aktiviert die Optionen zur Fehlerbehebung und signiert die App mit dem Schlüssel, während die App Der Release-Build-Typ kann deine App verkleinern, verschleiern und mit einem Release signieren Schlüssel für die Verteilung.
Sie müssen mindestens einen Build-Typ definieren, Ihre App zu entwickeln. Android Studio erstellt die Build-Typen für die Fehlerbehebung und den Release ist standardmäßig aktiviert. Informationen zum Anpassen der Paketeinstellungen für Ihre App Build-Konfiguration .
- Produktgeschmack
- Produktvarianten repräsentieren verschiedene Versionen Ihrer App, die Sie für Nutzer freigeben, z. B. kostenlose und kostenpflichtige Versionen. Sie können Produktvarianten anpassen, um beim Teilen unterschiedliche Codes und Ressourcen zu verwenden und die Teile wiederverwenden, die alle Versionen Ihrer App gemeinsam haben. Produkt Flavors sind optional und müssen manuell erstellt werden. So gehts verschiedene Versionen Ihrer App verfügbar sind, finden Sie hier Informationen zur Produktgeschmack.
- Build-Varianten
- Eine Build-Variante ist ein produktübergreifendes ist die Konfiguration, mit der Gradle Ihre App erstellt. Anhand von Build-Varianten können Sie die Debug-Version Ihrer Produkt-Varianten während der Entwicklung und unterzeichnete Release-Versionen Ihrer Produkt-Geschmacksrichtungen für den Vertrieb. Build-Varianten werden zwar nicht direkt konfiguriert, und Produktaromen zu entwickeln. Zusätzlicher Build wird erstellt oder Produkt-Geschmacksrichtungen erzeugt außerdem zusätzliche Build-Varianten. Weitere Informationen Build-Varianten konfigurieren Übersicht.
- Manifesteinträge
- Sie können Werte für einige Attribute der Manifestdatei im Build angeben. Konfiguration der Variante. Diese Build-Werte überschreiben die vorhandenen Werte in der Manifestdatei. Dies ist nützlich, wenn Sie mehrere Varianten generieren möchten der App durch einen anderen App-Namen, die SDK-Mindestversion oder SDK-Zielversion. Wenn mehrere Manifeste vorhanden sind, Merger-Tool führt Manifest-Einstellungen zusammen.
- Abhängigkeiten
- Das Build-System verwaltet Projektabhängigkeiten von Ihrem lokalen Dateisystem aus und aus Remote-Repositories. Sie müssen also nicht manuell Binärpakete Ihrer Abhängigkeiten suchen, herunterladen und in Ihr Projektverzeichnis. Weitere Informationen finden Sie unter Build hinzufügen Abhängigkeiten.
- Signieren
- Mit dem Build-System können Sie Signatureinstellungen im Build angeben und Ihre App während des Build-Prozesses automatisch signieren kann. . Das Build-System signiert die Debug-Version mit einem Standardschlüssel und Zertifikat mit bekannten Anmeldedaten, um eine Passwortaufforderung beim Build zu vermeiden . Das Build-System signiert die Release-Version nur, wenn Sie explizit eine Signaturkonfiguration für diesen Build zu definieren. Wenn Sie keine Releaseschlüssel haben, können Sie einen erstellen. Weitere Informationen dazu finden Sie unter App signieren. 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 eine andere ProGuard-Regeldatei für für jede Build-Variante. Beim Erstellen Ihrer App wendet das Build-System die entsprechenden Regelsatz zum Verkleinern Ihren Code und Ihre Ressourcen mithilfe der integrierten Tools zum Verkleinern (z. B. R8) zu reduzieren. Durch das Verkleinern von Code und Ressourcen lässt sich die APK- oder AAB-Größe verringern.
- Unterstützung mehrerer APKs
- Mit dem Build-System können Sie automatisch verschiedene APKs erstellen, die enthalten jeweils nur den Code und die Ressourcen, für eine bestimmte Bildschirmdichte oder Binärschnittstelle (Application Binary Interface, ABI) suchen. Weitere Informationen finden Sie unter Mehrere APKs erstellen Die Veröffentlichung eines einzigen AAB empfohlenen Ansatz, da die Aufteilung nach Sprache zusätzlich zur Bildschirmdichte und ABI-Wert unter Berücksichtigung von mehrere Artefakte bei Google Play zu präsentieren. Alle neuen Apps, die nach August 2021 eingereicht werden sind erforderlich, um AABs zu verwenden.
Java-Versionen in Android-Builds
Unabhängig davon, ob Ihr Quellcode in Java, Kotlin oder beidem geschrieben ist, Es gibt mehrere Stellen, an denen Sie die Sprache JDK oder Java auswählen müssen Version für Ihren Build. Siehe Java-Versionen in Android-Builds .
Build-Konfigurationsdateien
Um benutzerdefinierte Build-Konfigurationen zu erstellen, müssen Sie Änderungen an einer oder weitere Build-Konfigurationsdateien. Diese Nur-Text-Dateien verwenden Domain Specific Language (DSL), um wie Sie die Build-Logik mit Kotlin-Script eine Variante der Kotlin-Sprache. Sie können auch Groovy, dynamische Sprache für die Java Virtual Machine (JVM) zur Konfiguration Ihrer Builds verwenden.
Sie brauchen keine Kotlin- oder Groovy-Kenntnisse, um mit der Konfiguration da das Android-Gradle-Plug-in die meisten DSL-Elemente einführt, die Sie brauchen. Weitere Informationen zum Android-Gradle-Plug-in DSL finden Sie in der DSL-Referenzdokumentation Das Kotlin-Skript benötigt außerdem die zugrunde liegenden Gradle Kotlin DSL
Beim Starten eines neuen Projekts erstellt Android Studio automatisch einige diese Dateien für Sie und füllt sie basierend auf sinnvollen Standardwerten. Das Projekt Dateistruktur das folgende Layout hat:
└── 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 des Standard-Projektstruktur für eine Android-App. Bevor Sie beginnen können Konfiguration Ihres Builds kennen, ist es wichtig, den Umfang und Zweck der einzelnen Dateien und der von ihnen definierten DSL-Basiselemente.
Gradle-Wrapper-Datei
Der Gradle-Wrapper (gradlew) ist eine kleine Anwendung, die in Ihrem
Quellcodes, der Gradle herunterlädt und startet.
Dies sorgt für eine einheitlichere Build-Ausführung. Entwickler laden die
Anwendungsquelle und führen Sie gradlew aus. Dadurch wird der erforderliche Gradle-Code heruntergeladen.
Distribution und startet Gradle zum Erstellen Ihrer Anwendung.
Die Datei gradle/wrapper/gradle-wrapper.properties
enthält die Eigenschaft distributionUrl, die beschreibt, welche Version von
Gradle wird verwendet, um Ihren Build auszuführen.
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
Die Datei settings.gradle (für Groovy DSL) befindet sich
Projektverzeichnis. Mit dieser Einstellungsdatei wird ein Repository auf Projektebene definiert
Einstellungen und gibt Gradle an, welche Module beim Erstellen
Bei Projekten mit mehreren Modulen muss jedes Modul angegeben werden, das im
und der endgültigen Fertigstellung.
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")
Cool
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'
Die Build-Datei der obersten Ebene
Die Datei build.gradle.kts der obersten Ebene (für Kotlin DSL) oder
Die Datei build.gradle (für Groovy DSL) befindet sich
Projektverzeichnis. In der Regel werden die gängigen Plug-in-Versionen definiert.
nach Modulen in Ihrem Projekt.
Im folgenden Codebeispiel werden die Standardeinstellungen und DSL-Elemente in das übergeordnete Build-Skript, nachdem Sie ein neues Projekt erstellt haben:
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.5.0" apply false
id("com.android.library") version "8.5.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}
Cool
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.5.0' apply false
id 'com.android.library' version '8.5.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}
Build-Datei auf Modulebene
build.gradle.kts auf Modulebene (für Kotlin DSL) oder
Die Datei build.gradle (für die Groovy DSL) befindet sich jeweils
project/module/. Damit können Sie
die Build-Einstellungen für das Modul konfigurieren, in dem es sich befindet. Wird konfiguriert
Build-Einstellungen können Sie benutzerdefinierte Paketoptionen wie
zusätzliche Build-Typen und Produkt-Geschmacksrichtungen und überschreiben Sie die Einstellungen in den
main/ App-Manifest oder Build-Skript der obersten Ebene.
Android SDK-Einstellungen
Die Build-Datei auf Modulebene für Ihre Anwendung enthält Einstellungen, die angeben, Android SDK-Versionen, die beim Kompilieren, Auswählen des Plattformverhaltens und gibt die Mindestversion an, auf der Ihre Anwendung ausgeführt wird.
-
compileSdk -
compileSdkbestimmt, welche Android- und Java-APIs verwendet werden. wenn Sie Ihren Quellcode kompilieren. So verwendest du die neueste Android-Version: verwenden Sie bei der Kompilierung das neueste Android SDK.Einige APIs der Android-Plattform sind möglicherweise nicht verfügbar auf älteren API-Ebenen. Sie können <ph type="x-smartling-placeholder"></ph> die Nutzung neuerer Funktionen bedingt schützen oder <ph type="x-smartling-placeholder"></ph> AndroidX-Kompatibilitätsbibliotheken zur Verwendung neuerer Funktionen mit niedrigeren Android-API-Level.
Jedes Android-SDK stellt eine Teilmenge von Java-APIs zur Verwendung in Ihrer Anwendung bereit. Die Tabelle unter Welche Java APIs kann ich in meinem Java- oder Kotlin-Quellcode verwenden? zeigt an, welches Java-API-Level für die jeweilige Android SDK-Version verfügbar ist. Die neueren Java-APIs werden in früheren Versionen von Android durch deszuckers, der ebenfalls die in Ihrem Build aktiviert sind.
Android Studio zeigt Warnungen an, wenn
compileSdk-Konflikte auftreten mit der aktuellen Version von Android Studio, AGP oder der Bibliothek Ihres Projekts Abhängigkeitsanforderungen. -
minSdk -
Das
minSdkgibt die niedrigste Android-Version an, die du die Ihre App unterstützt. Durch Festlegen vonminSdkwird eingeschränkt, Geräte deine App installieren können.Zur Unterstützung niedrigerer Android-Versionen sind möglicherweise mehr bedingte Prüfungen erforderlich oder die Nutzung von AndroidX-Kompatibilitätsbibliotheken. Sie sollten die Wartungskosten für die Unterstützung niedrigerer Versionen der Nutzer, die noch die niedrigeren Versionen verwenden. Weitere Informationen finden Sie in der Versionsdiagramm im Assistenten für neue Projekte von Android Studio für die Prozentsätze der aktuellen Versionsnutzung.
Wenn Sie Ihren Code in Android Studio bearbeiten oder während der Ihres Builds warnt lint vor von Ihnen verwendeten APIs, die nicht in
minSdk. Sie sollten diese Probleme beheben, <ph type="x-smartling-placeholder"></ph> neue Funktionen bedingt machen oder <ph type="x-smartling-placeholder"></ph>Appcompatfür Abwärtskompatibilität. -
targetSdk -
targetSdkdient zwei Zwecken:- Sie legt das Laufzeitverhalten Ihrer Anwendung fest.
- Damit wird bestätigt, für welche Android-Version Sie getestet haben.
Wenn Ihr Gerät eine höhere Android-Version als Dein
targetSdk, Android führt deine App in einem Kompatibilitätsmodus aus die sich ähnlich wie die niedrigere in Ihrem KontotargetSdkAls z. B. API 23 die Laufzeit Berechtigungsmodell verwenden, waren nicht alle Apps für die sofortige Einführung bereit. Wenn dutargetSdkauf 22 setzt, können diese Apps auf API-23-Geräte ohne Laufzeitberechtigungen und könnten Funktionen nutzen in der neuesten Version voncompileSdkenthalten. Google Play Bereitstellungsrichtlinie erzwingt zusätzliche Richtlinien auf Ziel-API-Level.Der Wert von
targetSdkmuss kleiner oder gleich sein auf den voncompileSdk.
Hinweis: Die Werte von compileSdk und targetSdk
müssen nicht identisch sein. Beachten Sie dabei die folgenden Grundprinzipien:
- Mit
compileSdkerhalten Sie Zugriff auf neue APIs targetSdklegt das Laufzeitverhalten der Anwendung festtargetSdkmuss kleiner oder gleichcompileSdksein
Beispiel für ein Build-Script des App-Moduls
Dieses Beispiel-Build-Skript für ein Android-App-Modul der DSL-Basiselemente und -einstellungen an:
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.0")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Cool
/**
* 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.0'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Gradle-Attributdateien
Gradle enthält außerdem zwei Attributdateien, die sich in Ihrem Stammprojekt befinden , in dem Sie die Einstellungen für das Gradle-Build-Toolkit festlegen können. selbst:
-
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 lokale Umgebungsattribute für das Build-System, einschließlich der
Folgendes:
<ph type="x-smartling-placeholder">
- </ph>
ndk.dir: Pfad zum NDK. Diese Eigenschaft wurde eingestellt. Alle heruntergeladenen Versionen des NDK werden imndkim Android SDK-Verzeichnis.sdk.dir: Pfad zum Android SDK.cmake.dir– Pfad zu CMake.ndk.symlinkdir: In Android Studio 3.5 und höher erstellt einen Symlink zum NDK, der kürzer sein kann als das installierte NDK-Pfad.
Ordnen Sie das NDK einem kürzeren Pfad zu (nur Windows)
Unter Windows haben Tools im installierten NDK-Ordner, z. B. ld.exe, am Ende
langen Pfaden. Lange Pfade werden von den Tools nicht gut unterstützt.
Wenn Sie einen kürzeren Pfad erstellen möchten, legen Sie in local.properties das Attribut fest
ndk.symlinkdir, um anzufordern, dass das Android-Gradle-Plug-in einen Symlink zu
das NDK. Der Pfad dieses Symlink kann kürzer sein als der vorhandene NDK-Ordner.
Beispielsweise führt ndk.symlinkdir = C:\ zu folgendem Symlink:
C:\ndk\19.0.5232133
Projekt mit Gradle-Dateien synchronisieren
Wenn Sie Änderungen an den Build-Konfigurationsdateien in Ihrem Projekt vornehmen, In Android Studio müssen Sie Ihre Projektdateien synchronisieren, die Build-Konfigurationsänderungen importieren und überprüfen, ob Ihr keine Build-Fehler verursacht.
Klicke zum Synchronisieren deiner Projektdateien auf Jetzt synchronisieren
die angezeigt wird, wenn Sie eine Änderung vornehmen, z. B.
Abbildung 1 oder klicken Sie auf Projekt synchronisieren 
aus. Wenn Android Studio Fehler in Ihrem
Konfiguration haben. Ihr Quellcode verwendet beispielsweise API-Funktionen,
verfügbar in einem API-Level, das höher als dein compileSdkVersion ist
– Im Fenster Nachrichten wird das Problem beschrieben.
<ph type="x-smartling-placeholder">Quellsätze
Android Studio gruppiert Quellcode und Ressourcen für jedes Modul logisch
in Quellsätze. Wenn Sie ein neues Modul erstellen,
erstellt eine main/-Quelle im Modul. Die
Das main/-Quellset enthält den Code und die Ressourcen, die von allen zugehörigen
zu erstellen.
Zusätzliche Quellsatzverzeichnisse sind optional und Android
Studio erstellt sie nicht automatisch, wenn Sie einen neuen Build konfigurieren.
Varianten. Das Erstellen von Quellsätzen ähnlich wie main/ hilft jedoch
Dateien und Ressourcen organisieren, die Gradle nur beim Erstellen bestimmter
Versionen Ihrer App:
-
src/main/ - Dieser Quellcode enthält Code und Ressourcen, die allen Build-Varianten gemeinsam sind.
-
src/buildType/ - Erstellen Sie diesen Quellsatz, um Code und Ressourcen nur für einen bestimmten Build-Typ.
-
src/productFlavor/ -
Erstellen Sie diesen Quellsatz, um Code und Ressourcen nur für einen bestimmten
Produktgeschmack.
Hinweis:Wenn Sie Ihren Build für die Kombination mehrerer Produktvarianten verwenden, können Sie Quellsatzverzeichnisse für jede Kombination von Produktaromen zwischen den Geschmacksdimensionen:
src/productFlavor1ProductFlavor2/ -
src/productFlavorBuildType/ - Erstellen Sie diesen Quellsatz, um Code und Ressourcen nur für einen bestimmten Build-Variante.
Um beispielsweise den Parameter "fullDebug" Version deiner App, der „build system“ führt Code, Einstellungen und Ressourcen aus den folgenden Quellsätzen zusammen:
-
src/fullDebug/(der Quellsatz der Build-Variante) -
src/debug/(der Quellsatz des Build-Typs) -
src/full/(die Gruppe der Geschmacksquellen des Produkts) -
src/main/(die Hauptquellengruppe)
Hinweis:Wenn Sie in Android eine neue Datei oder ein neues Verzeichnis erstellen Studio verwenden, verwenden Sie den Link Datei > Neu Menüoptionen zum Erstellen von für einen bestimmten Quellensatz. Die zur Auswahl stehenden Quellsätze basieren auf und Android Studio erstellt automatisch die erforderlichen Verzeichnissen, falls diese noch nicht vorhanden sind.
Wenn verschiedene Quellsätze unterschiedliche Versionen derselben Datei enthalten, kann Gradle verwendet die folgende Prioritätsreihenfolge bei der Entscheidung, welche Datei verwendet werden soll. Quelle Gruppen auf der linken Seite überschreiben die Dateien und Einstellungen der Quellgruppen für die rechts:
<ph type="x-smartling-placeholder"></ph> Build-Variante > Build-Typ > Produktgeschmack > Hauptquellensatz > Bibliotheksabhängigkeiten
Dadurch kann Gradle Dateien verwenden, die für die Build-Variante spezifisch sind, die Aktivitäten, Anwendungslogik und Ressourcen, die auch in anderen Versionen Ihrer App vorhanden sind.
Beim Zusammenführen mehrerer Manifeste haben, verwendet Gradle dieselbe Prioritätsreihenfolge, sodass jede Build-Variante verschiedene Komponenten oder Berechtigungen im endgültigen Manifest definieren können. Weitere Informationen 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, verwenden Sie einen Versionskatalog oder Materialliste die allgemeinen Versionen angeben.
Andere Build-Systeme
Das Erstellen von Android-Apps mit Bazel ist möglich, aber offiziell nicht unterstützt. Android Studio wird nicht offiziell zur Unterstützung von Bazel-Projekten.
Informationen zu den aktuellen Einschränkungen beim Erstellen mit Bazel finden Sie in den bekannten Problemen.