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.
Android Studio menggunakan Gradle, sebuah toolkit build canggih, untuk mengotomatiskan dan mengelola proses build, sekaligus memungkinkan Anda menentukan konfigurasi build kustom yang fleksibel. Setiap konfigurasi build dapat menentukan rangkaian kode dan resource-nya sendiri, sekaligus menggunakan kembali bagian-bagian yang ada di semua versi aplikasi Anda. Plugin Android Gradle berfungsi dengan toolkit build ini untuk menyediakan proses dan setelan yang dapat dikonfigurasi khusus untuk mem-build dan menguji aplikasi Android.
Gradle dan plugin Android Gradle berjalan secara independen dari Android Studio. Ini berarti Anda dapat mem-build aplikasi Android dari dalam Android Studio, command line di komputer, atau di komputer yang tidak memiliki Android Studio, seperti server continuous integration.
Jika Anda tidak menggunakan Android Studio, Anda dapat mempelajari cara mem-build dan menjalankan aplikasi dari command line. Output build-nya akan sama saja, baik Anda mem-build project dari command line, di komputer jarak jauh, maupun menggunakan Android Studio.
Catatan: Karena Gradle dan plugin Android Gradle berjalan secara independen dari Android Studio, Anda perlu mengupdate alat build secara terpisah. Baca catatan rilis untuk mempelajari cara mengupdate Gradle dan plugin Android Gradle.
Fleksibilitas sistem build Android memungkinkan Anda membuat konfigurasi build kustom tanpa mengubah file sumber inti aplikasi. Halaman ini membantu Anda memahami cara kerja sistem build Android, dan bagaimana sistem ini dapat membantu Anda menyesuaikan dan mengotomatiskan sejumlah konfigurasi build sekaligus. Jika Anda ingin mempelajari cara men-deploy aplikasi lebih lanjut, lihat Mem-build dan menjalankan aplikasi. Untuk langsung mulai membuat konfigurasi build kustom menggunakan Android Studio, lihat Mengonfigurasi varian build.
Proses build
Proses build melibatkan banyak alat dan proses yang mengonversi project Anda menjadi Paket Aplikasi Android (APK) atau Android App Bundle (AAB).
Plugin Android Gradle melakukan banyak proses build untuk Anda, tetapi akan berguna untuk memahami aspek tertentu dari proses build agar Anda dapat menyesuaikan build untuk memenuhi kebutuhan Anda.
Project yang berbeda mungkin memiliki sasaran build yang berbeda pula. Misalnya, build untuk library pihak ketiga menghasilkan Android Archive (AAR) atau Java Archive (JAR) library. Namun, aplikasi adalah jenis project yang paling umum, dan build untuk project aplikasi menghasilkan APK atau AAB debug atau rilis dari aplikasi yang dapat Anda deploy, uji, atau rilis ke pengguna eksternal.
Halaman ini berfokus pada pengembangan aplikasi, tetapi banyak langkah dan konsep build bersifat umum untuk sebagian besar jenis 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, maupun keduanya, ada beberapa tempat di mana Anda harus memilih bahasa JDK atau Java untuk build Anda. Lihat Versi Java di build Android untuk mengetahui detailnya.
File konfigurasi build
Pembuatan konfigurasi build kustom mengharuskan Anda membuat perubahan pada satu atau lebih banyak file konfigurasi build. Ini file teks biasa menggunakan {i>Domain Specific Language<i} (DSL) untuk menggambarkan dan memanipulasi logika build menggunakan Skrip Kotlin, yang merupakan ragam dari bahasa Kotlin. Anda juga dapat menggunakan Groovy, yaitu dinamis untuk Java Virtual Machine (JVM), untuk mengonfigurasi build Anda.
Anda tidak perlu mengetahui skrip Kotlin atau Groovy untuk mulai mengonfigurasi karena plugin Android Gradle memperkenalkan sebagian besar elemen DSL yang dibutuhkan. Untuk mempelajari lebih lanjut DSL plugin Android Gradle, baca Dokumentasi referensi DSL. Skrip Kotlin juga bergantung pada dasar-dasar DSL Kotlin Gradle.
Saat memulai proyek baru, Android Studio secara otomatis membuat beberapa file-file ini untuk Anda dan mengisinya berdasarkan {i>default<i} yang masuk akal. Proyek struktur file memiliki tata letak berikut:
└── 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
Ada beberapa file konfigurasi build Gradle yang merupakan bagian dari struktur project standar untuk aplikasi Android. Sebelum Anda dapat mulai mengonfigurasi build, penting untuk memahami cakupan dan tujuan setiap file ini, serta elemen DSL dasar yang ditetapkannya.
File Wrapper Gradle
Wrapper Gradle (gradlew) adalah aplikasi kecil yang disertakan dengan
kode sumber yang mendownload dan meluncurkan Gradle sendiri.
Hal ini menghasilkan eksekusi build yang lebih konsisten. Developer mendownload
sumber aplikasi dan menjalankan gradlew. Tindakan ini akan mendownload Gradle yang diperlukan
distribusi, dan meluncurkan Gradle untuk membangun aplikasi Anda.
File gradle/wrapper/gradle-wrapper.properties
berisi properti, distributionUrl, yang mendeskripsikan versi
Gradle 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 Groovy DSL) terletak di root
project. File setelan ini menentukan repositori level project
pengaturan dan memberi tahu Gradle modul mana yang harus disertakan saat membangun
. Project multi-modul harus menentukan setiap modul yang harus masuk ke
build akhir.
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. 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")
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. 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'
File build level atas
File build.gradle.kts level teratas (untuk DSL Kotlin) atau
File build.gradle (untuk Groovy DSL) terletak di root
project. Biasanya menentukan versi umum dari plugin yang digunakan
berdasarkan modul dalam project Anda.
Contoh kode berikut menjelaskan setelan default dan elemen DSL dalam skrip pembangunan level teratas setelah membuat proyek 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.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
}
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.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
}
File build level modul
build.gradle.kts level modul (untuk DSL Kotlin) atau
File build.gradle (untuk Groovy DSL) terletak di setiap
Direktori project/module/. File ini memungkinkan Anda
mengonfigurasi setelan build untuk modul tertentu tempatnya berada. Mengonfigurasi
setelan build ini memungkinkan Anda menyediakan opsi pengemasan kustom, seperti
jenis build dan ragam produk tambahan, serta mengganti setelan di
main/ manifes aplikasi atau skrip build level atas.
Setelan Android SDK
File build tingkat modul untuk aplikasi Anda mencakup pengaturan yang menunjukkan Versi Android SDK yang digunakan saat mengompilasi, memilih perilaku platform, dan yang menetapkan versi minimum yang digunakan aplikasi Anda.
-
compileSdk -
compileSdkmenentukan API Android dan Java mana yang yang tersedia saat mengompilasi kode sumber Anda. Untuk menggunakan Android terbaru gunakan Android SDK terbaru saat mengompilasi.Beberapa API platform Android mungkin tidak tersedia dalam level API yang lebih lama. Anda dapat menjaga penggunaan fitur yang lebih baru atau menggunakan Library kompatibilitas AndroidX untuk menggunakan fitur yang lebih baru dengan API level Android.
Tiap Android SDK menyediakan subset API Java untuk digunakan di aplikasi Anda. Tabel di API Java mana yang dapat saya gunakan di kode sumber Java atau Kotlin menunjukkan level API Java yang tersedia berdasarkan versi Android SDK. Java API yang lebih baru didukung pada versi Android sebelumnya melalui desugaring, yang harus diaktifkan di build Anda.
Android Studio menampilkan peringatan jika
compileSdkAnda mengalami konflik dengan versi Android Studio, AGP, atau library project Anda saat ini persyaratan dependensi. -
minSdk -
minSdkmenentukan versi terendah Android yang Anda ingin didukung oleh aplikasi Anda. MenetapkanminSdkakan membatasi perangkat dapat menginstal aplikasi Anda.Mendukung versi Android yang lebih rendah mungkin memerlukan lebih banyak pemeriksaan bersyarat dalam kode Anda atau lebih banyak penggunaan library kompatibilitas AndroidX. Anda seharusnya mempertimbangkan biaya pemeliharaan untuk mendukung versi yang lebih rendah terhadap persentase pengguna yang masih menggunakan versi lebih rendah tersebut. Lihat diagram versi di New project wizard Android Studio untuk persentase penggunaan versi saat ini.
Saat mengedit kode di Android Studio atau menjalankan pemeriksaan selama build Anda, lint akan memperingatkan tentang API yang Anda gunakan yang tidak tersedia di
minSdk. Anda harus memperbaikinya dengan membuat fitur baru bersyarat atau dengan menggunakanAppcompatuntuk kompatibilitas mundur. -
targetSdk -
targetSdkmemiliki dua tujuan:- Class ini menetapkan perilaku runtime aplikasi Anda.
- Fitur ini mengesahkan versi Android yang telah diuji.
Jika Anda berjalan di perangkat yang menggunakan versi Android yang lebih tinggi dari
targetSdk, Android menjalankan aplikasi Anda dalam mode kompatibilitas yang berperilaku mirip dengan versi lebih rendah yang ditunjukkan ditargetSdk. Misalnya, saat API 23 memperkenalkan izin akses yang berbeda, 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 disertakan dalam versicompileSdkterbaru. Google Play kebijakan distribusi memberlakukan kebijakan tambahan terkait level API target.Nilai
targetSdkharus lebih kecil dari atau sama dengan dengancompileSdk.
Catatan: Nilai compileSdk dan targetSdk
tidak harus sama. Ingatlah prinsip-prinsip dasar berikut:
compileSdkmemberi Anda akses ke API barutargetSdkmenetapkan perilaku runtime aplikasi AndatargetSdkharus lebih kecil dari atau sama dengancompileSdk
Contoh skrip build modul aplikasi
Contoh skrip build modul aplikasi Android ini menguraikan beberapa elemen dan pengaturan 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:\ 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
bilah notifikasi yang muncul saat Anda membuat perubahan, seperti yang ditunjukkan
gambar 1, atau klik Sync Project 
dari panel menu. Jika Android Studio menemukan error pada
konfigurasi — misalnya, kode sumber Anda menggunakan fitur API yang hanya
tersedia di level API yang lebih tinggi dari compileSdkVersion
— Jendela Pesan 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. Fitur
Set sumber main/ berisi kode dan resource yang digunakan oleh semua
varian build.
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 proyek independen dengan dependensi yang sama, kami merekomendasikan Anda menggunakan katalog versi atau tagihan material (BOM) untuk menentukan versi umum.
Sistem build lainnya
Membuat aplikasi Android dengan Bazel adalah mungkin tetapi tidak didukung secara resmi. Android Studio tidak secara resmi mendukung proyek Bazel.
Untuk lebih memahami batasan saat ini untuk mem-build dengan Bazel, lihat masalah umum.