Jika Anda memublikasikan aplikasi ke Google Play, sebaiknya bangun dan upload Android App Bundle. Setelah Anda melakukannya, Google Play akan otomatis membuat dan menayangkan APK yang dioptimalkan untuk setiap konfigurasi perangkat pengguna, sehingga pengguna hanya mendownload kode dan resource yang diperlukan untuk menjalankan aplikasi Anda. Memublikasikan multi-APK akan berguna jika Anda tidak memublikasikan aplikasi ke Google Play. Namun, Anda harus membuat, menandatangani, dan mengelola setiap APK sendiri.
Saat mengembangkan aplikasi Android untuk memanfaatkan multi-APK di Google Play, Anda harus menerapkan beberapa praktik baik dari awal, dan mencegah sakit kepala yang tidak perlu terjadi. lebih jauh ke dalam proses pengembangan. Pelajaran ini menunjukkan cara membuat multi-APK APK masing-masing meliputi kelas ukuran layar yang berbeda. Anda juga akan mendapatkan beberapa alat yang diperlukan untuk membuat pemeliharaan codebase multi-APK semudah mungkin.
Mengonfirmasi bahwa Anda memerlukan multi-APK
Saat mencoba membuat aplikasi yang berfungsi di berbagai perangkat Android yang tersedia, perangkat Anda, tentu Anda ingin aplikasi Anda terlihat sebaik mungkin di setiap perangkat. Anda ingin memanfaatkan ruang layar besar tetapi tetap bekerja di layar kecil, untuk menggunakan Android API baru fitur atau tekstur visual yang tersedia di perangkat canggih tetapi tidak meninggalkan yang lebih lama. Mungkin tampak di awal seolah-olah dukungan multi-APK adalah solusi terbaik, namun ini sering kali bukan ini masalahnya atau bukan. Halaman Penggunaan Bagian APK Tunggal pada panduan multi-APK berisi beberapa informasi berguna tentang cara menyelesaikan semua ini dengan satu APK, termasuk penggunaan support library kami, dan tautan ke sumber daya di seluruh panduan Developer Android.
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 pelajaran ini mengasumsikan bahwa Anda telah meneliti topik tersebut, mempelajari topik tersebut dengan cermat dan dalam resource yang ditautkan, dan menentukan bahwa multi-APK adalah jalur yang tepat untuk aplikasi.
Membuat diagram kebutuhan Anda
Mulailah dengan membuat bagan sederhana untuk menentukan dengan cepat berapa banyak APK yang Anda butuhkan, dan layar apa ukuran yang dicakup oleh setiap APK. Untungnya, tidak sulit membuat diagram kebutuhan Anda dengan cepat, mudah, dan memiliki referensi mudah untuk nanti. Misalkan Anda ingin membagi APK menjadi dua dimensi, yaitu API dan ukuran layar. Buat tabel dengan baris dan kolom untuk setiap kemungkinan pasangan nilai, dan warna dalam beberapa "blob", setiap warna mewakili satu APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| small | |||||||||||
| normal | |||||||||||
| large | |||||||||||
| xlarge |
Di atas adalah contoh dengan empat APK. Biru untuk semua perangkat layar small/normal, Hijau untuk perangkat layar large, dan Merah untuk perangkat layar xlarge, semuanya dengan rentang API 3-10. Ungu adalah kasus khusus, seperti untuk semua ukuran layar, tetapi hanya untuk API 11 dan yang lebih baru. Lebih penting lagi, hanya dengan melihat bagan ini, Anda akan langsung mengetahui APK mana yang mencakup kombo API/ukuran layar tertentu. Kepada {i>booting<i}, Anda juga memiliki namakode yang keren untuk masing-masing, karena "Sudahkah kita menguji warna merah pada ?" sangat banyak lebih mudah ditanyakan kepada cubie daripada "Sudahkah kita menguji APK 3-ke-10 xlarge terhadap Xoom?" Cetak ini membuat diagram dan memberikannya kepada setiap orang yang mengerjakan codebase Anda. Semua jadi jauh lebih mudah.
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 proyek perpustakaan hanya perlu diperbarui sekali (pikirkan string yang dilokalkan tema warna, bug yang diperbaiki dalam kode bersama), yang mempercepat waktu pengembangan dan mengurangi kemungkinan kesalahan yang dapat dengan mudah dihindari.
Catatan: Meskipun detail penerapan terkait cara membuat dan menyertakan proyek perpustakaan berada di luar cakupan pelajaran ini, Anda bisa mendapatkan dengan membaca Membuat Library Android.
Jika Anda mengonversi aplikasi yang sudah ada untuk menggunakan dukungan multi-APK, jelajahi codebase Anda untuk setiap file string, daftar nilai, dan tema yang dilokalkan warna, ikon menu, dan tata letak yang tidak akan berubah di APK, serta semuanya dalam proyek perpustakaan. Kode yang tidak akan banyak berubah seharusnya juga masuk ke proyek perpustakaan. Anda mungkin akan memperluasnya untuk menambahkan satu atau dua metode dari APK ke APK.
Di sisi lain, jika Anda membuat aplikasi dari awal, coba sebanyak mungkin untuk menulis kode dalam project library terlebih dahulu, lalu memindahkannya ke bawah saja ke APK individual jika diperlukan. Ini jauh lebih mudah untuk dikelola dalam jangka panjang dibandingkan menambahkannya, lalu yang lain, lalu lagi, kemudian berbulan-bulan kemudian mencoba mencari tahu apakah blob ini dapat dipindahkan ke atas ke bagian perpustakaan tanpa mengacaukan apa pun.
Membuat project APK baru
Harus ada project Android terpisah untuk setiap APK yang akan Anda rilis. Untuk kemudahan organisasi, 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 belum tentu perlu membagikan nama paket dengan perpustakaan. Jika Anda memiliki 3 APK dengan mengikuti skema yang dijelaskan sebelumnya, direktori {i> root <i}Anda mungkin terlihat seperti ini:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
Setelah project dibuat, tambahkan project library sebagai referensi untuk setiap project APK. Jika memungkinkan, tentukan Aktivitas awal dalam project library, dan perluas Aktivitas tersebut dalam APK Anda proyek. Memiliki aktivitas awal yang ditentukan dalam project library memberi Anda kesempatan untuk melakukan inisialisasi aplikasi di satu tempat, sehingga setiap APK tidak perlu menerapkan kembali "universal" seperti menginisialisasi Analytics, menjalankan pemeriksaan pemberian lisensi, prosedur inisialisasi yang tidak banyak berubah dari APK ke APK.
Menyesuaikan manifes
Ketika pengguna mengunduh aplikasi yang menggunakan multi-APK melalui Google Play, APK yang akan digunakan 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 kita lihat beberapa APK yang dijelaskan sebelumnya, dan asumsikan bahwa setiap APK telah ditetapkan untuk mendukung semua ukuran layar yang lebih besar dari "target"-nya ukuran layar. Mari kita lihat diagram contoh yang sudah kita bahas sebelumnya:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| small | |||||||||||
| normal | |||||||||||
| large | |||||||||||
| xlarge |
Karena cakupan boleh tumpang-tindih, kita dapat mendeskripsikan area yang dicakup oleh setiap APK seperti jadi:
- Biru mencakup semua layar, minSDK 3.
- Hijau mencakup layar Large dan yang lebih tinggi, minSDK 3.
- Merah mencakup layar XLarge (umumnya tablet), minSDK 9.
- Ungu mencakup semua layar, minSDK 11.
Perhatikan bahwa ada banyak yang tumpang tindih dalam aturan tersebut. Misalnya, perangkat XLarge dengan API 11 mungkin dapat menjalankan salah satu dari 4 APK yang ditentukan. Namun, dengan menggunakan aturan "nomor versi tertinggi yang menang", kita dapat menetapkan urutan preferensi sebagai berikut:
Ungu ≥ Merah ≥ Hijau ≥ Biru
Mengapa mengizinkan semua tumpang tindih? Anggap saja APK Ungu memiliki beberapa persyaratan bahwa dua lainnya tidak. Halaman Filter di Google Play pada panduan Developer Android memiliki daftar lengkap kemungkinan penyebabnya. Sebagai contoh, anggaplah bahwa Ungu memerlukan kamera depan. Faktanya, tujuan Ungu adalah untuk gunakan kamera depan sebagai hal yang menghibur! 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 melihat bahwa Ungu mencantumkan kamera depan sebagai persyaratan, dan diam-diam mengabaikannya, setelah memutuskan bahwa Purple dan perangkat itu bukanlah jodoh di dunia digital. {i>Router<i} kemudian akan lihat bahwa Merah tidak hanya kompatibel dengan perangkat xlarge, tetapi juga tidak peduli apakah terdapat kamera depan! Aplikasi masih dapat diunduh dari Google Play oleh pengguna, karena meskipun terjadi kesalahan dengan kamera depan, masih ada APK yang mendukung level API.
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. Ada baiknya membaca seluruh bagian, tetapi intinya adalah untuk APK, kami akan menggunakan dua digit untuk mewakili minSDK, dua digit untuk mewakili ukuran layar min/maks, dan 3 digit untuk merepresentasikan nomor build. Dengan begitu, ketika perangkat diupgrade ke versi baru Android, (misalnya, dari 10 hingga 11), setiap APK yang kini memenuhi syarat dan lebih diutamakan daripada yang diinstal saat ini akan dilihat oleh perangkat sebagai "upgrade". Skema nomor versi, jika diterapkan ke kumpulan contoh APK, mungkin terlihat seperti:
Biru: 0304001, 0304002, 0304003...
Hijau: 0334001, 0334002, 0334003
Merah: 0344001, 0344002, 0344003...
Ungu: 1104001, 1104002, 1104003...
Dengan menyatukan semuanya, Manifes Android Anda mungkin akan terlihat seperti berikut ini:
Biru:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Hijau:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Merah:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Ungu
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Perhatikan bahwa secara teknis, beberapa APK akan berfungsi dengan tag Support-screens, atau tag kompatibel-layar. Supports-screens biasanya lebih disukai, dan umumnya sangat buruk menggunakan keduanya- Hal ini membuat segalanya menjadi sangat rumit, dan meningkatkan peluang untuk kesalahan. Perhatikan juga bahwa alih-alih memanfaatkan nilai default (small dan normal selalu benar, secara default), manifes secara eksplisit menetapkan nilai untuk setiap ukuran layar. Hal ini dapat menghemat membingungkan - Sebagai contoh, manifes dengan SDK target < 9 akan memiliki xlarge otomatis disetel ke salah (false), karena ukuran tersebut belum ada. Jadi, harus jelas!
Meninjau checklist pra-peluncuran Anda
Sebelum mengupload ke Google Play, periksa kembali item berikut. Ingatlah bahwa ini adalah yang 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.
- Setiap ukuran layar yang Anda inginkan agar mendukung APK, tetapkan ke true di manifes. Setiap ukuran layar yang ingin Anda hindari, tetapkan ke false.
- Periksa kembali filter manifes untuk informasi yang bertentangan (APK yang hanya mendukung cupcake di layar XLARGE tidak akan dilihat oleh siapa pun)
- Setiap manifes APK harus unik di setidaknya satu dari layar yang didukung, tekstur OpenGL, atau versi platform.
- Coba uji setiap APK pada setidaknya satu perangkat. Jika tidak, Anda memiliki salah satu cara yang paling emulator perangkat yang 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 kejutan apa pun 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 mengemas 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: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Ketika Anda memeriksa {i>output<i} aapt, pastikan untuk memeriksa bahwa Anda tidak memiliki nilai yang bertentangan untuk Support-screens dan kompatibel-screens, dan bahwa Anda tidak memiliki "uses-feature" yang tidak diinginkan nilai-nilai yang ditambahkan karena izin yang Anda tetapkan dalam manifes. Pada contoh di atas, APK akan terlihat oleh sebagian besar, atau tidak semua perangkat.
Mengapa? Dengan menambahkan izin yang diperlukan SEND_SMS, persyaratan fitur android.hardware.telephony ditambahkan secara implisit. Karena sebagian besar (jika tidak semua) perangkat xlarge adalah tablet tanpa hardware ponsel di dalamnya, Google Play akan memfilter APK dalam kasus ini, hingga perangkat di masa mendatang akan hadir dengan ukuran yang cukup besar untuk dilaporkan sebagai ukuran layar xlarge, dan memiliki 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!