Konfigurowanie kompilacji

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

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

Słowniczek kompilacji Androida

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

Rodzaje kompilacji

Typy kompilacji określają pewne 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 aplikacji.

Na przykład typ kompilacji debugowania włącza opcje debugowania i podpisuje aplikację kluczem debugowania, a typ kompilacji wersji może zmniejszać rozmiar aplikacji, zaciemniać jej kod i podpisywać ją 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 rozpocząć dostosowywanie ustawień pakowania aplikacji, dowiedz się, jak skonfigurować typy kompilacji.

Wersje produktów
Wersje produktu to różne wersje aplikacji, które możesz udostępniać użytkownikom, np. wersje bezpłatne i płatne. Możesz dostosowywać wersje produktu, aby używać innego kodu i zasobów, udostępniając i ponownie wykorzystując części wspólne 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. Za pomocą wariantów kompilacji możesz tworzyć wersje debugowania wersji produktu na potrzeby programowania oraz podpisane wersje wersji produktu na potrzeby dystrybucji. Wariantów kompilacji nie konfiguruje się bezpośrednio, ale konfiguruje się typy kompilacji i wersje produktu, które je tworzą. Utworzenie dodatkowych typów kompilacji lub wersji produktu 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
W konfiguracji wariantu kompilacji możesz określić wartości niektórych właściwości pliku manifestu. Te wartości kompilacji zastępują istniejące wartości w pliku manifestu. Jest to przydatne, jeśli chcesz wygenerować wiele wariantów aplikacji o różnych nazwach, minimalnych wersjach SDK lub docelowych wersjach SDK. Jeśli jest dostępnych kilka plików manifestu, narzędzie do scalania plików manifestu scala ustawienia plików manifestu.
Zależności
System kompilacji zarządza zależnościami projektu z lokalnego systemu plików i repozytoriów zdalnych. 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 za pomocą domyślnego klucza i certyfikatu, używając znanych danych logowania, aby uniknąć wyświetlania prośby o hasło w momencie kompilacji. System kompilacji nie podpisuje wersji produkcyjnej, 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 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 zestaw reguł, aby zmniejszyć rozmiar kodu i zasobów za pomocą wbudowanych narzędzi do zmniejszania rozmiaru, takich jak R8. Zmniejszenie 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 tworzenie różnych plików APK, które zawierają tylko kod i zasoby potrzebne w przypadku określonej gęstości ekranu lub interfejsu ABI. Więcej informacji znajdziesz w artykule Tworzenie wielu plików APK. Zalecamy jednak opublikowanie pojedynczego pakietu AAB, ponieważ umożliwia on podział według języka, gęstości ekranu i interfejsu ABI, a także eliminuje konieczność przesyłania do Google Play wielu artefaktów. 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 Javie, Kotlinie czy w obu tych językach, w kilku miejscach musisz wybrać wersję JDK lub języka Java na potrzeby kompilacji. Więcej informacji znajdziesz w artykule Wersje Javy w kompilacjach Androida.

Tworzenie plików konfiguracji kompilacji

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

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

Podczas tworzenia nowego projektu Android Studio automatycznie tworzy niektóre z tych plików i wypełnia je na podstawie rozsądnych ustawień domyślnych. Omówienie utworzonych plików znajdziesz w artykule Struktura kompilacji Androida.

Plik Gradle Wrapper

Wrapper Gradle (gradlew) to mała aplikacja dołączona do kodu źródłowego, która pobiera i uruchamia Gradle. Zapewnia to bardziej spójne wykonywanie kompilacji. 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óra wersja Gradle jest używana do uruchomienia 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 plik settings.gradle (w przypadku Groovy DSL) znajduje się w katalogu głównym projektu. Ten plik ustawień określa 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 ma być uwzględniony w końcowej kompilacji.

W przypadku większości projektów domyślnie wygląda on 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 najwyższego poziomu build.gradle.kts (w przypadku Kotlin DSL) lub plik build.gradle (w przypadku Groovy DSL) znajduje się w katalogu głównym projektu. Zwykle określa popularne 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 "8.11.0" apply false
    id("com.android.library") version "8.11.0" apply false
    id("org.jetbrains.kotlin.android") version "2.1.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.11.0' apply false
    id 'com.android.library' version '8.11.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.1.20' apply false
}