Skonfiguruj kompilację

System kompilacji Androida kompiluje zasoby aplikacji, kod źródłowy i pakiety do plików APK lub pakietów Android App Bundle, które możesz testować, wdrażać, podpisywać rozpowszechniania.

Android Studio wykorzystuje Gradle – zaawansowany zestaw narzędzi do kompilacji, i zarządzać procesem tworzenia, pozwalając jednocześnie elastycznie zdefiniować, konfiguracje kompilacji. Każda konfiguracja kompilacji może definiować własny zbiór kodu i zasobów, wykorzystując elementy wspólne dla wszystkich wersji aplikacji. Wtyczka Androida do obsługi Gradle współpracuje z narzędziem do kompilacji, procesów i konfigurowalnych ustawień, charakterystycznych dla tworzenia i testowania, Aplikacje na Androida.

Gradle i wtyczka Androida do obsługi Gradle działają niezależnie od Android Studio. Ten aplikacje na Androida można tworzyć w Android Studio. na komputerze i na komputerach, na których Android Studio nie jest takich jak serwery w trybie ciągłej integracji.

Jeśli nie używasz w Android Studio, dowiedz się, jak tworzyć i uruchamiać aplikacje wiersza poleceń. Dane wyjściowe kompilacji są takie same niezależnie od tego, tworząc projekt z poziomu wiersza poleceń, na komputerze zdalnym lub Android Studio.

Uwaga: ponieważ Gradle i wtyczka Androida do obsługi Gradle działają niezależnie od Android Studio, trzeba zaktualizować narzędzia do kompilacji, oddzielnie. Przeczytaj informacje o wersji, aby dowiedzieć się, jak zaktualizować Gradle. oraz wtyczki Androida do obsługi Gradle.

Elastyczność systemu kompilacji Androida pozwala tworzyć konfiguracje bez modyfikowania podstawowych plików źródłowych aplikacji. Ten pomaga zrozumieć sposób działania systemu Android Build może pomóc w dostosowaniu i automatyzacji różnych konfiguracji kompilacji. Jeśli Aby dowiedzieć się więcej o wdrażaniu aplikacji, przeczytaj artykuł Tworzenie i uruchamianie aplikacji. Aby zacząć tworzyć niestandardowe od razu po konfiguracji przy użyciu Android Studio. Więcej informacji znajdziesz w sekcji Konfigurowanie kompilacji wersji.

Proces kompilacji

Proces kompilacji obejmuje wiele narzędzi i procesów, które przekształcają projekt do pakietu Android Application Package (APK) lub Android App Bundle (AAB).

Wtyczka Androida do obsługi Gradle wykonuje większość procesu kompilacji, ale może być pomocne w zrozumieniu określonych aspektów procesu kompilacji, co pozwoli Ci dostosować aby spełnić wymagania.

Różne projekty mogą mieć różne cele kompilacji. Na przykład kompilacja dla biblioteka zewnętrzna tworzy plik Android Archive (AAR) lub Java Archive (JAR). biblioteki. Najpopularniejszym typem projektu jest jednak aplikacja, a kompilacja aplikacji projekt tworzy plik APK lub AAB aplikacji do debugowania albo opublikowania, który możesz wdrożyć; testowania lub udostępniania użytkownikom zewnętrznym.

Ta strona jest poświęcona tworzeniu aplikacji, ale wiele kroków i koncepcji budowania jest wspólnych dla większości typów kompilacji.

Glosariusz kompilacji na Androida

Gradle i wtyczka Androida do obsługi Gradle pomagają skonfigurować poniższe aspekty Twojej kompilacji:

Typy kompilacji

Typy kompilacji definiują określone właściwości używane przez Gradle podczas tworzenia pakietu aplikacji. Typy kompilacji są zwykle skonfigurowane pod kątem różnych etapów cyklu programowania.

Na przykład typ kompilacji do debugowania włącza opcje debugowania i podpisuje aplikację kluczem debugowania, a typ kompilacji do wersji może zmniejszyć rozmiar, zaciemniać i podpisywać wersję aplikacji oraz ją podpisywać; klucz do dystrybucji.

Musisz zdefiniować co najmniej 1 typ kompilacji, aby stworzyć aplikację. Android Studio tworzy typy kompilacji do debugowania i kompilacji wersji. domyślnie. Aby zacząć dostosowywać ustawienia pakietu aplikacji, dowiedz się, jak to zrobić. skonfigurować kompilację, .

Smaki produktów
Typy produktów to różne wersje Twojej aplikacji, np. wersji bezpłatnej i płatnej. Dostępne opcje dostosuj rodzaje usług, aby korzystać z różnego kodu i zasobów podczas udostępniania i ponownie wykorzystując elementy, które są wspólne dla wszystkich wersji aplikacji. Usługa smaki są opcjonalne i musisz je utworzyć ręcznie. Aby zacząć tworzyć różnych wersji aplikacji, dowiedz się, jak skonfigurować smaki produktów.
Tworzenie wariantów
Wariant kompilacji to usługa z różnych typów kompilacji i smaku produktu. to konfiguracja, której Gradle używa do skompilowania aplikacji. Korzystając z wariantów kompilacji, możesz utworzyć wersję do debugowania rodzajów produktów w trakcie tworzenia aplikacji, i podpisane wersje premierowe poszczególnych smaków. Chociaż nie konfigurujesz wariantów kompilacji bezpośrednio, rodzajów konstrukcji i smaków produktów, które z nich powstają. Tworzę dodatkową kompilację typów produktów lub smaków produktów umożliwiają też utworzenie dodatkowych wersji kompilacji. Aby się uczyć jak tworzyć warianty kompilacji i nimi zarządzać, przeczytaj artykuł Konfigurowanie wariantów kompilacji. .
Wpisy w pliku manifestu
Możesz określić wartości niektórych właściwości pliku manifestu w kompilacji. konfiguracji wariantu. Te wartości kompilacji zastępują istniejące wartości w plik manifestu. Przydaje się to, gdy chcesz wygenerować wiele wariantów aplikacji z inną nazwą lub minimalną wersją pakietu SDK albo docelową wersję pakietu SDK. Jeśli dostępnych jest kilka plików manifestu, narzędzie do łączenia danych ustawienia pliku manifestu zostaną scalone.
Zależności
System kompilacji zarządza zależnościami projektów z lokalnego systemu plików i z repozytoriów zdalnych. Oznacza to, że nie musisz ręcznie wyszukiwać, pobierać i kopiować pakiety binarne zależności katalogu projektu. Więcej informacji znajdziesz w sekcji Dodawanie kompilacji .
Podpisz
System kompilacji pozwala określić ustawienia podpisywania w kompilacji i może automatycznie podpisywać aplikację podczas kompilacji proces tworzenia konta. System kompilacji podpisuje wersję do debugowania kluczem domyślnym i certyfikatu używającego znanych danych logowania, aby uniknąć pytania o hasło podczas kompilacji obecnie się znajdujesz. System kompilacji nie podpisuje wersji, chyba że bezpośrednio zdefiniować konfigurację podpisywania dla tej kompilacji. Jeśli nie chcesz masz klucz wersji, możesz go wygenerować w sposób opisany w artykule Podpisywanie aplikacji. Podpisane kompilacje są wymagane do rozpowszechniania aplikacji w większości sklepów z aplikacjami.
Zmniejszanie kodu i zasobów
System kompilacji pozwala określić inny plik reguł ProGuard dla każdego wariantu kompilacji. Podczas tworzenia aplikacji system kompilacji stosuje odpowiedni zestaw reguł, aby zmniejszać kod i zasoby za pomocą wbudowanych narzędzi do zmniejszenia, takich jak R8. Zmniejszenie kodu i zasobów może pomóc w zmniejszeniu rozmiaru pliku APK lub pakietu AAB.
Obsługa wielu plików APK
System kompilacji pozwala automatycznie tworzyć różne pliki APK, każdy zawiera tylko kod i zasoby potrzebne dla określonej gęstości ekranu lub interfejsu binarnego aplikacji (ABI). Więcej informacji można znaleźć w sekcji Utwórz wiele plików APK. Jednak zwolnienie jednego pakietu aplikacji na Androida jest zalecany, ponieważ można podzielić według języka gęstości ekranu i interfejsu ABI przy jednoczesnym uniknięciu konieczności przesyłania artefaktów do Google Play. Wszystkie nowe aplikacje przesłane po sierpniu 2021 roku są wymagane do korzystania z pakietów aplikacji na Androida.

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, jest kilka miejsc, w których musisz wybrać język JDK lub Java dla swojej kompilacji. Zobacz wersje Java w kompilacjach na Androida. .

Pliki konfiguracji kompilacji

Tworzenie niestandardowych konfiguracji kompilacji wymaga wprowadzenia zmian w jednej lub więcej plików konfiguracji kompilacji. Te Zwykłe pliki tekstowe wykorzystują język specyficzny dla domeny (Domain Specific Language) do opisania i manipulowanie logiką kompilacji za pomocą Skrypt Kotlin, który jest odmianą języka Kotlin. Możesz też użyć Groovy, czyli język dynamiczny maszyny wirtualnej Java (JVM), aby skonfigurować kompilacje.

Nie musisz znać skryptu Kotlin ani Groovy, aby zacząć konfigurować bo wtyczka Androida do obsługi Gradle wprowadza większość elementów DSL. których potrzebujesz. Więcej informacji o wtyczce DSL do obsługi Gradle Androida znajdziesz w Dokumentacja referencyjna DSL. Skrypt Kotlin opiera się również odnoszący się Gradle Kotlin DSL.

Gdy rozpoczynasz nowy projekt, Android Studio automatycznie tworzy niektóre i wypełnia je na podstawie rozsądnych wartości domyślnych. Projekt ma taki układ:

└── 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

Istnieje kilka plików konfiguracji kompilacji Gradle, które są częścią standardowej struktury projektu dla aplikacji na Androida. Zanim zaczniesz podczas konfigurowania kompilacji, musisz poznać jej zakres i przeznaczenie. a także podstawowych elementów DSL, które zawierają.

Plik Gradle Wrapper

Otoka Gradle (gradlew) to mała aplikacja dołączona do Twojego kodu źródłowego, który pobiera i uruchamia Gradle. Zwiększa to spójność wykonywania kompilacji. Deweloperzy pobierają źródła aplikacji i uruchomić gradlew. Spowoduje to pobranie wymaganego Gradle dystrybucji i uruchamia Gradle, aby skompilować aplikację.

Plik gradle/wrapper/gradle-wrapper.properties zawiera właściwość distributionUrl, która opisuje wersję Gradle służy 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 (dla DSL Kotlin) lub Plik settings.gradle (dla Groovy DSL) znajduje się w katalogu głównym katalogu projektu. Ten plik ustawień definiuje repozytorium na poziomie projektu i informuje Gradle, które moduły powinna uwzględnić podczas tworzenia . W projektach złożonych z wielu modułów należy określić każdy moduł, który powinien się znaleźć i ostateczną kompilację.

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

Odlotowe

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'

Plik kompilacji najwyższego poziomu

Plik build.gradle.kts najwyższego poziomu (dla DSL Kotlin) lub Plik build.gradle (dla Groovy DSL) znajduje się w katalogu głównym katalogu projektu. Zwykle definiuje typowe wersje używanych przez Ciebie wtyczek według modułów w projekcie.

Następujący przykładowy kod opisuje ustawienia domyślne i elementy DSL w skrypt 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.5.0" apply false
    id("com.android.library") version "8.5.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}

Odlotowe

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