Konfigurasi build Anda

Sistem build Android mengompilasi sumber daya aplikasi dan kode sumber, dan mengemasnya ke dalam APK yang bisa Anda uji, terapkan, tandatangani, dan distribusikan. Android Studio menggunakan Gradle, sebuah toolkit build canggih, untuk mengotomatisasi dan mengelola proses build, sekaligus memungkinkan Anda untuk menentukan konfigurasi build khusus yang fleksibel. Setiap konfigurasi build bisa menentukan set kode dan sumber dayanya sendiri, sekaligus menggunakan kembali bagian umumnya ke semua versi aplikasi Anda. Plugin Android untuk Gradle bekerja dengan toolkit build agar proses dan setelan bisa dikonfigurasi yang spesifik untuk membuat dan menguji aplikasi Android.

Gradle dan plugin Android dan Gradle berjalan secara independen dari Android Studio. Ini berarti Anda bisa membuat aplikasi Android dari dalam Android Studio, baris perintah pada mesin, atau pada mesin yang tidak diinstal Android Studio (seperti server integrasi berkesinambungan). Jika Anda tidak menggunakan Android Studio, Anda bisa mempelajari cara membuat dan menjalankan aplikasi dari baris perintah. Output build ini sama saja, apakah Anda membuat project dari baris perintah, pada mesin jarak jauh, atau menggunakan Android Studio.

Catatan: Karena plugin Android dan Gradle berjalan secara independen dari Android Studio, Anda perlu mengupdate fitur build secara terpisah. Baca catatan rilis untuk mempelajari cara mengupdate Gradle dan plugin Android.

Fleksibilitas sistem build Android memungkinkan Anda melakukan konfigurasi build khusus tanpa mengubah file sumber inti aplikasi. Bagian ini membantu Anda memahami cara sistem build Android bekerja, dan bagaimana hal itu bisa membantu Anda menyesuaikan dan mengotomatisasi beberapa konfigurasi build. Jika Anda hanya ingin mempelajari lebih lanjut tentang menerapkan aplikasi, Lihat Membuat dan Menjalankan dari Android Studio. Untuk segera mulai membuat konfigurasi build khusus menggunakan Android Studio, lihat Mengonfigurasi Varian Build.

Proses build

Proses build melibatkan banyak fitur dan pemrosesan yang mengonversi project Anda menjadi Android Application Package (APK). Proses build sangat fleksibel, sehingga berguna untuk memahami beberapa kejadian dalam detail pemrosesannya.

Gambar 1. Proses build dari modul aplikasi Android khusus.

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

  1. Compiler mengonversi kode sumber menjadi file DEX (Dalvik Executable), yang menyertakan bytecode yang berjalan pada perangkat Android, serta lainnya menjadi sumber daya yang dikompilasi.
  2. APK Packager menggabungkan file DEX dan sumber daya yang dikompilasi ke dalam APK tunggal. Namun, sebelum aplikasi Anda bisa diinstal dan diterapkan pada perangkat Android, APK harus ditandatangani.
  3. APK Packager menandatangani APK Anda menggunakan keystore debug atau rilis:
      Jika Anda membuat sebuah versi debug aplikasi, yaitu, aplikasi yang Anda tujukan hanya untuk pengujian dan pembuatan profil, packager menandatangani aplikasi dengan keystore debug. Android Studio secara otomatis mengonfigurasi project baru dengan keystore debug.
    1. Jika Anda membuat versi rilis aplikasi yang ditujukan untuk dirilis secara eksternal, packager akan menandatangani aplikasi Anda dengan keystore rilis. Untuk membuat keystore rilis, baca tentang menandatngani aplikasi di Android Studio.
  4. Sebelum menghasilkan APK final, packager menggunakan fitur zipalign untuk mengoptimalkan aplikasi Anda agar hemat memori ketika berjalan pada perangkat.

Di akhir proses build, Anda akan mendapatkan sebuah APK debug atau APK rilis dari aplikasi yang bisa Anda gunakan untuk menerapkan, menguji, atau merilis untuk pengguna eksternal.

Konfigurasi build khusus

Plugin Android dan Gradle membantu Anda mengonfigurasi aspek-aspek berikut dari build Anda:

Tipe Build
Tipe build mendefinisikan properti tertentu yang digunakan Gradle ketika membuat dan mengemas aplikasi Anda, dan biasanya dikonfigurasi untuk berbagai stage daur siklus proses pengembangan Anda. Misalnya, tipe build debug mengaktifkan opsi debug dan menandatangani APK dengan kunci debug, sedangkan tipe build versi rilis bisa menciutkan, menyamarkan, dan menandatangani APK dengan kunci rilis untuk distribusi. Anda harus menentukan setidaknya satu tipe build untuk membuat aplikasi—Android Studio membuat tipe build versi rilis dan debug secara default. Untuk mulai menyesuaikan setelan pengemasan bagi aplikasi Anda, pelajari cara Mengonfigurasi Tipe Build.
Ragam Produk
Ragam produk merepresentasikan versi berbeda dari aplikasi yang mungkin Anda rilis untuk pengguna, seperti versi aplikasi gratis dan berbayar. Anda bisa menyesuaikan ragam produk untuk menggunakan kode dan sumber daya yang berbeda, sekaligus berbagi dan menggunakan kembali bagian-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 Konfigurasi Ragam Produk.
Varian Build
Varian build adalah produk persilangan dari tipe build dan ragam produk, dan merupakan konfigurasi yang digunakan Gradle untuk membuat aplikasi Anda. Dengan menggunakan varian build, Anda bisa membuat versi debug dari ragam produk selama pengembangan, atau menandatangani versi rilis dari ragam produk untuk distribusi. Meskipun tidak mengonfigurasi varian build secara langsung, Anda mengonfigurasi tipe build dan ragam produk yang membentuknya. Membuat tipe build atau ragam produk tambahan juga akan menciptakan varian build tambahan. Untuk mempelajari cara membuat dan mengelola varian build, baca ringkasan Konfigurasi Varian Build .
Entri Manifes
Anda bisa menentukan nilai untuk beberapa properti dari 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 yang memiliki nama aplikasi berbeda, versi SDK minimum, atau versi SDK target. Jika terdapat beberapa manifes, Gradle akan menggabungkan setelan manifes.
Dependensi
Sistem build mengelola dependensi project dari filesystem lokal dan dari repositori jarak jauh. Hal ini akan mencegah Anda dari keharusan menelusuri, mendownload, dan menyalin secara manual paket biner dependensi ke dalam direktori project Anda. Untuk mengetahui selengkapnya, lihat Tambahkan Dependensi Build.
Penandatanganan
Sistem build memungkinkan Anda untuk menentukan setelan penandatanganan dalam konfigurasi build, dan bisa secara otomatis menandatangani APK selama proses build. Sistem build menandatangani versi debug dengan kunci dan sertifikat 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 bisa membuatnya seperti yang dijelaskan dalam Tandatangani Aplikasi Anda.
ProGuard
Sistem build memungkinkan Anda untuk menentukan file aturan ProGuard yang berbeda untuk setiap varian build. Sistem build bisa menjalankan ProGuard untuk menciutkan dan menyamarkan class Anda selama proses build.
Dukungan Multi-APK
Sistem build memungkinkan Anda untuk secara otomatis membuat APK berbeda yang masing-masing hanya berisi kode dan sumber daya yang dibutuhkan untuk kepadatan layar tertentu atau Application Binary Interface (ABI). Untuk informasi selengkapnya, lihat  Buat multi-APK.

File konfigurasi build

Membuat konfigurasi build khusus mengharuskan Anda untuk membuat perubahan terhadap satu atau beberapa file konfigurasi build, atau file build.gradle. File-file teks biasa ini menggunakan Domain Specific Language (DSL) untuk menggambarkan dan memanipulasi logika build menggunakan Groovy, yang merupakan 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 lebih lanjut tentang DSL plugin Android, baca Dokumentasi referensi DSL.

Ketika memulai sebuah project baru, Android Studio secara otomatis membuat beberapa file ini untuk Anda, seperti yang ditunjukkan pada gambar 2, dan akan 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 bisa mulai mengonfigurasi build, penting untuk memahami cakupan dan tujuan dari setiap file, dan elemen DSL dasar yang harus ditetapkan.

File setelan Gradle

File settings.gradle, terletak di direktori project root, memberi tahu Gradle modul mana yang harus disertakan saat membuat aplikasi Anda. Untuk kebanyakan project, file-nya sederhana dan hanya berisi:

include ‘:app’

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

File build tingkat-atas

File build.gradle tingkat-atas, terletak di direktori project root, mendefinisikan konfigurasi build yang berlaku untuk semua modul dalam proyek Anda. Secara default, file build tingkat-atas menggunakan blok buildscript untuk mendefinisikan repositori dan dependensi Gradle yang umum untuk semua modul dalam project. Sampel kode berikut menjelaskan elemen DSL dan setelan default yang bisa Anda temukan di build.gradle tingkat-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.4.0 as a classpath dependency.
     */

    dependencies {
        classpath 'com.android.tools.build:gradle:3.4.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, kami sarankan agar menentukan properti tertentu di tingkat project dan membagikannya ke semua modul. Anda bisa melakukan ini dengan menambahkan properti tambahan ke blok ext di file build.gradle tingkat atas.

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 di project yang sama, gunakan sintaks berikut pada file build.gradle modul (Anda bisa mempelajari lebih lanjut tentang file ini di bagian 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 tingkat modul, Anda harus menghindari melakukannya karena menyebabkan modul yang membagikan properti tersebut akan digabungkan. Penggabungan modul membuatnya lebih sulit untuk mengekspor modul selanjutnya sebagai project mandiri dan secara efektif mencegah Gradle menggunakan eksekusi project paralel untuk mempercepat build multi-modul.

File build tingkat-modul

File build.gradle tingkat-modul, terletak di setiap direktori project/module/, yang memungkinkan Anda untuk mengonfigurasi setelan build untuk modul tertentu yang berada di dalamnya. Mengonfigurasi setelan build ini memungkinkan Anda untuk menyediakan opsi pengemasan khusus, seperti tipe build dan ragam produk tambahan, serta menimpa setelan dalam manifes aplikasi main/ atau file build.gradle tingkat-atas.

Contoh file build.gradle modul aplikasi Android ini menggarisbawahi 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 "28.0.3"

  /**
   * 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 Proguard settings 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 berisi dua file properti, terletak di direktori project root, yang bisa Anda gunakan untuk menentukan setelan bagi toolkit build Gradle itu sendiri:

gradle.properties
Di sini Anda bisa mengonfigurasi setelan Gradle lingkup-project, seperti ukuran heap maksimum daemon Gradle. Untukinformasi selengkapnya, lihat Lingkungan Build.
local.properties
Mengonfigurasi properti lingkungan lokal untuk sistem build, seperti jalur untuk penginstalan SDK. Karena konten dari file ini secara otomatis dihasilkan oleh Android Studio dan dikhususkan untuk lingkungan developer lokal, Anda sebaiknya tidak memodifikasi file ini secara manual atau memeriksanya dalam sistem kontrol versi.

Menyinkronkan project dengan file Gradle

Jika Anda membuat perubahan pada file konfigurasi build dalam proyek, Android Studio akan mengharuskan Anda untuk melakukan sinkronisasi file project sehingga ia bisa mengimpor perubahan konfigurasi build dan menjalankan beberapa pemeriksaan untuk memastikan konfigurasi Anda tidak akan menimbulkan kesalahan build.

Untuk menyinkronkan file project, klik Sync Now di baris notifikasi yang muncul saat Anda membuat perubahan, seperti yang ditunjukkan pada gambar 3, atau klik Sync Project dari panel menu. Jika Android Studio menemukan kesalahan dalam konfigurasi Anda, misalnya , kode sumber menggunakan fitur API yang hanya tersedia di tingkat API yang lebih tinggi dari compileSdkVersion Anda, jendela Messages akan muncul untuk menjelaskan masalah ini.

Gambar 3. Menyinkronkan project dengan file konfigurasi build dalam Android Studio.

Set sumber

Android Studio secara logis mengelompokkan kode sumber dan sumber daya untuk setiap modul ke dalam set sumber. Set sumber main/ modul berisi kode dan sumber daya 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, membuat set sumber, serupa dengan main/, akan membantu mengelola file dan sumber daya yang hanya boleh digunakan Gradle saat membuat versi aplikasi tertentu:

src/main/
Set sumber ini berisi kode dan sumber daya yang biasa dipakai oleh semua varian build.
src/buildType/
Buat set sumber ini untuk memuat kode dan sumber daya khusus untuk tipe build tertentu.
src/productFlavor/
Buat set sumber ini untuk memuat kode dan sumber daya khusus untuk ragam produk tertentu.

Catatan: Jika Anda mengonfigurasi build untuk mengombinasikan banyak ragam produk, Anda bisa membuat direktori set sumber untuk masing-masing kombinasi ragam produk di antara dimensi ragam tersebut: src/productFlavor1ProductFlavor2/

src/productFlavorBuildType/
Buat set sumber ini untuk memuat kode dan sumber daya khusus untuk varian build tertentu.

Misalnya, untuk menghasilkan versi aplikasi "fullDebug", sistem build akan menggabungkan kode, setelan, dan sumber daya dari set sumber berikut:

  • src/fullDebug/ (set sumber varian build)
  • src/debug/ (set sumber tipe build)
  • src/full/ (set sumber ragam produk)
  • src/main/ (set sumber utama)

Catatan: Saat membuat file atau direktori baru di Android Studio, dengan menggunakan pilihan menu File > New, Anda bisa membuatnya untuk set sumber tertentu. Set sumber yang bisa Anda pilih didasarkan pada konfigurasi build, dan Android Studio secara otomatis membuat direktori yang diperlukan jika belum ada.

Jika set sumber yang berbeda berisi versi berbeda dari file yang sama, Gradle menggunakan urutan prioritas berikut saat memutuskan file yang digunakan (set sumber di sebelah kiri menggantikan file dan setelan set sumber sebelah kanan):

varian build > tipe build > ragam produk > set sumber utama > dependensi library

Hal ini memungkinkan Gradle untuk menggunakan file khusus bagi varian build yang sedang coba Anda buat sekaligus menggunakan kembali aktivitas, logika aplikasi, dan sumber daya yang biasa dipakai oleh versi aplikasi yang lainnya. Saat menggabungkan beberapa manifes, Gradle menggunakan urutan prioritas yang sama, sehingga setiap varian build bisa menentukan komponen atau izin yang berbeda dalam manifes akhir. Untuk mempelajari lebih lanjut tentang membuat set sumber khusus, buka Buat Set Sumber untuk Varian Build.