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
}