Save the date! Android Dev Summit is coming to Sunnyvale, CA on Oct 23-24, 2019.

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 bisa Anda build. Misalnya, Anda mungkin ingin mem-build satu versi aplikasi gratis, dengan konten terbatas, dan versi berbayar lainnya yang menyertakan lebih banyak konten. Anda juga bisa mem-build versi aplikasi berbeda yang menargetkan perangkat berbeda, berdasarkan API level atau variasi perangkat lainnya. Akan tetapi, jika Anda ingin mem-build versi berbeda berdasarkan kepadatan layar atau ABI perangkat, sebagai gantinya build beberapa APK.

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

Misalnya, ragam produk "demo" bisa menetapkan fitur dan persyaratan perangkat berbeda, seperti kode sumber khusus, sumber daya, dan API level minimum, sedangkan tipe "debug" build menerapkan setelan build dan pemaketan yang berbeda, seperti opsi debug dan kunci penandatanganan. Varian build yang dihasilkan adalah versi “demoDebug” aplikasi Anda, dan meliputi kombinasi konfigurasi dan sumber daya yang disertakan dalam ragam produk “demo”, tipe “debug” build dan set sumber main/.

Mengonfigurasi tipe build

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

Anda bisa menambahkan tipe debug build ke konfigurasi jika ingin menambahkan atau mengubah setelan tertentu. Contoh berikut menetapkan applicationIdSuffix untuk tipe debug build, dan mengonfigurasi tipe build "staging" yang dilakukan inisialiasi menggunakan setelan dari tipe debug build.

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: Bila Anda membuat perubahan pada file konfigurasi build, Android Studio akan mengharuskan Anda menyinkronkan project dengan konfigurasi baru. Untuk menyinkronkan project, Anda bisa mengklik Sync Now dalam baris pemberitahuan 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 mengetahui selengkapnya mengenai semua properti yang bisa Anda konfigurasi dengan tipe versi, silakan baca referensi DSL tipe build.

Mengonfigurasi ragam produk

Membuat ragam produk hampir sama dengan membuat tipe 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—karena defaultConfig sebenarnya termasuk dalam class ProductFlavor. Ini berarti Anda bisa menyediakan konfigurasi dasar untuk semua ragam dalam blok defaultConfig, dan masing-masing ragam bisa mengubah nilai default ini, seperti applicationId. Untuk mempelajari lebih lanjut tentang ID aplikasi, baca Menetapkan ID Aplikasi.

Catatan: Anda masih harus menetapkan nama package dengan menggunakan atribut package di file manifes main/. Anda juga harus menggunakan nama package tersebut dalam kode sumber untuk mereferensikan ke class R, atau menetapkan aktivitas relatif atau pendaftaran layanan. Ini memungkinkan Anda menggunakan applicationId untuk memberikan ID unik ke masing-masing ragam produk untuk pemaketan dan distribusi, tanpa harus mengubah kode sumber.

Semua ragam harus dimiliki oleh dimensi ragam bernama, yang merupakan kelompok ragam produk. Anda harus menetapkan ragam ke dimensi ragam, meskipun Anda hanya berniat menggunakan satu dimensi; jika tidak, Anda akan mendapat error build berikut:

  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" serta ragam produk "full". Ragam ini memberikan applicationIdSuffix dan versionNameSuffixnya sendiri:

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // This property is optional if you are using only one 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 masing-masing varian versionCode yang berbeda. Untuk mendistribusikan varian aplikasi yang berbeda sebagai aplikasi terpisah di Google Play, Anda perlu menetapkan applicationId yang berbeda untuk masing-masing varian.

Setelah Anda membuat dan mengonfigurasi ragam produk, klik Sync Now di baris pemberitahuan. Setelah sinkronisasi selesai, Gradle secara otomatis akan membuat varian build berdasarkan tipe build dan ragam produk Anda, serta menamainya sesuai dengan <product-flavor><Build-Type>. Misalnya, jika Anda membuat ragam produk 'demo' dan 'full', dan mempertahankan tipe build "debug" dan "rilis" default, Gradle akan membuat varian build berikut:

  • demoDebug
  • demoRelease
  • fullDebug
  • fullRelease

Anda bisa mengubah varian build menjadi apa pun yang ingin Anda build dan jalankan—cukup masuk ke Build > Select Build Variant dan pilih salah satu dari menu drop-down. Namun, untuk mulai menyesuaikan setiap varian build dengan fitur dan sumber dayanya sendiri, Anda harus mengetahui cara membuat dan mengelola set sumber. membuat dan mengelola set 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 berbeda untuk ragam produk "full" dan "demo" berdasarkan pada API level. Caranya, Android Plugin for Gradle memungkinkan Anda membuat 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 tipe 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 mem-build beberapa APK sebagai ganti 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 API level:

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 tipe build yang Anda konfigurasikan. Bila 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 tipe 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 set sumber, Anda bisa membuat untuk setiap ragam produk individu dan varian build, Anda juga bisa membuat direktori set sumber untuk masing-masing kombinasi ragam produk. Misalnya, Anda bisa membuat dan menambahkan sumber Java ke direktori src/demoMinApi24/java/, dan Gradle hanya menggunakan sumber itu saat mem-build varian yang menggabungkan kedua ragam produk tersebut. Set sumber yang Anda buat untuk kombinasi ragam produk memiliki prioritas lebih tinggi daripada set sumber yang dimiliki masing-masing ragam produk individual. Untuk mempelajari lebih lanjut tentang set sumber dan cara Gradle menggabungkan sumber daya, baca bagian tentang cara Membuat Set Sumber.

Memfilter varian

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

Dengan menggunakan konfigurasi build dari bagian sebelumnya sebagai contoh, anggaplah Anda berencana hanya mendukung API level 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 pemberitahuan, Gradle akan mengabaikan semua varian build yang memenuhi syarat yang Anda tetapkan, dan tidak lagi terlihat di menu drop-down bila Anda mengklik Build > Select Build Variant dari panel menu (atau Build Variants dalam panel jendela fitur).

Membuat set sumber

Secara default, Android Studio membuat main/ set sumber dan direktori untuk segala sesuatu yang ingin Anda bagikan di antara semua varian build. Akan tetapi, Anda bisa membuat set sumber baru untuk mengontrol secara persis file yang dikompilasi Gradle dan package untuk tipe build tertentu, ragam produk (dan kombinasi ragam produk saat menggunakan dimensi ragam), dan varian build. Misalnya, Anda bisa mendefinisikan fungsionalitas dasar dalam set sumber main/ dan menggunakan set sumber ragam produk untuk mengubah merek aplikasi bagi klien yang berbeda, atau menyertakan izin khusus dan fungsionalitas logging hanya untuk varian build yang menggunakan tipe debug build.

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

Android Plugin for Gradle menyediakan tugas Gradle berguna yang akan menampilkan cara menata file Anda untuk setiap tipe build, ragam produk, dan varian build. Misalnya, contoh berikut dari keluaran tugas menjelaskan tempat Gradle diperkirakan akan menemukan file tertentu bagi tipe "debug" build:

------------------------------------------------------------
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 keluaran ini, ikuti langkah berikut:

  1. Klik Gradle di sisi kanan jendela IDE.
  2. Pilih MyApplication > Tasks > android dan klik dua kali sourceSets. Setelah Gradle mengeksekusi tugas, jendela Jalankan nanti akan terbuka untuk menampilkan keluarannya.
  3. Jika tampilan tidak dalam mode teks seperti yang ditunjukkan di atas, klik Beralih tampilan di samping kiri jendela Jalankan.

Catatan: Keluaran tugas ini juga menampilkan cara menata set sumber untuk file yang ingin Anda gunakan untuk menjalankan pengujian aplikasi, seperti test/ dan androidTest/ set sumber pengujian.

Bila Anda membuat varian build baru, Android Studio tidak akan membuatkan direktori set sumber, melainkan memberikan beberapa opsi untuk membantu Anda. Misalnya, untuk hanya membuat direktori java/ bagi tipe "debug" build:

  1. Buka panel Project dan pilih tampilan Project dari menu drop-down di bagian atas panel.
  2. Buka MyProject/app/src/.
  3. Klik-kanan direktori src dan pilih New > Folder > Java Folder.
  4. Dari menu drop-down di sebelah Target Source Set, pilih debug.
  5. Klik Finish.

Android Studio membuat direktori set sumber untuk tipe debug build, kemudian membuat direktori java/ di dalamnya. Atau, Anda bisa menyetel Android Studio agar membuat direktori bila Anda menambahkan file baru ke project Anda untuk varian build tertentu. Misalnya, untuk membuat file XML nilai bagi tipe "debug" build Anda:

  1. Di panel Project yang sama, klik-kanan direktori src dan pilih New > XML > Values XML File.
  2. Masukkan nama untuk file XML atau tetap menggunakan nama default.
  3. Dari menu drop-down di sebelah Target Source Set, pilih debug.
  4. Klik Finish.

Karena tipe "debug" build ditetapkan sebagai set 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 set sumber yang baru untuk tipe debug build.

Dengan menggunakan prosedur yang sama, Anda juga bisa membuat direktori set sumber untuk ragam produk, seperti src/demo/, dan varian build, seperti src/demoDebug/. Selain itu, Anda bisa membuat set sumber pengujian yang menargetkan varian build tertentu, seperti src/androidTestDemoDebug/. Untuk mempelajari lebih lanjut, lihat Set sumber pengujian.

Mengubah konfigurasi set sumber default

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

Contoh kode berikut memetakan sumber dari direktori app/other/ ke komponen set sumber main tertentu dan mengubah direktori akar set 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'
      ...
    }
  }
}
...

Mem-build dengan set sumber

Anda bisa menggunakan direktori set sumber untuk memuat kode dan sumber daya yang ingin Anda paketkan hanya dengan konfigurasi tertentu. Misalnya, jika Anda sedang mem-build varian build "demoDebug", yang merupakan produk persilangan ragam produk "demo" dan tipe "debug" build, Gradle akan melihat direktori ini, dan memberinya prioritas berikut:

  1. src/demoDebug/ (set sumber varian build)
  2. src/debug/ (set sumber tipe build)
  3. src/demo/ (set sumber ragam produk)
  4. src/main/ (set 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 yang termasuk dalam dimensi ragam kedua, dan seterusnya. Selain itu, set sumber yang Anda buat untuk kombinasi ragam produk memiliki prioritas lebih tinggi daripada set sumber yang termasuk dalam masing-masing ragam produk individual.

Urutan yang tercantum di atas menentukan set sumber yang memiliki prioritas lebih tinggi bila Gradle menggabungkan kode dan sumber daya. Karena direktori set sumber demoDebug/ kemungkinan besar berisi file khusus untuk varian build tersebut, jika demoDebug/ menyertakan file yang juga didefinisikan dalam debug/, Gradle menggunakan file dalam set sumber demoDebug/. Demikian pula, Gradle memberikan file dalam tipe build dan set 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/ dikompilasi bersama untuk menghasilkan keluaran tunggal.

    Catatan: Untuk varian build tertentu, Gradle melontarkan error build jika menemukan dua atau beberapa direktori set sumber yang telah mendefinisikan class Java yang sama. Misalnya, saat mem-build APK debug, Anda tidak bisa mendefinisikan src/debug/Utility.java dan src/main/Utility.java. Hal ini karena Gradle melihat dalam kedua direktori ini selama proses build dan melontarkan error "duplicate class". Jika ingin versi berbeda dari Utility.java untuk tipe build berbeda, Anda bisa mengatur agar setiap tipe build mendefinisikan versi filenya sendiri dan tidak menyertakannya dalam set sumber main/.

  • Manifes digabungkan bersama menjadi manifes tunggal. Prioritas diberikan dalam urutan yang sama seperti daftar di atas. Yaitu, setelan manifes untuk satu tipe build akan menggantikan setelan manifes untuk ragam produk, dan seterusnya. Untuk mempelajari lebih lanjut, baca tentang penggabungan manifes.
  • Demikian juga, file dalam direktori values/ digabungkan bersama. Jika ada dua file berbagi nama yang sama, seperti dua file strings.xml, prioritas akan diberikan dalam urutan yang sama seperti daftar di atas. Yaitu, nilai yang didefinisikan dalam file di set sumber tipe build akan menggantikan nilai yang didefinisikan dalam file yang sama dalam ragam produk, dan seterusnya.
  • Sumber daya dalam direktori res/ dan asset/ dipaket bersama. Jika ada beberapa sumber daya bernama sama dengan yang didefinisikan dalam dua atau beberapa set sumber, prioritas diberikan dalam urutan yang sama seperti daftar di atas.
  • Yang terakhir, Gradle memberikan prioritas terendah untuk sumber daya dan manifes yang disertakan bersama dependensi modul library saat membuat APK.

Mendeklarasikan dependensi

Anda bisa mengonfigurasi dependensi untuk varian build tertentu atau set sumber pengujian dengan memberi awalan pada nama varian build atau set 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 selengkapnya, lihat Menambahkan dependensi build.

Mengonfigurasi setelan penandatanganan

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

Untuk secara manual mengonfigurasi penandatanganan bagi tipe build rilis Anda menggunakan konfigurasi build Gradle:

  1. Buat keystore. Keystore adalah file biner yang berisi seperangkat kunci privat. Anda harus menyimpan keystore di tempat yang aman dan terlindungi.
  2. Buat kunci privat. Kunci privat 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 > Generate Signed APK dari panel menu. Package 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 bisa 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 sandi ini jika Anda memanggil build dari baris perintah:

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

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

Peringatan: Simpan keystore dan kunci privat Anda di tempat yang aman dan terlindungi, dan pastikan Anda memiliki backup yang aman. Jika Anda memublikasikan aplikasi ke Google Play kemudian kehilangan kunci yang digunakan untuk menandatangani aplikasi, Anda tidak akan bisa 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 dan APK ponsel opsional perlu ditandatangani. Untuk informasi selengkapnya mengenai pemaketan dan penandatanganan aplikasi Wear OS, lihat Memaketkan Aplikasi untuk Perangkat Wearable.