Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Mengonfigurasi build Anda

Sistem build Android mengompilasi resource dan kode sumber aplikasi lalu mengemasnya menjadi APK 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 umumnya ke semua versi aplikasi Anda. Plugin Android untuk Gradle bekerja dengan toolkit build ini agar proses dan setelan yang dapat dikonfigurasi yang ditunjukkan khusus untuk mem-build dan menguji aplikasi Android.

Gradle dan plugin Android 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 berjalan secara independen dari Android Studio, Anda perlu mengupdate alat build secara terpisah. Baca catatan rilis untuk mempelajari cara mengupdate Gradle dan plugin Android.

Fleksibilitas sistem build Android memungkinkan Anda melakukan konfigurasi build kustom tanpa mengubah file sumber inti aplikasi. Bagian ini membantu Anda memahami cara kerja sistem build Android, dan bagaimana sistem ini dapat membantu Anda menyesuaikan dan mengotomatiskan beberapa konfigurasi build. Jika Anda hanya ingin mempelajari cara men-deploy aplikasi lebih lanjut, lihat Mem-build dan Menjalankan dari Android Studio. Untuk segera mulai membuat konfigurasi build kustom menggunakan Android Studio, lihat Mengonfigurasi Varian Build.

Proses build

Proses build melibatkan banyak fitur dan pemrosesan yang mengonversi project Anda menjadi Paket Aplikasi Android (APK). Proses build sangat fleksibel, jadi Anda perlu memahami beberapa kejadian dalam detail pemrosesannya.

Gambar 1. Proses build modul aplikasi Android khusus.

Proses build modul aplikasi Android khusus, seperti yang ditunjukkan pada gambar 1, ikuti langkah umum berikut:

  1. Compiler mengonversi kode sumber Anda menjadi file DEX (Dalvik Executable), yang menyertakan bytecode yang berjalan di perangkat Android, serta hal-hal lainnya menjadi resource yang dikompilasi.
  2. APK Packager mengombinasikan file DEX dan resource yang dikompilasi menjadi satu APK. Namun, sebelum aplikasi dapat diinstal dan di-deploy ke perangkat Android, APK harus ditandatangani terlebih dahulu.
  3. APK Packager menandatangani APK Anda menggunakan keystore debug atau rilis:
    1. Jika Anda mem-build sebuah versi debug aplikasi, yaitu aplikasi yang hanya ditujukan untuk pengujian dan pembuatan profil, packager akan menandatangani aplikasi dengan keystore debug. Android Studio secara otomatis mengonfigurasi project baru dengan keystore debug.
    2. Jika Anda mem-build versi rilis aplikasi yang ditujukan untuk dirilis secara eksternal, packager akan menandatangani aplikasi dengan keystore rilis. Untuk membuat keystore rilis, baca tentang menandatangani aplikasi Anda di Android Studio.
  4. Sebelum menghasilkan APK final, packager menggunakan fitur zipalign untuk mengoptimalkan aplikasi Anda agar menghemat memori ketika berjalan di perangkat.

Pada akhir proses build, Anda akan mendapatkan sebuah APK debug atau APK rilis dari aplikasi yang dapat digunakan untuk di-deploy, diuji, atau dirilis kepada pengguna eksternal.

Konfigurasi build kustom

Gradle dan plugin Android membantu Anda mengonfigurasi aspek-aspek build berikut:

Jenis build
Jenis build menentukan properti tertentu yang digunakan Gradle ketika mem-build dan mengemas aplikasi, dan biasanya dikonfigurasi untuk berbagai tahap siklus proses pengembangan. Misalnya, jenis build debug mengaktifkan opsi debug dan menandatangani APK dengan kunci debug, sedangkan jenis build rilis dapat menyingkat, meng-obfuscate, dan menandatangani APK 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 pengemasan aplikasi, pelajari cara Mengonfigurasi Jenis Build.
Ragam produk
Ragam produk merepresentasikan versi berbeda dari aplikasi yang mungkin Anda rilis untuk pengguna, seperti versi aplikasi gratis dan berbayar. Anda dapat menyesuaikan ragam produk agar menggunakan kode dan resource yang berbeda, sekaligus berbagi dan menggunakan kembali bagian yang umum untuk semua versi aplikasi. 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, atau 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 menghasilkan beberapa APK untuk modul dan masing-masing file apk memiliki nama aplikasi, versi SDK minimum, atau versi SDK target yang berbeda. Jika ada beberapa manifes, Gradle akan menggabungkan setelan manifes.
Dependensi
Sistem build mengelola dependensi project dari filesystem lokal Anda dan dari repositori jarak jauh. Dengan demikian, 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 secara otomatis menandatangani APK 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 Anda tidak memiliki kunci rilis, Anda dapat membuatnya seperti yang dijelaskan dalam Menandatangani Aplikasi Anda.
Penyingkatan 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.
Dukungan multi-APK
Sistem build memungkinkan Anda untuk secara otomatis mem-build APK berbeda yang masing-masing hanya berisi kode dan resource yang dibutuhkan untuk kepadatan layar tertentu atau Application Binary Interface (ABI). Untuk mengetahui informasi selengkapnya, lihat Mem-build multi-APK.

File konfigurasi build

Proses build 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). Anda tidak perlu mengetahui Groovy untuk mulai mengonfigurasi build karena plugin Android untuk Gradle memperkenalkan sebagian besar elemen DSL yang Anda butuhkan. Untuk mempelajari DSL plugin Android lebih lanjut, baca Dokumentasi referensi DSL.

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

Gambar 2. 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 harus ditetapkannya.

File setelan Gradle

File settings.gradle, yang terletak dalam direktori root project, memberi tahu Gradle tentang modul yang harus disertakan saat mem-build aplikasi. Untuk sebagian besar project, filenya sederhana dan berisi:

include ‘:app’

Namun, project multi-modul harus menentukan setiap modul yang harus dimasukkan ke build final.

File build level atas

File build.gradle level atas, yang terletak dalam direktori project root, menentukan konfigurasi build yang berlaku untuk semua modul dalam project Anda. Secara default, file build level atas menggunakan blok buildscript untuk menentukan repositori dan dependensi Gradle yang sama untuk semua modul dalam project. Contoh kode berikut menjelaskan elemen DSL dan setelan default yang dapat Anda temukan dalam build.gradle level atas setelah membuat project baru.

/**
 * The buildscript block is where you configure the repositories and
 * dependencies for Gradle itself—meaning, you should not include dependencies
 * for your modules here. For example, this block includes the Android plugin for
 * Gradle as a dependency because it provides the additional instructions Gradle
 * needs to build Android app modules.
 */

buildscript {

    /**
     * The repositories block configures the repositories Gradle uses to
     * search or download the 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
     * JCenter as the repository Gradle should use to look for its dependencies.
     *
     * New projects created using Android Studio 3.0 and higher also include
     * Google's Maven repository.
     */

    repositories {
        google()
        jcenter()
    }

    /**
     * The dependencies block configures the dependencies Gradle needs to use
     * to build your project. The following line adds Android plugin for Gradle
     * version 3.6.0 as a classpath dependency.
     */

    dependencies {
        classpath 'com.android.tools.build:gradle:3.6.0'
    }
}

/**
 * The allprojects block is where you configure the repositories and
 * dependencies used by all modules in your project, such as third-party plugins
 * or libraries. However, you should configure module-specific dependencies in
 * each module-level build.gradle file. For new projects, Android Studio
 * includes JCenter and Google's Maven repository by default, but it does not
 * configure any dependencies (unless you select a template that requires some).
 */

allprojects {
   repositories {
       google()
       jcenter()
   }
}

Mengonfigurasi properti lingkup project

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

buildscript {...}

allprojects {...}

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

Untuk mengakses properti ini dari modul dalam project yang sama, gunakan sintaks berikut pada file build.gradle modul (Anda dapat mempelajari file ini lebih lanjut di bawah).

android {
  // Use the following syntax to access properties you defined at the project level:
  // rootProject.ext.property_name
  compileSdkVersion rootProject.ext.compileSdkVersion
  ...
}
...
dependencies {
    implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
    ...
}

Catatan: Meskipun Gradle memungkinkan Anda menentukan properti lingkup project di level modul, Anda harus menghindari hal ini karena menyebabkan modul yang membagikan properti tersebut akan digabungkan. Penggabungan modul nantinya akan mempersulit proses mengekspor modul sebagai project mandiri dan secara efektif mencegah Gradle menggunakan eksekusi project paralel untuk mempercepat build multi-modul.

File build level modul

File build.gradle level modul, yang terletak di setiap direktori project/module/, 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 file build.gradle level atas.

Contoh file build.gradle modul aplikasi Android ini menjelaskan beberapa elemen DSL dan setelan dasar yang harus Anda ketahui.

/**
 * The first line in the build configuration applies the Android plugin for
 * Gradle to this build and makes the android block available to specify
 * Android-specific build options.
 */

apply plugin: 'com.android.application'

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

  /**
   * compileSdkVersion 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.
   */

  compileSdkVersion 28

  /**
   * buildToolsVersion specifies the version of the SDK build tools, command-line
   * utilities, and compiler that Gradle should use to build your app. You need to
   * download the build tools using the SDK Manager.
   *
   * This property is optional because the plugin uses a recommended version of
   * the build tools by default.
   */

  buildToolsVersion "29.0.2"

  /**
   * 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 {

    /**
     * applicationId uniquely identifies the package for publishing.
     * However, your source code should still reference the package name
     * defined by the package attribute in the main/AndroidManifest.xml file.
     */

    applicationId 'com.example.myapp'

    // Defines the minimum API level required to run the app.
    minSdkVersion 15

    // Specifies the API level used to test the app.
    targetSdkVersion 28

    // 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 allows you to 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 splits block is where you can configure different APK builds that
   * each contain only code and resources for a supported screen density or
   * ABI. You'll also need to configure your build so that each APK has a
   * different versionCode.
   */

  splits {
    // Settings to build multiple APKs based on screen density.
    density {

      // Enable or disable building multiple APKs.
      enable false

      // Exclude these densities when building multiple APKs.
      exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
    }
  }
}

/**
 * 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 'com.android.support:appcompat-v7:28.0.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 dalam 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.

Memetakan ulang NDK ke jalur yang lebih pendek (khusus Windows)

Masalah paling umum pada jalur Windows yang panjang adalah alat (seperti ld.exe) dalam folder NDK yang diinstal akan memiliki jalur yang sangat dalam, tetapi alat tersebut tidak mendukung jalur panjang dengan baik.

Di local.properties, Anda dapat menetapkan properti ndk.symlinkdir untuk meminta plugin 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 3, atau klik Sync Project dari panel menu. Jika Android Studio menemukan error dalam konfigurasi Anda, misalnya, kode sumber menggunakan fitur API yang hanya tersedia di level API yang lebih tinggi dari compileSdkVersion, jendela Messages akan muncul untuk menjelaskan masalah tersebut.

Gambar 3. 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. 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 guna memuat kode dan resource hanya untuk jenis build tertentu.
src/productFlavor/
Buat set sumber ini guna memuat 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 guna memuat 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 menggunakan opsi menu File > New, Anda 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 untuk 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 untuk varian build yang sedang Anda build, sekaligus menggunakan kembali aktivitas, logika aplikasi, dan resource yang sama untuk versi aplikasi lainnya. Saat menggabungkan beberapa file manifes, Gradle akan menggunakan urutan prioritas yang sama sehingga setiap varian build dapat menentukan komponen dan izin yang berbeda di manifes final. Untuk mempelajari cara membuat set sumber kustom lebih lanjut, buka Membuat Set Sumber untuk Varian Build.