Bagaimana Cara Mengonfigurasi build aplikasi pada ANDROID STUDIO?

lalu memaketkannya menjadi APK yang bisa Anda uji, deploy, tanda tangani, dan distribusikan.

Sistem build Android mengompilasi resource dan kode sumber aplikasi lalu memaketkannya menjadi APK yang bisa 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 khusus yang fleksibel. Setiap konfigurasi build bisa menentukan resource dan kumpulan kodenya sendiri, sekaligus menggunakan kembali bagian umumnya ke semua versi aplikasi Anda. Plugin Android untuk Gradle bekerja dengan toolkit build ini agar proses dan setelan bisa dikonfigurasi yang spesifik untuk membuat dan menguji aplikasi Android.

Gradle dan plugin Android berjalan secara independen dari Android Studio. Ini berarti, Anda bisa membuat 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 bisa mempelajari cara membuat dan menjalankan aplikasi dari command line. Output buildnya akan sama saja, baik Anda membuat 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 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 kerja sistem build Android, dan bagaimana sistem ini bisa membantu Anda menyesuaikan dan mengotomatiskan beberapa konfigurasi build. Jika Anda hanya ingin mempelajari cara menerapkan aplikasi lebih lanjut, lihat Membuat dan Menjalankan dari Android Studio. Untuk segera mulai membuat konfigurasi build khusus menggunakan Android Studio, lihatMengonfigurasi 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 menggabungkan file DEX dan resource yang dikompilasi menjadi satu APK. Namun, sebelum aplikasi bisa 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 membuat 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 membuat 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.

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

Konfigurasi build khusus

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

Jenis Build

Jenis build menentukan properti tertentu yang digunakan Gradle ketika membuat dan memaketkan aplikasi, dan biasanya dikonfigurasi untuk berbagai tahap siklus pengembangan. Misalnya, jenis build debug mengaktifkan opsi debug dan menandatangani APK dengan kunci debug, sedangkan jenis build rilis bisa menciutkan, menyamarkan, dan menandatangani APK dengan kunci rilis untuk distribusi. Anda harus menentukan setidaknya satu jenis build untuk membuat aplikasi; Android Studio membuat jenis build rilis dan debug secara default. Untuk mulai menyesuaikan setelan pengemasan bagi 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 bisa menyesuaikan ragam produk agar menggunakan kode dan resource 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 Mengonfigurasi Ragam Produk.

Varian Build

Varian build adalah produk persilangan dari tipe build dan ragam produk, dan merupakan konfigurasi yang digunakan Gradle untuk membuat aplikasi. 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 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 bisa 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 semua 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 Dependesi Build.

Penandatanganan

Sistem build memungkinkan Anda menentukan setelan penandatanganan dalam konfigurasi build, dan bisa 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 bisa membuatnya seperti yang dijelaskan dalam Menandatangani Aplikasi Anda.

ProGuard

Sistem build memungkinkan Anda menentukan file aturan ProGuard yang berbeda untuk setiap varian build. Sistem build bisa menjalankan ProGuard untuk menciutkan dan menyamarkan class selama proses build.

Dukungan Multi-APK

Sistem build memungkinkan Anda untuk secara otomatis membuat APK berbeda yang masing-masing hanya berisi kode dan resource yang dibutuhkan untuk kepadatan layar tertentu atau Application Binary Interface (ABI). Untuk mengetahui informasi selengapnya, lihat Membuat multi-APK.

File konfigurasi build

Proses pembuatan konfigurasi build khusus mengharuskan Anda membuat 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 bisa 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, yang memberi tahu Gradle tentang modul yang harus disertakannya ketika membuat aplikasi. Untuk sebagian besar project, filenya sederhana dan hanya berisi:

    include ‘:app’
    

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

File build tingkat atas

File build.gradle tingkat atas, yang terletak dalam direktori root project, mendefinisikan konfigurasi build yang berlaku untuk semua modul dalam project Anda. Secara default, file build tingkat atas menggunakan blokbuildscript untuk menentukan repositori dan dependensi Gradle yang sama bagi semua modul dalam project. Contoh kode berikut ini menjelaskan elemen DSL dan setelan default yang bisa Anda temukan dalam 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.2 as a classpath dependency.
         */

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

    /**
     * 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 Anda menentukan properti tertentu di tingkat project dan membagikannya ke semua modul. Anda bisa melakukannya dengan menambahkan properti tambahan ke blok ext dalam 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 dalam project yang sama, gunakan sintaks berikut ini dalam file build.gradle modul (pelajari file ini lebih lanjut pada bagian di bawah ini).

    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 hal ini karena menyebabkan modul yang membagikan properti tersebut akan digabungkan. Penggabungan modul nantinya akan mempersulit proses mengekspor modul sebagai project mandiri dan akan mencegah Gradle menggunakan eksekusi project paralel untuk mempercepat build multimodul.

File build tingkat modul

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

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

      /**
       * 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 menyertakan dua file properti, yang terletak dalam direktori root project, 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. Untuk mengetahui informasi selengkapnya, lihat Lingkungan Build.

local.properties

Mengonfigurasi properti lingkungan lokal untuk sistem build, seperti lokasi untuk penginstalan SDK. Karena konten dari file ini otomatis dihasilkan oleh Android Studio dan dikhususkan untuk lingkungan developer lokal, sebaiknya jangan mengubah file ini secara manual atau memeriksanya dalam sistem kontrol versi.

Menyinkronkan project dengan file Gradle

Jika Anda membuat perubahan pada file konfigurasi build dalam project, Android Studio akan mengharuskan Anda untuk menyinkronkan file project supaya bisa mengimpor perubahan konfigurasi build dan menjalankan beberapa pemeriksaan untuk memastikan konfigurasi Anda tidak akan menimbulkan error build.

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

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

Kumpulan sumber

Android Studio secara logis mengelompokkan kode sumber dan resource untuk setiap modul ke dalam kumpulan sumber. Kumpulan sumber main/ modul berisi kode dan resource yang digunakan oleh semua varian build-nya. Direktori kumpulan sumber tambahan bersifat opsional, dan Android Studio tidak secara otomatis membuatnya saat Anda mengonfigurasi varian build baru. Namun, membuat kumpulan sumber, yang mirip dengan main/, akan membantu menata file dan resource yang hanya boleh digunakan Gradle ketika membuat versi aplikasi tertentu:

src/main/

Kumpulan sumber ini berisi kode dan resource yang sama bagi semua varian build.

src/buildType/

Buat kumpulan sumber ini untuk memuat kode dan resource bagi tipe build tertentu saja.

src/productFlavor/

Buat kumpulan sumber ini untuk memuat kode dan resource bagi ragam produk tertentu saja.

Catatan: Jika build Anda dikonfigurasi agar menggabungkan beberapa ragam produk, Anda bisa membuat direktori kumpulan sumber bagi setiap kombinasi ragam produk antar-dimensi ragam:src/productFlavor1ProductFlavor2/

src/productFlavorBuildType/

Buat kumpulan sumber ini untuk memuat kode dan resource bagi varian build tertentu saja.

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

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

Catatan: Saat membuat file atau direktori baru di Android Studio menggunakan opsi menu File > Baru, Anda bisa membuatnya untuk kumpulan sumber tertentu. Kumpulan sumber yang bisa dipilih didasarkan pada konfigurasi build Anda, dan Android Studio secara otomatis membuat direktori yang diperlukan jika belum ada.

Jika kumpulan sumber yang berbeda memuat beberapa versi untuk file yang sama, Gradle menggunakan urutan prioritas berikut ini saat menentukan file yang akan digunakan (kumpulan sumber di sebelah kiri menggantikan file dan setelan kumpulan sumber di sebelah kanan):

varian build > tipe build > ragam produk > kumpulan 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 bisa menentukan komponen atau izin yang berbeda dalam manifes final. Untuk mempelajari cara membuat kumpulan sumber khusus lebih lanjut, buka Membuat Kumpulan Sumber untuk Varian Build.

Was this page helpful?

sumber: https://developer.android.com/studio/build