Tenggat Aplikasi Android Indonesia Punya Dua Bagian: API 36 Hari Ini, Verifikasi Developer Berikutnya

Tenggat Google Play sudah berlaku, dan ada tenggat kedua yang sangat relevan bagi penerbit aplikasi di Indonesia. Sejak 31 Agustus 2026, aplikasi Android baru dan pembaruan yang dikirim ke Google Play harus menargetkan Android 16, API level 36, atau lebih tinggi. Pada 30 September, aturan verifikasi developer yang berbeda mulai berlaku untuk pemasangan aplikasi dari toko peserta di Indonesia, Brasil, Singapura, dan Thailand.

Bagi bisnis kecil yang memiliki aplikasi Android, dua tanggal ini mudah terbaca sebagai satu kebijakan. Padahal bukan. Yang pertama mengatur cara aplikasi dibangun dan dikirim ke Google Play. Yang kedua mengatur apakah identitas developer dan package aplikasi telah terdaftar untuk distribusi pada perangkat Android tersertifikasi. Tim yang memperlakukannya sebagai satu kotak centang bisa melewatkan hambatan yang berbeda pada masing-masing sistem.

Aturan target API Google Play berlaku mulai 31 Agustus 2026. Untuk aplikasi baru atau pembaruan aplikasi, target yang diperlukan adalah Android 16, API level 36. Pengecualian yang dipublikasikan Google cukup spesifik: pengiriman Wear OS dan Android Automotive OS memerlukan API 35 atau lebih baru; Android TV dan Android XR memerlukan API 34 atau lebih baru.

Dampaknya bagi aplikasi ponsel yang sudah ada lebih halus. Aplikasi yang menargetkan API 34 atau lebih rendah tidak otomatis dihapus dari Play. Namun, setelah tenggat, aplikasi tersebut hanya tersedia bagi pengguna baru pada versi Android yang sama atau lebih lama daripada level targetnya. Artinya, penemuan aplikasi pada ponsel yang lebih baru dapat menyusut meski pengguna lama masih dapat menggunakannya.

Verifikasi developer memiliki pemicu yang berbeda. Google menyatakan bahwa pada 30 September, toko peserta di Indonesia dan tiga negara awal lain harus mensyaratkan pendaftaran untuk aplikasi yang dipasang pada perangkat tersertifikasi dengan Android 7 atau lebih baru. Google Play, Galaxy Store, HONOR App Market, OPPO App Market, Palm Store, V-Appstore, dan Xiaomi GetApps masuk dalam daftar awal tersebut.

Kalender ini penting karena sebuah bisnis dapat lolos satu persyaratan dan gagal pada persyaratan lain. Menaikkan targetSdk tidak mendaftarkan identitas developer. Mendaftarkan package tidak membuat build lama dapat diterima oleh Play.

• 31 Agustus: pengiriman aplikasi dan pembaruan baru ke Play memerlukan API 36 untuk Android standar.
• 30 September: identitas developer dan aplikasi terdaftar menjadi syarat distribusi lewat toko peserta di Indonesia.
• 1 November: Google menyebut perpanjangan tenggat target API mungkin tersedia. Anggap sebagai cadangan, bukan rencana rilis.

targetSdkVersion adalah deklarasi dalam manifest dan konfigurasi build aplikasi Android. Nilai ini memberi tahu Android bahwa aplikasi telah diuji terhadap level platform tertentu. Nilai tersebut berbeda dari minSdkVersion, yang menentukan versi Android tertua tempat aplikasi boleh dipasang.

Perbedaan ini bersifat praktis. Bisnis dapat mempertahankan minSdk yang lebih rendah untuk mendukung perangkat pelanggan yang lebih lama sambil menaikkan targetSdk ke API 36. Pekerjaan utamanya ada pada perubahan perilaku Android yang diterapkan saat aplikasi memilih target lebih baru. Izin, pekerjaan latar belakang, akses penyimpanan, notifikasi, penanganan media, tata letak edge-to-edge, dan pustaka pihak ketiga adalah area yang sering perlu diuji. Dampak persisnya bergantung pada aplikasi, bukan sekadar angka versi.

Panduan migrasi Google mengarahkan tim ke daftar perubahan perilaku Android 13, 14, 15, dan 16. Melompat langsung dari target lama ke 36 boleh dilakukan, tetapi itu mengumpulkan perubahan platform beberapa tahun dalam satu siklus rilis. Karena itu, mengubah satu baris Gradle jarang menjadi seluruh pekerjaan.

Bagi studio web atau perusahaan dengan aplikasi yang sebagian besar membungkus situs, bukan berarti tidak ada yang perlu diuji. Aplikasi WebView tetap bisa mengandalkan kamera, unggah berkas, deep link, notifikasi push, perpindahan ke pembayaran, unduhan, pengalihan masuk akun, dan berbagi. Setiap alur menyentuh Android atau aplikasi terpasang lain pada titik yang dapat memunculkan masalah setelah pembaruan.

Google menjelaskan verifikasi developer sebagai cara mempersulit pelaku berbahaya menyebarkan aplikasi merugikan berulang kali dengan identitas anonim atau berubah-ubah. Kebijakan ini dijadwalkan mulai berlaku di Indonesia pada 30 September 2026, bersamaan dengan Brasil, Singapura, dan Thailand, lalu meluas secara global pada 2027.

Peluncuran ini tidak hanya menyangkut Google Play. Poin tersebut penting untuk bisnis Indonesia yang menggunakan toko produsen, jalur distribusi agensi, atau distribusi langsung. Daftar toko peserta mencakup tujuh toko yang disebut Google, bukan setiap jalur distribusi yang mungkin ada. Google juga menyatakan aplikasi yang belum terdaftar masih dapat dipasang melalui Android Debug Bridge atau alur lanjutan. Namun, keduanya bukan strategi onboarding pelanggan yang baik. Keduanya memerlukan tindakan sadar dari pengguna dan tidak menggantikan kebutuhan untuk merapikan data developer.

Halaman verifikasi developer Google menyatakan Play mendaftarkan 99% aplikasi secara otomatis dan mengarahkan developer Play untuk meninjau status sisanya di Play Console. Developer yang mendistribusikan aplikasi hanya di luar Play diarahkan ke Android Developer Console. Tim perlu memakai konsol yang sesuai dengan model distribusi sebenarnya, bukan menganggap akun Play mencakup setiap package yang dikirim lewat jalur lain.

Pertanyaan operasional yang berguna sederhana: entitas hukum mana yang memiliki signing key, nama package, dan akun toko? Jika jawabannya tersebar pada freelancer lama, email agensi, dan akun pribadi pendiri, verifikasi dapat membuka masalah tata kelola, bukan sekadar masalah teknis.

Sebelum membuka Android Studio, buat inventaris singkat. Isinya harus mencakup setiap nama package, setiap build produksi yang ditandatangani, setiap listing toko, dan setiap akun yang dapat mengirim pembaruan. Sertakan aplikasi yang dibuat bertahun-tahun lalu untuk promosi, acara, atau mitra lalu terlupakan. Aplikasi semacam itu sering masih memakai target lama.

Untuk setiap baris, catat:

• nama package dan nama aplikasi yang tampil;
• pemilik Play Console atau Android Developer Console;
• minSdk, targetSdk, dan compile SDK saat ini;
• penanggung jawab signing key produksi dan prosedur pemulihannya;
• toko serta negara distribusi;
• jalur rilis, tanggal pembaruan terakhir, dan lokasi kode sumber;
• orang yang dapat menyelesaikan verifikasi dan mengirim pembaruan.

Ini bukan administrasi tanpa tujuan. Nama package adalah unit yang dapat diperiksa oleh status API Google, sementara signing key adalah mekanisme kontinuitas yang membuat pembaruan dikenali berasal dari penerbit aplikasi yang sama. Jika tim tidak dapat mengenali keduanya, kepemilikan perlu dibereskan sebelum build diubah.

Tim kecil juga perlu membedakan aplikasi produksi dari build pengujian. Pengujian internal, pengujian tertutup, dan APK yang dibagikan lokal mungkin memiliki audiens berbeda, tetapi build yang dipasang pelanggan tetap bagian dari permukaan kepercayaan bisnis. Jangan biarkan jalur distribusi “sementara” lama menjadi satu-satunya tempat aplikasi terbaru tersedia.

Migrasi yang rapi dimulai dari branch dan build yang dapat diulang. Perbarui compile SDK dan target SDK ke level Android 16 yang didukung, lalu perbarui Android Gradle Plugin, Gradle wrapper, tooling Kotlin, dan dependensi hanya bila kompatibilitas membutuhkannya. Kunci versi yang dipakai untuk rilis agar pembaruan dependensi lain tidak tercampur dalam diagnosis yang sama.

Jalankan aplikasi setidaknya pada satu perangkat atau emulator Android 16 dan pada versi Android tertua yang masih dijanjikan oleh minSdk. Setelah itu, uji perjalanan bisnis, bukan hanya layar beranda. Untuk banyak bisnis kecil, ini berarti pembuatan akun, masuk dan keluar akun, reset kata sandi, pencarian, keranjang, checkout, pengembalian dari pembayaran, status pesanan, tautan kontak, notifikasi, unggah berkas, pilihan kamera atau galeri, pembukaan peta, dan chat dukungan.

Periksa kegagalan seperti pelanggan melihatnya. Apakah penolakan izin membuat pengguna buntu? Apakah tautan balik pembayaran membuka pesanan yang benar? Apakah berbagi invoice melampirkan berkas yang dapat dibaca? Apakah ketukan notifikasi membuka layar yang relevan? Build hijau dan instalasi sukses belum menjawab pertanyaan ini.

Google menyarankan pengujian alur utama, penanganan izin, Doze dan App Standby, peristiwa media, serta berbagi berkas bila relevan. Jadikan daftar itu kerangka awal, lalu tambahkan alur yang menghasilkan pendapatan atau membawa data pelanggan di aplikasi Anda.

Rezim verifikasi baru memberi alasan bagi tim untuk merapikan akses yang semestinya sudah terdokumentasi. Bisnis seharusnya mengendalikan akun Play Console atau Android Developer Console, menggunakan akses berbasis peran alih-alih kata sandi bersama, dan menyimpan catatan aman tentang organisasi serta kontak yang dipakai untuk verifikasi.

Pastikan signing key produksi dapat dipulihkan oleh bisnis. Jika memakai Play App Signing, dokumentasikan hubungan antara upload key dan app-signing key, termasuk orang yang berwenang meminta perubahan. Jika developer eksternal memegang satu-satunya keystore atau faktor pemulihan akun, bisnis memiliki risiko rilis yang akan tetap ada setelah tenggat ini lewat.

Google menyebut Android Developer ID Status API dapat memeriksa apakah nama package telah terdaftar, sedangkan Android Developer Console API mendukung pendaftaran serta pengelolaan nama package dari lingkungan pengembangan. API tersebut dapat membantu pipeline rilis yang lebih besar, tetapi tidak menggantikan peninjauan manusia yang bertanggung jawab. Tugas CI dapat melaporkan status, tetapi tidak dapat memutuskan apakah organisasi terverifikasi, kepemilikan package, dan listing toko sudah benar.

Bagi agensi, catat semuanya dalam paket serah-terima. Klien perlu menerima nama package, pengaturan signing, kepemilikan konsol, URL toko, prosedur rilis, dan status verifikasi saat ini. Menyerahkan informasi tersebut lebih mudah saat proyek aktif daripada ketika muncul minggu kepatuhan yang mendesak.

Perusahaan yang menerbitkan hanya melalui Google Play memiliki jalur lebih sempit dibanding yang juga mendistribusikan lewat toko produsen. Aplikasi yang sama dapat menimbulkan pekerjaan administratif berbeda di tiap kanal. Mulailah dari tautan toko yang aktif, kenali akun penerbit terkait pada setiap toko, lalu tinjau pendaftaran package pada tempat yang diarahkan Google.

Jangan menyimpulkan listing pada satu toko membuktikan pendaftaran atau kepatuhan pada toko lain. Jangan pula menganggap developer yang sudah memverifikasi akun untuk satu bisnis otomatis berwenang untuk klien atau entitas hukum lain. Selaraskan identitas organisasi dengan organisasi yang dilihat pelanggan pada aplikasi, kebijakan privasi, email dukungan, dan listing toko.

Aplikasi privat permanen yang dibatasi untuk pengguna dalam organisasi tertentu adalah pengecualian dalam persyaratan target API Google Play. Rumusannya sempit. Aplikasi yang dibagikan kepada pelanggan, franchisee, reseller, atau komunitas luas tidak sepatutnya begitu saja digolongkan privat. Jika model distribusinya tidak lazim, periksa statusnya pada konsol dan dokumentasi Google yang relevan sebelum mengandalkan pengecualian.

Kebijakan verifikasi September juga punya ruang lingkup: perangkat Android tersertifikasi, toko peserta, dan negara peluncuran awal. Tetap bijak bagi penerbit aplikasi Indonesia untuk bersiap seolah aturan ini penting meski sebagian pengguna berada di tempat lain. Pendekatan yang terpecah akan menambah pekerjaan dukungan ketika pelanggan memasang dari beragam sumber.

Tujuan praktisnya adalah satu rilis terkendali, bukan rangkaian edit panik. Tetapkan satu pemilik rilis, lalu buat daftar kerja terlihat oleh developer, pemilik bisnis, dan petugas dukungan.

• Konfirmasikan setiap nama package aktif beserta kanal distribusinya.
• Periksa target API saat ini dan kebutuhan pembaruan untuk pengiriman Play.
• Tingkatkan, build, dan uji terhadap API 36 bila aturan Play seluler standar berlaku.
• Tinjau perubahan perilaku Android 13 hingga Android 16 yang menyentuh aplikasi.
• Periksa akses konsol, data organisasi, pendaftaran package, dan penguasaan signing key.
• Uji rilis bertahap dengan alur akun, pembayaran, deep link, berkas, dan notifikasi nyata.
• Siapkan keputusan rollback dan pesan dukungan sebelum peluncuran produksi.

Distribusi bertahap berguna karena memberi ruang untuk mengamati crash, kegagalan autentikasi, dan regresi pada perangkat tertentu sebelum semua pengguna menerima build. Namun, ini bukan cara menghindari aturan target API. Build yang dikirim tetap harus memenuhi persyaratan yang berlaku.

Simpan bukti selama proses: commit atau tag yang menghasilkan rilis, versi perangkat uji, status yang dilihat di konsol terkait, nomor build, dan orang yang menyetujui peluncuran. Saat aplikasi dikelola studio kecil, catatan ini menghemat waktu pada perubahan target Android berikutnya dan mengurangi risiko pengetahuan hilang bersama kontraktor.

Tim kecil tidak memerlukan dashboard kepatuhan yang rumit untuk menentukan pekerjaan pertama. Kelompokkan setiap aplikasi ke dalam tiga keadaan. Kelompok pertama adalah aplikasi dengan pemilik aktif, jalur signing yang dapat dipulihkan, listing toko aktif, dan build yang masih tercatat. Aplikasi ini dapat langsung masuk ke pengujian API 36 dan pemeriksaan status. Kelompok kedua memiliki pemilik produk yang jelas, tetapi akses akun belum lengkap, penguasaan signing belum pasti, atau tidak ada catatan build produksi terakhir. Bereskan celah kepemilikan itu sebelum menjadwalkan pembaruan. Kelompok ketiga adalah listing yang ditinggalkan atau package yang tidak dapat didukung siapa pun. Kondisi ini memerlukan keputusan bisnis tentang pemulihan atau penghentian, bukan pura-pura bahwa aplikasi masih dipelihara.

Klasifikasi ini sangat berguna ketika agensi mengelola beberapa aplikasi klien. Urgensi teknis tidak boleh membuat agensi mengirim pembaruan dari akun yang tidak dikuasainya atau membuat pernyataan kebijakan atas nama klien. Tetapkan pemilik bernama untuk setiap keputusan: orang yang mengonfirmasi entitas hukum, orang yang menyetujui perubahan bagi pelanggan, dan orang yang memegang akses rilis. Dalam perusahaan kecil, satu orang dapat memiliki beberapa peran, tetapi perannya perlu jelas.

Ukur kesiapan dengan bukti, bukan optimisme. Rilis siap dikirim bila nama package produksi telah diperiksa, konsol terkait menunjukkan status yang diharapkan, bundle bertanda tangan dapat direproduksi, dan perjalanan pelanggan yang telah ditetapkan lolos pada perangkat terkini. Kotak centang bertuliskan “sudah diuji” kalah berguna dari daftar singkat alur, perangkat, dan hasil. Catatan tersebut membantu pemelihara berikutnya memahami apa yang sungguh-sungguh tercakup.

Tim dukungan juga memerlukan rencana kecil. Perbarui halaman bantuan publik dan kontak dukungan toko bila pelanggan mungkin menemui peringatan instalasi baru, layar izin yang berubah, atau masalah sementara pada rilis bertahap. Minta dukungan mencatat model perangkat, versi Android, versi aplikasi, sumber instalasi, dan tangkapan layar saat laporan masuk. Detail tersebut mengubah keluhan “aplikasi tidak bisa dipasang” yang kabur menjadi masalah yang dapat direproduksi oleh pemilik rilis.

Pengaman praktis terakhir adalah memisahkan persetujuan rilis dari penulisan kode. Developer yang mengubah target dapat menjalankan pengujian, tetapi orang kedua sebaiknya meninjau package toko, version code, catatan rilis, tautan privasi, dan persentase rollout bila kapasitas tim memungkinkan. Pemeriksaan murah ini membantu mencegah unggahan artefak yang keliru atau build yang sebenarnya hanya dimaksudkan untuk pengujian internal.

Jangan lupakan ketergantungan pihak ketiga. Pustaka analitik, pembayaran, autentikasi, peta, push notification, kamera, dan WebView dapat membawa batas kompatibilitasnya sendiri. Buat daftar dependensi yang dipakai dalam build produksi, periksa catatan rilisnya, lalu uji integrasi yang paling penting. Jika layanan pembayaran membuka aplikasi lain atau browser, uji juga kembali ke aplikasi setelah transaksi selesai. Jika aplikasi mengunggah dokumen pelanggan, uji pemilihan berkas dari penyimpanan lokal dan penyedia cloud yang umum digunakan.

Pemeriksaan di perangkat nyata tetap perlu, khususnya bila pelanggan memakai kombinasi merek dan versi Android yang luas. Emulator sangat baik untuk pengujian cepat, tetapi tidak menangkap semua perilaku produsen, koneksi jaringan, mode hemat daya, maupun cara pengguna berpindah antaraplikasi. Pilih sampel yang masuk akal dari perangkat dukungan yang paling sering muncul, kemudian catat hasilnya. Tidak perlu mengejar setiap ponsel di pasar untuk memperoleh manfaat dari pengujian yang terarah.

Terakhir, hindari menggabungkan migrasi kepatuhan dengan perubahan produk besar kecuali memang perlu. Rilis yang sekaligus mengganti desain checkout, sistem login, dan target API akan jauh lebih sulit didiagnosis saat terjadi masalah. Bila bisnis harus membawa fitur baru, pisahkan pengujian serta catatan rilisnya. Tujuannya bukan memperlambat kerja, melainkan memastikan setiap perubahan memiliki penjelasan dan jalur perbaikan yang jelas.

Sebelum menekan tombol kirim, bandingkan detail artefak dengan daftar rilis: nama package, application ID, version code, version name, sertifikat, dan track tujuan. Kesalahan kecil pada salah satu nilai itu dapat membuat build yang benar secara teknis tidak sampai ke audiens yang dimaksud. Simpan salinan ringkasan pemeriksaan bersama keputusan rollout. Ketika notifikasi konsol atau laporan pelanggan muncul beberapa hari kemudian, tim tidak perlu menebak build mana yang sedang dibahas.

Menargetkan API 36 tidak menyatakan aplikasi aman, privat, atau bebas cacat. Ini menyatakan aplikasi mendeklarasikan kompatibilitas dengan level platform tersebut dan memenuhi aturan pengiriman Google Play. Sistem verifikasi developer dimaksudkan menambah akuntabilitas distribusi, tetapi tidak menghapus malware, peniruan identitas, atau rancangan aplikasi yang buruk dengan sendirinya.

Bisnis juga tidak seharusnya berjanji bahwa setiap aplikasi sideload akan diblokir. Materi Google menjelaskan ADB dan alur lanjutan untuk aplikasi belum terdaftar. Pesan yang tepat untuk pelanggan lebih sederhana: pasang aplikasi resmi dari toko yang disebut atau kanal perusahaan terverifikasi, lalu hubungi dukungan jika nama package, nama penerbit, atau perintah instalasi tampak asing.

Ada pula fakta yang tidak dapat ditentukan artikel publik: apakah Google sudah otomatis mendaftarkan aplikasi tertentu, apakah akun konsol tertentu memenuhi syarat perpanjangan, dan perubahan perilaku mana yang akan menyentuh basis kode tertentu. Semua itu perlu diperiksa pada akun dan diuji pada build.

Tindakan segera adalah memisahkan kepemilikan, kepatuhan, dan mutu rilis ke dalam tiga alur kerja pendek. Pertama, daftar aplikasi dan akun. Kedua, bawa build rilis ke target API yang diperlukan dan uji perjalanan pelanggan. Ketiga, pastikan status verifikasi melalui konsol yang benar sebelum tanggal peluncuran Indonesia.

Untuk tim yang meluncurkan aplikasi baru, masukkan kepatuhan API 36 dalam rencana rilis sekarang. Untuk tim yang memelihara aplikasi lama, jangan menunggu permintaan fitur untuk mengetahui aplikasi tidak lagi mudah ditemukan pengguna baru pada perangkat yang lebih baru. Untuk agensi, jadikan pemeriksaan status sebagai butir standar serah-terima klien.

Tenggat terdekat sudah berlaku. Tenggat berikutnya adalah 30 September. Perusahaan yang mengenali nama package, memiliki jalur signing, dan menguji build API 36 nyata akan menangani ini sebagai pekerjaan rilis rutin, bukan keadaan darurat dukungan pelanggan.

Sumber: pengumuman dan panduan verifikasi developer Android Developers; persyaratan target API Google Play Console Help; dokumentasi manifest serta migrasi Android Developers; materi kebijakan Google Play. Diakses 31 Agustus 2026.