Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

Mengonfigurasi varian build

Halaman ini dibuat berdasarkan pada Ringkasan Mengonfigurasi Build Anda untuk menampilkan cara mengonfigurasi varian build guna membuat versi aplikasi yang berbeda dari sebuah project, dan cara mengelola konfigurasi penandatanganan dan dependensi dengan benar.

Setiap varian build menyatakan versi aplikasi berbeda yang dapat Anda buat. Misalnya, Anda ingin membuat satu versi aplikasi gratis, dengan materi terbatas, dan versi lainnya yaitu versi berbayar yang berisi lebih banyak materi. Anda juga dapat membuat versi aplikasi berbeda yang menargetkan perangkat berbeda, berdasarkan level API atau variasi perangkat lainnya. Namun, jika Anda ingin membuat versi berbeda berdasarkan kepadatan layar atau ABI perangkat, sebagai gantinya buat beberapa APK.

Varian build adalah hasil dari Gradle yang menggunakan seperangkat aturan tertentu untuk menggabungkan setelan, kode, dan resource yang dikonfigurasi dalam tipe build dan ragam produk. Meskipun tidak mengonfigurasi varian build secara langsung, Anda mengonfigurasi jenis build dan ragam produk yang membentuknya.

Misalnya, ragam produk "demo" dapat menetapkan fitur dan persyaratan perangkat yang berbeda, seperti kode sumber khusus, resource, dan level API minimum, sedangkan jenis build "debug" menerapkan setelan build dan paket yang berbeda, seperti opsi debug dan kunci penandatanganan. Varian build yang dihasilkan adalah versi "demoDebug" dari aplikasi Anda, dan versi tersebut mencakup kombinasi konfigurasi dan resource yang termasuk dalam ragam produk "demo", jenis build "debug", dan kumpulan sumber main/.

Mengonfigurasi jenis build

Anda dapat membuat dan mengonfigurasi jenis build dalam file build.gradle level modul di dalam blok android. Jika Anda membuat modul baru, Android Studio secara otomatis akan membuatkan debug dan jenis build rilis. Meskipun jenis build debug tidak muncul dalam file konfigurasi build, Android Studio akan mengonfigurasinya dengan debuggable true. Ini memungkinkan Anda untuk men-debug aplikasi di perangkat Android yang aman dan mengonfigurasi penandatanganan APK dengan keystore debug generik.

Anda bisa menambahkan jenis build debug ke konfigurasi jika ingin menambahkan atau mengubah setelan tertentu. Contoh berikut menentukan applicationIdSuffix untuk jenis build debug, dan mengonfigurasi jenis build "staging" yang diinisialisasi menggunakan setelan dari jenis build debug.

    android {
        defaultConfig {
            manifestPlaceholders = [hostName:"www.example.com"]
            ...
        }
        buildTypes {
            release {
                minifyEnabled true
                proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            }

            debug {
                applicationIdSuffix ".debug"
                debuggable true
            }

            /**
             * The `initWith` property allows you to copy configurations from other build types,
             * then configure only the settings you want to change. This one copies the debug build
             * type, and then changes the manifest placeholder and application ID.
             */
            staging {
                initWith debug
                manifestPlaceholders = [hostName:"internal.example.com"]
                applicationIdSuffix ".debugStaging"
            }
        }
    }
    

Catatan: Jika Anda membuat perubahan pada file konfigurasi build, Android Studio akan mengharuskan Anda untuk menyinkronkan project dengan konfigurasi baru. Untuk menyinkronkan project, Anda bisa mengklik Sync Now dalam baris notifikasi yang muncul begitu Anda membuat perubahan atau mengklik Sync Project dari toolbar. Jika Android Studio menemukan error pada konfigurasi Anda, jendela Messages akan muncul untuk menjelaskan masalah ini.

Untuk mempelajari lebih lanjut semua properti yang bisa Anda konfigurasikan dengan jenis build, baca referensi DSL jenis build.

Mengonfigurasi ragam produk

Membuat ragam produk hampir sama dengan membuat jenis build: tambahkan ragam produk ke blok productFlavors dalam konfigurasi build Anda dan sertakan setelan yang Anda inginkan. Ragam produk mendukung properti yang sama seperti defaultConfig. Ini karena defaultConfig sebenarnya termasuk class ProductFlavor. Ini berarti bahwa Anda bisa menyediakan konfigurasi dasar untuk semua ragam dalam blok defaultConfig, dan setiap ragam bisa mengganti nilai default ini, seperti applicationId. Untuk mempelajari ID aplikasi lebih lanjut, baca Menyetel ID Aplikasi.

Catatan: Anda masih harus menentukan nama paket menggunakan atribut package dalam file manifes main/. Anda juga harus menggunakan nama paket tersebut dalam kode sumber untuk merujuk ke class R, atau menetapkan aktivitas relatif atau pendaftaran layanan. Ini memungkinkan Anda menggunakan applicationId sehingga memberikan setiap ragam produk sebuah ID unik untuk pemaketan dan distribusi, tanpa harus mengubah kode sumber.

Semua ragam harus dimiliki oleh dimensi ragam bernama, yang merupakan kelompok ragam produk. Anda harus menentukan semua ragam ke dimensinya; jika tidak, Anda akan mengalami error build yang seperti di bawah ini. Jika modul yang diberikan hanya menentukan satu dimensi ragam, plugin Android Gradle secara otomatis menetapkan semua ragam modul ke dimensi tersebut.

      Error:All flavors must now belong to a named flavor dimension.
      The flavor 'flavor_name' is not assigned to a flavor dimension.
    

Contoh kode berikut membuat dimensi ragam yang diberi nama "version" dan menambahkan "demo" dan ragam produk "full". Ragam ini menyediakan applicationIdSuffix dan versionNameSuffix miliknya sendiri:

    android {
        ...
        defaultConfig {...}
        buildTypes {
            debug{...}
            release{...}
        }
        // Specifies one flavor dimension.
        flavorDimensions "version"
        productFlavors {
            demo {
                // Assigns this product flavor to the "version" flavor dimension.
                // If you are using only one dimension, this property is optional,
                // and the plugin automatically assigns all the module's flavors to
                // that dimension.
                dimension "version"
                applicationIdSuffix ".demo"
                versionNameSuffix "-demo"
            }
            full {
                dimension "version"
                applicationIdSuffix ".full"
                versionNameSuffix "-full"
            }
        }
    }
    

Catatan: Untuk mendistribusikan aplikasi Anda menggunakan Dukungan Multi APK di Google Play, berikan nilai applicationId yang sama ke semua varian dan berikan versionCode yang berbeda untuk setiap varian. Untuk mendistribusikan berbagai varian aplikasi Anda sebagai aplikasi terpisah di Google Play, Anda harus menetapkan applicationId yang berbeda untuk masing-masing varian.

Setelah Anda membuat dan mengonfigurasi ragam produk, klik Sinkronisasikan Sekarang di baris notifikasi. Setelah sinkronisasi selesai, Gradle secara otomatis akan membuat varian build berdasarkan jenis dan ragam produk Anda, dan memberinya nama yang sesuai dengan <product-flavor><Build-Type>. Misalnya, jika Anda membuat ragam produk “demo” dan “full”, dan mempertahankan jenis build default “debug” dan “release”, Gradle akan membuat varian build berikut:

  • demoDebug
  • demoRelease
  • fullDebug
  • fullRelease

Anda dapat mengubah varian build menjadi apa pun yang ingin Anda buat dan jalankan. Cukup buka Build > Pilih Varian Build, lalu pilih salah satu dari menu drop-down. Namun, untuk mulai menyesuaikan setiap varian build dengan fitur dan resourcenya sendiri, Anda harus mengetahui cara membuat dan mengelola kumpulan sumber.

Menggabungkan beberapa ragam produk dengan dimensi ragam

Dalam beberapa kasus, Anda mungkin ingin menggabungkan konfigurasi dari beberapa ragam produk. Misalnya, Anda mungkin ingin membuat konfigurasi yang berbeda untuk ragam produk "full" dan "demo" berdasarkan level API. Caranya, Android Plugin untuk Gradle memungkinkan Anda membuat beberapa grup ragam produk yang disebut dimensi ragam. Saat membuat aplikasi, Gradle menggabungkan konfigurasi ragam produk dari setiap dimensi ragam yang Anda definisikan, bersama dengan konfigurasi jenis build, untuk membuat varian build akhir. Gradle tidak menggabungkan ragam produk yang dimiliki dimensi ragam yang sama.

Tips: Untuk membuat versi aplikasi yang berbeda berdasarkan ABI dan kepadatan layar, Anda harus membuat beberapa APK, bukan menggunakan ragam produk.

Contoh kode berikut menggunakan properti flavorDimensions untuk membuat dimensi ragam "mode" guna mengelompokkan ragam produk "full" dan "demo", serta dimensi ragam "api" guna mengelompokkan konfigurasi ragam produk berdasarkan level API.

    android {
      ...
      buildTypes {
        debug {...}
        release {...}
      }

      // Specifies the flavor dimensions you want to use. The order in which you
      // list each dimension determines its priority, from highest to lowest,
      // when Gradle merges variant sources and configurations. You must assign
      // each product flavor you configure to one of the flavor dimensions.
      flavorDimensions "api", "mode"

      productFlavors {
        demo {
          // Assigns this product flavor to the "mode" flavor dimension.
          dimension "mode"
          ...
        }

        full {
          dimension "mode"
          ...
        }

        // Configurations in the "api" product flavors override those in "mode"
        // flavors and the defaultConfig block. Gradle determines the priority
        // between flavor dimensions based on the order in which they appear next
        // to the flavorDimensions property above--the first dimension has a higher
        // priority than the second, and so on.
        minApi24 {
          dimension "api"
          minSdkVersion 24
          // To ensure the target device receives the version of the app with
          // the highest compatible API level, assign version codes in increasing
          // value with API level. To learn more about assigning version codes to
          // support app updates and uploading to Google Play, read Multiple APK Support
          versionCode 30000 + android.defaultConfig.versionCode
          versionNameSuffix "-minApi24"
          ...
        }

        minApi23 {
          dimension "api"
          minSdkVersion 23
          versionCode 20000  + android.defaultConfig.versionCode
          versionNameSuffix "-minApi23"
          ...
        }

        minApi21 {
          dimension "api"
          minSdkVersion 21
          versionCode 10000  + android.defaultConfig.versionCode
          versionNameSuffix "-minApi21"
          ...
        }
      }
    }
    ...
    

Jumlah varian build yang dibuat Gradle sama dengan produk dari jumlah ragam di masing-masing dimensi ragam dan jumlah jenis build yang Anda konfigurasikan. Jika Gradle memberi nama masing-masing varian build atau APK terkait, ragam produk yang dimiliki dimensi ragam berprioritas lebih tinggi akan muncul terlebih dahulu, diikuti oleh ragam dari dimensi berprioritas lebih rendah, diikuti dengan jenis build. Dengan menggunakan konfigurasi build di atas sebagai contoh, Gradle total membuat 12 varian build dengan skema penamaan berikut:

Varian build: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
APK terkait: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
Misalnya,
Varian build: minApi24DemoDebug
APK terkait: app-minApi24-demo-debug.apk

Selain untuk direktori kumpulan sumber, Anda dapat membuat untuk setiap ragam produk individu dan varian build, dan juga dapat membuat direktori kumpulan sumber untuk masing-masing kombinasi ragam produk. Misalnya, Anda dapat membuat dan menambahkan sumber Java ke direktori src/demoMinApi24/java/, dan Gradle hanya menggunakan sumber itu saat membuat varian yang menggabungkan kedua ragam produk tersebut. Kumpulan sumber yang Anda buat untuk kombinasi ragam produk memiliki prioritas lebih tinggi daripada kumpulan sumber yang termasuk dalam masing-masing ragam produk individu. Untuk mempelajari lebih lanjut mengenai kumpulan sumber dan cara Gradle menggabungkan resource, baca bagian cara Membuat Kumpulan Sumber.

Memfilter varian

Gradle membuat varian build untuk setiap kombinasi yang memungkinkan dari ragam produk dan jenis build yang Anda konfigurasikan. Akan tetapi, mungkin ada varian build tertentu yang tidak Anda perlukan atau tidak masuk akal dalam konteks project Anda. Anda dapat menghapus konfigurasi varian build tertentu dengan membuat filter varian di file build.gradle level modul.

Dengan menggunakan konfigurasi build dari bagian sebelumnya sebagai contoh, anggaplah Anda berencana hanya mendukung level API 23 dan yang lebih tinggi untuk versi demo aplikasi. Anda bisa menggunakan blok variantFilter untuk memfilter semua konfigurasi varian build yang menggabungkan ragam produk "minApi21" dan "demo":

    android {
      ...
      buildTypes {...}

      flavorDimensions "api", "mode"
      productFlavors {
        demo {...}
        full {...}
        minApi24 {...}
        minApi23 {...}
        minApi21 {...}
      }

      variantFilter { variant ->
          def names = variant.flavors*.name
          // To check for a certain build type, use variant.buildType.name == "<buildType>"
          if (names.contains("minApi21") && names.contains("demo")) {
              // Gradle ignores any variants that satisfy the conditions above.
              setIgnore(true)
          }
      }
    }
    ...
    

Setelah Anda menambahkan filter varian ke konfigurasi build dan mengklik Sync Now di baris notifikasi, Gradle akan mengabaikan semua varian build yang memenuhi ketentuan yang Anda tetapkan, dan tidak lagi terlihat di menu drop-down jika Anda mengklik Build > Select Build Variant dari panel menu (atau Build Variants dalam panel jendela fitur).

Membuat kumpulan sumber

Secara default, Android Studio membuat main/ kumpulan sumber dan direktori untuk semua yang ingin Anda bagikan antara semua varian versi. Namun, Anda bisa membuat kumpulan sumber baru untuk mengontrol secara persis file yang dikompilasi Gradle dan paket untuk jenis build tertentu, ragam produk (dan kombinasi ragam produk saat menggunakan dimensi ragam), dan varian build. Misalnya, Anda dapat mendefinisikan fungsionalitas dasar di kumpulan sumber main/ dan menggunakan kumpulan sumber ragam produk untuk mengubah pencitraan aplikasi bagi klien yang berbeda, atau menyertakan izin khusus dan fungsionalitas logging hanya untuk varian build yang menggunakan jenis build debug.

Gradle mengharapkan Anda untuk menyetel file dan direktori kumpulan sumber dengan cara tertentu, serupa dengan kumpulan sumber main/. Misalnya, Gradle berharap agar file class Java yang khusus untuk jenis build "debug" terletak di direktori src/debug/java/.

Android Plugin untuk Gradle menyediakan tugas Gradle berdaya guna yang akan menunjukkan cara mengatur file Anda untuk setiap jenis build, ragam produk, dan varian build. Misalnya, contoh berikut dari output tugas menjelaskan tempat Gradle diperkirakan akan menemukan file tertentu untuk jenis build "debug".

    ------------------------------------------------------------
    Project :app
    ------------------------------------------------------------

    ...

    debug
    ----
    Compile configuration: compile
    build.gradle name: android.sourceSets.debug
    Java sources: [app/src/debug/java]
    Manifest file: app/src/debug/AndroidManifest.xml
    Android resources: [app/src/debug/res]
    Assets: [app/src/debug/assets]
    AIDL sources: [app/src/debug/aidl]
    RenderScript sources: [app/src/debug/rs]
    JNI sources: [app/src/debug/jni]
    JNI libraries: [app/src/debug/jniLibs]
    Java-style resources: [app/src/debug/resources]
    

Untuk melihat output ini, ikuti langkah berikut:

  1. Klik Gradle di sisi kanan jendela IDE.
  2. Buka MyApplication > Tasks > android lalu klik dua kali sourceSets. Setelah Gradle mengeksekusi tugas, jendela Run akan terbuka untuk menampilkan outputnya.
  3. Jika tampilan tidak dalam mode teks seperti yang ditunjukkan di atas, klik Toggle view di samping kiri jendela Run.

Catatan: Laporan ini juga menunjukkan cara mengatur kumpulan sumber untuk file yang ingin Anda gunakan untuk menjalankan pengujian bagi aplikasi Anda, seperti test/ dan androidTest/ pengujian kumpulan sumber.

Jika Anda membuat varian build baru, Android Studio tidak akan membuat direktori kumpulan sumber, melainkan memberikan beberapa opsi untuk membantu Anda. Misalnya, hanya membuat direktori java/ untuk jenis build "debug":

  1. Buka panel Project, lalu pilih tampilan Project dari menu drop-down di bagian atas panel.
  2. Arahkan ke MyProject/app/src/.
  3. Klik kanan direktori src lalu pilih New > Folder > Java Folder.
  4. Dari menu drop-down di sebelah Kumpulan Sumber Target, pilih debug.
  5. Klik Selesai.

Android Studio membuat direktori kumpulan sumber untuk jenis build debug, kemudian membuat direktori java/ di dalamnya. Atau, Anda dapat menyetel Android Studio agar membuat direktori jika menambahkan file baru ke project Anda untuk varian build tertentu. Misalnya, untuk membuat file XML nilai untuk jenis build "debug" Anda:

  1. Dalam panel Project yang sama, klik kanan direktori src, lalu pilih New > XML > Values XML File.
  2. Masukkan nama untuk file XML atau tetap menggunakan nama default.
  3. Dari menu drop-down di sebelah Kumpulan Sumber Target, pilih debug.
  4. Klik Selesai.

Karena jenis build "debug" ditetapkan sebagai kumpulan sumber target, Android Studio secara otomatis akan membuat direktori yang diperlukan ketika membuat file XML. Struktur direktori yang dihasilkan akan terlihat seperti gambar 2.

Gambar 2. Direktori kumpulan sumber baru untuk jenis build debug.

Menggunakan prosedur yang sama, Anda juga dapat membuat direktori kumpulan sumber untuk ragam produk, seperti src/demo/, dan varian build seperti src/demoDebug/. Selain itu, Anda juga dapat membuat pengujian kumpulan sumber yang menargetkan varian build tertentu, seperti src/androidTestDemoDebug/. Untuk mempelajari lebih lanjut, lihat Kumpulan sumber pengujian.

Mengubah konfigurasi kumpulan sumber default

Jika Anda memiliki sumber yang tidak diatur ke dalam struktur file kumpulan sumber default yang diharapkan Gradle, seperti yang dijelaskan di atas dalam bagian membuat kumpulan sumber, Anda bisa menggunakan blok sourceSets untuk mengubah lokasi pencarian Gradle untuk mengumpulkan file dari setiap komponen kumpulan sumber. Anda tidak perlu memindahkan lokasi file, Anda hanya perlu memberikan lokasinya ke Gradle, relatif terhadap file build.gradle level modul, lokasi seharusnya Gradle menemukan file untuk masing-masing komponen kumpulan sumber. Untuk mempelajari komponen mana yang dapat Anda konfigurasi, dan apakah Anda dapat memetakannya ke beberapa file atau direktori, baca referensi DSL Android Plugin untuk Gradle.

Contoh kode berikut memetakan sumber dari direktori app/other/ ke komponen kumpulan sumber main tertentu dan mengubah direktori root dari kumpulan sumber androidTest.

    android {
      ...
      sourceSets {
        // Encapsulates configurations for the main source set.
        main {
          // Changes the directory for Java sources. The default directory is
          // 'src/main/java'.
          java.srcDirs = ['other/java']

          // If you list multiple directories, Gradle uses all of them to collect
          // sources. Because Gradle gives these directories equal priority, if
          // you define the same resource in more than one directory, you get an
          // error when merging resources. The default directory is 'src/main/res'.
          res.srcDirs = ['other/res1', 'other/res2']

          // Note: You should avoid specifying a directory which is a parent to one
          // or more other directories you specify. For example, avoid the following:
          // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
          // You should specify either only the root 'other/res1' directory, or only the
          // nested 'other/res1/layouts' and 'other/res1/strings' directories.

          // For each source set, you can specify only one Android manifest.
          // By default, Android Studio creates a manifest for your main source
          // set in the src/main/ directory.
          manifest.srcFile 'other/AndroidManifest.xml'
          ...
        }

        // Create additional blocks to configure other source sets.
        androidTest {

          // If all the files for a source set are located under a single root
          // directory, you can specify that directory using the setRoot property.
          // When gathering sources for the source set, Gradle looks only in locations
          // relative to the root directory you specify. For example, after applying the
          // configuration below for the androidTest source set, Gradle looks for Java
          // sources only in the src/tests/java/ directory.
          setRoot 'src/tests'
          ...
        }
      }
    }
    ...
    

Membuat dengan menggunakan kumpulan sumber

Anda dapat menggunakan direktori kumpulan sumber untuk memuat kode dan resource yang ingin Anda paketkan hanya dengan konfigurasi tertentu. Misalnya, jika Anda membuat varian build “demoDebug” yang merupakan produk persilangan dari ragam produk “demo” dan jenis build “debug”, Gradle akan melihat direktori ini dan memberinya prioritas berikut:

  1. src/demoDebug/ (kumpulan sumber varian build)
  2. src/debug/ (kumpulan sumber jenis build)
  3. src/demo/ (kumpulan sumber ragam produk)
  4. src/main/ (kumpulan sumber utama)

Catatan: Jika Anda menggabungkan beberapa ragam produk , prioritas antara ragam produk ditentukan oleh dimensi ragam yang dimiliki. Saat mencantumkan dimensi ragam pada properti android.flavorDimensions ragam produk yang termasuk dalam dimensi ragam pertama yang Anda cantumkan memiliki prioritas lebih tinggi daripada ragam produk yang termasuk dalam dimensi ragam kedua, dan seterusnya. Selain itu, kumpulan sumber yang Anda buat untuk kombinasi ragam produk memiliki prioritas lebih tinggi daripada kumpulan sumber yang termasuk dalam setiap ragam produk individu.

Urutan yang tercantum di atas menentukan kumpulan sumber yang memiliki prioritas lebih tinggi jika Gradle menggabungkan kode dan resource. Karena direktori kumpulan sumber demoDebug/ kemungkinan berisi file yang dikhususkan untuk varian build, jika demoDebug/ memuat file yang juga didefinisikan dalam debug/, Gradle akan menggunakan file di kumpulan sumber demoDebug/. Demikian pula, Gradle memberikan file dalam jenis build dan kumpulan sumber ragam produk prioritas yang lebih tinggi daripada file yang sama dalam main/. Gradle mempertimbangkan urutan prioritas ini saat menerapkan aturan build berikut:

  • Semua kode sumber dalam direktori java/ disusun bersama untuk menghasilkan satu output.

    Catatan: Untuk varian build tertentu, Gradle menampilkan error build jika menemukan dua atau beberapa direktori kumpulan sumber yang telah menentukan class Java yang sama. Misalnya, jika membuat APK debug, Anda tidak dapat menetapkan src/debug/Utility.java maupun src/main/Utility.java. Hal ini karena Gradle melihat dalam kedua direktori ini selama proses pembuatan dan menampilkan error "class duplikat". Jika Anda menginginkan versi berbeda dari Utility.java untuk jenis versi yang berbeda, Anda dapat mengatur agar setiap jenis versi menetapkan versi filenya sendiri dan tidak memasukkannya dalam kumpulan sumber main/.

  • Manifes digabung menjadi satu manifes. Prioritas diberikan dalam urutan yang sama dengan daftar di atas. Artinya, setelan manifes untuk satu jenis versi akan menggantikan setelan manifes untuk ragam produk, dan sebagainya. Untuk mempelajari lebih lanjut, baca penggabungan manifes.
  • Demikian juga, file dalam direktori values/ digabungkan bersama-sama. Jika ada dua file memiliki nama yang sama, seperti dua file strings.xml, prioritas akan diberikan dalam urutan yang sama seperti daftar di atas. Yaitu, nilai yang ditentukan dalam file di kumpulan sumber jenis build akan menggantikan nilai yang ditentukan dalam file yang sama dalam ragam produk, dan seterusnya.
  • Resource di direktori res/ dan asset/ dikemas bersama-sama. Jika ada beberapa resource memiliki nama yang sama dengan yang ditentukan dalam dua atau beberapa kumpulan sumber, prioritas akan diberikan dalam urutan yang sama seperti daftar di atas.
  • Terakhir, Gradle memberikan prioritas terendah untuk resource dan manifes yang disertakan bersama dependensi modul library saat membuat APK.

Mendeklarasikan dependensi

Anda bisa mengonfigurasi dependensi untuk varian build tertentu atau kumpulan sumber pengujian dengan memberi awalan pada nama varian build atau kumpulan sumber pengujian sebelum kata kunci Implementation seperti yang ditampilkan dalam contoh berikut.

    dependencies {
        // Adds the local "mylibrary" module as a dependency to the "free" flavor.
        freeImplementation project(":mylibrary")

        // Adds a remote binary dependency only for local tests.
        testImplementation 'junit:junit:4.12'

        // Adds a remote binary dependency only for the instrumented test APK.
        androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
    }
    

Untuk informasi lebih lanjut, lihat Menambahkan dependensi build.

Mengonfigurasi setelan penandatanganan

Gradle tidak menandatangani APK build rilis kecuali Anda secara eksplisit mendefinisikan konfigurasi penandatanganan untuk build ini. Anda dapat dengan mudah membuat kunci rilis dan menandatangani jenis versi rilis menggunakan Android Studio.

Untuk secara manual mengubah konfigurasi penandatanganan bagi jenis build rilis Anda menggunakan konfigurasi build Gradle:

  1. Buat keystore. Keystore adalah file biner yang berisi kumpulan kunci pribadi. Anda harus menyimpan keystore di tempat yang aman dan terlindungi.
  2. Buat kunci pribadi. Kunci pribadi menyatakan entity yang akan diidentifikasi dengan aplikasi, seperti pengguna atau perusahaan.
  3. Tambahkan konfigurasi penandatanganan ke file build.gradle level modul:

        ...
        android {
            ...
            defaultConfig {...}
            signingConfigs {
                release {
                    storeFile file("myreleasekey.keystore")
                    storePassword "password"
                    keyAlias "MyReleaseKey"
                    keyPassword "password"
                }
            }
            buildTypes {
                release {
                    ...
                    signingConfig signingConfigs.release
                }
            }
        }
        

Untuk menghasilkan APK bertandatangan, pilih Build > Hasilkan APK yang ditandatangani dari panel menu. Paket dalam app/build/apk/app-release.apk sekarang telah ditandatangani dengan kunci rilis Anda.

Catatan: Menyertakan sandi untuk kunci rilis dan keystore di dalam file build bukanlah kebiasaan keamanan yang baik. Sebagai alternatif, Anda dapat mengonfigurasi file build untuk memperoleh sandi ini dari variabel lingkungan atau mengatur agar proses build meminta sandi ini.

Untuk memperoleh sandi ini dari variabel lingkungan:

    storePassword System.getenv("KSTOREPWD")
    keyPassword System.getenv("KEYPWD")
    

Agar proses build meminta kata sandi ini jika Anda memanggil build dari command line:

    storePassword System.console().readLine("\nKeystore password: ")
    keyPassword System.console().readLine("\nKey password: ")
    

Setelah menyelesaikan proses ini, Anda dapat mendistribusikan aplikasi dan memublikasikannya di Google Play.

Peringatan: Simpan keystore dan kunci pribadi Anda di tempat yang aman dan terlindungi, serta pastikan Anda memiliki backup yang aman. Jika Anda memublikasikan aplikasi ke Google Play kemudian kehilangan kunci yang digunakan untuk menandatangani aplikasi, Anda tidak akan dapat memublikasikan setiap update ke aplikasi, karena Anda harus selalu menandatangani semua versi aplikasi dengan kunci yang sama.

Menandatangani aplikasi Wear OS

Saat memublikasikan aplikasi Wear OS, APK jam tangan dan APK ponsel opsional perlu ditandatangani. Untuk mengetahui informasi selengkapnya mengenai paket dan penandatanganan aplikasi Wear OS, lihat Memaketkan Aplikasi untuk Perangkat Wearable.