Jika Anda memublikasikan aplikasi ke Google Play, sebaiknya build dan upload Android App Bundle. Jika Anda melakukannya, Google Play akan otomatis membuat dan menayangkan APK yang dioptimalkan untuk setiap konfigurasi perangkat pengguna, sehingga mereka hanya mendownload kode dan resource yang diperlukan untuk menjalankan aplikasi Anda. Memublikasikan beberapa APK akan berguna jika Anda tidak memublikasikan aplikasi ke Google Play. Namun, Anda harus mem-build, menandatangani, dan mengelola setiap APK sendiri.
Saat mengembangkan aplikasi Android guna memanfaatkan beberapa APK di Google Play, penting untuk menerapkan beberapa praktik terbaik dari awal, dan mencegah lebih banyak lagi kerumitan yang tidak perlu pada proses pengembangan. Tutorial ini menunjukkan cara membuat beberapa APK aplikasi, yang masing-masing mencakup rentang level API yang agak berbeda. Anda juga akan mendapatkan beberapa alat yang diperlukan untuk mempermudah pemeliharaan codebase multi-APK.
Mengonfirmasi bahwa Anda memerlukan multi-APK
Saat mencoba membuat aplikasi yang berfungsi di beberapa generasi platform Android, Anda tentu ingin agar aplikasi memanfaatkan fitur baru di perangkat baru, tanpa mengorbankan kompatibilitas dengan versi sebelumnya. Mungkin di awal akan tampak seolah-olah dukungan multi-APK adalah solusi terbaik, tetapi ini sering kali tidak sesuai harapan. Bagian Menggunakan APK Tunggal pada panduan developer multi-APK berisi informasi berguna tentang cara menyelesaikannya dengan satu APK, termasuk penggunaan support library kami. Anda juga dapat mempelajari cara menulis kode yang hanya berjalan di level API tertentu dalam satu APK, tanpa menggunakan teknik komputasi yang mahal seperti refleksi dari artikel ini.
Jika Anda dapat mengelolanya, membatasi aplikasi ke satu APK memiliki beberapa keuntungan, termasuk:
- Publikasi dan pengujian lebih mudah
- Hanya ada satu codebase yang harus dikelola
- Aplikasi Anda dapat beradaptasi dengan perubahan konfigurasi perangkat
- Pemulihan aplikasi berfungsi di seluruh perangkat
- Anda tidak perlu khawatir tentang preferensi pasar, perilaku akibat "upgrade" dari satu APK ke APK berikutnya, atau kesesuaian APK dengan tiap kelas perangkatnya
Bagian selanjutnya dari tutorial ini mengasumsikan bahwa Anda telah meneliti topik, mempelajari materi dalam referensi yang ditautkan, dan menentukan bahwa multi-APK adalah jalur yang tepat untuk aplikasi Anda.
Membuat diagram kebutuhan Anda
Mulailah dengan membuat diagram sederhana untuk menentukan dengan cepat berapa banyak APK yang Anda butuhkan, dan rentang API yang dicakup setiap APK. Untuk referensi praktis, halaman Versi Platform di situs Developer Android menyediakan data tentang jumlah relatif perangkat aktif yang menjalankan versi platform Android yang ditentukan. Selain itu, meskipun awalnya terdengar mudah, pelacakan kumpulan level API yang akan ditargetkan oleh APK dapat menjadi cukup sulit, terutama jika akan terjadi beberapa tumpang tindih (sering kali terjadi). Untungnya, tidak sulit membuat diagram kebutuhan Anda secara cepat, mudah, dan memiliki referensi untuk nanti.
Untuk membuat diagram multi-APK, mulailah dengan baris sel yang merepresentasikan berbagai level API platform Android. Tampilkan sel tambahan di bagian akhir untuk merepresentasikan versi Android yang akan datang.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Sekarang warnai diagram sehingga setiap warna merepresentasikan APK. Berikut adalah salah satu contoh cara Anda dapat menerapkan setiap APK ke rentang level API tertentu.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Setelah membuat diagram ini, distribusikan ke tim Anda. Komunikasi tim pada project Anda kini semakin sederhana, karena daripada bertanya "Bagaimana APK untuk level API 3 sampai 6, eh, yang itu, Android 1.x. Bagaimana statusnya?" Anda cukup katakan "Bagaimana status APK Biru?"
Memasukkan semua kode umum dan resource dalam project library
Baik Anda memodifikasi aplikasi Android yang ada atau memulai dari awal, ini adalah hal pertama yang harus Anda lakukan pada codebase, dan sejauh ini merupakan hal yang paling penting. Semua yang masuk ke project library hanya perlu diupdate sekali (pertimbangkan string yang dilokalkan dari segi bahasa, tema warna, bug yang diperbaiki dalam kode bersama), yang mempersingkat waktu pengembangan Anda serta mengurangi kemungkinan terjadinya kesalahan yang dapat dihindari dengan mudah.
Catatan: Meskipun detail penerapan tentang cara membuat dan menyertakan project library berada di luar cakupan tutorial ini, Anda dapat memperoleh informasi selengkapnya dengan membaca Membuat Library Android.
Jika Anda mengonversi aplikasi yang ada untuk menggunakan dukungan multi-APK, periksa codebase untuk setiap file string yang dilokalkan, daftar nilai, warna tema, ikon menu, dan tata letak yang tidak akan berubah di seluruh APK, lalu masukkan semuanya dalam project library. Kode yang tidak akan banyak berubah juga harus dimasukkan ke project library. Anda mungkin perlu memperluas class ini untuk menambahkan satu atau dua metode dari APK ke APK.
Sebaliknya, jika Anda membuat aplikasi dari awal, cobalah sebisa mungkin untuk menulis kode dalam project library terlebih dahulu, lalu pindahkan ke APK individual jika perlu. Cara ini jauh lebih mudah untuk dikelola dalam jangka panjang daripada menambahkannya ke satu library, lalu ke library lain, dan yang lainnya lagi, kemudian beberapa bulan ke depan mencoba mencari tahu apakah blob ini dapat dipindahkan ke bagian library tanpa mengacaukan apa pun.
Membuat project APK baru
Harus ada project Android terpisah untuk setiap APK yang akan Anda rilis. Untuk memudahkan pengaturan, tempatkan project library dan semua project APK terkait dalam folder induk yang sama. Ingat juga bahwa setiap APK harus memiliki nama paket yang sama, meskipun tidak harus membagikan nama paket dengan library. Jika Anda memiliki 3 APK yang mengikuti skema yang dijelaskan sebelumnya, direktori utama Anda mungkin akan terlihat seperti berikut:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
Setelah project dibuat, tambahkan project library sebagai referensi untuk setiap project APK. Jika memungkinkan, tentukan Aktivitas awal Anda dalam project library, lalu perluas Aktivitas tersebut dalam project APK Anda. Dengan memiliki aktivitas awal yang ditentukan dalam project library, Anda dapat menempatkan semua inisialisasi aplikasi di satu tempat, sehingga setiap APK tidak perlu menerapkan ulang tugas "universal" seperti menginisialisasi Analytics, menjalankan pemeriksaan pemberian lisensi, dan prosedur inisialisasi lainnya yang tidak banyak berubah dari APK ke APK.
Menyesuaikan manifes
Saat pengguna mendownload aplikasi yang menggunakan multi-APK melalui Google Play, APK yang tepat untuk digunakan akan dipilih dengan dua aturan sederhana:
- Manifes harus menunjukkan bahwa APK tersebut memenuhi syarat
- Dari APK yang memenuhi syarat, nomor versi tertinggi akan menang
Sebagai contoh, mari lihat beberapa APK yang dijelaskan sebelumnya, dan asumsikan bahwa kita belum menetapkan level API maks untuk APK mana pun. Jika dilihat secara terpisah, kemungkinan rentang setiap APK akan terlihat seperti berikut:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Karena APK dengan minSdkVersion yang lebih tinggi wajib memiliki kode versi yang lebih tinggi, kita tahu bahwa dalam aturan nilai versionCode, merah ≥ hijau ≥ biru. Oleh karena itu, kita dapat secara efektif menciutkan diagram agar terlihat seperti ini:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Sekarang, mari asumsikan bahwa APK Merah memiliki beberapa persyaratan yang tidak dimiliki oleh dua yang lain. Halaman Filter di Google Play pada panduan Developer Android memiliki daftar lengkap kemungkinan penyebabnya. Sebagai contoh, anggaplah warna merah memerlukan kamera depan. Faktanya, tujuan APK merah secara keseluruhan adalah menggabungkan kamera depan dengan fungsi baru yang ditambahkan dalam API 11. Namun, ternyata, tidak semua perangkat API 11 MEMILIKI kamera depan. Mengejutkan!
Untungnya, jika pengguna menjelajahi Google Play dari salah satu perangkat tersebut, Google Play akan melihat manifes tersebut, melihat bahwa Merah mencantumkan kamera depan sebagai persyaratan, dan diam-diam mengabaikannya, yang kemudian menentukan bahwa Merah dan perangkat tersebut tidak berjodoh di dunia digital. Kemudian akan terlihat bahwa Hijau tidak hanya kompatibel dengan versi setelahnya pada perangkat dengan API 11 (karena tidak ada maxSdkVersion yang ditetapkan), tetapi juga tidak peduli apakah ada kamera depan atau tidak. Aplikasi masih dapat didownload dari Google Play oleh pengguna, karena meskipun terjadi hal tak terduga dengan kamera depan, masih ada APK yang mendukung level API tersebut.
Untuk menyimpan semua APK di "jalur" yang terpisah, penting untuk memiliki skema kode versi yang baik. Fitur yang direkomendasikan dapat ditemukan di area Kode Versi dalam panduan developer kami. Karena contoh kumpulan APK hanya menangani salah satu dari 3 kemungkinan dimensi, cukup pisahkan setiap APK dengan 1.000, tetapkan beberapa digit pertama ke minSdkVersion untuk APK tertentu, dan tingkatkan mulai dari angka tersebut. Ini mungkin terlihat seperti:
Biru: 03001, 03002, 03003, 03004...
Hijau: 07001, 07002, 07003, 07004...
Merah:11001, 11002, 11003, 11004...
Dengan menyatukan semuanya, Manifes Android Anda mungkin akan terlihat seperti berikut:
Biru:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="03001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> ...
Hijau:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="07001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="7" /> ...
Merah:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="11001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> ...
Meninjau checklist pra-peluncuran Anda
Sebelum mengupload ke Google Play, periksa kembali item berikut. Ingat bahwa hal ini secara khusus relevan dengan multi-APK, dan sama sekali tidak merepresentasikan checklist lengkap untuk semua aplikasi yang diupload ke Google Play.
- Semua APK harus memiliki nama paket yang sama
- Semua APK harus ditandatangani dengan sertifikat yang sama
- Jika APK tumpang tindih dalam versi platform, APK dengan minSdkVersion yang lebih tinggi harus memiliki kode versi yang lebih tinggi
- Periksa kembali filter manifes Anda untuk informasi yang konflik (APK yang hanya mendukung cupcake di layar XLARGE tidak akan dilihat oleh siapa pun)
- Setiap manifes APK harus unik di setidaknya satu dari layar, tekstur OpenGL, atau versi platform yang didukung
- Coba uji setiap APK pada setidaknya satu perangkat. Jika tidak, Anda juga memiliki salah satu emulator perangkat yang paling dapat disesuaikan dalam bisnis yang ada di mesin pengembangan Anda. Cobalah!
Sebaiknya periksa juga APK yang telah dikompilasi sebelum meluncurkannya ke pasar, untuk memastikan tidak ada hal tak terduga yang dapat menyembunyikan aplikasi Anda di Google Play. Penggunaan alat "aapt" sebenarnya cukup sederhana. Aapt (Android Asset Packaging Tool) adalah bagian dari proses build untuk membuat dan memaketkan aplikasi Android Anda, dan juga merupakan alat yang sangat berguna untuk memeriksanya.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Saat memeriksa output aapt, pastikan Anda tidak memiliki nilai yang bertentangan untuk supports-screens dan compatible-screens, dan Anda tidak memiliki nilai "uses-feature" yang tidak diinginkan yang ditambahkan sebagai hasil dari izin yang Anda tetapkan dalam manifes. Pada contoh di atas, APK tidak akan terlihat oleh banyak perangkat.
Mengapa? Dengan menambahkan izin yang diperlukan SEND_SMS, persyaratan fitur android.hardware.telephony ditambahkan secara implisit. Karena API 11 adalah Honeycomb (versi Android yang dioptimalkan khusus untuk tablet), dan tidak ada perangkat Honeycomb yang memiliki hardware ponsel di dalamnya, Google Play akan memfilter APK dalam semua kasus, hingga perangkat di masa mendatang hadir dengan level API lebih tinggi dan disertai dengan hardware ponsel.
Untungnya, hal ini dapat diperbaiki dengan menambahkan kode berikut ke manifes:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Persyaratan android.hardware.touchscreen juga ditambahkan secara implisit. Jika ingin APK terlihat di TV yang bukan merupakan perangkat layar sentuh, Anda harus menambahkan kode berikut ke manifes:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Setelah Anda melengkapi checklist pra-peluncuran, upload APK ke Google Play. Mungkin diperlukan beberapa saat agar aplikasi muncul saat menjelajahi Google Play. Namun saat aplikasi muncul, lakukan satu pemeriksaan terakhir. Download aplikasi ke perangkat uji apa pun yang mungkin Anda miliki untuk memastikan bahwa APK menargetkan perangkat yang dituju. Selamat, Anda sudah selesai!