Tenggat API 36 Google Play: yang berubah pada 31 Agustus 2026

Apa yang berubah pada 1 November 2026

1 November 2026 mengakhiri masa perpanjangan level API target yang dipublikasikan Google. Tanggal itu tidak mengakhiri kemampuan Anda untuk mengirim pembaruan yang memenuhi syarat, dan tidak mengubah apa yang diperlukan aplikasi yang sudah tayang dan tidak diubah. Dua situasi berikut terus-menerus tertukar:

Google Play Console Help tentang persyaratan level API target, dan panduan target SDK di developer.android.com, keduanya dibaca pada 15 Oktober 2026.

Google menaikkan batas bawah level API target di Play Store sekali setahun, dan 2026 adalah siklus API 36. Yang membingungkan bukan angkanya. Yang membingungkan adalah "persyaratan level API target" sebenarnya berisi dua aturan yang memakai satu nama: satu mengatur apa yang boleh Anda unggah, satu lagi yang lebih rendah mengatur siapa yang masih bisa memasang aplikasi yang sudah tayang. Hampir semua halaman yang muncul untuk pertanyaan ini mencampur keduanya, dan dari situlah developer berakhir membangun ulang aplikasi yang sebenarnya tidak perlu dibangun ulang, atau mengabaikan peringatan Konsol Google Play yang justru penting.

Artikel ini memisahkan keduanya, memberi angka per jenis perangkat, lalu menjawab pertanyaan yang benar-benar masuk ke kotak dukungan kami: apa dampaknya bagi aplikasi yang sedang setengah jalan menjalani pengujian tertutup dengan 12 penguji selama 14 hari berturut-turut? PrimeTestLab menangani sisi pengujian itu untuk para developer, jadi kami melihat benturan jadwal ini terus-menerus, dan panduan di bagian tersebut berlaku baik Anda memakai jasa maupun merekrut penguji sendiri. Semua tanggal dan level di bawah ini dicocokkan dengan halaman resmi Google pada 9 Agustus 2026 dan dicocokkan ulang pada 15 Oktober 2026, dan apa pun yang sebenarnya belum didokumentasikan Google diberi label, bukan diisi dengan tebakan yang terdengar meyakinkan.

Aturannya dalam satu kalimat

Sejak 31 Agustus 2026, aplikasi ponsel, tablet, perangkat lipat, atau Android Auto pada umumnya wajib menargetkan Android 16, API level 36 atau lebih tinggi untuk bisa dikirim ke Google Play, baik itu aplikasi yang benar-benar baru maupun pembaruan aplikasi yang sudah tayang. Satu kalimat itu sudah mencakup sebagian besar pembaca. Pengecualiannya, dan ambang lebih rendah yang terpisah untuk aplikasi yang tidak Anda sentuh, adalah isi sisa artikel ini.

Satu nama, dua aturan berbeda

Google memakai istilah "persyaratan level API target" untuk dua hal yang perilakunya sama sekali berbeda. Memisahkan keduanya adalah hal paling berharga yang bisa Anda dapatkan dari halaman ini.

Jadi aplikasi yang diam di API 35 tanpa rencana pembaruan sudah memenuhi syarat pada 31 Agustus menurut aturan 2, dan langsung tidak memenuhi syarat begitu Anda mencoba merilis apa pun menurut aturan 1. Itu bukan pertentangan, melainkan memang rancangannya: Google menaikkan standar untuk yang masuk ke toko lebih cepat daripada standar untuk yang bertahan di dalamnya.

Tiga istilah yang didefinisikan Google dengan tepat

Kebijakan ini bertumpu pada tiga istilah, dan makna masing-masing menentukan Anda berada di bawah aturan yang mana:

• Aplikasi baru: aplikasi yang "belum dipublikasikan di Google Play". Unggahan pertama sebuah nama paket.
• Aplikasi yang sudah ada: aplikasi yang sudah dipublikasikan di Google Play.
• Pembaruan aplikasi: versi baru dari aplikasi yang sudah ada, dikirim untuk ditinjau agar menggantikan versi saat ini. Pembaruan dinilai dengan aturan pengiriman, bukan aturan ketersediaan.

Persyaratan per jenis perangkat

"Aplikasi Android" bukan satu baris saja. Ponsel, tablet, perangkat lipat, dan Android Auto naik ke API 36. Wear OS dan Android Automotive OS berhenti di API 35. Android TV dan Android XR berhenti di API 34. Ambang untuk aplikasi yang tidak Anda perbarui lebih rendah lagi, dan sakelar di bawah ini berpindah di antara kedua kelompok itu.

Android Auto bukan Android Automotive OS

Dua nama ini benar-benar menghabiskan waktu para developer setiap tahun. Android Auto memproyeksikan aplikasi dari ponsel ke layar mobil, jadi aplikasinya adalah aplikasi ponsel dan mengikuti aturan ponsel: API 36. Android Automotive OS adalah sistem operasi yang berjalan di kendaraannya sendiri, dan ia termasuk pengecualian dengan target lebih rendah yang disebut secara eksplisit: API 35. Kalau Anda membuat aplikasi media atau navigasi untuk keduanya, yang Anda butuhkan adalah yang lebih tinggi.

Apakah ini memengaruhi Anda? Jawab tiga pertanyaan

Apakah aturan API target menjadi masalah Anda saat ini bergantung pada tiga hal: apa yang akan Anda lakukan, untuk jenis perangkat apa Anda merilis, dan apa yang sebenarnya ditargetkan build Anda sekarang. Alat di bawah ini menerapkan ambang yang dipublikasikan Google pada kombinasi tersebut dan memberi tahu Anda berada di bawah aturan yang mana dari kedua aturan itu.

Kalau vonisnya menyatakan Anda aman, tetap lihat checklist sebelum tenggat di bagian akhir, karena "kode sumber saya menyetel target 36" dan "artefak yang dinilai Google menyatakan 36" bukan klaim yang sama. Rasa aman palsu yang paling umum di sepanjang siklus ini adalah developer yang membaca berkas Gradle-nya alih-alih bundle yang sudah ia unggah.

Apa yang sebenarnya terjadi kalau Anda melewati 31 Agustus

Dua hal berbeda, tergantung Anda berada di bawah aturan yang mana. Kalau Anda mencoba mengunggah build di bawah ambang, pengirimannya tidak memenuhi persyaratan. Kalau Anda hanya membiarkan aplikasi yang sudah tayang berada di bawah ambang ketersediaan, aplikasinya berhenti bisa ditemukan dan dipasang oleh pengguna baru di perangkat yang menjalankan versi Android lebih baru daripada targetnya. Keduanya bukan penghapusan.

Kalau Anda mencoba mengunggah

Perhatikan pada apa konsekuensi ini menempel: pada tindakan mengunggah. Kalender saja tidak melakukan apa pun terhadap build yang sudah tayang. Karena itulah sebuah aplikasi bisa sepenuhnya memenuhi syarat pada 1 September dan terblokir pada 2 September, murni karena Anda memutuskan merilis perbaikan bug.

Kalau Anda membiarkan aplikasi yang sudah tayang di bawah ambang

Inilah bagian yang oleh pesaing digambarkan sebagai "aplikasi Anda hilang", dan itu keliru dengan cara yang penting. Rumusan Google adalah aplikasinya akan "berhenti bisa ditemukan" oleh sekelompok pengguna tertentu. Konkretnya:

• Pengguna baru di perangkat lebih baru kehilangan akses. Kalau perangkat seorang pengguna menjalankan versi Android lebih tinggi daripada target aplikasi Anda, Google Play tidak lagi menampilkan atau memasangkan aplikasinya untuk mereka.
• Pengguna baru di perangkat lebih lama tidak terpengaruh. Perangkat yang menjalankan API level sama dengan target aplikasi, atau lebih rendah, masih bisa menerimanya.
• Yang sudah memasang tidak terpengaruh. Siapa pun yang sudah memasang aplikasinya tetap bisa menemukan, memasang ulang, dan memakainya di versi Android yang didukung.
• Tautan langsung mengatakan apa adanya. Pengguna di perangkat lebih baru yang tidak memenuhi syarat dan membuka tautan Play Store Anda akan diberi tahu bahwa aplikasinya "dibuat untuk versi Android yang lebih lama".

Yang tidak terjadi

Setiap Agustus kebijakan ini memunculkan empat kekhawatiran yang sama di forum bantuan Google. Tidak satu pun sesuai dengan yang dijelaskan halaman level API target.

Apakah menargetkan API 36 mematikan dukungan untuk ponsel lama?

Tidak, tidak dengan sendirinya. targetSdk menyatakan level perilaku Android yang menjadi acuan pembuatan dan pengujian aplikasi Anda. minSdk menentukan versi Android tertua tempat aplikasi bisa dipasang. Keduanya angka yang terpisah, dan menaikkan target ke 36 tidak dengan sendirinya menaikkan minimum: aplikasi Anda bisa terus mendukung versi Android lama sampai batas minimum itu, selama kode dan dependensi yang diperbarui tetap kompatibel.

Inilah kesalahpahaman yang paling banyak memicu kepanikan di setiap siklus. Seorang developer membaca "harus menargetkan Android 16", mengira artinya "cuma jalan di Android 16", lalu menyimpulkan Google baru saja menghapus sebagian besar perangkat yang bisa ia jangkau. Geser angka minimumnya di bawah ini dan lihat apa yang sebenarnya berubah.

Tiga angka, dan yang mana yang diawasi Google Play

Artinya kalau aplikasi Anda sedang dalam pengujian tertutup

Kalau Anda memakai akun developer pribadi yang baru dan sedang menjalankan pengujian tertutup wajib dengan 12 penguji selama 14 hari berturut-turut, migrasi ini, atau berakhirnya perpanjangan, bisa jatuh di tengah masa itu. Langkah yang aman adalah memasukkan build API 36 ke jalur tertutup yang sama sekarang, menjaga semua penguji tetap ikut serta, dan jangan pernah membiarkan tenggat memaksa Anda berganti jalur atau mengulang dari penguji baru.

Halaman API target Google dan halaman pengujian tertutup Google ditulis oleh tim berbeda untuk tujuan berbeda, dan tidak satu pun membahas yang lain. Itu meninggalkan celah yang nyata, dan hal yang jujur untuk dilakukan adalah menunjukkan persis di mana wilayah yang terdokumentasi berakhir.

Yang terverifikasi

• Akun pribadi baru yang termasuk kriteria harus menjalankan pengujian tertutup dengan minimal 12 penguji yang terus-menerus ikut serta selama 14 hari terakhir sebelum bisa mengajukan permohonan akses produksi. Ini berlaku untuk akun pribadi yang dibuat setelah 13 November 2023. Terverifikasi
• Dokumentasi developer Google menyatakan bahwa APK yang diunggah harus memenuhi persyaratan API target Play, dan tidak mempublikasikan pengecualian apa pun untuk jalur pengujian. Rumusannya berlaku untuk jalur mana pun, bukan khusus pengujian, jadi rencanakan unggahan baru ke jalur tertutup setelah tenggat seolah-olah memerlukan API 36. Ini kesimpulan yang kuat, bukan aturan yang terdokumentasi untuk jalur pengujian. Sebagian
• Panduan Google sendiri menganjurkan developer terus memperbarui aplikasi dalam pengujian tertutup sambil memperbaiki masalah, dan mendefinisikan masa yang dihitung berdasarkan kesinambungan keikutsertaan penguji, bukan berdasarkan satu artefak yang dibekukan. Terverifikasi
• Pengujian internal dibatasi 100 penguji dan tidak menggantikan pengujian tertutup yang memenuhi syarat. Terverifikasi

Yang belum didokumentasikan Google

Karena jawabannya belum diketahui, strategi yang tepat bukan menebaknya. Yang tepat adalah membuat pertanyaan itu tidak relevan, dengan memasukkan build yang memenuhi syarat ke jalur tersebut sekarang. Ini aman untuk kedua kemungkinan hasil dan tidak merugikan Anda seandainya artefak lama toh tetap berjalan.

Urutan yang aman apa pun hasilnya

1. Pertahankan jalur tertutup yang sama dan grup penguji yang sama

   Jangan membuat jalur baru untuk menampung build API 36 dan jangan mengeluarkan penguji yang sudah ikut serta. Kesinambungan 14 hari yang dihitung Google adalah soal penguji yang tetap ikut serta, jadi keikutsertaan itulah aset yang sedang Anda jaga.

2. Perlakukan migrasi API 36 sebagai pekerjaan tersendiri, dengan siklus pengujiannya sendiri

   Jalankan pemeriksaan Android 16 sebelum mengunggah, bukan setelah ditolak. Menemukan tata letak tepi ke tepi yang rusak pada hari Anda harus merilis adalah hari yang sangat berbeda dari menemukannya sepekan sebelumnya.

3. Unggah ke jalur tertutup yang sudah ada dengan versionCode lebih tinggi

   Setiap bundle pengganti memerlukan versionCode yang dinaikkan. Google mendefinisikan masa yang dihitung berdasarkan kesinambungan keikutsertaan penguji dan secara eksplisit menganjurkan developer terus memperbaiki masalah selama pengujian, tetapi Google tidak mempublikasikan jaminan mutlak yang mencakup setiap skenario penggantian build. Pertahankan jalur yang sama dan penguji yang sama, lalu periksa penghitung di Konsol Google Play sesudahnya. Mekanisme lengkap memperbarui di tengah pengujian layak dibaca kalau ini siklus pertama Anda.

4. Pastikan rilisnya benar-benar sampai ke penguji

   Rilis yang dipublikasikan tidak sama dengan rilis yang terkirim. Periksa bahwa rilis tertutupnya aktif, bahwa versionCode-nya lebih tinggi, dan bahwa penguji di daftar keikutsertaan bisa melihat pembaruannya.

5. Periksa ulang status kebijakan setelah pemrosesan

   Beri waktu bundle-nya diproses, lalu buka lagi halaman status kebijakan aplikasi. Kalau peringatan API target masih ada, kerjakan daftar penelusuran masalah alih-alih menghapus rilis secara acak.

6. Ajukan perpanjangan hanya kalau migrasinya benar-benar tidak mungkin selesai tepat waktu

   Masa perpanjangan yang dipublikasikan Google berakhir pada 1 November 2026, dan perpanjangan itu diajukan per aplikasi yang terdampak melalui pemberitahuan milik aplikasi tersebut. Setelah tanggal itu, satu-satunya jalan adalah build yang memenuhi syarat, jadi perpanjangan bukan alasan untuk menghentikan pekerjaan teknisnya.

Cara mengajukan perpanjangan sampai 1 November 2026

Developer yang terdampak dapat mengajukan perpanjangan yang menjaga distribusi tetap berjalan sampai 1 November 2026. Pengajuannya per aplikasi, dimulai dari peringatan kebijakan aplikasi tersebut di Konsol Google Play, yang di dokumentasi berbahasa Indonesia Google disebut Konsol Play. Google tidak menggambarkannya sebagai otomatis, pasti disetujui, atau pembebasan permanen, jadi teruskan migrasi selama pengajuannya masih berjalan.

Konsol Google Play · tangkapan layar asli Klik untuk memperbesar

1. Buka aplikasi yang terdampak di Konsol Google Play

   Akses perpanjangan bersifat per aplikasi, bukan per akun. Kalau Anda memublikasikan beberapa aplikasi, siapkan diri untuk mengulanginya pada tiap aplikasi yang terdampak.

   Terverifikasi
2. Masuk ke status kebijakan

   Hanya aplikasi yang dianggap Google belum memenuhi syarat yang seharusnya membawa masalah API target. Kalau aplikasinya sudah memenuhi syarat, tidak ada yang perlu diperpanjang dan tidak ada formulir untuk dicari.

   Terverifikasi
3. Buka peringatan API target atau detail masalahnya

   Judul masalah yang terlihat pada tangkapan layar di atas adalah App must target Android 16 (API level 36) or higher. Kata-katanya masih bisa berbeda antar aplikasi dan menurut tahap peluncuran, jadi anggap itu sebagai apa yang dilihat satu akun nyata, bukan string universal yang dijamin sama.

   Terverifikasi
4. Ikuti tautan perpanjangan di masalahnya, atau di Notifikasi

   Google mengarahkan sebagian developer yang terdampak lewat notifikasi aplikasi alih-alih panel masalah. Periksa keduanya sebelum menyimpulkan bahwa opsinya tidak ada untuk Anda.

   Terverifikasi
5. Kirim informasi yang diminta

   Google tidak mempublikasikan daftar pertanyaannya di halaman bantuan publik, jadi anggap belum terverifikasi setiap daftar "pertanyaan yang mereka ajukan" yang Anda temukan. Jawab berdasarkan rencana migrasi Anda yang sebenarnya.

   Sebagian
6. Perlakukan 1 November 2026 sebagai batas akhir

   Perpanjangan memindahkan tanggalnya, bukan menghapus persyaratannya. Apa pun yang dicakup perpanjangan yang diberikan harus selesai paling lambat 1 November 2026; setelah itu, artefak API 36 yang memenuhi syarat adalah satu-satunya cara untuk mengirim pembaruan aplikasi seluler biasa.

   Terverifikasi
7. Teruskan migrasi selama pengajuannya masih berjalan

   Tidak ada satu pun bagian dari rumusan Google yang menjanjikan persetujuan. Menyusun rencana berdasarkan perpanjangan yang belum Anda terima adalah asumsi termahal yang tersedia di siklus ini.

   Sebagian

Satu pembeda lagi yang layak diingat: Google menempelkan catatan perpanjangan pada persyaratan API 36, dan teksnya paling sering menggambarkan perpanjangan sebagai sesuatu yang menjaga distribusi aplikasi yang sudah ada. Google tidak menelusuri semua kombinasi aplikasi baru, pembaruan, dan aplikasi yang sudah ada dengan ketelitian yang sama. Sebelum menganggap sebuah perpanjangan mencakup unggahan tertentu yang Anda rencanakan, baca apa yang dinyatakan peringatan aplikasi Anda sendiri.

Bagaimana dengan API 37 pada 2027?

Google telah mengumumkan bahwa aplikasi baru dan pembaruan akan diwajibkan menargetkan API level 37 mulai Agustus 2027. Tabel persyaratan saat ini belum mencantumkan tanggal pastinya maupun matriks pengecualian per jenis perangkat untuk 2027, jadi artikel ini tidak mengarangnya. Jadwal rilis Android 17 sendiri (stabilitas platform ditargetkan pada Maret 2026, rilis besar pada Q2, dan rilis SDK minor pada Q4) adalah linimasa yang berbeda dari kalender penargetan Play; pisahkan keduanya. Sebagian: bulannya diumumkan, tanggalnya belum dipublikasikan

Cara menaikkan aplikasi ke API 36

Empat langkah: pasang SDK API 36, naikkan compileSdk dan targetSdk ke 36, perbarui dependensi yang rusak saat Anda melakukannya, lalu uji perubahan perilaku Android 16. Mengubah angkanya adalah suntingan satu baris. Membuktikan aplikasinya masih berfungsi adalah migrasi yang sesungguhnya.

Pembaruan saya ditolak karena level API targetnya. Apa yang harus saya perbaiki?

Mulailah dari level API target versi unggahan yang disebut dalam masalah tersebut, lalu ubah build yang menghasilkannya. Langkah migrasi umum di bawah ini tetap sama; ini adalah urutan mengerjakannya ketika Play Console sudah menolak.

1. Baca masalahnya. Buka masalah API target aplikasi di Policy status dan catat version code yang disebutkan, target yang dilaporkan, serta ambang yang diminta. Simpan tangkapan layar teks aslinya.

2. Periksa artefak itu. Di Test and release, Latest releases and bundles, buka versi tersebut dan baca level API targetnya. Bandingkan dengan branch, flavour, atau ekspor yang membangunnya. Artefaknyalah yang menjadi bukti; setelan di editor bukan bukti.

3. Perbaiki sumbernya. Jika artefaknya di bawah 36, pasang platform API 36 lalu naikkan compileSdk dan targetSdk, atau ikuti jalur framework atau pengekspor untuk stack Anda di bawah ini. Biarkan minSdk apa adanya kecuali perkakas atau dependensi memaksa perubahan tersendiri.

4. Uji, lalu unggah dengan version code yang lebih tinggi. Jalankan build rilis bertanda tangan di Android 16 dan di versi tertua yang Anda dukung, terutama setelah framework mengubah versi minimumnya.

5. Baca ulang artefak yang baru. Pastikan targetnya di Play Console, pastikan status rilisnya, lalu buka lagi masalah kebijakannya setelah pemrosesan selesai. Jika peringatannya masih menyebut versi yang lebih lama, periksa di jalur mana versi itu masih aktif; jangan menghapus pengujian tertutup yang sedang berjalan hanya untuk menghilangkannya.

6. Masih terblokir padahal artefaknya sudah benar? Gunakan jalur Bantuan aplikasi tersebut dengan menyertakan teks masalahnya, version code, jalur, dan detail artefak. Jangan menganggap pengajuan perpanjangan sudah dikabulkan; cakupannya ditentukan oleh pemberitahuan milik aplikasi itu sendiri.

Google Play Console Help tentang melihat versi yang diunggah dan tentang persyaratan API target, panduan konfigurasi SDK Android, serta laporan developer tentang peringatan yang tidak kunjung hilang, semuanya dibaca pada 15 Oktober 2026. Urutan ini adalah triase praktis, bukan peringkat penyebab yang diukur.

Langkah 1: pasang SDK Android 16

Buka Android Studio, masuk ke SDK Manager, lalu pasang Android SDK Platform untuk API level 36 beserta build tools 36.x.x yang berlaku sekarang. Tanpa platformnya terpasang, menaikkan compileSdk hanya menghasilkan error build yang tampak tidak berhubungan dengan apa pun yang Anda kerjakan.

Langkah 2: naikkan levelnya di build Anda

Pilih stack Anda. Jalur berkas dan baris persisnya berbeda-beda, tujuannya tidak: manifest di dalam bundle yang Anda unggah harus menyatakan target 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Langkah 3: perbarui dependensi dan perkakas framework

Menaikkan level kompilasi adalah titik ketika dependensi lama berguguran. Siapkan diri untuk menyentuh Android Gradle Plugin, Gradle sendiri, Kotlin, pustaka AndroidX, Google Play services, dan SDK iklan atau analitik apa pun yang membawa kode native. Artikel ini sengaja tidak memuat "versi yang benar", karena versi yang kompatibel berubah tiap pekan dan daftar yang dipatok di sini akan menyesatkan dalam dua pekan. Ambil versinya dari catatan rilis terbaru framework Anda sendiri pada hari Anda bermigrasi.

Langkah 4: bangun, unggah, dan periksa artefaknya

• Buat Android App Bundle bertanda tangan dan naikkan versionCode.
• Uji artefak release, bukan hanya build debug. Minifikasi dan penyusutan resource merusak hal-hal yang disembunyikan build debug.
• Unggah ke jalur yang dituju dan pastikan di Konsol Google Play bahwa artefaknya melaporkan level API target 36.
• Setelah pemrosesan selesai, tinjau semua jalur yang aktif dan buka lagi status kebijakannya.

Perilaku Android 16 yang perlu diuji sebelum merilis API 36

Menargetkan API 36 mengaktifkan perilaku Android 16 untuk aplikasi Anda di perangkat Android 16. Perilaku berprioritas tinggi yang perlu diuji adalah tata letak tepi ke tepi, tombol kembali prediktif, kebebasan orientasi di layar besar, izin kesehatan, penjadwalan berinterval tetap, dan tata letak teks. Centang yang sesuai di bawah ini dan Anda mendapat daftar pengujian untuk aplikasi Anda sendiri, bukan daftar umum.

Tepi ke tepi dan tombol kembali prediktif: jangkauan dampak terluas

Tata letak tepi ke tepi punya jangkauan dampak yang luas karena tidak menuntut aplikasi Anda memakai API yang aneh-aneh. Di Android 16, aplikasi yang menargetkan API 36 tidak lagi bisa memakai atribut pengecualian yang lama, sehingga konten yang mengandaikan bilah sistem menyisakan ruang kini berjalan di bawahnya. Gejalanya terlihat sebagai masalah tampilan saja, sampai tepat pada saat tombol utama berada di bawah bilah gestur dan tidak lagi bisa disentuh.

Tombol kembali prediktif punya jangkauan dampak yang sama luasnya. Kalau aplikasi Anda mendaftarkan penanganan kembali gaya lama, jalur itu bisa saja tidak terpanggil seperti dulu begitu kembali prediktif aktif secara bawaan untuk target 36. Uji tombol kembali dari setiap kedalaman navigasi yang Anda punya: modal, WebView, formulir dengan isian yang belum disimpan, dan layar terakhir sebelum keluar.

Yang bukan kerusakan universal target 36

Bagaimana dengan persyaratan ukuran halaman 16 KB?

Persyaratan berbeda, tanggal berbeda, aplikasi yang sama. Tenggat API target berkaitan dengan level yang dinyatakan manifest Anda. Persyaratan ukuran halaman 16 KB berkaitan dengan apakah pustaka native Anda bekerja di perangkat dengan halaman memori 16 KB. Panduan Google saat ini menyebut 1 Februari 2027 sebagai tanggal ketika pembaruan aplikasi terdampak tanpa dukungan 16 KB tidak lagi bisa dirilis.

• Siapa yang terdampak: persyaratan Google berlaku untuk aplikasi yang menargetkan API 35 atau lebih tinggi di perangkat Google Play 64 bit. Di dalam kelompok itu, aplikasi yang menyertakan pustaka native .so, langsung maupun lewat sebuah SDK, adalah yang paling mungkin memerlukan pembangunan ulang dan penyelarasan secara eksplisit. Kalau aplikasi Anda murni Kotlin atau Java, umumnya sudah kompatibel, tetapi tetap layak diuji alih-alih diasumsikan.
• Yang bukan: ini bukan bagian dari tenggat API target 31 Agustus 2026, dan lolos yang satu tidak berarti lolos yang lain.
• Kenapa datang bersamaan: menaikkan level target biasanya berarti membangun ulang, dan saat membangun ulang itulah masalah ukuran halaman pustaka native, yang sebenarnya terpisah, muncul ke permukaan. Kebetulan waktu itulah yang membuat keduanya sering tertukar.

Kalau aplikasi Anda menyertakan pustaka native, perlakukan pemeriksaan ukuran halaman sebagai pekerjaan tersendiri dengan siklus pengujiannya sendiri, alih-alih menyelipkannya ke build API 36 di menit-menit terakhir. Kedua perubahan itu menyentuh bagian build yang berbeda, dan menelusuri masalah keduanya sekaligus adalah cara migrasi satu pekan berubah menjadi tiga pekan.

Anda sudah mengunggah API 36 dan peringatannya masih ada

Biasanya salah satu dari tiga hal: bundle-nya belum selesai diproses dan status kebijakannya belum disegarkan, artefak lama masih menempel di jalur aktif lain, atau artefak yang Anda unggah sebenarnya tidak menyatakan 36 meski proyek Anda menyatakannya. Telusuri daftarnya dari atas, dan jangan mulai dengan menghapus rilis.

Judul masalah yang sedang dilaporkan para developer adalah Your app must target Android 16 (API level 36) or higher, berbahasa Inggris seperti yang tampil di Konsol Google Play. Google tidak pernah mempublikasikan teks error baku yang lengkap untuk setiap alur pengunggahan, jadi anggap kata-kata persis yang Anda temukan di internet, termasuk yang itu, sebagai hasil pengamatan dan bukan pernyataan resmi.

Satu kebiasaan menyelesaikan sebagian besar masalah ini untuk seterusnya: setelah setiap pengunggahan, baca ulang level API target dari artefaknya di Konsol Google Play dan catat di sebelah versionCode. Butuh sepuluh detik, dan itu menghapus seluruh kategori "saya yakin sudah membetulkannya" dari pekan Anda.

Checklist sebelum tenggat

Empat belas butir, dalam urutan yang benar-benar terjadi. Empat butir terakhir adalah yang biasanya dilewati orang, dan justru empat itulah yang menentukan apakah peringatannya hilang.

Di mana PrimeTestLab masuk dalam tenggat ini

Supaya batasannya jelas: kami tidak memigrasikan kode Anda. Menaikkan targetSdk, memperbarui dependensi, dan membereskan perubahan perilaku Android 16 adalah urusan build Anda, dan artikel ini adalah seluruh kontribusi kami untuk bagian itu. Yang kami tangani adalah separuh lainnya dari benturan ini: 12 penguji asli yang ikut serta selama 14 hari berturut-turut, yang dibutuhkan akun pribadi baru sebelum bisa sampai ke produksi.

Masalahnya ada pada waktunya. Orang yang pertama kali merilis aplikasi diminta mengerjakan dua hal sulit yang tidak berkaitan sekaligus: merilis build API 36, dan menjaga pengujian tertutup yang memenuhi syarat tetap berjalan selama dua pekan penuh. Build-nya adalah pekerjaan rekayasa yang bisa diselesaikan. Mengumpulkan dua belas orang nyata yang tetap ikut serta selama empat belas hari, di perangkat nyata, adalah bagian yang diam-diam menghabiskan sebulan.

Mengerjakan pengujian tertutup sendiri atau menyerahkannya

Urutan mengerjakannya

Kalau Anda menghadapi kedua masalah sekaligus, jalankan keduanya paralel, bukan berurutan. Mulai pengujian tertutupnya sekarang, karena 14 harinya adalah waktu kalender yang tidak bisa dipadatkan, lalu kerjakan migrasi API 36 berdampingan dengan itu. Dorong build yang memenuhi syarat ke jalur tertutup yang sama begitu siap, dengan versionCode lebih tinggi dan penguji yang sama masih ikut serta. Dengan begitu tenggat dan masa pengujian berhenti berebut dua pekan yang sama.

Pertanyaan yang sering diajukan

Ringkasan

Potret kebijakan diverifikasi pada 9 Agustus 2026 dan diverifikasi ulang pada 15 Oktober 2026 terhadap halaman Google saat ini tentang API target, ukuran halaman, dan pengujian tertutup. Google mengubah halaman-halaman ini tanpa pemberitahuan, jadi periksa sumber primer di atas sebelum mengambil keputusan berdasarkan tanggal apa pun. Pemeriksaan ulang redaksi berikutnya: setelah masa perpanjangan berakhir pada 1 November 2026.