Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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.
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 akan otomatis 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 mana yang digunakan untuk menjalankan build Anda.
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"applyfalseid("com.android.library")version"8.7.0"applyfalseid("org.jetbrains.kotlin.android")version"2.0.20"applyfalse}
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'applyfalseid'com.android.library'version'8.7.0'applyfalseid'org.jetbrains.kotlin.android'version'2.0.20'applyfalse}
File build level modul
File build.gradle.kts level modul (untuk DSL Kotlin) 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.
Gambar 1. Android SDK dalam build
compileSdk
compileSdk menentukan API Android dan Java mana yang
tersedia saat mengompilasi kode sumber Anda. Untuk menggunakan fitur Android
terbaru, gunakan Android SDK terbaru saat mengompilasi.
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 versi Android sebelumnya melalui
desugaring, yang harus
diaktifkan dalam build Anda.
Android Studio menampilkan peringatan jika compileSdk Anda bertentangan
dengan versi Android Studio, AGP, atau persyaratan dependensi
pustaka project Anda saat ini.
minSdk
minSdk menentukan versi Android terendah yang
ingin didukung aplikasi Anda. Menyetel minSdk akan membatasi perangkat mana saja 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 menggunakan
Appcompat untuk kompatibilitas mundur.
targetSdk
targetSdk memiliki 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 dalam
targetSdk. Misalnya, saat API 23 memperkenalkan model izin
runtime, tidak semua aplikasi siap untuk segera mengadopsinya.
Dengan menetapkan targetSdk ke 22, aplikasi tersebut dapat berjalan di
perangkat API 23 tanpa menggunakan izin runtime, dan dapat menggunakan fitur
yang disertakan dalam versi compileSdk terbaru. Kebijakan distribusi
Google Play menerapkan
kebijakan tambahan pada API level target.
Nilai targetSdk harus kurang dari atau sama
dengan nilai compileSdk.
Catatan: Nilai compileSdk dan targetSdk tidak harus sama. Perhatikan prinsip dasar berikut:
compileSdk memberi Anda akses ke API baru
targetSdk menetapkan perilaku runtime aplikasi Anda
targetSdk harus lebih kecil dari atau sama dengan compileSdk
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"tolistOf("*.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{jvmToolchain11}/** * 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. */compileSdk33/** * 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.minSdk21// Specifies the API level used to test the app.targetSdk33// Defines the version number of your app.versionCode1// 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{minifyEnabledtrue// Enables code shrinking for the release build type.proguardFilesgetDefaultProguardFile('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{implementationproject(":lib")implementation'androidx.appcompat:appcompat:1.7.0'implementationfileTree(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 direktori
ndk dalam 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:\ 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.
Gambar 2. Menyinkronkan project dengan file konfigurasi
build di Android Studio.
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
gunakan
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.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2024-11-07 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2024-11-07 UTC."],[],[]]
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 