Dukungan multi-APK

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.

Dukungan Multi-APK adalah fitur di Google Play yang memungkinkan Anda memublikasikan berbagai APK untuk aplikasi Anda, yang masing-masing ditargetkan ke konfigurasi perangkat yang berbeda. Setiap APK adalah versi aplikasi yang lengkap dan independen, tetapi memiliki listingan aplikasi yang sama di Google Play dan harus memiliki nama paket yang sama dan ditandatangani dengan kunci rilis yang sama. Fitur ini berguna untuk kasus di mana aplikasi Anda tidak dapat menjangkau semua perangkat yang diinginkan dengan satu APK.

Perangkat Android dapat berbeda dalam beberapa hal dan akan berpengaruh terhadap kesuksesan aplikasi Anda jika membuatnya tersedia untuk perangkat sebanyak mungkin. Aplikasi Android biasanya berjalan di sebagian besar perangkat yang kompatibel dengan satu APK, dengan menyediakan resource alternatif untuk konfigurasi yang berbeda (misalnya, tata letak yang berbeda untuk ukuran layar yang berbeda) dan sistem Android akan memilih resource yang sesuai untuk perangkat pada waktu proses. Namun, dalam beberapa kasus, satu APK tidak dapat mendukung semua konfigurasi perangkat, karena resource alternatif membuat file APK terlalu besar atau tantangan teknis lainnya mencegah satu APK bekerja pada semua perangkat.

Untuk membantu memublikasikan aplikasi Anda untuk perangkat sebanyak mungkin, Google Play membantu Anda memublikasikan multi-APK dalam listingan aplikasi yang sama. Kemudian, Google Play menyediakan setiap APK ke perangkat yang sesuai berdasarkan dukungan konfigurasi yang telah Anda deklarasikan dalam file manifes untuk setiap APK.

Dengan memublikasikan aplikasi dengan multi-APK, Anda dapat:

• Mendukung format kompresi tekstur OpenGL yang berbeda dengan setiap APK.
• Mendukung ukuran dan kepadatan layar yang berbeda dengan setiap APK.
• Mendukung set fitur perangkat yang berbeda dengan setiap APK.
• Mendukung versi platform yang berbeda dengan setiap APK.
• Mendukung arsitektur CPU yang berbeda dengan setiap APK (seperti untuk ARM atau x86, saat aplikasi Anda menggunakan Android NDK).
• Optimalkan aplikasi Anda untuk perangkat entry-level, misalnya yang menjalankan Android (edisi Go).

Saat ini, karakter perangkat ini merupakan satu-satunya yang didukung Google Play untuk memublikasikan multi-APK sebagai aplikasi yang sama.

Catatan: Untuk mempelajari cara menyiapkan dan memublikasikan APK di Google Play, lihat artikel dukungan Menyiapkan & meluncurkan rilis.

Cara kerja multi-APK

Konsep untuk menggunakan multi-APK di Google Play adalah Anda hanya memiliki satu entri di Google Play untuk aplikasi Anda, tetapi perangkat yang berbeda mungkin mendownload APK yang berbeda. Artinya:

• Anda cukup mempertahankan satu set detail produk (screenshot, ikon, deskripsi aplikasi, dll.). Ini juga berarti Anda tidak dapat menagih harga yang berbeda untuk APK yang berbeda.
• Semua pengguna hanya akan melihat satu versi aplikasi Anda di Google Play, sehingga pengguna tidak bingung dengan perbedaan versi yang mungkin telah Anda publikasikan, yaitu “untuk tablet” atau “untuk ponsel”.
• Semua ulasan pengguna diterapkan ke listingan aplikasi yang sama, meskipun pengguna di perangkat yang berbeda mungkin memiliki APK yang berbeda.
• Jika Anda memublikasikan APK yang berbeda untuk versi Android yang berbeda (untuk API level yang berbeda), maka saat perangkat pengguna menerima update sistem yang memenuhi syarat untuk APK lain yang telah Anda publikasikan, Google Play akan mengupdate aplikasi pengguna ke APK yang dirancang untuk versi Android yang lebih tinggi. Semua data sistem yang terkait dengan aplikasi akan dipertahankan (sama seperti update aplikasi umumnya saat menggunakan APK tunggal).

Filter yang didukung

Perangkat yang akan menerima setiap APK ditentukan oleh filter Google Play, yang ditetapkan oleh elemen dalam file manifes masing-masing APK. Namun, Google Play hanya memungkinkan Anda memublikasikan multi-APK jika setiap APK menggunakan filter untuk mendukung variasi karakteristik perangkat berikut:

• Format kompresi tekstur OpenGL

  Hal ini didasarkan pada elemen <supports-gl-texture> file manifes Anda.

  Misalnya, saat mengembangkan game yang menggunakan OpenGL ES, Anda dapat memberikan satu APK untuk perangkat yang mendukung kompresi tekstur ATI dan APK yang terpisah untuk perangkat yang mendukung kompresi PowerVR (di antara banyak hal lainnya).

• Ukuran layar (dan, jika perlu, kepadatan layar)

  Hal ini didasarkan pada elemen <supports-screens> atau <compatible-screens> file manifes Anda. Sebaiknya jangan gunakan kedua elemen tersebut dan hanya gunakan <supports-screens> jika memungkinkan.

  Misalnya, Anda dapat memberikan satu APK yang mendukung layar berukuran kecil dan normal, dan APK lain yang mendukung layar besar dan ekstra besar. Untuk mempelajari lebih lanjut cara membuat APK terpisah berdasarkan ukuran atau kepadatan layar, buka Membuat Multi-APK.

  Pertimbangkan praktik terbaik berikut untuk mendukung semua ukuran layar:

  • Sistem Android memberikan dukungan yang kuat bagi aplikasi untuk mendukung semua konfigurasi layar dengan satu APK. Sebaiknya hindari membuat multi-APK untuk mendukung ukuran layar yang berbeda kecuali benar-benar diperlukan, dan ikuti panduan untuk Mendukung Beberapa Layar sehingga aplikasi Anda cukup fleksibel dan dapat beradaptasi dengan semua konfigurasi layar menggunakan satu APK.
  • Secara default, semua atribut ukuran layar dalam elemen <supports-screens> adalah "benar" jika Anda tidak mendeklarasikan sebaliknya. Namun, karena atribut android:xlargeScreens ditambahkan di Android 2.3 (API level 9), Google Play akan menganggap bahwa atribut tersebut “salah” jika aplikasi Anda tidak menetapkan android:minSdkVersion atau android:targetSdkVersion ke "9" atau lebih tinggi.
  • Anda tidak boleh menggabungkan elemen <supports-screens> dan <compatible-screens> dalam file manifes. Menggunakan keduanya akan meningkatkan peluang terjadinya error karena konflik di antara keduanya. Untuk bantuan dalam menentukan elemen yang akan digunakan, baca Mendistribusikan ke Layar Tertentu. Jika Anda tidak dapat menghindari penggunaan kedua elemen tersebut, ingat bahwa untuk setiap konflik dalam perjanjian antara ukuran yang ditentukan, “salah” akan digunakan.
• Set fitur perangkat

  Set fitur didasarkan pada elemen <uses-feature> file manifes Anda.

  Misalnya, Anda dapat menyediakan satu APK untuk perangkat yang mendukung multisentuh, dan APK lain untuk perangkat yang tidak mendukung multisentuh. Lihat Referensi Fitur untuk mengetahui daftar fitur yang didukung oleh platform.

• Android (edisi Go)

  Untuk menargetkan perangkat yang menjalankan Android (edisi Go), APK harus mendeklarasikan <uses-feature android:name="android.hardware.ram.low" android:required="true">, menargetkan setidaknya API Level 26, dan memiliki kode versi yang lebih tinggi daripada APK edisi non-Go.

• API level

  API level didasarkan pada elemen <uses-sdk> file manifes Anda. Anda dapat menggunakan atribut android:minSdkVersion dan android:maxSdkVersion untuk menentukan dukungan bagi berbagai API level.

  Misalnya, Anda dapat memublikasikan aplikasi dengan satu APK yang mendukung level API 16 - 19 (Android 4.1.x - 4.4.4)—hanya menggunakan API yang tersedia sejak level API 16 atau yang lebih rendah—dan APK lain yang mendukung level API 21 dan atau yang lebih tinggi (Android 5.0+)—menggunakan API yang tersedia sejak level API 21 atau yang lebih rendah. Untuk mempelajari cara membuat APK terpisah yang masing-masing menargetkan rentang API yang berbeda, buka Mengonfigurasi Ragam Produk.

  Jika Anda menggunakan karakteristik ini sebagai faktor untuk membedakan multi-APK, APK yang memiliki nilai android:minSdkVersion yang lebih tinggi harus memiliki nilai android:versionCode yang lebih tinggi. Hal ini juga berlaku jika dua APK tumpang tindih dengan dukungan perangkatnya berdasarkan filter didukung yang berbeda. Hal ini memastikan bahwa saat perangkat menerima update sistem, Google Play dapat menawarkan update kepada pengguna untuk aplikasi Anda (karena update didasarkan pada peningkatan pada kode versi aplikasi). Persyaratan ini dijelaskan lebih lanjut di bagian selanjutnya tentang Aturan multi-APK.

  Sebaiknya hindari penggunaan android:maxSdkVersion secara umum, karena selama Anda mengembangkan aplikasi dengan benar menggunakan API publik, aplikasi akan selalu kompatibel dengan versi Android yang akan datang. Jika Anda ingin memublikasikan APK yang berbeda untuk API level yang lebih tinggi, Anda tetap tidak perlu menentukan versi maksimumnya karena jika android:minSdkVersion adalah "16" dalam satu APK dan "21" di APK lain, perangkat yang mendukung API level 21 atau yang lebih tinggi akan selalu menerima APK kedua (karena kode versinya lebih tinggi, sesuai dengan catatan sebelumnya).



• Arsitektur CPU (ABI)

  Beberapa library native menyediakan paket terpisah untuk arsitektur CPU tertentu, atau Antarmuka Biner Aplikasi (ABI). Daripada mengemas semua library yang tersedia ke dalam satu APK, Anda dapat membuat APK terpisah untuk setiap ABI dan hanya menyertakan library yang diperlukan untuk ABI tersebut. Untuk mempelajari lebih lanjut cara membuat APK terpisah berdasarkan ABI target, buka Membuat Multi-APK .

Elemen manifes lain yang mengaktifkan filter Google Play tetapi tidak tercantum di atas masih berlaku untuk setiap APK seperti biasa. Namun, Google Play tidak mengizinkan Anda memublikasikan APK terpisah berdasarkan variasi karakteristik perangkat tersebut. Jadi, Anda tidak dapat memublikasikan multi-APK jika filter yang tercantum di atas sama untuk setiap APK (tetapi APK berbeda berdasarkan karakteristik lain dalam manifes atau APK). Misalnya, Anda tidak dapat menyediakan APK berbeda yang semata-mata berbeda berdasarkan karakteristik <uses-configuration>-nya.

Aturan multi-APK

Sebelum memublikasikan multi-APK untuk aplikasi, Anda harus memahami aturan berikut:

• Semua APK yang dipublikasikan untuk aplikasi yang sama harus memiliki nama paket yang sama dan ditandatangani dengan kunci sertifikat yang sama.
• Setiap APK harus memiliki kode versi yang berbeda, yang ditentukan oleh atribut android:versionCode.
• Setiap APK tidak boleh sama persis dengan dukungan konfigurasi dari APK lain.

  Artinya, setiap APK harus mendeklarasikan dukungan yang sedikit berbeda setidaknya untuk salah satu filter Google Play yang didukung (tercantum di atas).

  Umumnya, Anda dapat membedakan APK berdasarkan karakteristik tertentu (seperti format kompresi tekstur yang didukung), dan dengan demikian, setiap APK akan mendeklarasikan dukungan untuk perangkat yang berbeda. Namun, Anda dapat memublikasikan multi-APK yang sedikit tumpang tindih dengan dukungannya. Saat dua APK tumpang tindih (keduanya mendukung beberapa konfigurasi perangkat yang sama), perangkat yang berada dalam rentang tumpang tindih tersebut akan menerima APK dengan kode versi yang lebih tinggi (yang ditetapkan oleh android:versionCode).

• Anda tidak dapat mengaktifkan APK baru yang memiliki kode versi lebih rendah daripada APK yang menggantikannya. Misalnya, Anda memiliki APK aktif untuk layar berukuran kecil - normal dengan kode versi 0400, lalu Anda mencoba menggantinya dengan APK untuk ukuran layar yang sama dengan kode versi 0300. Hal ini menghasilkan error, karena pengguna APK sebelumnya tidak akan dapat mengupdate aplikasinya.
• APK yang memerlukan API level yang lebih tinggi harus memiliki kode versi yang lebih tinggi.

  Hal ini hanya berlaku jika: APK berbeda hanya berdasarkan pada API level yang didukung (tidak ada filter didukung lain yang membedakan APK satu sama lain) atau saat APK menggunakan filter lain yang didukung, tetapi terjadi tumpang tindih antara APK dalam filter tersebut.

  Hal ini penting karena perangkat pengguna menerima update aplikasi dari Google Play hanya jika kode versi APK di Google Play lebih tinggi daripada kode versi APK yang saat ini ada di perangkat. Hal ini memastikan bahwa jika perangkat menerima update sistem yang kemudian memenuhi syarat untuk menginstal APK untuk API level yang lebih tinggi, perangkat akan menerima update aplikasi karena meningkatnya kode versi.

  Catatan: Ukuran peningkatan kode versi tidak relevan; hanya perlu lebih besar dalam versi yang mendukung API level yang lebih tinggi.

  Berikut beberapa contohnya:

  • Jika APK yang Anda upload untuk API level 16 dan yang lebih tinggi (Android 4.1.x+) memiliki kode versi 0400, APK untuk API level 21 dan yang lebih tinggi (Android 5.0+) harus 0401 atau lebih besar. Dalam hal ini, API level adalah satu-satunya filter didukung yang digunakan, sehingga kode versi harus meningkat sehubungan dengan dukungan API level untuk setiap APK, agar pengguna mendapatkan update saat menerima update sistem.
  • Jika Anda memiliki satu APK untuk API level 16 (dan di atasnya) dan layar berukuran kecil - besar, serta APK lain untuk API level 21 (dan lebih tinggi) dan layar berukuran besar - ekstra besar, maka kode versi harus meningkat sehubungan dengan API levelnya. Dalam hal ini, filter API level digunakan untuk membedakan setiap APK, begitu juga dengan ukuran layarnya. Karena ukuran layar tumpang tindih (kedua APK mendukung layar besar), kode versi harus tetap berurutan. Hal ini memastikan bahwa perangkat berlayar besar yang menerima update sistem untuk API level 21 akan menerima update untuk APK kedua.
  • Jika Anda memiliki satu APK untuk API level 16 (dan yang lebih tinggi) dan layar berukuran kecil - normal, serta APK lain untuk API level 21 (dan yang lebih tinggi) dan layar berukuran besar - ekstra besar, maka kode versi tidak perlu meningkat sehubungan dengan APi levelnya. Karena tidak terjadi tumpang-tindih dalam filter ukuran layar, tidak ada perangkat yang berpotensi berpindah di antara kedua APK ini, sehingga kode versi tidak perlu ditingkatkan dari API level yang lebih rendah ke API level yang lebih tinggi.
  • Jika Anda memiliki satu APK untuk API level 16 (dan yang lebih tinggi) dan CPU ARMv7, serta APK lain untuk API level 21 (dan yang lebih tinggi) dan CPU ARMv5TE, maka kode versi harus meningkat sehubungan dengan API levelnya. Dalam hal ini, filter API level digunakan untuk membedakan setiap APK, begitu juga dengan arsitektur CPU-nya. Karena APK yang memiliki library ARMv5TE kompatibel dengan perangkat yang memiliki CPU ARMv7, APK dapat tumpang-tindih pada karakteristik ini. Dengan demikian, kode versi untuk APK yang mendukung API level 21 dan yang lebih tinggi haruslah lebih tinggi. Hal ini memastikan bahwa perangkat yang memiliki CPU ARMv7 yang menerima update sistem untuk API level 21 akan menerima update untuk APK kedua yang dirancang untuk API level 21. Namun, karena jenis update ini membuat perangkat ARMv7 menggunakan APK yang tidak sepenuhnya dioptimalkan untuk CPU perangkat tersebut, Anda harus menyediakan APK untuk arsitektur ARMv5TE dan ARMv7 pada masing-masing API levelnya guna mengoptimalkan performa aplikasi di setiap CPU. Catatan: Ini hanya berlaku saat membandingkan APK yang memiliki library ARMv5TE dengan ARMv7, dan tidak berlaku saat membandingkan library native lainnya.

Tidak mematuhi aturan di atas akan menyebabkan error pada Konsol Google Play saat Anda mengaktifkan APK; Anda tidak akan dapat memublikasikan aplikasi hingga error tersebut diatasi.

Ada konflik lain yang mungkin terjadi saat Anda mengaktifkan APK, tetapi hanya akan menyebabkan peringatan, bukan error. Peringatan dapat disebabkan oleh hal berikut:

• Anda memodifikasi APK untuk "mengurangi" dukungan bagi suatu karakteristik perangkat dan tidak memiliki APK lain yang mendukung perangkat di luar rentang yang didukung. Misalnya, jika APK saat ini mendukung layar berukuran kecil dan normal dan Anda mengubahnya menjadi hanya mendukung layar berukuran kecil, Anda telah mengurangi sekumpulan perangkat yang didukung dan beberapa perangkat tidak akan lagi menemukan aplikasi Anda di Google Play. Anda dapat mengatasi hal ini dengan menambahkan APK lain yang mendukung layar berukuran normal agar semua perangkat yang didukung sebelumnya tetap didukung.
• Jika terjadi "tumpang tindih" antara dua APK atau lebih. Misalnya, jika APK mendukung layar berukuran kecil, normal, dan besar, sementara APK lain mendukung layar berukuran besar dan ekstra besar, akan terjadi tumpang tindih, karena kedua APK mendukung layar berukuran besar. Jika Anda tidak menyelesaikan hal ini, perangkat yang memenuhi syarat untuk kedua APK tersebut (perangkat berlayar besar dalam contoh) akan menerima APK mana pun yang memiliki kode versi tertinggi.

  Catatan: Jika Anda membuat APK terpisah untuk arsitektur CPU yang berbeda, perlu diketahui bahwa APK untuk ARMv5TE akan tumpang tindih dengan APK untuk ARMv7. Artinya, APK yang didesain untuk ARMv5TE kompatibel dengan perangkat ARMv7, tetapi tidak berlaku sebaliknya (APK yang hanya memiliki library ARMv7 tidak kompatibel dengan perangkat ARMv5TE).

Saat konflik tersebut terjadi, Anda akan melihat pesan peringatan, tetapi masih dapat memublikasikan aplikasi.

Membuat multi-APK

Setelah memutuskan untuk memublikasikan multi-APK, Anda mungkin perlu membuat project Android terpisah untuk setiap APK yang ingin dipublikasikan, sehingga Anda dapat mengembangkannya secara terpisah. Anda dapat melakukannya cukup dengan menduplikasi project yang ada dan memberinya nama baru. (Atau, Anda dapat menggunakan sistem build yang dapat menghasilkan resource yang berbeda, seperti tekstur, berdasarkan konfigurasi build.)

Tips: Salah satu cara untuk menghindari duplikasi sebagian besar kode aplikasi Anda adalah dengan menggunakan project library. Project library menyimpan kode dan resource yang dibagikan, yang dapat Anda sertakan dalam project aplikasi sebenarnya.

Saat membuat beberapa project untuk aplikasi yang sama, praktik terbaiknya adalah menamai setiap project dengan nama yang menunjukkan pembatasan perangkat yang akan diterapkan pada APK, sehingga Anda dapat mengenalinya dengan mudah. Misalnya, "HelloWorld_21" mungkin adalah nama yang cocok untuk aplikasi yang dirancang untuk API level 21 dan yang lebih tinggi.

Catatan: Semua APK yang Anda publikasikan untuk aplikasi yang sama harus memiliki nama paket yang sama dan ditandatangani dengan kunci sertifikat yang sama. Pastikan Anda juga memahami setiap Aturan untuk multi-APK.

Menetapkan kode versi

Setiap APK untuk aplikasi yang sama harus memiliki kode versi yang unik, yang ditentukan oleh atribut android:versionCode. Anda harus berhati-hati dalam menetapkan kode versi saat memublikasikan multi-APK, karena setiap APK harus berbeda, tetapi dalam beberapa kasus, kode versi harus atau akan ditentukan dalam urutan tertentu, berdasarkan konfigurasi yang didukung oleh masing-masing APK.

Mengurutkan kode versi

APK yang memerlukan API level yang lebih tinggi biasanya harus memiliki kode versi yang lebih tinggi. Misalnya, jika Anda membuat dua APK untuk mendukung API level yang berbeda, APK untuk API level yang lebih tinggi harus memiliki kode versi yang lebih tinggi. Hal ini memastikan bahwa jika perangkat menerima update sistem yang nantinya memenuhi syarat untuk menginstal APK untuk API level yang lebih tinggi, pengguna akan menerima notifikasi untuk mengupdate aplikasi. Untuk informasi selengkapnya tentang bagaimana persyaratan ini berlaku, lihat bagian di atas tentang Aturan multi-APK.

Sebaiknya Anda juga mempertimbangkan bagaimana urutan kode versi dapat memengaruhi APK yang diterima pengguna, baik karena tumpang tindih antara cakupan APK yang berbeda atau perubahan di masa mendatang yang mungkin Anda buat untuk APK.

Misalnya, jika memiliki APK yang berbeda berdasarkan ukuran layarnya, seperti untuk layar berukuran kecil - normal dan untuk layar berukuran besar - ekstra besar, tetapi Anda ingin mengubah APK menjadi untuk layar berukuran kecil dan untuk layar berukuran normal - ekstra besar, maka Anda harus membuat kode versi APK untuk layar berukuran besar - ekstra besar menjadi lebih tinggi. Dengan begitu, perangkat yang memiliki layar berukuran normal akan menerima update yang sesuai saat Anda membuat perubahan, karena kode versinya meningkat dari APK yang ada ke APK baru yang sekarang mendukung perangkat.

Selain itu, saat membuat multi-APK yang berbeda berdasarkan dukungan untuk format kompresi tekstur OpenGL yang berbeda, perlu diketahui bahwa banyak perangkat mendukung beberapa format. Karena perangkat menerima APK yang memiliki kode versi tertinggi, saat terjadi tumpang tindih cakupan antara dua APK, Anda harus mengurutkan kode versi di antara APK agar APK yang memiliki format kompresi yang ditentukan memiliki kode versi tertinggi. Misalnya, Anda mungkin ingin membuat build terpisah untuk aplikasi menggunakan format kompresi PVRTC, ATITC, dan ETC1. Jika Anda memilih format ini dalam urutan ini, maka APK yang menggunakan PVRTC harus memiliki kode versi tertinggi, APK yang menggunakan ATITC memiliki kode versi yang lebih rendah, dan APK yang menggunakan ETC1 memiliki kode versi terendah. Jadi, jika perangkat mendukung PVRTC dan ETC1, perangkat akan menerima APK yang menggunakan PVRTC, karena memiliki kode versi tertinggi.

Jika Google Play Store tidak dapat mengidentifikasi APK yang tepat yang akan diinstal ke perangkat target, sebaiknya buat APK universal yang menyertakan resource untuk semua variasi perangkat berbeda yang ingin Anda dukung. Jika Anda menyediakan APK universal, Anda harus menetapkan versionCode terendah ke APK tersebut. Karena Google Play Store menginstal versi aplikasi Anda yang kompatibel dengan perangkat target dan yang memiliki versionCode tertinggi, menetapkan versionCode yang lebih rendah ke APK universal memastikan bahwa Google Play Store mencoba menginstal salah satu APK Anda yang lain sebelum menggunakan kembali APK universal yang lebih tinggi.

Menggunakan skema kode versi

Agar dapat mengizinkan APK yang berbeda untuk mengupdate kode versinya secara terpisah (misalnya saat Anda memperbaiki bug dalam satu APK saja sehingga tidak perlu mengupdate semua APK), gunakan sebuah skema bagi kode versi Anda yang memberikan ruang yang cukup di antara masing-masing APK sehingga Anda dapat meningkatkan kode dalam salah satunya tanpa perlu meningkatkan yang lain. Anda juga harus menyertakan nama versi yang sebenarnya dalam kode tersebut (yaitu, versi yang terlihat oleh pengguna yang ditetapkan ke android:versionName), sehingga Anda dapat mengaitkan kode versi dan nama versinya dengan mudah.

Catatan: Saat meningkatkan kode versi untuk APK, Google Play akan meminta pengguna versi sebelumnya untuk mengupdate aplikasinya. Dengan demikian, untuk menghindari update yang tidak diperlukan, Anda tidak boleh meningkatkan kode versi untuk APK yang sebenarnya tidak menyertakan perubahan.

Sebaiknya gunakan kode versi yang memiliki minimal 7 digit: bilangan bulat yang mewakili konfigurasi didukung adalah untuk bit urutan yang lebih tinggi, dan nama versi (dari android:versionName) adalah untuk bit urutan yang lebih rendah. Misalnya, jika nama versi aplikasi adalah 3.1.0, kode versi untuk APK dengan API level 4 dan APK dengan API level 11 akan menjadi 0400310 dan 1100310. Dua digit pertama adalah untuk API level (4 dan 11,) dua digit di tengah adalah untuk ukuran layar atau format tekstur GL (tidak digunakan dalam contoh ini), dan tiga digit terakhir adalah untuk nama versi aplikasi (3.1.0). Gambar 1 menunjukkan dua contoh yang dipisah berdasarkan versi platform (API Level) dan ukuran layar.

Gambar 1. Skema yang disarankan untuk kode versi Anda, menggunakan dua digit pertama untuk API Level, digit kedua dan ketiga untuk ukuran layar minimum dan maksimum (1 - 4 menunjukkan masing-masing dari empat ukuran) atau untuk menunjukkan format tekstur, dan tiga digit terakhir untuk versi aplikasi.

Skema untuk kode versi ini hanyalah saran tentang cara Anda sebaiknya membuat pola yang dapat diskalakan seiring dengan berkembangnya aplikasi Anda. Secara khusus, skema ini tidak menunjukkan solusi untuk mengidentifikasi format kompresi tekstur yang berbeda. Salah satu opsinya mungkin adalah dengan menentukan tabel Anda sendiri yang menentukan bilangan bulat yang berbeda untuk setiap format kompresi berbeda yang didukung aplikasi Anda (misalnya, 1 untuk ETC1 dan 2 untuk ATITC, dan seterusnya).

Anda dapat menggunakan skema apa pun yang diinginkan, tetapi pertimbangkan dengan cermat bagaimana versi mendatang aplikasi Anda perlu meningkatkan kode versinya dan bagaimana perangkat dapat menerima update saat konfigurasi perangkat berubah (misalnya karena update sistem) atau saat Anda mengubah dukungan konfigurasi untuk satu atau beberapa APK.