Build konfigurieren

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 Build-Typ „Debug“ aktiviert beispielsweise Debugging-Optionen und signiert die App mit dem Debug-Schlüssel, während der Build-Typ „Release“ 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. Android Studio erstellt standardmäßig die Build-Typen „Debug“ und „Release“. Informationen zum Anpassen der Verpackungseinstellungen für Ihre App finden Sie unter Build-Typen konfigurieren.

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 können. 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 Sie definieren 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 unter Build-Varianten konfigurieren.

Manifesteinträge

Sie können in der Build-Varianten-Konfiguration für einige Attribute der Manifestdatei Werte 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, sie herunterladen und in Ihr Projektverzeichnis kopieren müssen. Weitere Informationen finden Sie unter Build-Abhängigkeiten hinzufügen.

Signieren

Sie können im Build-System in der Build-Konfiguration Signatureinstellungen 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 Release-Schlü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

Sie können im Build-System 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 komprimieren. Dazu werden integrierte Tools wie R8 verwendet. Durch das Komprimieren 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 Binärschnittstelle (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 nicht mehrere Artefakte bei Google Play hochgeladen werden müssen. 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 (Domain-specific Language, DSL), um die Build-Logik mit Kotlin-Script zu beschreiben und zu bearbeiten. Kotlin-Script ist eine Variante der Sprache Kotlin. Sie können Ihre Builds auch mit Groovy konfigurieren, einer dynamischen Sprache für die Java Virtual Machine (JVM).

Sie müssen weder Kotlin-Script noch 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 Kotlin-DSL von Gradle.

Wenn Sie ein neues Projekt starten, erstellt Android Studio automatisch einige dieser Dateien und fügt sinnvolle Standardwerte in diese ein. 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 die Gradle selbst herunterlädt und startet. Dadurch wird die Ausführung von Builds konsistenter. Entwickler laden den Anwendungscode 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 Eigenschaft 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:

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")

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 Datei build.gradle.kts (für die Kotlin-DSL) oder build.gradle (für die Groovy-DSL) auf oberster Ebene 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 nach dem Erstellen eines neuen Projekts beschrieben:

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 "9.4.0" apply false
    id("com.android.library") version "9.4.0" apply false
    id("org.jetbrains.kotlin.android") version "2.4.10" apply false
}

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 '9.4.0' apply false
    id 'com.android.library' version '9.4.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.4.10' apply false
}