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.

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

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
}