System kompilacji Androida kompiluje zasoby aplikacji oraz kod źródłowy i pakuje je w pliki APK lub pakiety Android App Bundle, które możesz testować, wdrażać, podpisywać i rozpowszechniać.
Android Studio korzysta z Gradle, zaawansowanego zestawu narzędzi do tworzenia kompilacji, który automatyzuje proces kompilacji i nim zarządza, a także pozwala definiować elastyczne, niestandardowe konfiguracje kompilacji. Każda konfiguracja kompilacji może definiować własny zestaw kodu i zasobów, wykorzystując jednocześnie części wspólne dla wszystkich wersji aplikacji. Wtyczka Androida do obsługi Gradle współpracuje z zestawem narzędzi do kompilacji, zapewniając procesy i konfigurowalne ustawienia właściwe do tworzenia i testowania aplikacji na Androida.
Gradle i wtyczka Androida do obsługi Gradle działają niezależnie od Android Studio. Oznacza to, że możesz tworzyć aplikacje na Androida w Android Studio, za pomocą wiersza poleceń na komputerze lub na komputerach, na których nie masz zainstalowanego Android Studio, takich jak serwery ciągłej integracji.
Jeśli nie korzystasz z Android Studio, dowiedz się, jak utworzyć i uruchomić aplikację z poziomu wiersza poleceń. Dane wyjściowe kompilacji są takie same niezależnie od tego, czy tworzysz projekt z poziomu wiersza poleceń, na maszynie zdalnej czy przy użyciu Android Studio.
Uwaga: narzędzie Gradle i wtyczka Androida do obsługi Gradle działają niezależnie od Android Studio, dlatego narzędzia do kompilacji trzeba aktualizować osobno. Aby dowiedzieć się, jak zaktualizować Gradle i wtyczkę Androida do obsługi Gradle, przeczytaj informacje o wersji.
Elastyczność systemu kompilacji Androida pozwala tworzyć niestandardowe konfiguracje kompilacji bez modyfikowania podstawowych plików źródłowych aplikacji. Na tej stronie dowiesz się, jak działa system kompilacji Androida i jak może pomóc Ci dostosować i zautomatyzować różne konfiguracje kompilacji. Więcej informacji o wdrażaniu aplikacji znajdziesz w artykule Tworzenie i uruchamianie aplikacji. Jeśli chcesz od razu zacząć tworzyć niestandardowe konfiguracje kompilacji za pomocą Android Studio, przeczytaj artykuł Konfigurowanie wariantów kompilacji.
Proces kompilacji
Proces kompilacji obejmuje wiele narzędzi i procesów, które konwertują projekt na pakiety Android Application Package (APK) lub Android App Bundle (AAB).
Wtyczka Androida do obsługi Gradle wykonuje za Ciebie dużą część procesu kompilacji, ale może też przydać się do poznania niektórych aspektów tego procesu i dostosowania kompilacji pod kątem Twoich wymagań.
Różne projekty mogą mieć różne cele kompilacji. Na przykład kompilacja do biblioteki zewnętrznej powoduje utworzenie bibliotek Android Archive (AAR) lub Java Archive (JAR). Najpopularniejszym typem projektu jest jednak aplikacja, a kompilacja na potrzeby tego projektu tworzy pakiet APK lub pakiet aplikacji do debugowania, który możesz wdrożyć, przetestować lub udostępnić użytkownikom zewnętrznym.
Ta strona dotyczy tworzenia aplikacji, ale wiele etapów i koncepcji kompilacji jest typowych dla większości typów kompilacji.
Glosariusz kompilacji Androida
Gradle i wtyczka Androida do obsługi Gradle pomagają skonfigurować te aspekty kompilacji:
- Typy kompilacji
-
Typy kompilacji określają pewne właściwości, których Gradle używa podczas tworzenia i pakowania aplikacji. Typy kompilacji są zwykle konfigurowane dla różnych etapów cyklu programowania.
Na przykład typ kompilacji do debugowania włącza opcje debugowania i podpisuje aplikację kluczem debugowania. Z kolei typ kompilacji wersji może się zmniejszać, zaciemniać i podpisywać aplikację do dystrybucji kluczem wersji.
Aby stworzyć aplikację, musisz zdefiniować co najmniej 1 typ kompilacji. Android Studio domyślnie tworzy typy kompilacji przeznaczone do debugowania i do publikacji. Aby zacząć dostosowywać ustawienia pakietu dla aplikacji, dowiedz się, jak skonfigurować typy kompilacji.
- Smaki produktów
- Smaki produktów oznaczają różne wersje aplikacji, które możesz udostępniać użytkownikom, np. wersję bezpłatną i płatną. Możesz dostosować smaki produktów, aby używać innego kodu i zasobów oraz udostępniać i wykorzystywać ponownie elementy wspólne dla wszystkich wersji aplikacji. Smaki produktów są opcjonalne i musisz je utworzyć ręcznie. Aby zacząć tworzyć różne wersje aplikacji, dowiedz się, jak skonfigurować różne rodzaje usług.
- Utwórz warianty
- Wariant kompilacji to połączenie różnych usług o typie kompilacji i rodzaju usługi. Jest to konfiguracja, której Gradle używa do tworzenia aplikacji. Za pomocą wariantów kompilacji możesz tworzyć wersje do debugowania smaków produktów w trakcie tworzenia aplikacji i podpisane wersje do publikacji smaków produktów do dystrybucji. Chociaż nie konfigurujesz bezpośrednio wersji kompilacji, konfigurujesz typy kompilacji i smaki usług, które je tworzące. Utworzenie dodatkowych typów kompilacji lub rodzajów usług powoduje również utworzenie dodatkowych wersji kompilacji. Aby dowiedzieć się, jak tworzyć warianty kompilacji i nimi zarządzać, przeczytaj omówienie konfigurowania wariantów kompilacji.
- Wpisy w pliku manifestu
- W konfiguracji wariantu kompilacji możesz podać 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, gdy chcesz wygenerować wiele wariantów aplikacji o innej nazwie aplikacji, minimalnej wersji pakietu SDK lub docelowej wersji pakietu SDK. Jeśli dostępnych jest wiele 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 lokalnym systemem plików i repozytoriami zdalnymi. 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 o dodawaniu zależności kompilacji.
- Podpisanie
- System kompilacji umożliwia określenie ustawień podpisywania w konfiguracji kompilacji i może automatycznie podpisywać aplikację podczas jej tworzenia. System kompilacji podpisuje wersję do debugowania za pomocą domyślnego klucza i certyfikatu, korzystając ze znanych danych logowania, aby uniknąć pytania o hasło podczas kompilacji. System kompilacji nie podpisuje wersji do publikacji, chyba że jednoznacznie zdefiniujesz konfigurację podpisywania dla tej kompilacji. Jeśli nie masz klucza wersji, możesz go wygenerować zgodnie z opisem w sekcji Podpisywanie aplikacji. Kompilacje z podpisanymi wersjami 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 tworzenia aplikacji system kompilacji stosuje odpowiedni zestaw reguł, by zmniejszać kod i zasoby przy użyciu wbudowanych narzędzi, takich jak R8. Zmniejszenie kodu i zasobów może zmniejszyć rozmiar pliku APK lub pakietu AAB.
- Obsługa wielu plików APK
- System kompilacji pozwala automatycznie tworzyć różne pliki APK, z których każdy zawiera tylko kod i zasoby potrzebne do 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 udostępnienie jednego pakietu aplikacji na Androida, ponieważ umożliwia podział według języka, a także gęstości ekranu i interfejsu ABI, a jednocześnie pozwala uniknąć przesyłania wielu artefaktów do Google Play. Wszystkie nowe aplikacje przesłane po sierpniu 2021 r. muszą używać pakietów aplikacji na Androida.
Wersje Javy w kompilacjach 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, w kilku miejscach musisz wybrać dla swojej kompilacji wersję językową JDK lub Java. Więcej informacji znajdziesz na stronie Wersje Java w kompilacjach Androida.
Tworzenie plików konfiguracji
Tworzenie niestandardowych konfiguracji kompilacji wymaga wprowadzenia zmian w co najmniej 1 pliku konfiguracji kompilacji. Te pliki tekstowe używają języka specyficznego dla domeny (Domain Specific Language) do opisania logiki kompilacji i manipulowania nią za pomocą skryptu Kotlin, który jest rodzajem języka Kotlin. Do konfigurowania kompilacji możesz też użyć Groovy, który jest językiem dynamicznym maszyny wirtualnej Java (JVM).
Aby rozpocząć konfigurowanie kompilacji, nie musisz znać skryptu Kotlin ani Groovy, bo wtyczka Androida do obsługi Gradle wprowadza większość potrzebnych elementów DSL. Więcej informacji o DSL wtyczki Android do obsługi Gradle znajdziesz w dokumentacji DSL. Skrypt Kotlin korzysta też z podstawowego DSL Gradle Kotlin.
Gdy rozpoczynasz nowy projekt, Android Studio automatycznie tworzy dla Ciebie niektóre z tych plików i wypełnia je na podstawie zrozumiałych wartości domyślnych. Struktura pliku projektu ma następujący 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 w ramach standardowej struktury projektu dla aplikacji na Androida. Zanim zaczniesz konfigurować kompilację, musisz poznać zakres i przeznaczenie każdego z tych plików oraz zdefiniowane przez nie podstawowe elementy DSL.
Plik opakowujący Gradle
Otoka Gradle (gradlew) to mała aplikacja dołączona do kodu źródłowego, która pobiera i uruchamia Gradle.
Dzięki temu wykonywanie kompilacji będzie bardziej spójne. Programiści pobierają źródło aplikacji i uruchamiają gradlew. Pobiera ona wymaganą dystrybucję Gradle i uruchamia Gradle w celu skompilowania aplikacji.
Plik gradle/wrapper/gradle-wrapper.properties zawiera właściwość distributionUrl, która określa, która wersja Gradle ma być 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 (dla DSL Kotlin) lub settings.gradle (dla DSL Groovy) znajduje się w 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 tworzenia aplikacji. Projekty wielomodułowe muszą określać każdy moduł, który powinien zostać uwzględniony w ostatecznej kompilacji.
W większości projektów domyślnie plik 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")
Odlotowy
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 build.gradle (dla DSL Groovy) znajduje się w głównym katalogu projektu. Zwykle definiuje typowe wersje wtyczek używanych przez moduły w projekcie.
Ten przykładowy kod opisuje 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.3.0" apply false
id("com.android.library") version "8.3.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}
Odlotowy
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.3.0' apply false
id 'com.android.library' version '8.3.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}
Plik kompilacji na poziomie modułu
Plik build.gradle.kts na poziomie modułu (dla DSL Kotlin) lub build.gradle (dla DSL Groovy DSL) znajduje się w każdym katalogu project/module/. Umożliwia skonfigurowanie ustawień kompilacji dla konkretnego modułu, w którym się znajduje. Skonfigurowanie tych ustawień kompilacji pozwala udostępnić niestandardowe opcje opakowania, na przykład dodatkowe typy kompilacji i smaki usług, oraz zastąpić ustawienia w pliku manifestu aplikacji main/ lub w skrypcie kompilacji najwyższego poziomu.
Ustawienia pakietu Android SDK
Plik kompilacji na poziomie modułu dla aplikacji zawiera ustawienia wskazujące wersje pakietu Android SDK używane podczas kompilowania, wybór zachowań platformy i określanie minimalnej wersji, na której działa aplikacja.
-
compileSdk -
compileSdkokreśla, które interfejsy API Androida i Java są dostępne podczas kompilowania kodu źródłowego. Aby korzystać z najnowszych funkcji Androida, podczas kompilacji użyj najnowszego pakietu Android SDK.Niektóre interfejsy API platformy Androida mogą być niedostępne na starszych poziomach API. Możesz warunkowo blokować korzystanie z nowszych funkcji lub użyć bibliotek zgodności z AndroidemX, aby używać nowszych funkcji o niższych poziomach interfejsów API Androida.
Każdy pakiet Android SDK zapewnia podzbiór interfejsów API Java, których możesz używać w swojej aplikacji. Tabela w sekcji Których interfejsów API w Javie mogę używać w kodzie źródłowym Java lub Kotlin pokazuje, jaki poziom interfejsu API Javy jest dostępny w zależności od wersji pakietu Android SDK. Nowsze interfejsy API w Javie są obsługiwane we wcześniejszych wersjach Androida za pomocą wycofywania, które musi być włączone w kompilacji.
Android Studio wyświetla ostrzeżenia, jeśli
compileSdkkoliduje z bieżącą wersją Android Studio, AGP lub z wymaganiami dotyczącymi zależności biblioteki w projekcie. -
minSdk -
minSdkokreśla najniższą wersję Androida, która ma być obsługiwana przez Twoją aplikację. UstawienieminSdkokreśla, na których urządzeniach można instalować Twoją aplikację.Obsługa starszych wersji Androida może wymagać większej liczby kontroli warunkowych w kodzie lub większej liczby bibliotek zgodności z AndroidemX. Koszt utrzymania obsługi starszych wersji należy wyważyć z odsetkiem użytkowników, którzy wciąż z nich korzystają. Aktualne wartości procentowe wykorzystania wersji znajdziesz na wykresie wersji w kreatorze nowego projektu w Android Studio.
Podczas edytowania kodu w Android Studio lub sprawdzania podczas kompilacji narzędzie Lint będzie ostrzegać o używanych przez Ciebie interfejsach API, które nie są dostępne w
minSdk. Rozwiąż te problemy, włączając warunkowe działanie nowszych funkcji lub korzystając z modeluAppcompat, aby zapewnić zgodność wsteczną. -
targetSdk -
Interfejs
targetSdksłuży do 2 celów:- Określa działanie aplikacji w czasie działania.
- Potwierdza ona, która wersja Androida została przetestowana.
Jeśli używasz urządzenia z Androidem w wersji wyższej niż
targetSdk, Android uruchomi Twoją aplikację w trybie zgodności, który działa podobnie do wcześniejszej wersji wskazanej w komponencietargetSdk. Na przykład po wprowadzeniu modelu uprawnień czasu działania w interfejsie API 23 nie wszystkie aplikacje były gotowe do jego wdrożenia od razu. Gdy ustawisztargetSdkna 22, te aplikacje będą mogły działać na urządzeniach z interfejsem API 23 bez uprawnień w czasie działania i będą mogły korzystać z funkcji dostępnych w najnowszej wersjicompileSdk. Zasada dystrybucji Google Play wymusza dodatkowe zasady na docelowym poziomie interfejsu API.Wartość
targetSdknie może być większa niżcompileSdk.
Uwaga: wartości compileSdk i targetSdk nie muszą być takie same. Pamiętaj o tych podstawowych zasadach:
compileSdkzapewnia dostęp do nowych interfejsów APItargetSdkokreśla działanie aplikacji w czasie działania aplikacji- Wartość w polu
targetSdknie może być większa niżcompileSdk
Przykładowy skrypt kompilacji modułu aplikacji
Ten przykładowy skrypt tworzenia modułu aplikacji na Androida przedstawia niektóre podstawowe elementy i ustawienia DSL:
Kotlin
/**
* The first section in the build configuration applies the Android Gradle plugin
* to this build and makes the android block available to specify
* Android-specific build options.
*/
plugins {
id("com.android.application")
}
/**
* Locate (and possibly download) a JDK used to build your kotlin
* source code. This also acts as a default for sourceCompatibility,
* targetCompatibility and jvmTarget. Note that this does not affect which JDK
* is used to run the Gradle build itself, and does not need to take into
* account the JDK version required by Gradle plugins (such as the
* Android Gradle Plugin)
*/
kotlin {
jvmToolchain(11)
}
/**
* The android block is where you configure all your Android-specific
* build options.
*/
android {
/**
* The app's namespace. Used primarily to access app resources.
*/
namespace = "com.example.myapp"
/**
* compileSdk specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*/
compileSdk = 33
/**
* The defaultConfig block encapsulates default settings and entries for all
* build variants and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {
// Uniquely identifies the package for publishing.
applicationId = "com.example.myapp"
// Defines the minimum API level required to run the app.
minSdk = 21
// Specifies the API level used to test the app.
targetSdk = 33
// Defines the version number of your app.
versionCode = 1
// Defines a user-friendly version name for your app.
versionName = "1.0"
}
/**
* The buildTypes block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies ProGuard settings and is not signed by default.
*/
buildTypes {
/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
*/
getByName("release") {
isMinifyEnabled = true // Enables code shrinking for the release build type.
proguardFiles(
getDefaultProguardFile("proguard-android.txt"),
"proguard-rules.pro"
)
}
}
/**
* The productFlavors block is where you can configure multiple product flavors.
* This lets you create different versions of your app that can
* override the defaultConfig block with their own settings. Product flavors
* are optional, and the build system does not create them by default.
*
* This example creates a free and paid product flavor. Each product flavor
* then specifies its own application ID, so that they can exist on the Google
* Play Store, or an Android device, simultaneously.
*
* If you declare product flavors, you must also declare flavor dimensions
* and assign each flavor to a flavor dimension.
*/
flavorDimensions += "tier"
productFlavors {
create("free") {
dimension = "tier"
applicationId = "com.example.myapp.free"
}
create("paid") {
dimension = "tier"
applicationId = "com.example.myapp.paid"
}
}
/**
* To override source and target compatibility (if different from the
* toolchain JDK version), add the following. All of these
* default to the same value as kotlin.jvmToolchain. If you're using the
* same version for these values and kotlin.jvmToolchain, you can
* remove these blocks.
*/
//compileOptions {
// sourceCompatibility = JavaVersion.VERSION_11
// targetCompatibility = JavaVersion.VERSION_11
//}
//kotlinOptions {
// jvmTarget = "11"
//}
}
/**
* The dependencies block in the module-level build configuration file
* specifies dependencies required to build only the module itself.
* To learn more, go to Add build dependencies.
*/
dependencies {
implementation(project(":lib"))
implementation("androidx.appcompat:appcompat:1.6.1")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Odlotowy
/**
* The first line in the build configuration applies the Android Gradle plugin
* to this build and makes the android block available to specify
* Android-specific build options.
*/
plugins {
id 'com.android.application'
}
/**
* Locate (and possibly download) a JDK used to build your kotlin
* source code. This also acts as a default for sourceCompatibility,
* targetCompatibility and jvmTarget. Note that this does not affect which JDK
* is used to run the Gradle build itself, and does not need to take into
* account the JDK version required by Gradle plugins (such as the
* Android Gradle Plugin)
*/
kotlin {
jvmToolchain 11
}
/**
* The android block is where you configure all your Android-specific
* build options.
*/
android {
/**
* The app's namespace. Used primarily to access app resources.
*/
namespace 'com.example.myapp'
/**
* compileSdk specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*/
compileSdk 33
/**
* The defaultConfig block encapsulates default settings and entries for all
* build variants and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {
// Uniquely identifies the package for publishing.
applicationId 'com.example.myapp'
// Defines the minimum API level required to run the app.
minSdk 21
// Specifies the API level used to test the app.
targetSdk 33
// Defines the version number of your app.
versionCode 1
// Defines a user-friendly version name for your app.
versionName "1.0"
}
/**
* The buildTypes block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies ProGuard settings and is not signed by default.
*/
buildTypes {
/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
*/
release {
minifyEnabled true // Enables code shrinking for the release build type.
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
/**
* The productFlavors block is where you can configure multiple product flavors.
* This lets you create different versions of your app that can
* override the defaultConfig block with their own settings. Product flavors
* are optional, and the build system does not create them by default.
*
* This example creates a free and paid product flavor. Each product flavor
* then specifies its own application ID, so that they can exist on the Google
* Play Store, or an Android device, simultaneously.
*
* If you declare product flavors, you must also declare flavor dimensions
* and assign each flavor to a flavor dimension.
*/
flavorDimensions "tier"
productFlavors {
free {
dimension "tier"
applicationId 'com.example.myapp.free'
}
paid {
dimension "tier"
applicationId 'com.example.myapp.paid'
}
}
/**
* To override source and target compatibility (if different from the
* tool chain JDK version), add the following. All of these
* default to the same value as kotlin.jvmToolchain. If you're using the
* same version for these values and kotlin.jvmToolchain, you can
* remove these blocks.
*/
//compileOptions {
// sourceCompatibility JavaVersion.VERSION_11
// targetCompatibility JavaVersion.VERSION_11
//}
//kotlinOptions {
// jvmTarget = '11'
//}
}
/**
* The dependencies block in the module-level build configuration file
* specifies dependencies required to build only the module itself.
* To learn more, go to Add build dependencies.
*/
dependencies {
implementation project(":lib")
implementation 'androidx.appcompat:appcompat:1.6.1'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Pliki właściwości Gradle
Gradle zawiera też 2 pliki właściwości znajdujące się w głównym katalogu projektu, których możesz użyć do określenia ustawień zestawu narzędzi do kompilacji Gradle:
-
gradle.properties - W tym miejscu możesz skonfigurować ustawienia Gradle dla całego projektu, takie jak maksymalny rozmiar stosu demona Gradle. Więcej informacji znajdziesz w artykule Środowisko kompilacji.
-
local.properties - Konfiguruje na potrzeby systemu kompilacji właściwości środowiska lokalnego, w tym:
ndk.dir– ścieżka do NDK. Ta właściwość została wycofana. Pobrane wersje pakietu NDK są instalowane w katalogundkw katalogu Android SDK.sdk.dir– ścieżka do pakietu Android SDK.cmake.dir– ścieżka do CMake.ndk.symlinkdir– w Android Studio w wersji 3.5 lub nowszej tworzy dowiązanie symboliczne do NDK, które może być krótsze niż ścieżka zainstalowana NDK.
Przypisz krótszą ścieżkę pakietu NDK (tylko w systemie Windows)
W systemie Windows narzędzia w zainstalowanym folderze NDK, takie jak ld.exe, prowadzą do długich ścieżek. Narzędzia nie radzą sobie dobrze z długimi ścieżkami.
Aby utworzyć krótszą ścieżkę, w local.properties ustaw właściwość ndk.symlinkdir tak, aby wysyłała żądanie, by wtyczka Androida do obsługi Gradle utworzyła dowiązanie symboliczne do NDK. Ścieżka tego dowiązania symbolicznego może być krótsza niż istniejący folder NDK.
Na przykład użycie funkcji ndk.symlinkdir = C:\ spowoduje wygenerowanie takiego dowiązania symbolicznego: C:\ndk\19.0.5232133
Synchronizacja projektu z plikami Gradle
Gdy wprowadzasz zmiany w plikach konfiguracji kompilacji w projekcie, Android Studio wymaga zsynchronizowania plików projektu, aby móc zaimportować zmiany w konfiguracji kompilacji i sprawdzić, czy konfiguracja nie powoduje błędów kompilacji.
Aby zsynchronizować pliki projektu, kliknij Synchronizuj teraz na pasku powiadomień, który pojawi się po wprowadzeniu zmiany (jak pokazano na ilustracji 1), lub kliknij Synchronizuj projekt 
na pasku menu. Jeśli Android Studio znajdzie błędy w konfiguracji, np. kod źródłowy korzysta z funkcji interfejsu API, które są dostępne tylko na poziomie API wyższym niż compileSdkVersion, problem pojawi się w oknie Wiadomości.
Zbiory źródłowe
Android Studio logicznie grupuje kod źródłowy i zasoby każdego modułu w zbiory źródłowe. Gdy tworzysz nowy moduł, Android Studio tworzy w nim zestaw źródeł main/. Zbiór źródłowy main/ modułu zawiera kod i zasoby używane przez wszystkie warianty kompilacji.
Dodatkowe katalogi zbiorów źródłowych są opcjonalne. Android Studio nie utworzy ich automatycznie, gdy skonfigurujesz nowe warianty kompilacji. Tworzenie zbiorów źródłowych, podobnie jak main/, ułatwia jednak porządkowanie plików i zasobów, których Gradle powinna używać tylko podczas tworzenia określonych wersji aplikacji:
-
src/main/ - Ten zbiór źródłowy zawiera kod i zasoby wspólne dla wszystkich wariantów kompilacji.
-
src/buildType/ - Utwórz ten zbiór źródłowy tak, aby zawierał kod i zasoby tylko dla określonego typu kompilacji.
-
src/productFlavor/ - Utwórz ten zbiór źródłowy tak, aby zawierał kod i zasoby tylko dla określonego rodzaju usługi.
Uwaga: jeśli skonfigurujesz kompilację w taki sposób, aby połączyć różne rodzaje usług, możesz utworzyć katalogi zbioru źródłowego dla każdej kombinacji smaków produktów między wymiarami smaków:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Utwórz ten zbiór źródłowy tak, aby zawierał kod i zasoby tylko dla określonego wariantu kompilacji.
Aby na przykład wygenerować wersję „fullDebug” aplikacji, system kompilacji scala kod, ustawienia i zasoby z tych zbiorów źródłowych:
-
src/fullDebug/(zestaw źródeł wariantu kompilacji) -
src/debug/(zestaw źródeł typu kompilacji) -
src/full/(zestaw źródeł rodzaju produktu) -
src/main/(główny zbiór źródeł)
Uwaga: podczas tworzenia nowego pliku lub katalogu w Android Studio użyj opcji menu Plik > Nowy, aby utworzyć go dla określonego zbioru źródłowego. Zbiory źródłowe, które możesz wybrać, zależą od Twoich konfiguracji kompilacji, a Android Studio automatycznie tworzy wymagane katalogi, jeśli jeszcze nie istnieją.
Jeśli różne zbiory źródłowe zawierają różne wersje tego samego pliku, Gradle przy wyborze pliku stosuje podaną niżej kolejność priorytetów. Zestawy źródeł po lewej stronie zastępują pliki i ustawienia zbiorów źródeł po prawej:
Wariant kompilacji > Typ kompilacji > Typ usługi > główny zestaw źródłowy > Zależności biblioteki
Dzięki temu Gradle może korzystać z plików specyficznych dla wariantu kompilacji, który próbujesz skompilować, a jednocześnie wykorzystywać działania, logikę aplikacji i zasoby wspólne dla innych wersji aplikacji.
Podczas scalania wielu plików manifestu Gradle używa tej samej kolejności priorytetów, aby każdy wariant kompilacji mógł definiować różne komponenty lub uprawnienia w końcowym pliku manifestu. Więcej informacji o tworzeniu niestandardowych zbiorów źródłowych znajdziesz w artykule Tworzenie zbiorów źródłowych.
Katalogi wersji
Jeśli kompilacja zawiera wiele modułów o wspólnych zależnościach lub masz wiele niezależnych projektów o wspólnych zależnościach, zalecamy użycie katalogu wersji lub listy materiałów (BOM), aby określić typowe wersje.
Inne systemy kompilacji
Tworzenie aplikacji na Androida za pomocą aplikacji Bazel jest możliwe, ale nie jest oficjalnie obsługiwane. Android Studio nie obsługuje oficjalnie projektów Bazel.
Aby lepiej zrozumieć obecne ograniczenia tworzenia w Bazel, zapoznaj się ze znanymi problemami.