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.6.0" apply false id("com.android.library") version "8.6.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.6.0' apply false id 'com.android.library' version '8.6.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
Plik kompilacji na poziomie modułu
build.gradle.kts
na poziomie modułu (dla DSL Kotlin) lub
Plik build.gradle
(dla Groovy DSL) znajduje się w każdym
Katalog project/module/
. Pozwala
skonfigurować ustawienia kompilacji dla konkretnego modułu, w którym się znajduje. Konfiguruję
te ustawienia kompilacji pozwalają określić niestandardowe opcje tworzenia pakietów, takie jak
dodatkowych typów kompilacji i typów usług, a także zastąpić ustawienia
Plik manifestu aplikacji main/
lub skrypt kompilacji najwyższego poziomu.
Ustawienia pakietu SDK na Androida
Plik kompilacji na poziomie modułu aplikacji zawiera ustawienia wskazujące, wersje pakietu SDK na Androida użyte podczas kompilacji, wyboru działań platformy oraz określając minimalną wersję, na której działa aplikacja.
-
compileSdk
-
compileSdk
określa, które interfejsy API Androida i Java są dostępnych podczas kompilowania kodu źródłowego. Aby korzystać z najnowszego Androida funkcji, podczas kompilacji użyj najnowszego pakietu Android SDK.Niektóre interfejsy API platformy Androida mogą być niedostępne na starszych poziomach API. Dostępne opcje warunkowo zabezpieczać korzystanie z nowszych funkcji lub bibliotek zgodności z AndroidemX, aby korzystać z nowszych funkcji o niższych poziomach. Poziomy interfejsu API Androida.
Każdy pakiet Android SDK zawiera podzbiór interfejsów API Java, które możesz wykorzystać w aplikacji. Tabela w Których interfejsów API Java mogę używać w moim kodzie źródłowym Java lub Kotlin pokazuje, jaki poziom interfejsu API języka Java jest dostępny w zależności od wersji pakietu Android SDK. Nowsze interfejsy API Java są obsługiwane we wcześniejszych wersjach Androida przez desugaring, które musi być włączone w kompilacji.
Android Studio wyświetla ostrzeżenia, jeśli
compileSdk
powoduje konflikty z bieżącą wersją Android Studio, AGP lub biblioteką Twojego projektu w zakresie zależności. -
minSdk
-
minSdk
określa najniższą wersję Androida, które aplikacja ma obsługiwać. UstawienieminSdk
ogranicza urządzeń, na których możesz zainstalować Twoją aplikację.Obsługa starszych wersji Androida może wymagać większej liczby testów warunkowych w kodzie i większej liczbie bibliotek zgodności z AndroidemX. Zalecenia koszty obsługi starszych wersji w porównaniu z odsetek użytkowników, którzy nadal używają starszych wersji. Zobacz wykres wersji w kreatorze nowego projektu w Android Studio dla bieżących wartości procentowych wykorzystania wersji.
Podczas edytowania kodu w Android Studio lub sprawdzania Lint będzie ostrzegać o używanych przez Ciebie interfejsach API, które nie są dostępne w
minSdk
. Napraw to do przekształcanie nowszych funkcji jako warunkowych lub za pomocą funkcjiAppcompat
, aby zapewnić zgodność wsteczną. -
targetSdk
-
targetSdk
ma 2 cele:- Określa zachowanie aplikacji w czasie działania aplikacji.
- Potwierdza on wersję Androida do testów.
Jeśli używasz urządzenia z Androidem w wersji wyższej niż
targetSdk
, Android uruchamia Twoją aplikację w trybie zgodności który działa podobnie do starszej wersji wskazywanej w parametrzetargetSdk
Na przykład: gdy interfejs API 23 wprowadził środowisko wykonawcze model uprawnień, nie wszystkie aplikacje były gotowe do jego wdrożenia. Jeśli ustawisztargetSdk
na 22, te aplikacje mogą działać Urządzenia z interfejsem API 23 bez uprawnień czasu działania i które mogłyby używać funkcji dostępne w najnowszej wersjicompileSdk
. Google Play, zasada dystrybucji wymuszana dodatkowych zasad dotyczących docelowego poziomu interfejsu API.Wartość
targetSdk
musi być mniejsza lub równa do okresucompileSdk
.
Uwaga: wartości compileSdk
i targetSdk
nie muszą być takie same. Pamiętaj o tych podstawowych zasadach:
compileSdk
daje Ci dostęp do nowych interfejsów APItargetSdk
ustawia działanie aplikacji w czasie działania- Wartość w polu
targetSdk
nie może być większa niżcompileSdk
Przykładowy skrypt tworzenia modułu aplikacji
W tym przykładowym skrypcie kompilacji modułu aplikacji na Androida omówiono kilka podstawowych elementów i ustawień 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.7.0") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
Odlotowe
/** * 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.7.0' 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 projekcie głównym. którego możesz użyć do określenia ustawień pakietu narzędzi do kompilacji Gradle. :
-
gradle.properties
- Tutaj możesz skonfigurować ustawienia Gradle dotyczące całego projektu, takie jak Maksymalny rozmiar sterty demona Gradle. Więcej informacji znajdziesz w artykule Tworzenie środowiska.
-
local.properties
-
Konfiguruje właściwości środowiska lokalnego dla systemu kompilacji, w tym
:
ndk.dir
– ścieżka do NDK. Ta usługa została wycofane. Wszystkie pobrane wersje NDK są zainstalowane wndk
w katalogu Android SDK.sdk.dir
– ścieżka do pakietu SDK na Androida.cmake.dir
– ścieżka CMake.ndk.symlinkdir
– w Android Studio 3.5 lub nowszym tworzy dowiązanie symboliczne do klucza NDK, które może być krótsze niż zainstalowane Ścieżka NDK.
.
Przypisz ponownie NDK na krótszą ścieżkę (tylko Windows)
W systemie Windows narzędzia z zainstalowanego folderu NDK, takie jak ld.exe
, kończą się
długich ścieżek. Takie 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
, aby zażądać, aby wtyczka Androida do obsługi Gradle utworzyła dowiązanie symboliczne do
NK. Ścieżka tego dowiązania symbolicznego może być krótsza niż w istniejącym folderze NDK.
Na przykład użycie funkcji ndk.symlinkdir = C:\
daje następujący dowiązanie symboliczne:
C:\ndk\19.0.5232133
Synchronizowanie projektu z plikami Gradle
Gdy wprowadzasz zmiany w plikach konfiguracji kompilacji w projekcie, Android Studio wymaga synchronizacji plików projektu, zaimportuj zmiany w konfiguracji kompilacji i przeprowadź testy, aby upewnić się, nie powoduje błędów kompilacji.
Aby zsynchronizować pliki projektu, kliknij Sync Now (Synchronizuj teraz) w
paska powiadomień, który pojawia się po wprowadzeniu zmian, jak widać tutaj:
rysunek 1 lub kliknij Synchronizacja projektu
na pasku menu. Jeśli Android Studio wykryje błędy na
konfiguracji – na przykład kod źródłowy korzysta z funkcji API, które są
dostępne na poziomie interfejsu API wyższym niż compileSdkVersion
– okno Wiadomości zawiera opis problemu.
Zbiory źródłowe
Android Studio logicznie grupuje kod źródłowy i zasoby w każdym module
na zbiory źródłowe. Gdy tworzysz nowy moduł, Android Studio
tworzy w module zbiór źródłowy main/
. Atrybuty
Zbiór źródłowy main/
zawiera kod i zasoby używane przez wszystkie
wariantów kompilacji.
Dodatkowe katalogi zbioru źródeł są opcjonalne. Android
Studio nie tworzy ich automatycznie, gdy konfigurujesz nową kompilację.
wersji. Jednak utworzenie zbiorów źródłowych, podobnych w zasadzie main/
, pomaga
Porządkują pliki i zasoby, których Gradle powinna używać tylko do tworzenia określonych
wersje Twojej 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, by zawierał kod i zasoby na potrzeby określonego typu kompilacji.
-
src/productFlavor/
-
Utwórz ten zbiór źródłowy, by zawierał kod i zasoby na potrzeby określonego
smak produktu.
Uwaga: jeśli skonfigurujesz kompilację w taki sposób, aby połączyć kilka typów usług, możesz utworzyć katalogi zbiorów źródłowych kombinacja smaków produktów o różnych wymiarach smaków:
src/productFlavor1ProductFlavor2/
-
src/productFlavorBuildType/
- Utwórz ten zbiór źródłowy, by zawierał kod i zasoby na potrzeby określonego wariantu kompilacji.
Aby na przykład wygenerować plik „fullDebug” wersji Twojej aplikacji, system kompilacji scala kod, ustawienia i zasoby z tych zbiorów źródłowych:
-
src/fullDebug/
(zbiór źródeł wariantów kompilacji) -
src/debug/
(zbiór źródłowy typu kompilacji) -
src/full/
(zestaw źródeł smaku produktu) -
src/main/
(główny zestaw źródłowy)
Uwaga: podczas tworzenia nowego pliku lub katalogu na Androidzie w Studio, użyj menu Plik > Opcje menu, które chcesz utworzyć dla określonego zbioru źródłowego. Do wyboru masz zbiory źródeł, w konfiguracjach kompilacji, a Android Studio automatycznie utworzy wymaganych katalogów, jeśli jeszcze nie istnieją.
Jeśli różne zbiory źródłowe zawierają różne wersje tego samego pliku, Gradle przy wyborze pliku użyć tej kolejności. Źródło zestawów po lewej stronie zastępuje pliki i ustawienia zbiorów źródłowych prawa:
wariant kompilacji > typ kompilacji > smak produktu > główny zbiór źródeł > zależności bibliotek.
Dzięki temu Gradle może używać plików, które są specyficzne dla Twojego wariantu kompilacji które próbują tworzyć, wykorzystując ponownie działania, logikę aplikacji zasobów wspólnych dla innych wersji aplikacji.
W przypadku scalania wielu plików manifestu, Gradle używa tej samej kolejności priorytetu, aby każdy wariant kompilacji i zdefiniować różne komponenty lub uprawnienia w ostatecznej wersji pliku manifestu. Aby się uczyć więcej informacji o tworzeniu niestandardowych zbiorów źródłowych znajdziesz w artykule Tworzenie zestawów źródłowych.
Katalogi wersji
Jeśli kompilacja zawiera wiele modułów o wspólnych zależnościach lub masz kilka niezależnych projektów o wspólnych zależnościach, zalecamy Używasz katalogu wersji lub spisu materiałów (BOM), i określić wspólne wersje.
Inne systemy kompilacji
Tworzenie aplikacji na Androida przy użyciu Bazel ale nie jest to oficjalnie obsługiwane. Android Studio nie jest oficjalnie wspierają projekty Bazel.
Aby lepiej zrozumieć obecne ograniczenia tworzenia za pomocą Bazel, zapoznaj się z znanych problemach.