Skonfiguruj kompilację

System kompilacji Androida kompiluje zasoby aplikacji i kod źródłowy, a potem pakuje je w pliki APK lub pakiety Android App Bundle, które możesz testować, wdrażać, podpisywać i rozpowszechniać.

W artykułach Omówienie kompilacji Gradle i Struktura kompilacji na Androida omawialiśmy pojęcia związane z kompilacją oraz strukturę aplikacji na Androida. Teraz nadszedł czas na skonfigurowanie kompilacji.

Glosariusz dotyczący kompilacji Androida

Gradle i wtyczka Androida do obsługi Gradle pomagają skonfigurować te aspekty kompilacji:

Typy kompilacji

Typy kompilacji definiują określone właściwości, których Gradle używa podczas kompilowania i pakowania aplikacji. Typy kompilacji są zwykle konfigurowane na różne etapy cyklu życia rozwoju.

Na przykład typ kompilacji debugowania umożliwia korzystanie z opcji debugowania i podpisuje aplikację kluczem debugowania, a typ kompilacji wersji może kompresować, zaciemniać i podpisywać aplikację kluczem wersji na potrzeby dystrybucji.

Aby skompilować aplikację, musisz zdefiniować co najmniej 1 typ kompilacji. Android Studio domyślnie tworzy typy kompilacji debugowania i wersji. Aby zacząć dostosowywać ustawienia pakowania aplikacji, dowiedz się, jak konfigurować typy kompilacji.

Smaki produktów
Wersje produktu to różne wersje aplikacji, które możesz udostępnić użytkownikom, np. bezpłatne i płatne. Możesz dostosowywać wersje produktu, aby używać różnych wersji kodu i zasobów podczas udostępniania oraz ponownie używać elementów wspólnych dla wszystkich wersji aplikacji. Wersje produktu są opcjonalne i musisz je utworzyć ręcznie. Aby zacząć tworzyć różne wersje aplikacji, dowiedz się, jak skonfigurować wersje produktu.
Tworzenie wariantów
Wariant kompilacji to połączenie typu kompilacji i wersji produktu. Jest to konfiguracja, której Gradle używa do kompilowania aplikacji. Dzięki wariantom kompilacji możesz kompilować wersję debugową wersji produktu na etapie rozwoju oraz podpisane wersje wersji produktu na potrzeby dystrybucji. Nie konfigurujesz bezpośrednio wariantów kompilacji, ale konfigurujesz typy kompilacji i wersje produktów, z których są one tworzone. Tworzenie dodatkowych typów kompilacji lub wersji produktu powoduje również utworzenie dodatkowych wariantów kompilacji. Aby dowiedzieć się, jak tworzyć wersje kompilacji i nimi zarządzać, przeczytaj artykuł Konfigurowanie wersji kompilacji.
Wpisy w pliku manifestu
Wartości niektórych właściwości pliku manifestu możesz określić w konfiguracji wariantu kompilacji. Te wartości kompilacji zastępują istniejące wartości w pliku manifestu. Jest to przydatne, jeśli chcesz wygenerować kilka wersji aplikacji z inną nazwą, inną minimalną wersją pakietu SDK lub inną wersją docelową pakietu SDK. Jeśli jest więcej niż jeden plik manifestu, narzędzie do łączenia plików manifestu scala ustawienia manifestu.
Zależności
System kompilacji zarządza zależnościami projektu z lokalnego systemu plików i z repozytoriów zdalnych. Oznacza to, że nie musisz ręcznie wyszukiwać, pobierać ani kopiować pakietów binarnych zależności do katalogu projektu. Więcej informacji znajdziesz w artykule Dodawanie zależności kompilacji.
Podpisywanie
System kompilacji umożliwia określenie ustawień podpisywania w konfiguracji kompilacji i automatyczne podpisywanie aplikacji podczas procesu kompilacji. System kompilacji podpisuje wersję debugową za pomocą domyślnego klucza i certyfikatu, używając znanych poświadczeń, aby uniknąć wyświetlania monitu o hasło podczas kompilacji. System kompilacji nie podpisuje wersji wydania, chyba że wyraźnie zdefiniujesz konfigurację podpisywania dla tej kompilacji. Jeśli nie masz klucza wersji, możesz go wygenerować w sposób opisany w artykule Podpisywanie aplikacji. Podpisane wersje są wymagane do rozpowszechniania aplikacji w większości sklepów z aplikacjami.
Zmniejszanie kodu i zasobów
System kompilacji umożliwia określenie innego pliku reguł ProGuard dla każdego wariantu kompilacji. Podczas kompilowania aplikacji system kompilacji stosuje odpowiedni zbiór reguł, aby skracać kod i zasoby za pomocą wbudowanych narzędzi, takich jak R8. Skracanie kodu i zasobów może pomóc w zmniejszeniu rozmiaru pliku APK lub AAB.
Obsługa wielu plików APK
System kompilacji umożliwia automatyczne kompilowanie różnych plików APK, z których każdy zawiera tylko kod i zasoby potrzebne do obsługi określonej gęstości ekranu lub interfejsu binarnego aplikacji (ABI). Więcej informacji znajdziesz w artykule Tworzenie wielu plików APK. Zalecamy jednak opublikowanie pojedynczego pakietu AAB, ponieważ umożliwia ono podział według języka, a nie tylko gęstości ekranu i interfejsu ABI, a jednocześnie nie wymaga przesyłania wielu artefaktów do Google Play. Wszystkie nowe aplikacje przesłane po sierpniu 2021 r. muszą używać pakietów AAB.

Wersje Javy w kompilacji Androida

Niezależnie od tego, czy Twój kod źródłowy jest napisany w języku Java, Kotlin czy w obu tych językach, musisz wybrać wersję JDK lub Javy na potrzeby kompilacji. Więcej informacji znajdziesz w artykule Wersje Javy w kompilacji Androida.

Tworzenie plików konfiguracji

Aby utworzyć niestandardowe konfiguracje kompilacji, musisz wprowadzić zmiany w co najmniej jednym pliku konfiguracji kompilacji. Te pliki w czystym tekście używają języka domenowego (DSL), aby opisywać i modyfikować logikę kompilacji za pomocą skryptu Kotlina, który jest odmianą języka Kotlin. Do konfigurowania kompilacji możesz też użyć Groovy, czyli języka dynamicznego dla maszyny wirtualnej Java (JVM).

Aby zacząć konfigurować kompilację, nie musisz znać skryptu Kotlin ani Groovy, ponieważ wtyczka Gradle dla Androida udostępnia większość potrzebnych elementów DSL. Więcej informacji o wtyczce Gradle dla Androida w języku DSL znajdziesz w dokumentacji na temat tego języka. Skrypt Kotlin korzysta też z podstawowego Gradle Kotlin DSL.

Gdy rozpoczynasz nowy projekt, Android Studio automatycznie tworzy niektóre z tych plików i wypełnia je na podstawie sensownych wartości domyślnych. Przegląd utworzonych plików znajdziesz w artykule Struktura kompilacji Androida.

Plik Gradle Wrapper

Opakowanie Gradle (gradlew) to mała aplikacja dołączona do kodu źródłowego, która pobiera i uruchamia Gradle. Dzięki temu proces kompilacji jest bardziej spójny. Deweloperzy pobierają źródło aplikacji i uruchamiają gradlew. Spowoduje to pobranie wymaganej dystrybucji Gradle i uruchomienie Gradle w celu skompilowania aplikacji.

Plik gradle/wrapper/gradle-wrapper.properties zawiera właściwość distributionUrl, która określa, której wersji Gradle używasz do uruchamiania kompilacji.

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

Plik ustawień Gradle

Plik settings.gradle.kts (w przypadku DSL w języku Kotlin) lub plik settings.gradle (w przypadku DSL w języku Groovy) znajduje się w katalogu głównym katalogu projektu. Ten plik ustawień definiuje ustawienia repozytorium na poziomie projektu i informuje Gradle, które moduły należy uwzględnić podczas kompilowania aplikacji. Projekty wielomodułowe muszą określać każdy moduł, który powinien zostać uwzględniony w końcowej kompilacji.

W przypadku większości projektów plik domyślnie wygląda tak:

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

Groovy

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'

Plik kompilacji najwyższego poziomu

Plik build.gradle.kts (w przypadku Kotlin DSL) lub plik build.gradle (w przypadku Groovy DSL) znajduje się w katalogu głównym katalogu projektu. Zwykle definiuje ona typowe wersje wtyczek używanych przez moduły w Twoim projekcie.

Poniższy przykładowy kod przedstawia domyślne ustawienia i elementy DSL w skrypcie kompilacji najwyższego poziomu po utworzeniu nowego projektu:

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

Groovy

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