Build konfigurieren

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.6.0" apply false
    id("com.android.library") version "8.6.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.6.0' apply false
    id 'com.android.library' version '8.6.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}