Tenggat API 36 Google Play: yang berubah pada 31 Agustus 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 Google Play Console yang justru penting.

Artikel ini memisahkan keduanya, memberi angka per jenis perangkat, lalu menjawab pertanyaan yang benar-benar masuk ke kotak dukungan kami setiap Agustus: apa dampaknya bagi aplikasi yang sedang setengah jalan menjalani pengujian tertutup (closed testing) 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 apa pun yang sebenarnya belum didokumentasikan Google diberi label, bukan diisi dengan tebakan yang terdengar meyakinkan.

Aturannya dalam satu kalimat

Mulai 31 Agustus 2026, aplikasi ponsel, tablet, perangkat lipat, atau Android Auto pada umumnya harus 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 31 Agustus menjadi masalah Anda 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.

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, tenggatnya jatuh tepat di tengah masa itu. Langkah yang aman adalah memasukkan build API 36 ke jalur tertutup yang sama sebelum 31 Agustus, 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 sudah memiliki build yang memenuhi syarat di jalur tersebut sebelum tanggalnya. 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. Bangun dan uji API 36 sebelum tenggat, bukan tepat di hari tenggat

   Perlakukan migrasinya sebagai pekerjaan tersendiri dengan siklus pengujiannya sendiri. Menemukan tata letak tepi layar yang rusak pada 30 Agustus adalah hari yang sangat berbeda dari menemukannya pada 10 Agustus.

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 Google Play Console 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

   Perpanjangan memberi waktu sampai 1 November 2026 dan diajukan per aplikasi yang terdampak. Itu 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 Google Play Console, 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.

Google Play Console · tangkapan layar asli Klik untuk memperbesar

1. Buka aplikasi yang terdampak di Google Play Console

   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 tidak selesai sebelum 31 Agustus tetap harus selesai sebelum 1 November.

   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.

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.

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 Google Play Console 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: siapa pun yang menaikkan level target bulan ini toh akan membangun ulang, dan di situlah pemeriksaan ukuran halaman 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 Google Play Console. 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 Google Play Console 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 pada Agustus 2026 diminta mengerjakan dua hal sulit yang tidak berkaitan dalam periode yang sama: 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 bulan ini

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 yang diverifikasi pada 9 Agustus 2026. Google mengubah halaman-halaman ini tanpa pemberitahuan, jadi periksa sumber primer di atas sebelum mengambil keputusan berdasarkan tanggal apa pun. Artikel ini dijadwalkan untuk diperiksa ulang segera setelah 31 Agustus dan sekali lagi setelah 1 November 2026.