Skip to content

Most visited

Recently visited

navigation

Migrasi ke Android Plugin untuk Gradle 3.0.0

Masalah yang dikenal: Bila Anda memiliki project Android Studio yang menggunakan versi alpha Android plugin 3.0.0 (seperti 3.0.0-alpha9), Anda mungkin akan mendapatkan error berikut saat Anda bermigrasi ke Android plugin 3.0.0-beta4 dan menyinkronkan project Anda: Gradle project refresh failed.

Atasi masalah ini dengan memilih Build > Clean Project dari bilah menu—Anda hanya perlu melakukan aksi ini sekali untuk setiap project. Anda kemudian bisa menyinkronkan file project bersama Gradle dengan mengklik Sync Project dari bilah menu.

Jika Anda ingin memindahkan project ke Android plugin 3.0.0-beta4 atau yang lebih tinggi, baca halaman ini untuk mempelajari cara menerapkan plugin dan versi Gradle tertentu, dan menyesuaikan project Anda dengan beberapa perubahan sela.

Mengupdate versi Gradle

Android plugin baru membutuhkan Gradle versi 4.1-rc-1 atau yang lebih tinggi. Bila Anda membuka project menggunakan Android Studio 3.0 Beta 1 atau yang lebih baru, ikuti petunjuk untuk mengupdate project yang ada secara otomatis ke versi Gradle yang kompatibel.

Untuk mengupdate Gradle secara manual, update URL di gradle-wrapper.properties seperti berikut:

distributionUrl=\
  https\://services.gradle.org/distributions/gradle-4.1-rc-1-all.zip

Menerapkan plugin

Bila Anda membuka project menggunakan Android Studio 3.0 Beta 1 atau yang lebih baru, ikuti petunjuk untuk mengupdate project Anda secara otomatis ke versi Android plugin terbaru. Untuk mengupdate project Anda secara manual, sertakan repo maven dan ubah versi plugin di file build.gradle level-project seperti berikut:

buildscript {
    repositories {
        ...
        // You need to add the following repository to download the
        // new plugin.
        google()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.0-beta4'
    }
}

Menggunakan Dimensi Ragam untuk manajemen dependensi sadar-varian

Plugin 3.0.0 menyertakan mekanisme dependensi baru yang secara otomatis menyesuaikan dengan varian saat memakai library. Ini berarti varian debug aplikasi secara otomatis memakai varian debug library, dan seterusnya. Itu juga bekerja saat menggunakan ragam—sebuah varian redDebug aplikasi akan memakai varian redDebug library. Agar ini bekerja, sekarang plugin memerlukan semua ragam yang menjadi bagian dimensi ragam yang dinamai - bahkan jika Anda hanya ingin menggunakan dimensi tunggal. Jika tidak, Anda akan mendapatkan 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.

Untuk mengatasi error ini, berikan masing-masing ragam ke dimensi yang diberi nama, seperti yang ditunjukkan pada contoh di bawah ini. Karena penyesuaian dependensi sekarang ditangani oleh plugin, Anda harus memberi nama dimensi ragam Anda dengan hati-hati. Misalnya, bila semua modul aplikasi dan library Anda menggunakan dimensi foo, Anda akan memiliki lebih sedikit kontrol daripada ragam yang cocok dengan plugin.

// Specifies a flavor dimension.
flavorDimensions "color"

productFlavors {
     red {
      // Assigns this product flavor to the 'color' flavor dimension.
      // This step is optional if you are using only one dimension.
      dimension "color"
      ...
    }

    blue {
      dimension "color"
      ...
    }
}

Mengatasi error build yang terkait dengan penyesuaian dependensi

Android plugin mencoba menyesuaikan setiap varian aplikasi Anda dengan varian yang sama dari library. Jadi, ketika Anda membuat versi "freeDebug" dari aplikasi Anda, plugin tersebut akan mencoba menyesuaikannya dengan versi "freeDebug" dari dependensi library lokalnya.

Namun, pertimbangkan jika aplikasi Anda mengonfigurasi tipe build yang disebut "staging", tetapi salah satu dependensi library-nya tidak. Saat plugin mencoba membuat versi "staging" aplikasi, ia tidak akan tahu versi library apa yang akan digunakan, dan Anda akan melihat pesan error seperti berikut:

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

Android plugin 3.0.0-beta4 dan yang lebih tinggi menyertakan elemen DSL untuk membantu mengontrol cara plugin harus mengatasi situasi ketika penyesuaian varian langsung antara aplikasi dan dependensi tidak mungkin dilakukan. Tabel di bawah ini membantu Anda menentukan properti DSL mana yang harus digunakan untuk mengatasi error build tertentu yang terkait dengan penyesuaian dependensi sadar-varian.

Penyebab error buildSolusi

Aplikasi Anda menyertakan tipe build yang tidak terdapat pada dependensi library.

Misalnya, aplikasi Anda menyertakan tipe build "staging", namun dependensi hanya menyertakan tipe build "debug" dan "rilis".

Perhatikan bahwa tidak terjadi masalah saat dependensi library menyertakan tipe build yang tidak dimiliki aplikasi Anda. Itu karena plugin tidak pernah meminta tipe build tersebut dari dependensi.

Gunakan matchingFallbacks untuk menentukan kesesuaian alternatif bagi tipe build yang diberikan, seperti yang ditunjukkan di bawah ini:
// In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin should try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

Untuk dimensi ragam tertentu yang ada dalam aplikasi dan dependensi library-nya, aplikasi Anda memuat ragam yang tidak dimiliki library.

Misalnya, aplikasi dan dependensi library Anda memuat dimensi ragam "tier". Namun, dimensi "tier" di aplikasi memuat ragam "free" dan "paid", tetapi dependensi hanya memuat ragam "demo" dan "paid" untuk dimensi yang sama.

Perhatikan bahwa, untuk dimensi ragam tertentu yang ada di aplikasi dan dependensi library, tidak akan terjadi masalah saat library menyertakan ragam produk yang tidak dimiliki aplikasi Anda. Itu karena plugin tidak pernah meminta ragam tersebut dari dependensi.

Gunakan matchingFallbacks untuk menentukan kesesuaian alternatif bagi ragam produk "free" aplikasi, seperti yang ditunjukkan di bawah ini:
// In the app's build.gradle file.
android {
    defaultConfig{
    // Do not configure matchingFallbacks in the defaultConfig block.
    // Instead, you must specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // should try to use when a dependency's matching dimension does
            // not include a "free" flavor. You may specify as many
            // fallbacks as you like, and the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

Sebuah dependensi library memuat dimensi ragam yang tidak dimiliki aplikasi Anda.

Misalnya, dependensi library memuat ragam untuk dimensi "minApi", tetapi aplikasi Anda menyertakan ragam hanya untuk dimensi "tier". Jadi, ketika Anda ingin membangun versi "freeDebug" aplikasi, plugin tidak tahu apakah akan menggunakan versi "minApi23Debug" atau "minApi18Debug" dari dependensi.

Perhatikan bahwa tidak ada masalah ketika aplikasi Anda menyertakan dimensi ragam yang tidak dimiliki oleh dependensi library. Itu karena plugin tersebut sesuai dengan ragam dari dimensi yang ada dalam dependensi. Misalnya, jika dependensi tidak menyertakan dimensi untuk ABI, versi "freeX86Debug" aplikasi Anda hanya akan menggunakan versi "freeDebug" dari dependensi.

Gunakan missingDimensionStrategy dalam blok defaultConfig untuk menentukan ragam default yang harus dipilih plugin dari setiap dimensi yang hilang, seperti yang ditunjukkan pada contoh di bawah ini. Anda juga bisa mengganti pilihan Anda di blok productFlavors, sehingga setiap ragam dapat menentukan strategi penyesuaian yang berbeda untuk dimensi yang hilang.
// In the app's build.gradle file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin should try to use from
    // a given dimension. The following tells the plugin that, when encountering
    // a dependency that includes a "minApi" dimension, it should select the
    // "minApi18" flavor. You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
    // You should specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy 'abi', 'x86', 'arm64'
    }
    flavorDimensions 'tier'
    productFlavors {
        free {
            dimension 'tier'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
        }
        paid {}
    }
}

Migrasi konfigurasi dependensi untuk modul lokal

Bila Anda telah mengonfigurasi dimensi ragam dengan benar untuk memanfaatkan resolusi dependensi sadar-varian, Anda tidak perlu lagi menggunakan konfigurasi khusus-varian, seperti redDebugImplementation, bagi dependensi modul lokal—plugin akan menangani hal ini untuk Anda. Menggunakan konfigurasi khusus-varian bersifat opsional dan tidak merusak build Anda.

Namun, menargetkan varian dependensi modul lokal tertentu (misalnya, menggunakan configuration: 'debug') menyebabkan error build berikut:

Error:Could not resolve all dependencies for configuration
  ':app:prodDebugCompileClasspath'.
Project :app declares a dependency from configuration 'compile'
  to configuration 'debug' which is not declared in the descriptor
  for project :foo.

Sebagai gantinya, Anda harus mengonfigurasi dependensi Anda seperti berikut:

dependencies {
    // This is the old method and no longer works for local
    // library modules:
    // debugCompile project(path: ':foo', configuration: 'debug')
    // releaseCompile project(path: ':foo', configuration: 'release')

    // Instead, simply use the following to take advantage of
    // variant-aware dependency resolution. You can learn more about
    // the 'implementation' configuration in the section about
    // new dependency configurations.
    implementation project(':foo')

    // You can, however, keep using variant-specific configurations when
    // targeting external dependencies. The following line adds 'app-magic'
    // as a dependency to only the 'debug' version of your module.

    debugImplementation 'com.example.android:app-magic:12.3'
}

Catatan: Anda tidak bisa dengan mudah menggunakan mekanisme lama bagi dependensi varian manual lagi, meskipun Gradle API untuk hal itu masih ada. Konfigurasi yang diberikan ke project() DSL sekarang harus sesuai dengan konsumen dalam tipe dan ragam build (serta atribut lainnya). Misalnya, tidak mungkin membuat varian 'debug' agar memakai varian 'rilis' melalui mekanisme ini karena produsen dan konsumen tidak akan cocok. (Dalam kasus ini, nama 'debug' merujuk pada objek konfigurasi yang dipublikasikan yang disebutkan di atas pada bagian Penerbitan Dependensi.) Sekarang setelah kita menerbitkan dua konfigurasi, satu untuk mengompilasi dan satu lagi untuk waktu proses, cara lama memilih satu konfigurasi ini sebenarnya sudah tidak bisa digunakan lagi.

Mengonfigurasi dependensi Wear App

Untuk mendukung resolusi dependensi sadar-varian untuk aplikasi wear yang disematkan, plugin 3.0.0 sekarang menggabungkan semua grafik bersama-sama sebelum menyelesaikannya, sama seperti cara dependensi lainnya ditangani. Pada versi plugin sebelumnya, grafik dependensi <component>WearApp diselesaikan secara terpisah. Jadi, misalnya, Anda bisa melakukan hal seperti berikut, dan varian biru akan menggunakan :wear2 dan semua varian yang lain menggunakan :wear1:

dependencies {
    // This is the old way of configuring Wear App dependencies.
    wearApp project(':wear1')
    blueWearApp project(':wear2')
}

Konfigurasi di atas tidak lagi bekerja dengan plugin baru. Namun, jika modul wearable Anda mengonfigurasi ragam yang sama dengan aplikasi utama, Anda tidak perlu menggunakan konfigurasi <flavor>WearApp. Cukup tetapkan konfigurasi wearApp dan setiap varian dari aplikasi utama akan menggunakan varian yang sesuai dari wearable:

dependencies {
    // If the main app and wearable modules have the same flavors,
    // the following configuration uses automatic dependency matching.
    wearApp  project(':wearable')
}

Bila Anda ingin menetapkan modul Wear App yang berbeda per ragam aplikasi, Anda tetap bisa menggunakan konfigurasi <flavor>WearApp seperti berikut (namun Anda tidak dapat menggabungkannya dengan konfigurasi wearApp):

dependencies {
    redWearApp project(':wear1')
    greenWearApp project(':wear1')
    blueWearApp project(':wear2')
}

Menggunakan konfigurasi dependensi baru

Gradle 3.4 memperkenalkan baru Konfigurasi plugin Library Java baru yang memungkinkan kontrol atas penerbitan untuk mengompilasi dan waktu proses classpath (untuk dependensi antar-modul). Android plugin 3.0.0 pindah ke konfigurasi dependensi baru ini. Untuk memigrasikan project Anda, cukup update dependensi Anda agar menggunakan konfigurasi baru dan bukan yang tidak digunakan lagi, seperti yang dijelaskan dalam tabel di bawah ini.

Konfigurasi baru Konfigurasi yang tidak digunakan lagi Perilaku
implementation compile Dependensi tersedia untuk modul pada waktu kompilasi, dan tersedia untuk konsumen modul hanya pada saat waktu proses. Untuk build multi-project besar, menggunakan implementation sebagai ganti api/compile bisa menyebabkan peningkatan waktu build yang signifikan karena mengurangi jumlah project yang harus dikompilasi ulang oleh sistem build. Sebagian besar modul aplikasi dan pengujian semestinya menggunakan konfigurasi ini.
api compile Dependensi tersedia untuk modul pada waktu kompilasi, dan juga tersedia untuk konsumen modul pada waktu kompilasi dan waktu proses. Konfigurasi ini berperilaku seperti compile (yang sekarang tidak digunakan lagi), dan Anda sebaiknya menggunakannya hanya di modul library. Modul aplikasi sebaiknya menggunakan implementation, kecuali jika Anda ingin mengekspos API-nya ke modul pengujian terpisah.
compileOnly provided Dependensi hanya tersedia untuk modul pada waktu kompilasi, dan tidak tersedia bagi konsumen saat kompilasi atau waktu proses. Konfigurasi ini berperilaku seperti provided (yang sekarang sudah tidak digunakan lagi).
runtimeOnly apk Dependensi tersedia untuk modul dan konsumen hanya pada waktu proses. Konfigurasi ini berperilaku seperti apk (yang sekarang sudah tidak digunakan lagi).

Sama seperti versi stabil Android plugin saat ini, konfigurasi di atas tersedia untuk dependensi spesifik ragam atau tipe build. Misalnya, Anda bisa menggunakan api untuk membuat dependensi agar tersedia untuk semua varian, atau Anda dapat menggunakan redApi agar ia tersedia hanya untuk varian red dari modul.

Catatan: compile, provided, dan apk saat ini masih tersedia Namun, mereka akan dihilangkan dalam rilis utama Android plugin berikutnya.

Publikasi dependensi

Konfigurasi berikut menyimpan dependensi transitif library untuk dikonsumsi oleh konsumennya:

Dahulu ada satu konfigurasi per varian yang disebut: <variant>. Karena sekarang library bisa mengendalikan apa yang konsumen lihat untuk kompilasi, menggunakan konfigurasi implementation dan api yang dijelaskan di bagian sebelumnya, sekarang ada dua konfigurasi, satu untuk kompilasi konsumen, dan satu untuk waktu proses.

Untuk mempelajari lebih lanjut tentang hubungan antara beragam konfigurasi, buka Konfigurasi plugin Java Library.

Migrasi strategi resolusi dependensi khusus

Plugin menggunakan konfigurasi berikut untuk menyelesaikan semua dependensi varian:

Bila Anda masih menggunakan konfigurasi lama, Anda akan mendapatkan error build seperti berikut:

Error:Configuration with old name _debugCompile found.
Use new name debugCompileClasspath instead.

Plugin atau file build yang menyetel strategi resolusi pada konfigurasi yang diselesaikan perlu disesuaikan dengan nama baru. Karena resolusi dependensi yang tertunda, sekarang menetapkan strategi resolusi bisa dilakukan saat menggunakan varian API, seperti yang ditunjukkan pada contoh di bawah ini. (Android plugin sekarang menyertakan getter untuk mengakses objek konfigurasi varian.)

// Previously, you had to apply a custom resolution strategy during the
// configuration phase, rather than in the execution phase. That's
// because, by the time the variant was created and the Variant API was
// called, the dependencies were already resolved. This no longer works, and
// you should use this method only while using an older version of the plugin.
// configurations {
//     _debugCompile
//     _debugApk
// }
// ...
//
// configurations._debugCompile.resolutionStrategy {
//     ...
// }
//
// configurations.all {
//     resolutionStrategy {
//     ...
//     }
// }

// Because the new build model delays dependency resolution, you should
// query and modify the resolution strategy using the Variant API.
android {
    applicationVariants.all { variant ->
        variant.getCompileConfiguration().resolutionStrategy {
            ...
        }
        variant.runtimeConfiguration.resolutionStrategy {
            ...
        }
        variant.getAnnotationProcessorConfiguration().resolutionStrategy {
            ...
        }
    }
}

Catatan: Sekarang plugin baru mencari konfigurasi menggunakan nama lama dan akan gagal bila menemukannya. Jika tidak, ia akan secara diam-diam mengabaikan strategi resolusi khusus. Kami dapat mengubah ini berdasarkan masukan, tetapi kami ingin menemukan cara untuk mempermudah migrasi.

Menggunakan konfigurasi dependensi prosesor anotasi

Pada versi Android plugin untuk Gradle sebelumnya, dependensi pada classpath kompilasi ditambahkan secara otomatis ke classpath prosesor. Artinya, Anda bisa menambahkan prosesor anotasi ke classpath kompilasi dan itu akan bekerja seperti yang diharapkan. Namun, hal ini menyebabkan dampak yang signifikan terhadap kinerja dengan menambahkan sejumlah besar dependensi yang tidak perlu ke processor.

Saat menggunakan plugin baru, prosesor anotasi harus ditambahkan ke prosesor classpath prosesor menggunakan konfigurasi dependensi annotationProcessor, seperti yang ditunjukkan di bawah ini:

dependencies {
    ...
    annotationProcessor 'com.google.dagger:dagger-compiler:<version-number>'
}

Plugin mengasumsikan dependensi adalah prosesor anotasi bila file JAR-nya berisi file berikut: META- INF/services/javax.annotation.processing.Processor. Jika plugin mendeteksi prosesor anotasi pada classpath kompilasi, build akan gagal dan Anda mendapatkan pesan error yang mencantumkan setiap prosesor anotasi prosesor anotasi pada classpath kompilasi. Untuk memperbaiki error, cukup ubah konfigurasi dari dependensi tersebut agar menggunakan annotationProcessor. Jika dependensi mencakup komponen yang juga harus ada di classpath kompilasi, deklarasikan dependensi itu untuk kedua kalinya dan gunakan konfigurasi dependensi compile.

pengguna plugin android-apt: Perubahan perilaku ini sekarang tidak memengaruhi android-apt plugin. Namun, plugin tidak akan kompatibel dengan versi Android plugin untuk Gradle di masa mendatang.

Menonaktifkan pengecekan error

Bila Anda memiliki dependensi pada classpath kompilasi yang menyertakan prosesor anotasi yang tidak dibutuhkan, Anda bisa menonaktifkan pengecekan error dengan menambahkan kode berikut ini ke file build.gradle Anda. Perlu diingat, prosesor anotasi yang Anda tambahkan ke classpath kompilasi masih belum ditambahkan ke classpath prosesor.

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                includeCompileClasspath false
            }
        }
    }
}

Bila Anda mengalami masalah bermigrasi ke strategi resolusi dependensi yang baru, Anda bisa memulihkan perilaku Android plugin 2.3 dengan menyetel includeCompileClasspath true. Namun, memulihkan perilaku ke versi 2.3 tidak disarankan, dan opsi untuk melakukannya akan dihapus dalam update di masa mendatang. Untuk membantu kami meningkatkan kompatibilitas dengan dependensi yang Anda gunakan, mohon laporkan bug.

Menggunakan modul pengujian terpisah

Modul pengujian terpisah sekarang sadar-varian (lihat bagian di atas) ketika menggunakan plugin 3.0.0. Ini berarti penetapan targetVariant tidak lagi diperlukan.

Setiap varian dalam modul pengujian akan mencoba untuk menguji varian yang sesuai pada project target. Secara default, modul pengujian hanya berisi varian debug, namun Anda bisa membuat tipe dan ragam build baru untuk membuat varian baru agar cocok dengan project aplikasi yang diuji. Tugas connectedCheck dibuat untuk setiap varian.

Agar project Test hanya menguji tipe build yang berbeda, dan bukan yang tipe debug, gunakan VariantFilter untuk menonaktifkan varian debug dalam project pengujian, seperti yang ditunjukkan di bawah ini:

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug') {
            variant.setIgnore(true);
        }
    }
}

Bila Anda ingin modul pengujian hanya menargetkan varian ragam aplikasi tertentu, Anda bisa menggunakan properti flavorSelection untuk menargetkan ragam yang ingin diuji. Ini juga mencegah modul pengujian sehingga tidak perlu mengonfigurasi sendiri ragam tersebut.

Jar Lokal Di Library

Sebelumnya, modul library akan menangani dependensi pada JAR lokal dengan cara tidak- standar dan akan mengemasnya dalam AAR mereka. Bahkan dalam build multi-project, konsumen AAR akan melihat file JAR ini dalam versi yang sudah dikemas.

Android plugin 3.0.0 dan yang lebih tinggi menggunakan Gradle API baru untuk memperbolehkan pemakaian project untuk melihat JAR lokal sebagai dependensi transitif biasa, serupa dengan dependensi berdasarkan koordinat maven. Untuk beradaptasi dengan Gradle API baru, plugin harus mengubah beberapa aspek dalam cara menangani file JAR lokal.

Penerbitan antar-project

Penerbitan ke repo Maven

Perubahan API

Android plugin 3.0.0 memperkenalkan perubahan API yang menghapus fungsionalitas tertentu dan mungkin merusak build yang ada. Versi plugin selanjutnya mungkin memperkenalkan API publik baru untuk menggantikan fungsionalitas yang rusak.

Keluaran varian

Menggunakan Variant API untuk memanipulasi keluaran varian yang rusak dengan plugin baru. Ini masih bisa digunakan untuk tugas sederhana, seperti mengubah nama APK selama waktu build, seperti yang ditunjukkan di bawah ini:

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

Namun, tugas lebih rumit yang melibatkan pengaksesan objek outputFile tidak lagi bisa digunakan. Itu karena tugas khusus-varian tidak lagi dibuat selama tahap konfigurasi. Hal ini mengakibatkan plugin tidak bisa langsung mengetahui semua keluarannya, tetapi berarti juga waktu konfigurasi yang lebih cepat.

manifestOutputFile

Metode processManifest.manifestOutputFile() tidak lagi tersedia, dan Anda akan mendapatkan error berikut saat mencoba memanggilnya:

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest'
   of type com.android.build.gradle.tasks.ProcessManifest.

Alih-alih memanggil manifestOutputFile() untuk mendapatkan file manifes bagi setiap varian, Anda bisa memanggil processManifest.manifestOutputDirectory() untuk menampilkan lokasi direktori yang berisi semua manifes yang dihasilkan. Anda kemudian bisa menempatkan manifes dan menerapkan logika ke manifes. Contoh di bawah ini secara dinamis mengubah kode versi dalam manifes:

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}
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!

Ikuti Google Developers di 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. (Dec 2017 Android Platform & Tools Survey)