System kompilacji Androida kompiluje zasoby aplikacji i kod źródłowy, a potem pakuje je w pliki APK lub pakiety Android App Bundle, które możesz testować, wdrażać, podpisywać i rozpowszechniać.
W artykułach Omówienie kompilacji Gradle i Struktura kompilacji na Androida omawialiśmy pojęcia związane z kompilacją oraz strukturę aplikacji na Androida. Teraz nadszedł czas na skonfigurowanie kompilacji.
Glosariusz dotyczący 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óżne etapy cyklu życia rozwoju.
Na przykład typ kompilacji do debugowania włącza opcje debugowania i podpisuje aplikację kluczem debugowania. Typ kompilacji wersji może natomiast skracać i zaciemniać kod aplikacji oraz 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.
- Smaki produktów
- Wersje produktu to różne wersje aplikacji, które możesz udostępnić użytkownikom, np. darmowe i płatne. Możesz dostosować smaki produktów, aby używać różnych kodów i zasobów, a jednocześnie udostępniać i wykorzystywać ponownie te części, które są wspólne dla wszystkich wersji Twojej aplikacji. Gromady produktów są opcjonalne i trzeba je utworzyć ręcznie. Aby zacząć tworzyć różne wersje aplikacji, dowiedz się, jak skonfigurować wersje produktu.
- Tworzenie wariantów
- Wariant kompilacji to usługa łącząca typ kompilacji i rodzaj produktu. To konfiguracja, której Gradle używa do utworzenia aplikacji. Za pomocą wariantów kompilacji możesz utworzyć wersję do debugowania różnych rodzajów produktów w trakcie programowania oraz w podpisanych wersjach do dystrybucji. Nie konfigurujesz wariantów kompilacji bezpośrednio, ale konfigurujesz typy kompilacji i typy produktów, które z nich korzystają. Tworzenie dodatkowych typów kompilacji lub wersji produktu powoduje również utworzenie dodatkowych wariantów kompilacji. Aby dowiedzieć się, jak tworzyć wersje kompilacji i nimi zarządzać, przeczytaj artykuł Konfigurowanie wersji 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ć kilka wersji aplikacji z inną nazwą aplikacji, inną minimalną wersją pakietu SDK lub inną docelową wersją pakietu SDK. Jeśli jest więcej niż jeden plik manifestu, narzędzie do łączenia plików manifestu scala ustawienia manifestu.
- Zależności
- System kompilacji zarządza zależnościami projektu z lokalnego systemu plików i z repozytoriów zdalnych. Oznacza to, że nie musisz ręcznie wyszukiwać, pobierać ani kopiować pakietów binarnych zależności do katalogu projektu. Więcej informacji znajdziesz w sekcji Dodawanie zależności kompilacji.
- Podpisywanie
- System kompilacji umożliwia określenie ustawień podpisywania w konfiguracji kompilacji i automatyczne podpisywanie aplikacji podczas procesu kompilacji. System kompilacji podpisuje wersję debugowania domyślnym kluczem i certyfikatem przy użyciu znanych danych logowania, aby podczas kompilacji nie pojawiał się monit o hasło. System kompilacji nie podpisuje wersji wydania, chyba że wyraźnie zdefiniujesz konfigurację podpisywania dla tej kompilacji. Jeśli nie masz klucza wersji, możesz go wygenerować w sposób opisany 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 zbiór reguł, aby skracać kod i zasoby za pomocą wbudowanych narzędzi, takich jak R8. Skracanie 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 kompilowanie 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 Tworzenie wielu plików APK. Zalecane jest jednak opublikowanie pojedynczego pakietu aplikacji na Androida, ponieważ umożliwia on 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 AAB.
Wersje Javy w kompilacji Androida
Niezależnie od tego, czy kod źródłowy jest napisany w Javie, w Kotlinie czy w obu tych językach, musisz wybrać dla swojej kompilacji wersję JDK lub Java w kilku miejscach. Więcej informacji znajdziesz w artykule Wersje Javy w kompilacji Androida.
Pliki konfiguracji kompilacji
Tworzenie niestandardowych konfiguracji kompilacji wymaga wprowadzenia zmian w co najmniej 1 pliku konfiguracji kompilacji. Te zwykłe pliki tekstowe wykorzystują język specyficzny dla domeny (DSL) do opisania i manipulacji logiką kompilacji przy użyciu skryptu Kotlin, który jest odmianą języka Kotlin. Do konfigurowania kompilacji możesz też użyć Groovy – dynamicznego języka maszyny wirtualnej Java (JVM).
Aby zacząć konfigurować kompilację, nie musisz znać skryptu Kotlin ani Groovy, ponieważ wtyczka Gradle dla Androida udostępnia większość potrzebnych elementów DSL. Więcej informacji o wtyczce DSL dla Androida Gradle znajdziesz w dokumentacji na temat DSL. Skrypt Kotlin korzysta też z podstawowego Gradle Kotlin DSL.
Gdy rozpoczynasz nowy projekt, Android Studio automatycznie tworzy niektóre z tych plików i wypełnia je na podstawie sensownych wartości domyślnych. Przegląd utworzonych plików znajdziesz w artykule Struktura kompilacji Androida.
Plik Gradle Wrapper
Opakowanie Gradle (gradlew
) to mała aplikacja dołączona do kodu źródłowego, która pobiera i uruchamia Gradle.
Zwiększa to spójność wykonywania 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órej wersji Gradle używasz 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 DSL w języku Kotlin) lub plik settings.gradle
(w przypadku DSL w języku Groovy) znajduje się w katalogu głównym katalogu projektu. Ten plik ustawień definiuje ustawienia repozytorium na poziomie projektu i informuje Gradle, które moduły powinno uwzględnić podczas tworzenia aplikacji. Projekty wielomodułowe muszą określać każdy moduł, który ma się znaleźć 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")
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. 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 build.gradle.kts
najwyższego poziomu (dla Kotlin DSL) lub plik build.gradle
(dla Groovy DSL) znajduje się w katalogu głównym projektu. Zwykle definiuje ona typowe wersje wtyczek używanych przez moduły w Twoim projekcie.
Poniższy przykładowy kod przedstawia 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.7.0" apply false id("com.android.library") version "8.7.0" apply false id("org.jetbrains.kotlin.android") version "2.0.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.7.0' apply false id 'com.android.library' version '8.7.0' apply false id 'org.jetbrains.kotlin.android' version '2.0.20' apply false }
Plik kompilacji na poziomie modułu
Plik build.gradle.kts
(w przypadku Kotlin DSL) lub plik build.gradle
(w przypadku 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 umożliwia określenie niestandardowych opcji pakowania, takich jak dodatkowe typy kompilacji i wersje produktu, oraz zastąpienie ustawień w pliku main/
pliku manifestu aplikacji lub skrypcie kompilacji najwyższego poziomu.
Ustawienia Android SDK
Plik kompilacji na poziomie modułu aplikacji zawiera ustawienia, które wskazują wersje pakietu Android SDK używane podczas kompilacji, wybierasz zachowania platformy i określasz minimalną wersję, na której działa aplikacja.
-
compileSdk
-
compileSdk
określa, które interfejsy API Androida i Java są dostępne podczas kompilowania kodu źródłowego. Aby korzystać z najnowszych funkcji Androida, podczas kompilowania używaj najnowszego pakietu Android SDK.Niektóre interfejsy API platformy Android mogą być niedostępne na starszych poziomach interfejsu API. Możesz warunkowo zablokować korzystanie z nowych funkcji lub użyć bibliotek zgodności AndroidX, aby korzystać z nowych funkcji na niższych poziomach interfejsu API Androida.
Każdy pakiet Android SDK udostępnia podzbiór interfejsów API Javy do użycia w aplikacji. Tabela Dostępnych interfejsów API Javy, których możesz używać w kodzie źródłowym w języku Java lub Kotlin pokazuje, który poziom interfejsu API Javy jest dostępny w zależności od wersji pakietu Android SDK. Nowsze interfejsy API Javy są obsługiwane w starszych wersjach Androida dzięki desugaringowi, który musi być włączony w kompilacji.
Android Studio wyświetla ostrzeżenia, jeśli
compileSdk
jest w sprzeczności z bieżącą wersją Android Studio, AGP lub wymaganiami dotyczącymi zależności biblioteki projektu. -
minSdk
-
Wartość
minSdk
określa najstarszą wersję Androida, którą ma obsługiwać aplikacja. UstawienieminSdk
ogranicza liczbę urządzeń, na których można zainstalować Twoją aplikację.Obsługa starszych wersji Androida może wymagać większej liczby sprawdzeń warunkowych w kodzie lub większego wykorzystania bibliotek zgodności AndroidX. Należy porównać koszty utrzymania obsługi starszych wersji z procentem użytkowników, którzy nadal z nich korzystają. Bieżące wartości procentowe wykorzystania wersji znajdziesz w tabeli wersji w kreatorze nowego projektu w Android Studio.
Gdy edytujesz kod w Android Studio lub przeprowadzasz testy podczas kompilacji, Lint będzie ostrzegać o używanych przez Ciebie interfejsach API, które nie są dostępne w
minSdk
. Należy je naprawić, uwzględniając nowsze funkcje w warunkach lub używającAppcompat
w celu zapewnienia zgodności wstecznej. -
targetSdk
-
targetSdk
służy do 2 celów:- Określa zachowanie aplikacji w czasie działania aplikacji.
- Potwierdza on wersję Androida do testów.
Jeśli aplikacja działa na urządzeniu z wersją Androida nowszą niż ta wskazana w
targetSdk
, Android uruchamia ją w trybie zgodności, który działa podobnie do starszej wersji wskazanej wtargetSdk
. Na przykład, gdy w interfejsie API 23 wprowadzono model uprawnień czasu działania, nie wszystkie aplikacje były gotowe do natychmiastowego skorzystania z tego rozwiązania. Ustawienie wartościtargetSdk
na 22 pozwala na uruchamianie tych aplikacji na urządzeniach z poziomem API 23 bez konieczności używania uprawnień w czasie wykonywania oraz na korzystanie z funkcji dostępnych w najnowszej wersjicompileSdk
. Zasady dystrybucji Google Play nakładają dodatkowe zasady na docelowym poziomie interfejsu API.Wartość
targetSdk
musi być mniejsza lub równa wartościcompileSdk
.
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
określa zachowanie aplikacji w czasie działaniatargetSdk
musi być równa lub mniejsza niżcompileSdk
Przykładowy skrypt kompilacji modułu aplikacji
Ten przykładowy skrypt kompilacji modułu aplikacji na Androida zawiera 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.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 katalogu głównym projektu, których możesz używać do określania ustawień samego pakietu narzędzi kompilacji Gradle:
-
gradle.properties
- Tutaj możesz skonfigurować ustawienia Gradle na poziomie projektu, takie jak maksymalny rozmiar stosu demona Gradle. Więcej informacji znajdziesz w artykule Środowisko kompilacji.
-
local.properties
-
Skonfiguruj właściwości środowiska lokalnego dla systemu kompilacji, w tym:
ndk.dir
– ścieżka do NDK. Ta usługa została wycofana. Wszystkie pobrane wersje NDK są instalowane w katalogundk
w katalogu pakietu Android SDK.sdk.dir
– ścieżka do pakietu Android SDK.cmake.dir
– ścieżka do CMake.ndk.symlinkdir
– w Android Studio 3.5 i nowszych wersjach tworzy symboliczny link do NDK, który może być krótszy niż ścieżka do zainstalowanego NDK.
Przypisz NDK do krótszej ścieżki (tylko w systemie Windows)
W systemie Windows narzędzia w zainstalowanym folderze NDK, takie jak ld.exe
, mają długie ścieżki. Takie narzędzia nie radzą sobie dobrze z długimi ścieżkami.
Aby utworzyć krótszą ścieżkę, w pliku local.properties
ustaw właściwość ndk.symlinkdir
, aby poprosić wtyczkę Android Gradle o utworzenie symbolicznego linku do NDK. Ścieżka tego symbolicznego linku może być krótsza niż istniejący folder NDK.
Na przykład ndk.symlinkdir = C:\
powoduje utworzenie tego symbolicznego linku: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 przeprowadzić kilka kontroli, które mają na celu sprawdzenie, 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 (patrz rysunek 2), lub kliknij Synchronizuj projekt na pasku menu. Jeśli Android Studio wykryje błędy w konfiguracji (np. kod źródłowy używa funkcji interfejsu API, które są dostępne tylko na poziomie interfejsu API wyższego niż compileSdkVersion
), w oknie Wiadomości pojawi się opis problemu.
Zestawy źródeł
Android Studio logicznie grupuje kod źródłowy i zasoby każdego modułu w zbiory źródłowe. Gdy utworzysz nowy moduł, Android Studio utworzy w nim zestaw main/
źródeł. Zestaw źródeł main/
modułu zawiera kod i zasoby używane przez wszystkie jego warianty kompilacji.
Dodatkowe katalogi zbiorów źródeł są opcjonalne, a Android Studio nie tworzy ich automatycznie podczas konfigurowania nowych wariantów kompilacji. Jednak utworzenie zbiorów źródłowych, podobnie jak w przypadku main/
, pomaga uporządkować pliki i zasoby, których Gradle powinna używać tylko do tworzenia określonych wersji aplikacji:
-
src/main/
- Ten zestaw źródeł zawiera kod i zasoby wspólne dla wszystkich wariantów kompilacji.
-
src/buildType/
- Utwórz ten zestaw źródeł, aby uwzględnić kod i zasoby tylko w przypadku określonego typu kompilacji.
-
src/productFlavor/
- Utwórz ten zbiór źródłowy, aby zawierał kod i zasoby tylko dla określonego rodzaju produktów.
Uwaga: jeśli skonfigurujesz kompilację w taki sposób, aby połączyć różne rodzaje produktów, możesz utworzyć katalogi zbiorów źródłowych dla każdej kombinacji odmian produktów w wymiarach „
src/productFlavor1ProductFlavor2/
”. -
src/productFlavorBuildType/
- Utwórz ten zestaw źródłowy, aby uwzględnić kod i zasoby tylko dla konkretnej wersji.
Na przykład aby wygenerować wersję „fullDebug” aplikacji, system kompilacji scala kod, ustawienia i zasoby z tych zbiorów źródłowych:
-
src/fullDebug/
(zbiór źródeł wariantu 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 w Android Studio użyj opcji menu Plik > Nowy, aby utworzyć go dla określonego zbioru źródłowego. Dostępne zestawy źródeł zależą od 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 wybiera plik do użycia zgodnie z tą kolejnością priorytetów. Pliki i ustawienia zbiorów źródeł po lewej stronie zastępują pliki i ustawienia zbiorów źródeł po prawej stronie:
wariant kompilacji > typ kompilacji > rodzaj usługi > 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 wariantu kompilacji, który próbujesz skompilować, jednocześnie wykorzystując ponownie aktywności, logikę aplikacji i zasoby, które są wspólne dla innych wersji aplikacji.
Podczas łączenia wielu plików manifestu Gradle używa tej samej kolejności priorytetów, więc każdy wariant kompilacji może definiować różne komponenty lub uprawnienia w ostatecznym pliku manifestu. Więcej informacji o tworzeniu niestandardowych zestawów źródeł znajdziesz w artykule [GA4] Tworzenie zestawów źródeł.
Katalogi wersji
Jeśli kompilacja zawiera wiele modułów z współzależnościami lub masz wiele niezależnych projektów z współzależnościami, zalecamy użycie katalogu wersji lub listy materiałów (BOM), aby określić wspólne wersje.
Inne systemy kompilacji
Tworzenie aplikacji na Androida za pomocą 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 za pomocą usługi Bazel, zapoznaj się ze znanymi problemami.