Mengonfigurasi build 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.

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. Misalnya, build untuk library pihak ketiga menghasilkan library AAR atau JAR. 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.

File konfigurasi build

Pembuatan konfigurasi build kustom mengharuskan Anda melakukan perubahan terhadap satu atau beberapa file konfigurasi build atau file build.gradle. File teks biasa ini menggunakan Domain Specific Language (DSL) untuk menggambarkan dan memanipulasi logika build menggunakan Groovy, yaitu bahasa dinamis untuk Java Virtual Machine (JVM), atau skrip Kotlin, yang merupakan ragam dari bahasa Kotlin.

Anda tidak perlu mengetahui Groovy atau skrip Kotlin 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 untuk Groovy. Skrip Kotlin juga bergantung pada DSL Kotlin Gradle yang digunakan.

Ketika memulai project baru, Android Studio secara otomatis akan membuat beberapa file ini untuk Anda, seperti dalam gambar 1, dan mengisinya berdasarkan default yang logis.

Gambar 1. Struktur project default untuk modul aplikasi Android.

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 setelan Gradle

File settings.gradle (untuk Groovy) atau file settings.gradle.kts (untuk skrip Kotlin) 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:

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’

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")

File build level atas

File build.gradle level atas (untuk Groovy) atau file build.gradle.kts (untuk skrip Kotlin) terletak di direktori root project. File ini menentukan dependensi yang berlaku untuk semua modul dalam project Anda. Secara default, file build level atas menggunakan blok plugins untuk menentukan dependensi Gradle yang sama untuk semua modul dalam project. Selain itu, file build level atas berisi kode untuk membersihkan direktori build.

Contoh kode berikut menjelaskan setelan default dan elemen DSL dalam file build.gradle level atas setelah membuat project baru:

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 '7.4.1' apply false
    id 'com.android.library' version '7.4.1' apply false
    id 'org.jetbrains.kotlin.android' version '1.8.10' apply false
}

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 "7.4.1" apply false
    id("com.android.library") version "7.4.1" apply false
    id("org.jetbrains.kotlin.android") version "1.8.10" apply false
}

Mengonfigurasi properti lingkup project menggunakan properti tambahan (tidak digunakan lagi)

Perhatian: Jika Anda memiliki beberapa project, sebaiknya gunakan Katalog Versi Gradle, bukan blok ext{} untuk berbagi dependensi lintas modul. Blok ext{} diakses oleh semua project, yang membuatnya tidak mungkin untuk mengekspor modul sebagai project mandiri dan mencegah Gradle menggunakan eksekusi project paralel untuk mempercepat build multi-modul.

Untuk project Android yang mencakup beberapa modul, sebaiknya Anda menentukan properti tertentu di level project dan membagikannya ke semua modul. Anda dapat melakukannya dengan menambahkan properti tambahan ke blok ext dalam file build.gradle level atas (untuk Groovy) atau file build.gradle.kts (untuk Skrip Kotlin):

Groovy

// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
    sdkVersion = 33
    // You can also create properties to specify versions for dependencies.
    // Having consistent versions between modules can avoid conflicts with behavior.
    appcompatVersion = "1.6.1"
    ...
}
...

Kotlin

// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
    extra["sdkVersion"] = 33
    // You can also create properties to specify versions for dependencies.
    // Having consistent versions between modules can avoid conflicts with behavior.
    extra["appcompatVersion"] = "1.6.1"
    ...
}
...

Untuk mengakses properti ini dari modul dalam project yang sama, gunakan sintaksis berikut pada file build.gradle modul.

Groovy

android {
    // Use the following syntax to access properties you defined at the project level:
    // rootProject.ext.property_name
    compileSdk rootProject.ext.sdkVersion
    ...
}
...
dependencies {
    implementation "androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}"
    ...
}

Kotlin

android {
    // Use the following syntax to access properties you defined at the project level:
    // rootProject.extra["property_name"]
    compileSdk = rootProject.extra["sdkVersion"]

    // Alternatively, you can access properties using a type safe delegate:
    val sdkVersion: Int by rootProject.extra
    ...
    compileSdk = sdkVersion
}
...
dependencies {
    implementation("androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}")
    ...
}

File build level modul

File build.gradle level modul (untuk Groovy) atau build.gradle.kts (untuk skrip Kotlin) 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 pemaketan kustom, seperti ragam produk dan jenis build tambahan, serta mengganti setelan dalam manifes aplikasi main/ atau file build.gradle level atas atau file build.gradle.kts.

Contoh file build.gradle modul aplikasi Android ini menjelaskan beberapa setelan dan elemen DSL dasar:

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'
}

/**
 * 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'
        }
    }
}

/**
 * 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.6.1'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

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")
}

/**
 * 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"
        }
    }
}

/**
 * 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.6.1")
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.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 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.

Perhatian: File local.properties disimpan untuk properti tertentu untuk plugin Android Gradle. Memasukkan nilai Anda sendiri dalam file ini dapat menyebabkan masalah. Jika Anda perlu menentukan properti lokal sendiri, buat file properti terpisah dan muat secara manual.

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.

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.

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.