Sistem build Android mengompilasi resource dan kode sumber aplikasi lalu memaketkannya menjadi APK atau Android App Bundle yang dapat Anda uji, deploy, tanda tangani, dan distribusikan.
Dalam ringkasan build Gradle dan struktur build Android, kita telah membahas konsep build dan struktur aplikasi Android. Sekarang saatnya mengonfigurasi build.
Glosarium build Android
Gradle dan plugin Android Gradle membantu Anda mengonfigurasi aspek-aspek build berikut:
- Jenis build
-
Jenis build menentukan properti tertentu yang digunakan Gradle ketika mem-build dan memaketkan aplikasi. Jenis build biasanya dikonfigurasi untuk berbagai tahap siklus proses pengembangan.
Misalnya, jenis build debug mengaktifkan opsi debug dan menandatangani aplikasi dengan kunci debug, sedangkan jenis build rilis dapat menyusutkan ukuran, meng-obfuscate, dan menandatangani aplikasi dengan kunci rilis untuk distribusi.
Anda harus menentukan setidaknya satu jenis build untuk mem-build aplikasi. Android Studio membuat jenis build rilis dan debug secara default. Untuk mulai menyesuaikan setelan pemaketan aplikasi, pelajari cara mengonfigurasi jenis build.
- Ragam produk
- Ragam produk merepresentasikan berbagai versi aplikasi Anda yang dapat dirilis kepada pengguna, seperti versi gratis dan berbayar. Anda dapat menyesuaikan ragam produk untuk menggunakan kode dan resource yang berbeda sekaligus berbagi dan menggunakan kembali bagian-bagian yang umum untuk semua versi aplikasi Anda. Ragam produk bersifat opsional, dan Anda harus membuatnya secara manual. Untuk mulai membuat versi aplikasi yang berbeda, pelajari cara mengonfigurasi ragam produk.
- Varian build
- Varian build adalah cross product dari jenis build dan ragam produk, dan merupakan konfigurasi yang digunakan Gradle untuk mem-build aplikasi Anda. Dengan varian build, Anda dapat mem-build versi debug ragam produk selama pengembangan dan menandatangani versi rilis ragam produk untuk distribusi. Meskipun tidak harus mengonfigurasi varian build secara langsung, Anda perlu mengonfigurasi jenis build dan ragam produk yang membentuknya. Membuat jenis build atau ragam produk tambahan juga akan membuat varian build tambahan. Untuk mempelajari cara membuat dan mengelola varian build, baca ringkasan Mengonfigurasi varian build.
- Entri manifes
- Anda dapat menentukan nilai untuk beberapa properti file manifes dalam konfigurasi varian build. Nilai build ini menggantikan nilai yang ada dalam file manifes. Ini berguna jika Anda ingin membuat beberapa varian aplikasi dengan nama aplikasi, versi SDK minimum, atau versi SDK target yang berbeda. Jika ada beberapa manifes, alat penggabung manifes akan menggabungkan setelan manifes.
- Dependensi
- Sistem build mengelola dependensi project dari sistem file lokal Anda dan dari repositori jarak jauh. Ini berarti Anda tidak perlu menelusuri, mendownload, dan menyalin paket biner dependensi secara manual ke dalam direktori project. Untuk mencari tahu selengkapnya, lihat Menambahkan dependensi build.
- Penandatanganan
- Sistem build memungkinkan Anda menentukan setelan penandatanganan dalam konfigurasi build, dan dapat otomatis menandatangani aplikasi selama proses build. Sistem build menandatangani versi debug dengan sertifikat dan kunci default menggunakan kredensial yang dikenal untuk menghindari permintaan sandi pada waktu build. Sistem build tidak menandatangani versi rilis kecuali Anda secara eksplisit menentukan konfigurasi penandatanganan untuk build ini. Jika tidak memiliki kunci rilis, Anda dapat membuatnya seperti yang dijelaskan dalam Menandatangani aplikasi Anda. Build rilis yang ditandatangani diperlukan untuk mendistribusikan aplikasi melalui sebagian besar app store.
- Penyingkatan ukuran kode dan resource
- Sistem build memungkinkan Anda menentukan file aturan ProGuard yang berbeda untuk setiap varian build. Saat mem-build aplikasi Anda, sistem build akan menerapkan rangkaian aturan yang sesuai untuk menyingkat kode dan resource Anda menggunakan alat penyingkat bawaan, seperti R8. Menyingkat kode dan resource dapat membantu mengurangi ukuran APK atau AAB.
- Dukungan multi-APK
- Sistem build memungkinkan Anda untuk otomatis mem-build berbagai APK yang masing-masing hanya berisi kode dan resource yang dibutuhkan untuk kepadatan layar tertentu atau Antarmuka Biner Aplikasi (ABI). Untuk mengetahui informasi selengkapnya, lihat Mem-build multi-APK. Namun, merilis satu AAB adalah pendekatan yang direkomendasikan, karena memberikan pemisahan menurut bahasa selain kepadatan layar dan ABI, sekaligus tidak perlu mengupload beberapa artefak ke Google Play. Semua aplikasi baru yang dikirimkan setelah Agustus 2021 harus menggunakan AAB.
Versi Java dalam build Android
Baik kode sumber Anda ditulis dalam Java, Kotlin, atau keduanya, ada beberapa tempat yang mengharuskan Anda memilih versi bahasa JDK atau Java untuk build. Lihat Versi Java dalam build Android untuk mengetahui detailnya.
File konfigurasi build
Pembuatan konfigurasi build kustom mengharuskan Anda melakukan perubahan terhadap satu atau beberapa file konfigurasi build. File teks biasa ini menggunakan bahasa khusus domain (DSL) untuk mendeskripsikan dan memanipulasi logika build menggunakan skrip Kotlin, yang merupakan ragam dari bahasa Kotlin. Anda juga dapat menggunakan Groovy, yang merupakan bahasa dinamis untuk Java Virtual Machine (JVM), untuk mengonfigurasi build.
Anda tidak perlu mengetahui skrip Kotlin atau Groovy untuk mulai mengonfigurasi build karena plugin Android Gradle memperkenalkan sebagian besar elemen DSL yang Anda butuhkan. Untuk mempelajari DSL plugin Android Gradle lebih lanjut, baca Dokumentasi referensi DSL. Skrip Kotlin juga bergantung pada DSL Kotlin Gradle yang mendasarinya
Saat memulai project baru, Android Studio secara otomatis akan membuat beberapa file ini untuk Anda dan mengisinya berdasarkan default yang logis. Untuk ringkasan file yang dibuat, lihat Struktur build Android.
File Wrapper Gradle
Wrapper Gradle (gradlew) adalah aplikasi kecil yang disertakan dengan
kode sumber Anda yang mendownload dan meluncurkan Gradle itu sendiri.
Hal ini akan menghasilkan eksekusi build yang lebih konsisten. Developer mendownload
sumber aplikasi dan menjalankan gradlew. Tindakan ini akan mendownload distribusi Gradle
yang diperlukan, dan meluncurkan Gradle untuk mem-build aplikasi Anda.
File gradle/wrapper/gradle-wrapper.properties
berisi properti, distributionUrl, yang menjelaskan versi
Gradle yang digunakan untuk menjalankan build Anda.
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
File setelan Gradle
File settings.gradle.kts (untuk DSL Kotlin) atau
file settings.gradle (untuk DSL Groovy) terletak di direktori
project root. File setelan ini menentukan setelan repositori
level project dan memberi tahu Gradle modul mana yang harus disertakan saat mem-build
aplikasi. Project multi-modul perlu menentukan setiap modul yang harus dimasukkan ke
build final.
Untuk sebagian besar project, file akan terlihat seperti berikut secara default:
Kotlin
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include(":app")
Groovy
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include ':app'
File build level atas
File build.gradle.kts level atas (untuk Kotlin DSL) atau
file build.gradle (untuk Groovy DSL) terletak di direktori
project root. File ini biasanya menentukan versi plugin umum yang digunakan
oleh modul dalam project Anda.
Contoh kode berikut menjelaskan setelan default dan elemen DSL dalam skrip build level atas setelah membuat project baru:
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 }
File build level modul
File build.gradle.kts level modul (untuk Kotlin DSL) atau
build.gradle (untuk Groovy DSL) terletak di setiap
direktori project/module/. File ini memungkinkan Anda
mengonfigurasi setelan build untuk modul tertentu tempatnya berada. Dengan mengonfigurasi
setelan build ini, Anda dapat menyediakan opsi pengemasan kustom, seperti
ragam produk dan jenis build tambahan, serta mengganti setelan dalam
manifes aplikasi main/ atau skrip build level atas.
Setelan Android SDK
File build tingkat modul untuk aplikasi Anda menyertakan setelan yang menunjukkan versi Android SDK yang digunakan saat mengompilasi, memilih perilaku platform, dan menentukan versi minimum yang digunakan aplikasi Anda.
-
compileSdk -
compileSdkmenentukan API Android dan Java mana yang tersedia saat mengompilasi kode sumber Anda. Untuk menggunakan fitur Android terbaru, gunakan Android SDK terbaru saat mengompilasi.Beberapa API platform Android mungkin tidak tersedia di level API yang lebih lama. Anda dapat melindungi penggunaan fitur yang lebih baru secara kondisional atau menggunakan library kompatibilitas AndroidX untuk menggunakan fitur yang lebih baru dengan level Android API yang lebih rendah.
Setiap Android SDK menyediakan subset Java API untuk digunakan dalam aplikasi Anda. Tabel di API Java mana yang dapat saya gunakan dalam kode sumber Java atau Kotlin menunjukkan level API Java yang tersedia berdasarkan versi Android SDK. API Java yang lebih baru didukung di Android versi sebelumnya melalui desugaring, yang harus diaktifkan dalam build Anda.
Android Studio menampilkan peringatan jika
compileSdkAnda bertentangan dengan versi Android Studio, AGP, atau persyaratan dependensi pustaka project Anda saat ini. -
minSdk -
minSdkmenentukan versi Android terendah yang ingin didukung aplikasi Anda. MenetapkanminSdkakan membatasi perangkat yang dapat menginstal aplikasi Anda.Mendukung versi Android yang lebih rendah mungkin memerlukan lebih banyak pemeriksaan kondisional dalam kode Anda atau lebih banyak penggunaan library kompatibilitas AndroidX. Anda harus mempertimbangkan biaya pemeliharaan untuk mendukung versi yang lebih rendah dengan persentase pengguna yang masih menggunakan versi yang lebih rendah tersebut. Lihat diagram versi di wizard project baru Android Studio untuk mengetahui persentase penggunaan versi saat ini.
Saat mengedit kode di Android Studio atau menjalankan pemeriksaan selama build, lint akan memperingatkan tentang API yang Anda gunakan yang tidak tersedia di
minSdk. Anda harus memperbaikinya dengan membuat fitur yang lebih baru bersifat kondisional atau dengan menggunakanAppcompatuntuk kompatibilitas mundur. -
targetSdk -
targetSdkmemiliki dua tujuan:- File ini menetapkan perilaku runtime aplikasi Anda.
- Hal ini membuktikan versi Android yang telah Anda uji.
Jika Anda menjalankan aplikasi di perangkat yang menggunakan versi Android yang lebih tinggi daripada
targetSdk, Android akan menjalankan aplikasi Anda dalam mode kompatibilitas yang berperilaku mirip dengan versi yang lebih rendah yang ditunjukkan dalamtargetSdk. Misalnya, saat API 23 memperkenalkan model izin runtime, tidak semua aplikasi siap untuk segera mengadopsinya. Dengan menetapkantargetSdkke 22, aplikasi tersebut dapat berjalan di perangkat API 23 tanpa menggunakan izin runtime, dan dapat menggunakan fitur yang disertakan dalam versicompileSdkterbaru. Kebijakan distribusi Google Play menerapkan kebijakan tambahan pada API level target.Nilai
targetSdkharus kurang dari atau sama dengan nilaicompileSdk.
Catatan: Nilai compileSdk dan targetSdk
tidak harus sama. Perhatikan prinsip dasar berikut:
compileSdkmemberi Anda akses ke API barutargetSdkmenetapkan perilaku runtime aplikasi AndatargetSdkharus kurang dari atau sama dengancompileSdk
Contoh skrip build modul aplikasi
Contoh skrip build modul aplikasi Android ini menjelaskan beberapa setelan dan elemen DSL dasar:
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")))) }
Groovy
/** * 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']) }
File properti Gradle
Gradle juga menyertakan dua file properti, yang terletak dalam direktori root project, yang dapat Anda gunakan untuk menentukan setelan toolkit build Gradle itu sendiri:
-
gradle.properties - Di sini, Anda dapat mengonfigurasi setelan Gradle lingkup project, seperti ukuran heap maksimum daemon Gradle. Untuk mengetahui informasi selengkapnya, lihat Lingkungan Build.
-
local.properties -
Mengonfigurasi properti lingkungan lokal untuk sistem build, termasuk properti berikut:
ndk.dir- Jalur ke NDK. Properti ini sudah tidak digunakan lagi. Setiap versi NDK yang didownload akan diinstal di direktorindkdalam direktori Android SDK.sdk.dir- Jalur ke Android SDK.cmake.dir- Jalur ke CMake.ndk.symlinkdir- Di Android Studio 3.5 dan yang lebih baru, membuat symlink ke NDK yang dapat lebih pendek dari jalur NDK yang diinstal.
Memetakan ulang NDK ke jalur yang lebih pendek (khusus Windows)
Di Windows, alat dalam folder NDK yang diinstal, seperti ld.exe, akan memiliki
jalur panjang. Alat tersebut tidak mendukung jalur panjang dengan baik.
Untuk membuat jalur yang lebih pendek, di local.properties, setel properti
ndk.symlinkdir untuk meminta plugin Android Gradle membuat symlink ke
NDK. Jalur symlink tersebut dapat lebih pendek dari folder NDK yang ada.
Misalnya, ndk.symlinkdir = C:\ akan menghasilkan symlink berikut:
C:\ndk\19.0.5232133
Menyinkronkan project dengan file Gradle
Jika Anda membuat perubahan pada file konfigurasi build dalam project, Android Studio akan mengharuskan Anda untuk menyinkronkan file project agar dapat mengimpor perubahan konfigurasi build dan menjalankan beberapa pemeriksaan untuk memastikan konfigurasi Anda tidak akan menimbulkan error build.
Untuk menyinkronkan file project, klik Sync Now di baris notifikasi
yang muncul saat Anda membuat perubahan, seperti dalam
gambar 2, atau klik Sync Project 
dari panel menu. Jika Android Studio menemukan error pada konfigurasi
Anda, misalnya, kode sumber Anda menggunakan fitur API yang hanya
tersedia di API level yang lebih tinggi dari compileSdkVersion
— jendela Messages akan menjelaskan masalah tersebut.
Set sumber
Android Studio secara logis mengelompokkan kode sumber dan resource untuk setiap modul dalam set sumber. Saat Anda membuat modul baru, Android Studio
akan membuat set sumber main/ dalam modul. Set sumber
main/ modul berisi kode dan resource yang digunakan oleh semua
varian build-nya.
Direktori set sumber tambahan bersifat opsional, dan Android
Studio tidak secara otomatis membuatnya saat Anda mengonfigurasi varian build
baru. Namun, pembuatan set sumber, yang mirip dengan main/, akan membantu
mengatur file dan resource yang hanya boleh digunakan Gradle saat mem-build
versi aplikasi tertentu:
-
src/main/ - Set sumber ini berisi kode dan resource yang sama untuk semua varian build.
-
src/buildType/ - Buat set sumber ini untuk menyertakan kode dan resource hanya untuk jenis build tertentu.
-
src/productFlavor/ -
Buat set sumber ini untuk menyertakan kode dan resource hanya untuk ragam produk tertentu.
Catatan: Jika build dikonfigurasi agar menggabungkan beberapa ragam produk, Anda dapat membuat direktori set sumber untuk setiap kombinasi ragam produk antar-dimensi ragam:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Buat set sumber ini untuk menyertakan kode dan resource hanya untuk varian build tertentu.
Misalnya, untuk menghasilkan versi "fullDebug" aplikasi, sistem build akan menggabungkan kode, setelan, dan resource dari set sumber berikut:
-
src/fullDebug/(set sumber varian build) -
src/debug/(set sumber jenis build) -
src/full/(set sumber ragam produk) -
src/main/(set sumber utama)
Catatan: Saat membuat file atau direktori baru di Android Studio, gunakan opsi menu File > New agar dapat membuatnya untuk set sumber tertentu. Set sumber yang dapat dipilih didasarkan pada konfigurasi build Anda, dan Android Studio secara otomatis membuat direktori yang diperlukan jika belum ada.
Jika set sumber yang berbeda memuat beberapa versi file yang sama, Gradle akan menggunakan urutan prioritas berikut saat menentukan file yang akan digunakan. Set sumber di sebelah kiri menggantikan file dan setelan set sumber di sebelah kanan:
varian build > jenis build > ragam produk > set sumber utama > dependensi library
Hal ini memungkinkan Gradle menggunakan file khusus bagi varian build yang sedang Anda buat, sekaligus menggunakan kembali aktivitas, logika aplikasi, dan resource yang sama bagi versi aplikasi lainnya.
Saat menggabungkan beberapa manifes, Gradle menggunakan urutan prioritas yang sama, sehingga setiap varian build dapat menentukan komponen atau izin yang berbeda dalam manifes akhir. Untuk mempelajari lebih lanjut cara membuat set sumber kustom, baca Membuat set sumber.
Katalog versi
Jika build Anda berisi beberapa modul dengan dependensi umum, atau Anda memiliki beberapa project independen dengan dependensi umum, sebaiknya Anda menggunakan katalog versi atau bill of materials (BOM) untuk menentukan versi umum.
Sistem build lainnya
Membuat aplikasi Android dengan Bazel dapat dilakukan, tetapi tidak didukung secara resmi. Android Studio tidak secara resmi mendukung project Bazel.
Untuk lebih memahami batasan saat ini untuk mem-build dengan Bazel, lihat masalah umum.