Konfigurowanie kompilacji

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

W sekcjach Omówienie kompilacji Gradle i Struktura kompilacji Androida omówiliśmy koncepcje kompilacji i strukturę aplikacji na Androida. Teraz nadszedł czas na skonfigurowanie kompilacji.

Glosariusz 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óżnych etapach cyklu życia programowania.

Na przykład typ kompilacji do debugowania włącza opcje debugowania i podpisuje aplikację kluczem debugowania, a typ kompilacji do publikacji może zmniejszyć i zaciemnić aplikację oraz podpisać ją kluczem wersji do dystrybucji.

Aby utworzyć aplikację, musisz zdefiniować co najmniej 1 typ kompilacji. Android Studio domyślnie tworzy typy kompilacji do debugowania i publikacji. Aby rozpocząć dostosowywanie ustawień pakowania aplikacji, dowiedz się, jak skonfigurować typy kompilacji.

Warianty usługi
Warianty usługi to różne wersje aplikacji, które możesz udostępniać użytkownikom, np. wersja bezpłatna i płatna. Możesz dostosować warianty usługi, aby używały różnych kodów i zasobów, jednocześnie udostępniając i ponownie wykorzystując części wspólne dla wszystkich wersji aplikacji. Warianty usługi są opcjonalne i musisz je utworzyć ręcznie. Aby zacząć tworzyć różne wersje aplikacji, dowiedz się, jak skonfigurować warianty usługi.
Warianty kompilacji
Wariant kompilacji to iloczyn kartezjański typu kompilacji i wariantu usługi. Jest to konfiguracja, której Gradle używa do kompilowania aplikacji. Za pomocą wariantów kompilacji możesz tworzyć wersje debugowania wariantów usługi podczas programowania oraz podpisane wersje do publikacji wariantów usługi na potrzeby dystrybucji. Chociaż nie konfigurujesz bezpośrednio wariantów kompilacji, konfigurujesz typy kompilacji i warianty usługi, które je tworzą. Utworzenie dodatkowych typów kompilacji lub wariantów usługi powoduje też utworzenie dodatkowych wariantów kompilacji. Aby dowiedzieć się, jak tworzyć warianty kompilacji i nimi zarządzać, przeczytaj omówienie Konfigurowanie wariantów 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ć wiele wariantów aplikacji z inną nazwą, minimalną wersją pakietu SDK lub docelową wersją pakietu SDK. Jeśli jest kilka plików manifestu, narzędzie łączące scala ich ustawienia.
Zależności
System kompilacji zarządza zależnościami projektu z lokalnego systemu plików i zdalnych repozytoriów. Oznacza to, że nie musisz ręcznie wyszukiwać, pobierać i 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 może automatycznie podpisywać aplikację podczas procesu kompilacji. System kompilacji podpisuje wersję debugowania domyślnym kluczem i certyfikatem, używając znanych danych logowania, aby uniknąć wyświetlania prośby o hasło podczas kompilacji. System kompilacji nie podpisuje wersji do publikacji, chyba że wyraźnie zdefiniujesz konfigurację podpisywania dla tej kompilacji. Jeśli nie masz klucza wersji, możesz go wygenerować zgodnie z opisem w artykule Podpisywanie aplikacji. Podpisane kompilacje do publikacji 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 zestaw reguł, aby zmniejszyć kod i zasoby za pomocą wbudowanych narzędzi do zmniejszania, takich jak R8. Zmniejszenie kodu i zasobów może pomóc w zmniejszeniu rozmiaru pliku APK lub AAB.
Obsługa wielu pakietów APK
System kompilacji umożliwia automatyczne tworzenie 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 o  tworzeniu wielu plików APK. Zalecamy jednak opublikowanie jednego pakietu AAB, ponieważ umożliwia on podział według języka, gęstości ekranu i ABI, a jednocześnie eliminuje konieczność 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 kompilacjach Androida

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

Pliki konfiguracji kompilacji

Tworzenie niestandardowych konfiguracji kompilacji wymaga wprowadzenia zmian w co najmniej jednym pliku konfiguracji kompilacji. Te pliki tekstowe używają języka dziedzinowego (DSL) do opisywania logiki kompilacji i manipulowania nią za pomocą skryptu Kotlin, który jest odmianą języka Kotlin. Do konfigurowania kompilacji możesz też używać Groovy, który jest językiem dynamicznym dla maszyny wirtualnej Java (JVM).

Nie musisz znać skryptu Kotlin ani Groovy, aby rozpocząć konfigurowanie kompilacji, ponieważ wtyczka Androida do obsługi Gradle wprowadza większość potrzebnych elementów DSL. Więcej informacji o DSL wtyczki Androida do obsługi Gradle znajdziesz w dokumentacji referencyjnej DSL. Skrypt Kotlin opiera się też na Gradle Kotlin DSL.

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

Plik Gradle Wrapper

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

Plik gradle/wrapper/gradle-wrapper.properties zawiera właściwość distributionUrl, która określa, która wersja Gradle jest używana 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 Kotlin DSL) lub settings.gradle (w przypadku Groovy DSL) znajduje się w głównym katalogu projektu. Ten plik ustawień definiuje ustawienia repozytorium na poziomie projektu i informuje Gradle, które moduły powinien uwzględnić podczas tworzenia aplikacji. W przypadku projektów wielomodułowych należy określić każdy moduł, który powinien znaleźć się w ostatecznej 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")

Dynamiczny

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 najwyższego poziomu build.gradle.kts (w przypadku Kotlin DSL) lub build.gradle (w przypadku Groovy DSL) znajduje się w głównym katalogu projektu. Zwykle definiuje on typowe wersje wtyczek używanych przez moduły w projekcie.

Poniższy przykładowy kod opisuje ustawienia domyślne 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 "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
}

Dynamiczny

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
}