Skip to content

Most visited

Recently visited

navigation

Mengonfigurasi Varian Pembangunan

Laman ini dibuat berdasar Ringkasan Mengonfigurasi Pembangunan Anda untuk menunjukkan bagaimana Anda bisa mengonfigurasi varian pembangunan untuk membuat versi aplikasi yang berbeda dari sebuah proyek, dan bagaimana mengelola konfigurasi penandatanganan dan dependensi dengan benar.

Setiap varian pembangunan merepresentasikan versi aplikasi berbeda yang bisa Anda buat. Misalnya, Anda ingin membangun satu versi aplikasi gratis, dengan materi terbatas, dan versi berbayar lainnya yang berisi lebih banyak materi. Anda juga bisa membangun versi aplikasi berbeda yang menargetkan perangkat berbeda, berdasarkan API level atau variasi perangkat lainnya. Namun, jika Anda ingin membangun versi berbeda berdasarkan kepadatan layar atau ABI perangkat, sebagai gantinya gunakan APK splits.

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

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

Mengonfigurasi Tipe Pembangunan

Anda bisa membuat dan mengonfigurasi tipe pembangunan dalam file build.gradle level modul di dalam blok android {}. Ketika membuat modul baru, Android Studio secara otomatis akan membuat tipe pembangunan versi debug dan rilis untuk Anda. Meskipun tipe pembangunan versi debug tidak muncul di file konfigurasi pembangunan, 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 pembangunan versi debug ke konfigurasi jika Anda ingin menambahkan atau mengubah setelan tertentu. Contoh berikut menetapkan applicationIdSuffix untuk tipe pembangunan versi debug, dan mengonfigurasi tipe pembangunan "jnidebug" yang di-inisialiasi menggunakan setelan dari tipe pembangunan versi debug.

android {
    ...
    defaultConfig {...}
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */

        jnidebug {

            // This copies the debuggable attribute and debug signing configurations.
            initWith debug

            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

Catatan: Bila Anda membuat perubahan untuk file konfigurasi pembangunan, Android Studio akan mengharuskan Anda menyinkronkan proyek dengan konfigurasi yang baru. Untuk melakukan sinkronisasi proyek, Anda bisa mengeklik Sync Now di bilah notifikasi yang langsung muncul setelah Anda melakukan perubahan atau mengeklik Sync Project dari bilah alat. Jika Android Studio melihat kesalahan dengan konfigurasi Anda, jendela Messages akan muncul untuk menjelaskan masalah ini.

Untuk mengetahui selengkapnya mengenai semua properti yang bisa Anda konfigurasi dengan tipe pembangunan, silakan baca referensi DSL tipe pembangunan.

Mengonfigurasi Ragam Produk

Membuat ragam produk hampir sama dengan membuat tipe pembangunan: tambahkan mereka ke blok productFlavors {} dan mengonfigurasi setelan yang Anda inginkan. Ragam produk mendukung properti yang sama seperti defaultConfig—karena defaultConfig sebenarnya termasuk dalam kelas ProductFlavor. Ini berarti Anda bisa menyediakan konfigurasi dasar untuk semua ragam dalam blok defaultConfig {}, dan masing-masing ragam dapat mengubah nilai default ini, seperti applicationId. Untuk mengetahui selengkapnya tentang ID aplikasi, baca Menetapkan ID Aplikasi.

Catatan: Anda masih harus menentukan nama paket menggunakan atribut package di file manifes main/. Anda juga harus menggunakan nama paket tersebut dalam kode sumber Anda untuk merujuk ke kelas R, atau menyelesaikan aktivitas relatif atau registrasi layanan. Ini memungkinkan Anda menggunakan applicationId untuk memberikan masing-masing ragam produk sebuah ID unik untuk pengemasan dan distribusi, tanpa harus mengubah kode sumber.

Contoh kode berikut membuat ragam produk "demo" dan "full" yang menyediakan applicationIdSuffix dan versionNameSuffix sendiri:

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

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

Setelah Anda membuat dan mengonfigurasi ragam produk, klik Sync Now pada bilah notifikasi. Setelah sinkronisasi selesai, Gradle secara otomatis akan membuat varian pembangunan berdasarkan tipe pembangunan dan ragam produk Anda, serta menamainya menurut <product-flavor><Build-Type>. Misalnya, jika Anda membuat ragam produk 'demo' dan 'full', dan mempertahankan tipe pembangunan versi 'debug' dan 'rilis' default, Gradle akan membuat varian pembangunan berikut:

Anda bisa mengubah varian pembangunan menjadi apa pun yang ingin Anda buat dan jalankan—cukup masuk ke Build > Select Build Variant dan pilih salah satu dari menu tarik-turun. Namun, untuk mulai menyesuaikan setiap varian pembangunan dengan fitur dan sumber dayanya sendiri, Anda harus mengetahui cara membuat dan mengelola set sumber.

Menggabungkan beberapa ragam produk

Dalam kejadian tertentu, Anda mungkin ingin menggabungkan konfigurasi dari beberapa ragam produk. Misalnya, Anda mungkin ingin membuat konfigurasi berbeda untuk ragam produk "full" dan "demo" yang didasarkan pada level API. Untuk melakukannya, plugin Android untuk Gradle memungkinkan Anda membuat grup ragam produk, yang disebut dimensi ragam. Saat membangun aplikasi, Gradle menggabungkan konfigurasi ragam produk dari setiap dimensi ragam yang Anda tetapkan, bersama dengan konfigurasi tipe pembangunan, untuk membuat varian pembangunan akhir. Gradle tidak menggabungkan ragam produk yang termasuk dalam dimensi ragam yang sama.

Tip: Untuk membuat versi aplikasi yang berbeda berdasarkan ABI dan kepadatan layar, Anda sebaiknya Mengonfigurasi Pemisahan APK bukannya menggunakan ragam produk.

Contoh kode berikut menggunakan properti flavorDimensions untuk membuat dimensi ragam "mode" guna mengelompokkkan ragam produk "full" dan "demo", serta dimensi ragam "api" untuk 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 pembangunan yang dibuat Gradle sama dengan produk dari jumlah ragam di masing-masing dimensi ragam dan jumlah tipe pembangunan yang Anda konfigurasikan. Ketika Gradle memberi nama masing-masing varian pembangunan atau APK yang bersesuaian, ragam produk yang dimiliki dimensi ragam berprioritas lebih tinggi akan muncul terlebih dahulu, diikuti oleh ragam dari dimensi berprioritas lebih rendah, lalu diikuti oleh tipe pembangunan. Dengan menggunakan konfigurasi pembangunan di atas sebagai contoh, Gradle total membuat 12 varian pembangunan dengan skema penamaan berikut:

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

Selain untuk direktori set sumber, Anda bisa membuat untuk setiap ragam produk individu dan varian pembangunan, Anda juga dapat 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 ketika membangun 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 individu. Untuk mengetahui selengkapnya tentang set sumber dan bagaimana Gradle menggabungkan sumber daya, baca bagian tentang cara Membuat Set Sumber.

Memfilter varian

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

Dengan menggunakan konfigurasi pembangunan dari bagian sebelumnya sebagai contoh, misalkan Anda berencana untuk hanya mendukung API level 23 dan lebih tinggi untuk versi demo aplikasi. Anda bisa menggunakan blok variantFilter {} untuk memfilter semua konfigurasi varian pembangunan 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 pembangunan dan mengeklik Sync Now di bilah notifikasi, Gradle akan mengabaikan semua varian pembangunan yang memenuhi ketentuan yang Anda tetapkan, dan mereka tak lagi terlihat di menu tarik turun ketika mengeklik Build > Select Build Variant dari bilah menu (atau mengeklik Build Variants di bilah jendela alat bantu).

Membuat Set Sumber

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

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

Plugin Android untuk Gradle menyediakan tugas Gradle berdaya guna yang akan menunjukkan cara mengatur file Anda untuk setiap tipe pembangunan, ragam produk, dan varian pembangunan. Misalnya, bagian laporan berikut menjelaskan di mana Gradle berharap untuk menemukan file tertentu bagi tipe pembangunan versi "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 menghasilkan dan menampilkan laporan ini untuk konfigurasi pembangunan Anda, lakukan hal berikut:

  1. Klik Gradle di sisi kanan jendela IDE.
  2. Arahkan ke MyApplication > Tasks > android dan klik-ganda sourceSets.
  3. Untuk menampilkan laporan, klik Gradle Console di bagian bawah jendela IDE.

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

Ketika membuat varian pembangunan baru, Android Studio tidak membuat direktori set sumber bagi Anda, namun itu memberikan beberapa opsi untuk membantu Anda. Misalnya, untuk hanya membuat direktori java/ bagi tipe pembangunan versi "debug”:

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

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

  1. Di panel Project, 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 tarik-turun di sebelah Target Source Set, pilih debug.
  4. Klik Finish.

Karena tipe pembangunan versi "debug" 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 pembangunan versi debug.

Dengan menggunakan prosedur yang sama, Anda juga bisa membuat direktori set sumber untuk ragam produk, seperti src/demo/, dan varian pembangunan, seperti src/demoDebug/. Selain itu, Anda bisa membuat pengujian set sumber yang menargetkan varian pembangunan tertentu, seperti src/androidTestDemoDebug/. Untuk mengetahui selengkapnya, kunjungi Pengujian set sumber.

Mengubah konfigurasi set sumber default

Jika Anda memiliki sumber yang tidak dikelola dalam struktur file set sumber default yang diharapkan Gradle, seperti yang dijelaskan di atas pada 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 jalurnya ke Gradle, relatif terhadap file build.gradle level-modul, tempat seharusnya Gradle menemukan file untuk masing-masing komponen set sumber. Untuk mengetahui komponen mana yang bisa dikonfigurasi, dan apakah Anda bisa memetakannya ke beberapa file atau direktori, silakan baca referensi DSL plugin Android untuk 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'
      ...
    }
  }
}
...

Membangun dengan set sumber

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

  1. src/demoDebug/ (set sumber varian pembangunan)
  2. src/debug/ (set sumber tipe pembangunan)
  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 mendaftar dimensi ragam dengan properti android.flavorDimensions, ragam produk yang termasuk dalam dimensi ragam pertama yang Anda daftarkan 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 individu.

Urutan yang tercantum di atas menentukan set sumber yang memiliki prioritas lebih tinggi ketika Gradle menggabungkan kode dan sumber daya. Karena direktori set sumber demoDebug/ kemungkinan besar berisi file khusus untuk varian pembangunan tersebut, jika demoDebug/ menyertakan file yang juga didefinisikan dalam debug/, Gradle menggunakan file dalam set sumber demoDebug/. Demikian pula, Gradle memberikan file dalam tipe pembangunan dan set sumber ragam produk prioritas yang lebih tinggi daripada file yang sama dalam main/. Gradle mempertimbangkan urutan prioritas ini ketika menerapkan aturan pembangunan berikut:

Mendeklarasikan Dependensi

Contoh berikut mendeklarasikan tiga tipe dependensi langsung yang berbeda dalam file app/ modul build.gradle:

android {...}
...
dependencies {
    // The 'compile' configuration tells Gradle to add the dependency to the
    // compilation classpath and include it in the final package.

    // Dependency on the "mylibrary" module from this project
    compile project(":mylibrary")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:27.0.0'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

Masing-masing dependensi langsung tersebut dijelaskan di bawah ini.

Dependensi Modul
Baris compile project(':mylibrary') mendeklarasikan modul pustaka Android lokal bernama "mylibrary" sebagai dependensi, dan mengharuskan sistem pembangunan untuk mengompilasi dan memasukkan modul lokal ketika membuat aplikasi Anda.
Dependensi biner jarak jauh
Baris compile 'com.android.support:appcompat-v7:27.0.0' mendeklarasikan dependensi pada versi 27.0.0 dari Pustaka Dukungan Android dengan menentukan koordinat JCenter-nya. Secara default, Android Studio mengonfigurasi proyek untuk menggunakan Repositori JCenter di file build tingkat-atas. Gradle secara otomatis menarik dependensi dari JCenter saat Anda menyinkronkan proyek Anda dengan file konfigurasi pembangunan. Atau, Anda bisa mengunduh dan memasang dependensi tertentu dengan menggunakan SDK Manager.
Dependensi biner lokal
Baris compile fileTree(dir: 'libs', include: ['*.jar']) memerintahkan sistem pembangunan untuk menyertakan semua file JAR di direktori app/libs/ dalam classpath kompilasi dan paket final aplikasi Anda. Jika Anda memiliki modul yang membutuhkan dependensi biner lokal, salin file JAR untuk dependensi ini ke <moduleName>/libs dalam proyek Anda.

Beberapa dependensi langsung dari modul mungkin memiliki dependensi sendiri, yang disebut dependensi transitif modul. Daripada secara manual mendeklarasikan setiap dependensi transitif, Gradle secara otomatis mengumpulkan dan menambahkannya untuk Anda. Plugin Android untuk Gradle menyediakan tugas Gradle berguna yang bisa menghasilkan pohon dependensi untuk setiap varian pembangunan dan set sumber pengujian, sehingga Anda dapat dengan mudah memvisualisasikan dependensi langsung dan transitif dari modul Anda. Untuk menghasilkan laporan ini, ikuti prosedur berikut:

  1. Klik Gradle di sisi kanan jendela IDE.
  2. Arahkan ke MyApplication > Tasks > android dan klik-ganda androidDependencies.
  3. Untuk menampilkan laporan, klik Gradle Console di bagian bawah jendela IDE.

Laporan contoh berikut menunjukkan pohon dependensi untuk varian versi debug, dan menyertakan dependensi modul lokal dan dependensi jarak jauh dari contoh sebelumnya.

Executing tasks: [androidDependencies]
:app:androidDependencies
debug
/**
 * Both the library module dependency and remote binary dependency are listed
 * with their transitive dependencies.
 */
+--- MyApp:mylibrary:unspecified
|    \--- com.android.support:appcompat-v7:27.0.0
|         +--- com.android.support:animated-vector-drawable:27.0.0
|         |    \--- com.android.support:support-vector-drawable:27.0.0
|         |         \--- com.android.support:support-v4:27.0.0
|         |              \--- LOCAL: internal_impl-27.0.0.jar
|         +--- com.android.support:support-v4:27.0.0
|         |    \--- LOCAL: internal_impl-27.0.0.jar
|         \--- com.android.support:support-vector-drawable:27.0.0
|              \--- com.android.support:support-v4:27.0.0
|                   \--- LOCAL: internal_impl-27.0.0.jar
\--- com.android.support:appcompat-v7:27.0.0
     +--- com.android.support:animated-vector-drawable:27.0.0
     |    \--- com.android.support:support-vector-drawable:27.0.0
     |         \--- com.android.support:support-v4:27.0.0
     |              \--- LOCAL: internal_impl-27.0.0.jar
     +--- com.android.support:support-v4:27.0.0
     |    \--- LOCAL: internal_impl-27.0.0.jar
     \--- com.android.support:support-vector-drawable:27.0.0
          \--- com.android.support:support-v4:27.0.0
               \--- LOCAL: internal_impl-27.0.0.jar
...

Untuk informasi selengkapnya tentang mengelola dependensi dalam Gradle, silakan lihat Dependency Management Basics di Panduan Pengguna Gradle.

Mengonfigurasi dependensi

Anda bisa menggunakan kata kunci konfigurasi tertentu untuk memberi tahu Gradle bagaimana dan kapan harus menggunakan dependensi, seperti kata kunci compile dari contoh sebelumnya. Berikut adalah penjelasan beberapa kata kunci yang bisa Anda gunakan untuk mengonfigurasi dependensi:

compile
Menentukan dependensi waktu kompilasi. Gradle menambahkan dependensi dengan konfigurasi ini untuk classpath dan APK aplikasi Anda. Ini adalah konfigurasi default-nya.
apk
Menentukan dependensi hanya-waktu proses yang perlu dipaket Gradle dengan aplikasi APK Anda. Anda bisa menggunakan konfigurasi ini dengan dependensi biner JAR, namun tidak dengan dependensi modul pustaka atau dependensi biner AAR yang lain.
provided
Menentukan dependensi waktu kompilasi yang tidak dipaket Gradle dengan APK aplikasi Anda. Hal ini akan membantu mengurangi ukuran APK jika dependensi tidak diperlukan saat waktu proses. Anda bisa menggunakan konfigurasi ini dengan dependensi biner JAR, namun tidak dengan dependensi modul pustaka atau dependensi biner AAR yang lain.

Selain itu, Anda bisa mengonfigurasi dependensi untuk varian pembangunan tertentu atau menguji set sumber dengan menerapkan nama varian pembangunan atau menguji set sumber terhadap kata kunci konfigurasi, seperti yang ditunjukkan dalam contoh berikut.

dependencies {
    ...
    // Adds specific library module dependencies as compile time dependencies
    // to the fullRelease and fullDebug build variants.
    fullReleaseCompile project(path: ':library', configuration: 'release')
    fullDebugCompile project(path: ':library', configuration: 'debug')

    // Adds a compile time dependency for local tests.
    testCompile 'junit:junit:4.12'

    // Adds a compile time dependency for the test APK.
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
}

Mengonfigurasi Setelan Penandatanganan

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

Untuk secara manual mengubah konfigurasi penandatanganan bagi tipe pembangunan versi rilis Anda menggunakan konfigurasi pembangunan 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 pribadi menyatakan entitas yang akan diidentifikasi dengan aplikasi, seperti orang atau perusahaan.
  3. Tambahkan konfigurasi penandatanganan ke file build.gradle tingkat-modul:

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

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

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

Untuk memperoleh kata sandi ini dari variabel lingkungan:

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

Agar proses pembangunan meminta kata sandi ini jika Anda memanggil versi dari baris perintah:

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

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

Peringatan: Simpan keystore dan kunci privat Anda di tempat yang aman serta terlindungi, dan pastikan Anda memiliki cadangan yang aman. Jika Anda mempublikasikan aplikasi ke Google Play kemudian kehilangan kunci yang digunakan untuk menandatangani aplikasi, Anda tidak akan bisa mempublikasikan setiap pembaruan ke aplikasi, karena Anda harus selalu menandatangani semua versi aplikasi Anda dengan kunci yang sama.

Menandatangani Aplikasi Android Wear

Saat mempublikasikan aplikasi Android Wear, Anda memaketkan aplikasi yang dapat dikenakan dalam aplikasi perangkat genggam, karena pengguna tidak bisa menjelajahi dan memasang aplikasi secara langsung pada perangkat dapat dikenakan. Kedua aplikasi harus ditandatangani. Untuk informasi selengkapnya mengenai pemaketan dan penandatanganan aplikasi Android Wear, lihat Memaketkan Aplikasi Dapat Dikenakan.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience.
(Sep 2017 survey)