Jawaban singkat
Google Play mewajibkan aplikasi yang menargetkan Android 15 (level API 35) atau lebih tinggi mendukung ukuran halaman memori 16 KB di perangkat 64 bit, dan mulai 1 Februari 2027 Anda tidak akan bisa merilis update yang belum memenuhinya. Aplikasi yang ditulis hanya dengan Java atau Kotlin, termasuk seluruh library dan SDK di dalamnya, sudah otomatis memenuhi syarat. Aplikasi yang mengemas library native .so akan gagal sampai setiap file itu dibangun ulang atau diganti, sebaiknya dengan Android Gradle Plugin 8.5.1+ dan NDK r28+, lalu build-nya lolos dua pemeriksaan terpisah: setiap segmen LOAD ELF selaras pada sedikitnya 2**14, dan app bundle melaporkan PAGE_ALIGNMENT_16K. Menaikkan versi framework bukan bukti; artefaknyalah buktinya. Kalau upaya menghilangkan peringatan ini membuat pengujian tertutup yang sedang berjalan jadi tersendat, PrimeTestLab menjaga sisi penguji tetap jalan selama Anda membangun ulang.
Peringatannya pendek, paling banter menyebut satu nama file, dan datang saat Anda sudah merasa build-nya selesai. Karena itulah tiga salah langkah yang sama terus terulang: developer memercayai tenggat yang sudah bergeser, menaikkan versi framework lalu menganggap urusan selesai, atau memeriksa satu APK lokal dan tidak pernah melihat bundle yang justru dipakai Google untuk membangun aplikasinya. Artikel ini disusun mengikuti cara masalahnya benar-benar selesai, yaitu kenali, telusuri pemiliknya, perbaiki, lalu buktikan, dan seluruh isinya berlaku per 5 Agustus 2026, diperiksa terhadap panduan ukuran halaman milik Google pada hari yang sama saat halaman itu terakhir diperbarui. Di tempat yang buktinya hanya berupa pelacak masalah milik pengelola paket, bukan catatan rilis resmi, halaman ini menyebutkannya di kartu alih-alih membulatkannya menjadi fakta.
Laboratorium Penyelarasan
Dua belas alat yang dibuat khusus untuk satu error ini. Tidak ada yang butuh akun, unggahan, atau permintaan jaringan; semuanya berjalan di browser Anda dengan nilai yang Anda ketik sendiri.
Daftar isi
Perbaiki dalam tiga langkah
Setiap perbaikan yang sungguh-sungguh untuk error ini adalah tiga gerakan yang sama dengan urutan yang sama: kenali library native yang tidak selaras, perbarui dependensi yang memilikinya, lalu buktikan artefak yang akan Anda upload. Langsung melompat ke langkah dua itulah sebabnya begitu banyak developer menaikkan versi framework, membangun ulang, lalu menonton peringatannya muncul lagi tanpa berubah.
Persyaratannya sendiri sempit. Panduan ukuran halaman milik Google menyatakan bahwa aplikasi yang menargetkan Android 15 (level API 35) atau lebih tinggi harus mendukung ukuran halaman memori 16 KB di perangkat 64 bit, dan bahwa mulai 1 Februari 2027 Anda tidak akan bisa merilis update yang belum memenuhinya. Ini hanya berlaku untuk kode native. Kalau aplikasi Anda beserta setiap library dan SDK di dalamnya murni Java atau Kotlin, Google menyatakan aplikasi Anda sudah mendukung perangkat 16 KB. Masalahnya, sebagian besar developer yang melihat peringatan ini merasa dirinya masuk kategori itu, padahal tidak.
Kenali file .so yang gagal
Buka APK rilis Anda di Android Studio lewat Build > Analyze APK..., buka lib/arm64-v8a dan lib/x86_64, lalu baca kolom Alignment. Catat setiap nama file yang ditandai. Nama file itulah satu-satunya kunci pencarian yang bisa Anda andalkan.
Perbarui apa pun yang memilikinya
Biner yang Anda kompilasi sendiri diperbaiki oleh toolchain Anda: AGP 8.5.1 atau lebih baru dengan NDK r28 atau lebih baru. Biner yang datang di dalam plugin, SDK, engine atau AAR hanya bisa diperbaiki oleh pihak yang membangunnya, jadi tindakannya adalah menaikkan versi, mengganti, atau meminta artefak yang sudah dibangun ulang dari paket tersebut.
Cari jalur tersingkat untuk framework AndaBuktikan artefaknya, bukan kenaikan versinya
Dua pemeriksaan yang saling bebas harus sama-sama lolos. Setiap segmen LOAD ELF harus selaras pada 2**14 atau lebih besar, dan bundletool harus melaporkan PAGE_ALIGNMENT_16K untuk bundle rilis Anda. Lolos yang satu tidak membuktikan apa pun tentang yang lain.
Seluruh keputusannya dalam satu layar
Sebelum Anda mengubah satu pun versi dependensi, telusuri ini. Butuh sekitar dua menit, dan inilah pembeda antara memperbaiki hal yang benar dan menaikkan versi sebelas paket yang sejak awal bukan penyebabnya.
Apakah APK rilis Anda punya folder lib berisi file .so?
Sudah memenuhi syarat
Tidak ada kode native di dalam APK. Google menyatakan aplikasi yang hanya memakai Java atau Kotlin, termasuk library dan SDK di dalamnya, sudah mendukung perangkat 16 KB. Tetap layak diuji sekali, dan layak dipastikan bahwa build yang Anda periksa sama dengan build yang Anda upload.
Apakah APK Analyzer atau check_elf_alignment.sh menyebut nama library yang tidak selaras?
Telusuri pemiliknya, lalu naikkan versinya
Cari framework, plugin, SDK atau engine mana yang membawa nama file persis itu, lalu perbarui paket tersebut. NDK Anda sendiri tidak bisa menulis ulang biner siap pakai milik orang lain.
Apa yang dilaporkan bundletool dump config untuk bundle rilis Anda?
PAGE_ALIGNMENT_4K
Library-nya sudah benar tetapi pengemasannya belum. Pindah ke AGP 8.5.1 atau lebih baru lalu bangun ulang, atau terapkan solusi sementara pengemasan lama kalau Anda belum bisa menaikkan versi.
PAGE_ALIGNMENT_16K
Pengemasannya sudah benar. Sekarang uji APK yang dihasilkan Play di lingkungan 16 KB sungguhan, dan periksa kode berjalan mana pun yang berasumsi ukuran halamannya tetap.
Jebakannya dalam satu kalimat
APK lokal yang lolos semua pemeriksaan penyelarasan tidak membuktikan bundle yang Anda upload sudah benar. Google secara khusus memperingatkan bahwa Android Gradle Plugin 8.3 sampai 8.5 bisa menghasilkan bundle yang APK bentukan Play-nya tidak tersejajarkan ZIP dengan benar, walaupun APK di komputer Anda terlihat sempurna. Ketidakcocokan itulah alasan paling umum peringatannya bertahan setelah perbaikan yang tampak "berhasil".
Apa sebenarnya arti peringatan Play Console itu
Akibat yang didokumentasikan Google sangat spesifik: mulai 1 Februari 2027 Anda tidak akan bisa merilis update yang menargetkan Android 15 (level API 35) atau lebih tinggi tanpa dukungan 16 KB. Ini pemblokiran rilis untuk update, bukan pernyataan bahwa aplikasi yang sudah terbit akan dihapus dari toko pada tanggal itu. Sampai saat itu, sebagian besar developer melihat peringatan kompatibilitas, bukan penolakan unggahan.
Pilihan katanya penting, karena versi panik dari cerita ini menyebar lebih cepat daripada versi yang akurat. Baca teks yang benar-benar ditampilkan Google, maka cakupannya menjadi sempit dan bisa ditangani.
App must support 16 KB memory page sizes
Direkonstruksi dari tangkapan layar Play Console yang diterbitkan Google di panduan ukuran halaman. Labelnya dibiarkan berbahasa Inggris persis seperti di tangkapan layar itu: Konsol Play Anda bisa saja menampilkannya dalam bahasa Indonesia, dan tata letak serta tombol yang tersedia bisa berbeda antar akun.
Dua pembacaan atas kartu itu sering keliru. Pertama, "Action by Feb 1, 2027" bukan hitung mundur menuju penghapusan; teks Google di halaman yang sama menggambarkan akibatnya sebagai ketidakmampuan merilis update tersebut. Kedua, teks Extension granted memang muncul di tangkapan layar Google, tetapi itu tidak membuktikan bahwa alur permintaan perpanjangan sekarang terbuka untuk Anda. Anggap perpanjangan itu nyata hanya kalau Anda melihat opsinya di dalam Play Console Anda sendiri.
Tenggat mana yang sebenarnya Anda baca?
Tiga tanggal sedang beredar dan hanya satu yang berlaku. Pilih tanggal mana pun yang pernah Anda lihat, lalu alat ini menentukan statusnya terhadap halaman Google yang berlaku, yang terakhir diperbarui pada 5 Agustus 2026.
Alat 01
Penentu tenggat
Google sudah lebih dari sekali menggeser tenggat ini. Sebelum Anda menyusun rencana rilis di sekitar 1 Februari 2027, buka sendiri panduan ukuran halamannya lalu periksa stempel "Last updated" di bagian bawah. Satu kebiasaan itu lebih berharga daripada tanggal mana pun yang tercetak di sebuah artikel, termasuk artikel ini.
Apakah persyaratan 16 KB berdampak pada aplikasi saya?
Framework Anda bukan penentunya. Isi APK yang dihasilkan aplikasi Andalah penentunya. Kalau ada file .so di bawah lib, Anda masuk cakupan tanpa peduli apakah Anda pernah membuka satu berkas C++ pun, dan kalau tidak ada satu pun, panduan Google sendiri menyatakan aplikasi Anda sudah mendukung perangkat 16 KB.
Aplikasi Java atau Kotlin murni
Google tidak menyisakan keraguan di sini: kalau aplikasi Anda beserta seluruh library dan SDK di dalamnya hanya memakai Java atau Kotlin, aplikasi Anda sudah mendukung perangkat 16 KB. Google tetap menyarankan pengujian di lingkungan 16 KB untuk menangkap kemunduran yang tidak terduga, dan itu hanya memakan satu kali jalan emulator.
Jebakannya ada pada frasa "beserta seluruh library dan SDK di dalamnya". Satu dependensi basis data, analitik, pelaporan kerusakan, media, peta, pembelajaran mesin atau keamanan saja bisa menambahkan biner native ke proyek yang kode sumbernya sendiri hanya berisi Kotlin. "Saya tidak menulis C++" bukan bukti. Folder lib itulah buktinya.
Flutter, React Native, Unity, Kivy dan app builder tanpa kode
Tumpukan teknologi ini memang membawa runtime native, biner engine dan library plugin sejak awal, jadi hampir selalu masuk cakupan. Google secara eksplisit menyebut app builder pihak ketiga yang memakai library native sebagai salah satu cara sebuah aplikasi bisa terdampak walaupun penulisnya tidak pernah menulis C atau C++. Yang berbeda-beda bukan apakah Anda punya kode native, melainkan paket mana yang membawa bagian yang gagal, dan karena itulah menelusuri nama filenya harus datang lebih dulu sebelum kenaikan versi apa pun.
Cara memeriksanya, persisnya
Buka APK rilisnya, buka lib, lalu lihat folder ABI di dalamnya, biasanya arm64-v8a dan x86_64. Adanya file shared object berarti aplikasi Anda memakai kode native. Tidak ada file .so dan tidak ada folder lib berarti APK ini sama sekali tidak memakai kode native. Kolom Alignment di penganalisis menampilkan pesan peringatan untuk file yang bermasalah penyelarasannya, dan itulah jalan tercepat dari "ada yang salah" menuju sebuah nama file.
Alat 02
Triase keterdampakan
01 Aplikasi Anda saat ini menargetkan apa?
02 Buka APK rilis Anda di APK Analyzer. Adakah folder lib?
03 Mana yang paling menggambarkan aplikasi Anda?
04 Sudahkah Anda menjalankan bundletool dump config pada bundle rilisnya?
Kenapa biner 4 KB gagal di perangkat 16 KB
Halaman memori adalah blok terkecil yang dipetakan kernel sekali jalan. Android selama ini memakai halaman 4 KB; Android 15 menambahkan dukungan untuk perangkat yang disetel dengan halaman 16 KB. Sebuah library native mencatat penyelarasan yang dipakai saat segmennya ditautkan, dan kalau nilai itu lebih kecil daripada ukuran halaman perangkatnya, pemuat tidak bisa menempatkan segmen itu di batas halaman.
Itulah seluruh mekanismenya, dan itu menjelaskan satu angka yang akan terus Anda lihat. Penyelarasan dinyatakan sebagai pangkat dua: 2**12 adalah 4096 bita, 2**14 adalah 16384 bita. Aturan Google adalah setiap segmen LOAD di dalam library native harus selaras pada 2**14 atau lebih besar. Library yang dibangun pada 2**14 berjalan di perangkat 4 KB maupun 16 KB, karena 16384 adalah kelipatan bulat dari 4096. Library yang dibangun pada 2**12 hanya berjalan pada ukuran halaman yang lebih kecil. Ketimpangan itulah sebabnya perbaikannya selalu "naikkan penyelarasannya" dan tidak pernah "deteksi perangkatnya".
Alat 03
Peraga halaman memori
Pilih penyelarasan yang dilaporkan library Anda, lalu lihat di mana segmennya boleh mulai pada perangkat yang memakai halaman 16 KB.
Lolos
Ada satu batasan kedua yang sepenuhnya terpisah dan berada di luar library. Library native yang disimpan tanpa kompresi di dalam APK juga harus duduk di batas 16 KB di dalam arsip ZIP itu sendiri. Itu sifat pengemasan, diperiksa dengan zipalign dan diatur oleh plugin build Anda, dan sifat itu bisa salah walaupun setiap library di dalamnya sudah selaras sempurna. Menjaga kedua gagasan itu tetap terpisah adalah hal paling berguna yang bisa Anda bawa dari bagian ini.
Cara membaca angkanya
Ketika Anda melihat 2**14 di keluaran llvm-objdump, itu berarti lolos. 2**13 atau 2**12 berarti gagal. Tidak ada nilai setengah dan tidak ada "sudah mendekati"; satu segmen LOAD yang tidak selaras di satu library pada satu ABI saja sudah cukup untuk membuat peringatannya tetap menempel di akun Anda.
Perbaikan tersingkat untuk masing-masing framework
Kesiapan framework dan kepatuhan aplikasi adalah dua hal yang berbeda. React Native 0.77 dan daftar versi Unity yang didukung adalah patokan sungguhan yang terdokumentasi. Flutter tidak punya versi minimum universal yang bisa diverifikasi. Dalam setiap kasus, kenaikan versi memperbaiki biner milik framework itu sendiri dan meninggalkan setiap plugin pihak ketiga persis setidak-patuh keadaan sebelumnya.
Alat 04
Pencari jalur framework
Apa yang masih bisa gagal setelah ini
Semua patokan dalam satu tabel
| Framework | Patokan terdokumentasi | Tindakan tersingkat | Keyakinan |
|---|---|---|---|
| Flutter | Tidak ada minimum universal yang terverifikasi; 3.38 adalah tonggak persiapan yang terdokumentasi (NDK bawaan r28) | Flutter stabil terbaru, perbarui plugin native, bersihkan, bangun ulang, periksa setiap library | SEBAGIAN |
| React Native | 0.77 | Jalur kenaikan versi yang didukung, lalu perbarui modul native dan SDK vendor | TERVERIFIKASI |
| Unity jalur 6.1 | 6000.1 atau lebih baru | Naikkan editornya, perbarui paket dan plugin, bangun ulang | TERVERIFIKASI |
| Unity 6 LTS | 6000.0.38f1 atau lebih baru | Sama seperti di atas | TERVERIFIKASI |
| Unity 2022 LTS | 2022.3.56f1 atau lebih baru | Sama seperti di atas | TERVERIFIKASI |
| Unity 2021 | 2021.3.48f1 atau lebih baru, butuh kelayakan LTS diperpanjang | Naikkan versi kalau berhak, kalau tidak pindahlah ke editor yang didukung | TERVERIFIKASI |
| Unity Burst | 1.8.21 atau lebih baru | Naikkan Burst saat lib_burst_generated.so disebut |
TERVERIFIKASI |
| Android native | NDK r28+ dengan AGP 8.5.1+ | Kompilasi ulang kode milik Anda, perbarui setiap dependensi siap pakai | TERVERIFIKASI |
| Terpaku di NDK lama | r27 atau lebih lama dengan kedua opsi linker | Tambahkan max-page-size dan common-page-size, bangun ulang seluruh library |
BERHASIL, TAPI BUKAN PILIHAN UTAMA |
| Kivy atau builder Python | Tidak ada versi universal yang terverifikasi | Perbarui builder dan resepnya, teruskan nama file persisnya ke pengembang hulu | BERGANTUNG VENDOR |
| App builder tanpa kode | Tidak ada versi universal yang terverifikasi | Bangkitkan ulang di atas tumpukan build vendor yang sudah patuh, kirimkan nama filenya ke mereka | BERGANTUNG VENDOR |
Label keyakinan bermakna sama di seluruh halaman ini. TERVERIFIKASI berarti sumber primer yang berlaku menyatakannya secara langsung. SEBAGIAN berarti sumber tepercaya mendukung klaim intinya tetapi tidak setiap detail penerapannya. DILAPORKAN berarti buktinya berupa pelacak isu milik pengelola atau laporan developer, bukan catatan rilis resmi.
Temukan library persis penyebab error-nya
Nama file itulah seluruh penelusurannya. Begitu Anda tahu libfoo.so adalah biner yang gagal, pertanyaannya berhenti menjadi "bagaimana saya memperbaiki dukungan 16 KB" dan berubah menjadi "paket mana yang membawa libfoo.so, dan adakah versi yang lebih baru". Pertanyaan kedua itu ada jawabannya; yang pertama tidak.
Mulai dari APK Analyzer
Buka Build > Analyze APK..., muat APK rilisnya, lalu buka lib. Di dalamnya Anda akan melihat satu folder per ABI, biasanya arm64-v8a dan x86_64. Kolom Alignment menampilkan pesan peringatan pada file yang bermasalah penyelarasannya. Peringatan bawaan Android Studio dan Lint juga menyorot library native yang belum memenuhi syarat, jadi temuan yang sama bisa muncul di lebih dari satu tempat.
Catat setiap nama file yang ditandai sebelum Anda menyentuh satu pun nomor versi. Periksa kedua folder ABI secara terpisah: wajar sekali kalau arm64-v8a lolos sementara x86_64 gagal, atau sebaliknya, karena keduanya biner berbeda yang bisa dibangun oleh alur yang berbeda.
Baca keluaran baris perintahnya
Kalau Anda lebih suka bekerja di terminal, Google menyediakan check_elf_alignment.sh, yang melaporkan ALIGNED atau UNALIGNED untuk sebuah APK, dan Anda bisa memeriksa satu library secara langsung dengan llvm-objdump. Keduanya butuh Android SDK Build-Tools 35.0.0 atau lebih baru. Tempelkan apa pun yang mereka cetak di bawah ini dan alat ini akan membacakannya kembali untuk Anda.
Alat 05
Pembaca ELF
Tempelkan keluaran dari llvm-objdump -p file.so | grep LOAD, check_elf_alignment.sh atau zipalign -c -P 16. Semuanya diurai di browser Anda; tidak ada yang diunggah ke mana pun.
Cari tahu dependensi mana yang memilikinya
Play Console dan APK Analyzer sama-sama memberi Anda nama file tanpa menyebut pemiliknya. Ketikkan nama itu di bawah dan alat ini akan memberi tahu apa yang diketahui tentang biner tersebut, lengkap dengan mutu buktinya, lalu memberi Anda perintah pencarian dengan nama file Anda sudah terpasang di dalamnya.
Alat 06
Pencarian pemilik library
./gradlew app:dependencies menampilkan graf dependensi yang benar-benar terpilih, dan begitulah cara Anda menemukan paket turunan yang menarik masuk sebuah library yang tidak pernah Anda tambahkan sendiri. Perintah itu tidak langsung memberi tahu artefak mana yang berisi sebuah file .so, jadi pasangkan dengan membuka isi AAR yang Anda curigai. Ini teknik diagnosis yang praktis, bukan langkah yang diwajibkan Google.
Periksa app bundle, bukan hanya APK lokal
APK lokal Anda dan APK yang dihasilkan Google Play dari bundle Anda adalah artefak yang berbeda. Penyelarasan ELF ada di dalam setiap library; penyelarasan ZIP adalah sifat cara arsipnya dikemas; sedangkan bundle membawa konfigurasi yang memberi tahu Play mana yang harus dipakai. Ketiganya bisa saling bertentangan, dan hanya yang terakhirlah yang menentukan apa yang dipasang pengguna.
Inilah mekanisme di balik versi paling menjengkelkan dari masalah ini: developer menaikkan versi semuanya, memeriksa APK lokal, melihat keluaran bersih, mengunggahnya, dan peringatannya masih di sana. Tidak ada satu pun yang dia periksa itu salah. Dia hanya tidak pernah memeriksa hal yang dinilai Play.
Yang Anda periksa
app-release.apk di komputer AndaDibangun langsung oleh Gradle di perangkat keras Anda, dengan perilaku pengemasan Anda. Lolos zipalign di sini membuktikan file ini dikemas dengan benar.
Yang dinilai Play
APK yang dihasilkan dari app-release.aabDibangun Google dari bundle Anda, memakai penyelarasan yang diminta bundle itu. Kalau bundle-nya menyebut 4 KB, APK ini salah sebersih apa pun APK lokal Anda tadi.
Jadi jalankan perintah ini terhadap bundle yang akan Anda upload, setiap kali:
bundletool dump config --bundle=app-release.aab | grep alignment
PAGE_ALIGNMENT_16K adalah hasil yang Anda inginkan. PAGE_ALIGNMENT_4K berarti bundle Anda menyuruh bundletool mengemas library native di batas 4 KB, sehingga setiap APK yang dibangun Play darinya akan salah. Google secara khusus memperingatkan bahwa Android Gradle Plugin 8.3 sampai 8.5 bisa menghasilkan ketidakcocokan persis seperti ini: build lokalnya terlihat selaras, sementara aplikasi yang dibangun Play dari bundle itu tidak akan terpasang dengan benar di perangkat 16 KB. Perbaikan yang dianjurkan adalah pindah ke Android Gradle Plugin 8.5.1 atau lebih baru.
Setiap perintah, dengan nama file Anda sendiri di dalamnya
Ketik nama file Anda satu kali. Setiap perintah di bawah akan menulis ulang dirinya, dan tiap tab menampilkan keluaran persis yang dihitung lolos, jadi Anda tidak pernah menebak apakah hasilnya bagus.
Alat 07
Laboratorium perintah
Jangan berhenti di "APK Analyzer bilang sudah selaras"
Pemeriksaan APK yang lolos adalah satu dari empat pemeriksaan, bukan garis finis. Pastikan penyelarasan LOAD ELF, penyelarasan ZIP APK, konfigurasi bundle, dan perilaku saat berjalan dari artefak yang benar-benar dihasilkan Play. Satu saja di antaranya gagal sudah cukup untuk membuat peringatannya menempel di akun Anda setelah build yang Anda kira sudah beres.
AGP, NDK dan jebakan pengemasan
Dua nomor versi memikul sebagian besar bebannya. NDK r28 atau lebih baru mengompilasi kode native dengan penyelarasan 16 KB secara bawaan, dan Android Gradle Plugin 8.5.1 atau lebih baru mengemas library native tanpa kompresi di batas ZIP 16 KB dengan benar. Tidak satu pun dari keduanya bisa memperbaiki biner siap pakai yang datang di dalam sebuah dependensi.
Wilayah tengah yang berbahaya adalah Android Gradle Plugin 8.3 sampai 8.5. Di rentang itu, build lokal bisa terlihat sepenuhnya benar sementara bundletool tidak menyejajarkan ZIP pada APK yang dihasilkannya dari bundle Anda untuk Play, dan kalimat Google tentang akibatnya sangat lugas: aplikasi yang dibangun dari bundle itu tidak akan terpasang dengan benar. Kalau Anda ada di 8.5.0 dan APK lokal Anda lolos setiap pemeriksaan yang terpikir oleh Anda, inilah hal pertama yang harus disingkirkan.
Alat 08
Pemeriksa toolchain
Rujukan setelan build
| Situasi | Setelan | Catatan |
|---|---|---|
| NDK yang dianjurkan | r28 atau lebih baru |
Menghasilkan keluaran native yang selaras 16 KB secara bawaan |
| AGP yang dianjurkan | 8.5.1 atau lebih baru |
Menangani library native tanpa kompresi di batas ZIP 16 KB |
| NDK r27 atau lebih lama | -Wl,-z,max-page-size=16384 |
Opsi linker yang wajib ada di setiap target native |
| NDK r27 atau lebih lama | -Wl,-z,common-page-size=16384 |
Dipakai bersama opsi ukuran halaman maksimum |
ndk-build |
LOCAL_LDFLAGS += ... |
Terapkan kedua opsi itu ke masing-masing target native |
| CMake | target_link_options(...) |
Terapkan kedua opsi itu ke setiap target yang relevan |
| Belum bisa menaikkan AGP | jniLibs.useLegacyPackaging = true |
Mengompresi library native; menambah pemakaian ruang penyimpanan terpasang |
| AGP 8.0 atau lebih lama | android.bundle.enableUncompressedNativeLibs=false |
Properti lama tambahan yang menyertai opsi di atas |
| Kode saat berjalan | getpagesize() atau sysconf(_SC_PAGESIZE) |
Gantikan nilai 4096 yang ditulis mati dan asumsi PAGE_SIZE yang tetap |
Bagian yang tidak bisa diperbaiki pengemasan
Kalau kode C atau C++ Anda sendiri berasumsi tentang ukuran halaman, tidak ada flag build yang menyelamatkan Anda. Buang nilai 4096 yang ditulis mati dan setiap ketergantungan pada konstanta PAGE_SIZE yang tetap, tanyakan nilai sebenarnya saat program berjalan dengan getpagesize() atau sysconf(_SC_PAGESIZE), lalu periksa ulang setiap panggilan mmap() beserta argumen mana pun yang Anda selaraskan ke halaman secara manual. Inilah jenis kegagalan yang membuat aplikasi terpasang mulus di perangkat 16 KB, lolos pemeriksaan bundle, lalu mogok begitu pertama kali menyentuh pemetaan memori.
Urutan pengerjaan
Benahi sisi kompilator sebelum sisi pengemasan. Kalau Anda menerapkan solusi sementara pengemasan lama lebih dulu, APK Anda akan mulai lolos zipalign padahal library di dalamnya masih dibangun untuk halaman 4 KB, dan Anda sudah menyembunyikan masalah yang sebenarnya di balik hasil berwarna hijau.
Uji di lingkungan 16 KB sungguhan
Satu perintah menentukan apakah pengujian Anda berarti: adb shell getconf PAGE_SIZE harus mengembalikan 16384. Jalankan sebelum setiap sesi. Emulator yang diam-diam menyala dalam mode 4 KB akan meluluskan build yang rusak, apa pun yang Anda lemparkan padanya.
Anda punya tiga jalan praktis dan dua jalan khusus. Pilih mana pun yang benar-benar bisa Anda jangkau hari ini; untuk keperluan menangkap kegagalan ukuran halaman, mutunya sama saja.
Alat 09
Pemilih lingkungan uji
Batasannya
Lalu, setiap kali, sebelum pengujian apa pun
adb shell getconf PAGE_SIZE
Jangan lanjut sebelum keluarannya 16384.
Apa yang sebenarnya harus dijajal
Begitu lingkungannya dipastikan, uji yang berguna bukanlah "apakah aplikasinya terbuka". Kegagalan native berkumpul di fitur yang menyentuh kode native, jadi jajallah fitur itu dengan sengaja: peluncuran dingin, penjelajahan di dalam aplikasi, kamera, baca dan tulis basis data, pemutaran dan perekaman media, autentikasi, pekerjaan latar belakang, fitur pembelajaran mesin atau realitas tertambah apa pun, setiap permukaan plugin native, dan bagian mana pun dari kode Anda sendiri yang memakai pemetaan memori. Kalau sebuah fitur digerakkan oleh salah satu library yang baru saja Anda naikkan versinya, fitur itulah pengujiannya.
Mode kompatibilitas bukan tanda lulus
Android bisa menjalankan sebagian aplikasi yang selaras 4 KB di perangkat 16 KB lewat jalur kompatibilitas, dan Anda mungkin melihat peringatan saat peluncuran pertama ketika itu terjadi. Google tetap menganjurkan penyelarasan 16 KB yang benar demi keandalan dan kestabilan terbaik. Aplikasi yang berjalan semata karena mode kompatibilitas turun tangan bukanlah aplikasi yang sudah diperbaiki, dan merilis di atas dasar itu berarti kegagalan yang sebenarnya masih menunggu di depan.
Kenapa peringatannya bertahan setelah versi dinaikkan
Hampir setiap kasus "saya kan sudah memperbaikinya" adalah salah satu dari tiga belas situasi tertentu, dan sebelas di antaranya bisa dibuktikan dari artefak yang ada di depan Anda. Pilih gejala yang cocok dan biasanya Anda sudah tahu penyebabnya sebelum selesai membacanya.
Alat 10
Triase peringatan membandel
Dua di antaranya layak diberi catatan alih-alih jawaban yang percaya diri. Tidak ada sumber primer yang menetapkan berapa lama Google Play menilai ulang sebuah bundle yang diunggah, jadi kalau peringatan Anda bertahan tepat setelah unggahan, langkah yang jujur adalah memastikan kode versi yang baru muncul di halaman rilis terbaru dan app bundle Anda lalu memeriksanya lagi nanti, bukan memercayai angka tertentu yang Anda baca soal lama pemrosesan. Dan aplikasi yang berjalan semata karena mode kompatibilitas turun tangan bukanlah aplikasi yang sudah diperbaiki, melainkan aplikasi yang sedang dimaklumi.
Library pihak ketiga yang terus muncul
Ini contoh yang dilaporkan, bukan peringkat seberapa umum masing-masing, dan bukan janji bahwa versi tertentu akan memperbaiki build Anda. Sebuah paket bisa menambah, membuang atau mengganti artefak native-nya di rilis mana pun. Otoritas terakhirnya selalu biner yang duduk di dalam bundle rilis Anda sendiri.
Pakai ini sebagai titik awal saat sebuah nama file terasa tidak asing, lalu periksa terhadap rilis terbaru dan isu terbuka proyek tersebut. Di tempat yang buktinya hanya berupa pelacak isu milik pengelola, bukan catatan rilis, kartunya menyebutkan hal itu.
Alat 11
Indeks library terlapor
libobjectbox-jni.so
Library native Android versi lama gagal di lingkungan 16 KB. Versi perbaikan yang spesifik tidak terkonfirmasi cukup kuat untuk kami terbitkan di sini. Periksa catatan rilis ObjectBox yang berlaku untuk versi yang menambahkan dukungan 16 KB, lalu pastikan lewat biner di dalam APK hasil build Anda, bukan hanya memercayai nomor versinya.
library Android bawaan paketnya
SDK Dart milik ObjectBox membawa library Android-nya sendiri. Versi perbaikan yang spesifik tidak terkonfirmasi cukup kuat untuk kami terbitkan di sini. Periksa catatan rilis ObjectBox yang berlaku, lalu buktikan artefak yang benar-benar dipilih build Anda.
libsqlite3.so
Dependensi lama 3.43.0 muncul pada pengemasan Flutter dan AWS Amplify yang terdampak. Bukti dari isu menyebut 3.46.1+1 sebagai versi yang menambahkan dukungan 16 KiB. Periksa versi dependensi yang benar-benar terpilih, bukan hanya yang Anda deklarasikan, karena sebuah paket framework bisa mengunci versi yang lebih lama.
sqlcipher-android
Paket lama android-database-sqlcipher sudah tidak dipakai lagi oleh pengembang hulunya dan digantikan paket sqlcipher-android yang dirawat. Tidak ada versi tertentu yang terkonfirmasi cukup kuat untuk kami terbitkan sebagai batas minimum perbaikan, jadi pindahlah ke paket yang dirawat itu lalu periksa setiap ABI di aplikasi hasil build Anda, bukan memercayai nomor versi.
biner pemrosesan media
Repositori FFmpegKit yang asli sudah dipensiunkan, dan tidak ada rilis patuh yang aman secara universal yang bisa ditetapkan. Mutu setiap turunannya berbeda-beda. Kenali persis turunan mana yang dipilih build Anda, periksa langsung artefak setiap ABI-nya, dan timbang perawatan serta asal usulnya sebelum Anda menjadikannya perbaikan.
biner Realm dan JNI
Laporannya saling bertentangan. Versi 20.1.0 sempat ditandai, lalu laporan berikutnya menyebut 20.2.0 memperbaiki satu biner Realm sementara satu biner JNI lain tetap bermasalah. Tidak ada satu versi aman yang bisa disebut secara bertanggung jawab, jadi naikkan versinya lalu periksa satu per satu setiap library yang disumbangkan Realm.
libmediapipe_tasks_vision_jni.so
Dilaporkan berada pada penyelarasan 2**12. Tidak ada rilis perbaikan yang ditetapkan pada isu yang kami baca, jadi perlakukan kompatibilitasnya sebagai hal yang bergantung versi: periksa catatan rilis terbaru, naikkan versinya, lalu buktikan binernya di build Anda sendiri.
artefak OpenCV Android
Masalah penyelarasan dilaporkan terhadap artefak Android OpenCV 5.0.0. Isu di repositorinya menyebut perbaikan di CI, tetapi tidak ada artefak rilis tertentu yang bisa ditetapkan dengan aman. Unduh AAR persis yang menjadi dependensi Anda, buka isinya, lalu periksa sendiri library di dalamnya.
lib_burst_generated.so
Panduan resmi Unity adalah memperbarui paket Burst ke 1.8.21 atau lebih baru saat file ini ditandai. Inilah satu-satunya entri dalam indeks ini yang bersandar pada dokumentasi resmi vendor, bukan laporan isu.
libUnityARCore.so, libquack.so dan lainnya
Laporan komunitas menyebut nama-nama ini di antara biner yang selamat dari kenaikan versi editor. Tidak ada satu versi universal yang bisa dikutip karena masing-masing milik paket yang berbeda. Pakai nama file persisnya untuk menentukan paket mana yang harus Anda kejar.
Tidak ada entri yang cocok dengan saringan itu. Hal itu wajar: indeks ini memuat contoh yang dilaporkan, bukan setiap library di ekosistem. Pakai pencarian pemilik library lalu telusuri file itu di dalam proyek Anda sendiri.
Kenapa indeks ini pendek: jumlah isu menunjukkan proyek mana yang penggunanya vokal, bukan library mana yang paling sering dipasang. Menerbitkan daftar berperingkat berisi "pelanggar paling umum" sama saja dengan mengarang statistik. Yang justru berlaku umum adalah metodenya: ambil nama filenya, temukan paketnya, periksa rilis terbaru paket itu, lalu buktikan binernya di build Anda.
Hubungannya dengan tenggat API 36 pada 31 Agustus 2026
Keduanya adalah dua persyaratan Google Play yang berdiri sendiri dan hanya bertemu di satu titik. Menaikkan level API target bisa memunculkan peringatan 16 KB, karena persyaratan itu berlaku untuk aplikasi yang menargetkan Android 15 (level API 35) atau lebih tinggi. Menaikkan target tidak menciptakan ketidakselarasan itu, dan juga tidak bisa memperbaikinya.
Google Play mewajibkan aplikasi baru dan update aplikasi menargetkan Android 16 (level API 36) mulai 31 Agustus 2026, dengan perpanjangan yang bisa diminta sampai 1 November 2026. Itu perubahan pada manifest dan perilaku aplikasi. Aturan 16 KB adalah perubahan kompatibilitas biner. Developer yang menaikkan targetSdk pada hari Senin lalu melihat peringatan 16 KB pada hari Selasa tidak merusak apa pun: library native-nya memang sudah dibangun untuk halaman 4 KB, dan level target yang lebih tinggi hanya membawa aplikasi masuk ke cakupan pemeriksaan yang cepat atau lambat pasti berlaku.
Persyaratan A
Menargetkan API 36- Tanggal 31 Agustus 2026, perpanjangan sampai 1 November 2026
- Cakupan Aplikasi baru dan update aplikasi
- Ada di Manifest dan konfigurasi build Anda
- Diselesaikan dengan Menaikkan level target dan menangani perubahan perilaku Android 16
Persyaratan B
Dukungan ukuran halaman 16 KB- Tanggal 1 Februari 2027
- Cakupan Aplikasi yang menargetkan API 35+ di perangkat 64 bit
- Ada di Biner native di dalam bundle Anda
- Diselesaikan dengan Membangun ulang atau mengganti setiap library yang tidak selaras
Secara praktis, perlakukan keduanya sebagai satu migrasi dengan dua bukti. Level target toh akan Anda naikkan juga, jadi jadwalkan audit library native pada rilis yang sama daripada menemukannya saat sedang buru-buru mengejar API 36. Untuk daftar lengkap level per bentuk perangkat, pengecualiannya dan cara kerja perpanjangan pada aturan API target, baca artikel kami tentang tenggat API 36 Google Play, dan untuk seluruh urutannya dari akun sampai produksi baca artikel persyaratan publikasi 2026.
Gerbang rilis sebelum upload
Sebelas pemeriksaan, masing-masing dengan bukti kelulusan yang spesifik. Kerjakan semuanya sebelum Anda upload, bukan setelah Play memberi tahu ada yang salah, dan Anda mengubah sesi penelusuran galat yang tak berujung menjadi satu daftar yang terbatas.
Alat 12
Gerbang rilis
0 dari 11 lolos
Belum ada yang terbukti. Mulailah dari build yang memang hendak Anda upload, bukan build terakhir yang kebetulan masih terbuka.
Kemajuan Anda disimpan di browser ini saja. Tidak ada yang dikirim ke mana pun, dan menghapus data browser Anda ikut menghapusnya.
Melewati sebelas gerbang itu membuktikan keselarasan teknis terhadap pemeriksaan yang dikutip di halaman ini. Itu bukan janji persetujuan. Google Play tetap bisa memunculkan masalah kebijakan, konten atau kualitas yang tidak berhubungan pada unggahan yang sama, dan tidak ada daftar periksa di mana pun yang bisa berbicara mewakili hal itu.
Di mana urusan ini bertabrakan dengan pengujian tertutup
Tidak ada satu pun di halaman ini yang mengubah syarat penguji Anda, dan tidak ada apa pun soal penguji Anda yang mengubah build Anda. Kedua masalah itu bertabrakan hanya pada satu sumbu: waktu. Pengujian tertutup 14 hari berjalan di atas jam yang tidak bisa Anda jeda, sedangkan penelusuran library native berjalan di atas jam yang tidak bisa diramalkan siapa pun.
Urutan yang menyakitkan biasanya begini. Sebuah akun developer pribadi memulai pengujian tertutup, jendela keikutsertaan 14 hari berturut-turut mulai berjalan, lalu di tengah jalan kenaikan level target memunculkan peringatan 16 KB. Kini developer membangun ulang dependensi native sementara grup penguji harus tetap utuh di sekitarnya. Mengunggah build baru ke jalur pengujian tidak masalah, dan Google justru menganjurkan developer terus memperbarui aplikasinya selama pengujian. Yang merusak jalannya pengujian adalah sisi penguji yang mendadak sepi.
Bagian itulah yang dijaga tetap stabil oleh PrimeTestLab. Kami menyediakan 12 penguji asli di perangkat asli mulai Android 7 sampai 17, sudah ikut serta dan dipertahankan selama 14 hari penuh, sehingga proses membangun ulang Anda berjalan di atas pengujian yang stabil, bukan yang sedang runtuh. Pengujian mulai dalam 4-6 jam, dan kami sudah menjalankannya untuk lebih dari 7.400 aplikasi di 120+ negara dengan tingkat keberhasilan 99,9%.
Mencari penguji sendiri dibandingkan pengujian yang dikelola
| Persyaratan Google | Mencari sendiri | Dikelola kami |
|---|---|---|
| Minimal 12 penguji yang ikut serta | Mencari, menjelaskan dan mengejar orang sungguhan, lalu berharap tidak ada yang berhenti ikut serta | 12 penguji disediakan dan dijaga sepanjang jendela pengujian |
| 14 hari berturut-turut | Satu penguji yang keluar di tengah jalan memutus jendela 14 hari itu | Grupnya dipantau supaya jendelanya tetap utuh |
| Perangkat asli, orang asli | Emulator dan akun tidak aktif adalah jalan pintas yang biasa dipakai, sekaligus penyebab paling umum pengujian gagal | Perangkat asli dari Android 7 sampai 17 |
| Waktu sampai keikutsertaan pertama | Berhari-hari, tergantung siapa yang membalas Anda | Pengujian mulai dalam 4-6 jam |
| Biaya | Waktu Anda, tepat di minggu saat Anda sudah sibuk membangun ulang library | Mulai $19.99, ditambah biaya layanan 5% |
| Membangun ulang di tengah pengujian | Setiap unggahan baru berarti satu putaran lagi meminta orang memperbarui aplikasinya | Kirim build baru sesuka Anda; grupnya tetap ikut serta |
Supaya batasnya jelas: kami tidak membangun ulang library native Anda, dan artikel ini bukan jualan untuk itu. Pekerjaan 16 KB adalah bagian Anda, dan semua bagian di atas ditulis supaya pekerjaan itu sesingkat mungkin. Yang kami angkat dari pundak Anda adalah syarat penguji yang berjalan bersamaan, supaya kedua masalah itu berhenti memperebutkan dua minggu yang sama.
Tips urutan pengerjaan
Kalau pengujian tertutup belum Anda mulai dan Anda sudah tahu ada library native di aplikasi Anda, jalankan dulu jendela pengujinya lalu kerjakan penyelarasan di dalamnya. Masa kualifikasi Google diukur dari kesinambungan keikutsertaan penguji, bukan dari satu build yang dibekukan, dan Google menganjurkan developer terus memperbarui aplikasinya selama pengujian, jadi kedua garis waktu itu bisa tumpang tindih alih-alih bertumpuk. Pertahankan jalur pengujian dan grup penguji yang sama sambil mengerjakannya. Sering kali itu menghemat satu minggu penuh.
Pertanyaan yang sering diajukan
Apakah Google Play menolak aplikasi yang belum mendukung 16 KB sekarang?
Dokumentasi Google yang berlaku menyatakan bahwa mulai 1 Februari 2027 Anda tidak akan bisa merilis update yang menargetkan Android 15 (level API 35) atau lebih tinggi tanpa dukungan 16 KB di perangkat 64 bit. Sebelum tanggal itu, sebagian besar developer melihat peringatan kompatibilitas di Play Console, bukan pemblokiran keras. Akibat yang tertulis di halaman Google yang dikutip adalah ketidakmampuan merilis update yang belum sesuai, bukan penghapusan otomatis aplikasi yang sudah terbit.
Kenapa Google menyebut 1 Februari 2027 sementara artikel lain menyebut 1 November 2025?
1 November 2025 adalah tenggat yang pertama kali diumumkan Google dan 31 Mei 2026 adalah tanggal perpanjangan berikutnya yang kini bersifat historis. Per 5 Agustus 2026, halaman Android Developers yang berlaku dan tangkapan layar peringatan Play Console yang berlaku sama-sama menunjukkan 1 Februari 2027, jadi sumber primer yang lebih baru itulah yang menentukan. Banyak artikel blog dan jawaban AI masih mengutip tanggal lama karena ditulis sebelum perubahan itu.
Saya tidak pernah menulis C++. Kenapa aplikasi saya ikut terdampak?
Sebuah framework, SDK, plugin, mesin gim, basis data, komponen media atau app builder bisa menambahkan file .so meskipun kode sumber Anda sendiri ditulis dengan Dart, JavaScript, Python, Java atau Kotlin. Panduan Google secara tegas mencakup aplikasi yang memakai library NDK secara tidak langsung lewat dependensi. Buka APK Anda di Android Studio lewat Build lalu Analyze APK; setiap file .so di bawah lib berarti aplikasi yang dikemas memang memakai kode native.
Apakah aplikasi Kotlin murni perlu diubah?
Menurut Google, aplikasi yang hanya memakai Java atau Kotlin, termasuk seluruh library dan SDK di dalamnya, sudah mendukung perangkat 16 KB. Google tetap menyarankan pengujian di lingkungan 16 KB untuk berjaga terhadap kemunduran yang tidak terduga. Pastikan APK rilis yang sebenarnya tidak punya direktori lib sebelum Anda menyebut aplikasi Anda Kotlin murni, karena satu dependensi analitik atau basis data saja bisa menambahkannya.
Versi Flutter berapa yang memperbaiki peringatan ukuran halaman 16 KB?
Tidak ada sumber resmi yang menetapkan satu versi Flutter yang menjamin setiap aplikasi dan plugin Flutter sudah sesuai. Catatan rilis Flutter 3.27 lebih sempit daripada kesan yang ditimbulkannya, karena mencakup dukungan 16 KB untuk template plugin_ffi secara khusus, bukan seluruh engine. Flutter 3.38 adalah tonggak berdokumentasi paling kuat: Flutter secara eksplisit memposisikan naik ke versi itu sebagai persiapan menghadapi persyaratan 16 KB Play dan mengganti NDK bawaannya menjadi r28. Langkah paling aman adalah pindah ke rilis stabil Flutter terbaru, memperbarui setiap plugin native, membangun ulang bundle rilis, lalu memeriksa setiap file .so yang dihasilkan.
Versi React Native berapa yang mendukung halaman 16 KB?
React Native 0.77 adalah patokan resmi yang jelas. Pengumuman rilisnya menyatakan bahwa React Native siap mendukung penuh ukuran halaman 16 KB. Modul komunitas native, kode C++ lokal dan SDK pihak ketiga tetap bisa membawa biner yang tidak kompatibel, jadi naikkan versi lewat jalur migrasi React Native atau Expo yang didukung, lalu periksa APK yang dihasilkan.
Versi Unity berapa yang saya butuhkan untuk dukungan ukuran halaman 16 KB?
Unity menyebut 6000.1 atau lebih baru, 6000.0.38f1 atau lebih baru, 2022.3.56f1 atau lebih baru, dan 2021.3.48f1 atau lebih baru di bawah LTS diperpanjang untuk pelanggan Enterprise atau Industry yang memenuhi syarat. Perbarui juga plugin native Anda, dan naikkan Burst ke 1.8.21 atau lebih baru kalau Play Console menyebut lib_burst_generated.so. Versi editor yang didukung itu perlu tetapi belum cukup, karena plugin pihak ketiga membawa binernya sendiri.
Bagaimana cara menemukan file .so yang persis gagal?
Buka APK lewat Build lalu Analyze APK di Android Studio, buka lib/arm64-v8a dan lib/x86_64, lalu baca kolom Alignment yang menampilkan peringatan untuk file yang bermasalah penyelarasannya. Untuk konfirmasi lewat baris perintah, jalankan skrip check_elf_alignment.sh milik Google terhadap APK itu, atau periksa satu library dengan llvm-objdump -p file.so yang disalurkan ke grep LOAD. Setiap penyelarasan LOAD di bawah 2**14 perlu ditangani.
Kenapa APK saya lolos tetapi app bundle saya tetap gagal?
Penyelarasan ELF di dalam sebuah library dan penyelarasan ZIP di dalam artefak yang dikemas adalah dua pemeriksaan yang berbeda. Jalankan bundletool dump config --bundle=app.aab lalu cari kata alignment: PAGE_ALIGNMENT_16K berarti lolos, sedangkan PAGE_ALIGNMENT_4K berarti APK yang dihasilkan masih diminta pada 4 KB. Google secara khusus memperingatkan bahwa Android Gradle Plugin 8.3 sampai 8.5 bisa terlihat benar di komputer Anda padahal APK yang dibangun Play dari bundle Anda tidak tersejajarkan ZIP dengan benar, jadi pindahlah ke 8.5.1 atau lebih baru.
Apakah cukup naik ke NDK r28 untuk memperbaikinya?
Tidak. NDK r28 ke atas mengompilasi dengan penyelarasan 16 KB secara bawaan, tetapi itu hanya berlaku untuk kode native yang dikompilasi saat build Anda berjalan. NDK tidak bisa menulis ulang file .so yang sudah terkompilasi dan datang di dalam paket AAR, plugin atau mesin gim pihak ketiga. Setiap dependensi native siap pakai harus diperbarui, diganti, atau dibangun ulang lalu diimpor kembali.
Bagaimana cara menguji dukungan 16 KB tanpa punya ponsel yang mendukung?
Pasang salah satu image sistem Android Emulator 16 KB dari Google lewat SDK Manager, atau pesan perangkat yang didukung lewat Samsung Remote Test Lab. Apa pun yang Anda pakai, pastikan dulu lingkungannya dengan adb shell getconf PAGE_SIZE; keluarannya harus 16384 sebelum pengujian itu berarti apa pun. Keberhasilan di emulator membuktikan perilaku saat berjalan, bukan cara pengemasan, jadi tetap periksa juga bundle rilis Anda.
Apakah memperbaiki dukungan 16 KB mereset atau mengganggu pengujian tertutup saya?
Google mengukur masa kualifikasi dari minimal 12 penguji yang terus-menerus ikut serta selama 14 hari, bukan dari satu build yang dibekukan, dan Google menganjurkan developer terus memperbarui build-nya selama pengujian. Google tidak menerbitkan jaminan tersurat yang mencakup setiap skenario penggantian build, jadi cara paling aman adalah menjaga grup penguji Anda tetap stabil sambil mengirim bundle baru yang sudah sesuai 16 KB di tengah pengujian. PrimeTestLab menyediakan 12 penguji asli di perangkat asli mulai $19.99 ditambah biaya layanan 5%, dan menjaga grup itu selama 14 hari penuh.
Intinya
Ringkasan
Google Play mewajibkan aplikasi yang menargetkan Android 15 (level API 35) atau lebih tinggi mendukung ukuran halaman memori 16 KB di perangkat 64 bit, dan mulai 1 Februari 2027 update yang belum sesuai tidak bisa dirilis. 1 November 2025 dan 31 Mei 2026 adalah tanggal mati yang masih sering muncul di hasil pencarian. Aplikasi murni Java atau Kotlin sudah otomatis memenuhi syarat. Selebihnya mengerjakan tiga langkah yang sama: sebutkan file .so yang gagal, perbarui paket pemiliknya, lalu buktikan artefaknya lewat dua pemeriksaan yang saling bebas, yaitu setiap segmen LOAD ELF berada di 2**14 atau lebih besar, dan bundle melaporkan PAGE_ALIGNMENT_16K. AGP 8.5.1+ dengan NDK r28+ adalah toolchain bawaan yang paling aman, dan tidak satu pun dari keduanya bisa memperbaiki biner yang dikompilasi orang lain. Kalau semua ini datang di tengah pengujian tertutup, sisi pengujilah bagian yang bisa Anda serahkan. Lihat paket harga →
Sumber primer
Apa yang paling cepat basi di halaman ini
- Tanggal 1 Februari 2027. Google sudah lebih dari sekali menggeser garis waktu ini. Periksa stempel "Last updated" di bagian bawah panduan ukuran halaman sebelum Anda menyusun jadwal rilis di sekitarnya.
- Teks di Play Console. Kalimat dan navigasi Konsol Play berubah terpisah dari halaman kebijakan, jadi judul persis yang Anda lihat bisa berbeda dari yang direproduksi di sini.
- Patokan versi framework. Flutter merilis versi stabil dengan cepat, kebijakan dukungan React Native terus berkembang, dan kelayakan Unity LTS berubah. Pastikan lewat catatan rilis terbaru, bukan lewat nomor versi yang tercetak di sebuah artikel.
- Indeks library yang dilaporkan. Paket mana pun bisa menambah, mengganti atau menurunkan kualitas biner native-nya di rilis mana pun. Selalu periksa artefak di dalam bundle Anda sendiri.
- Nama image emulator. Image yang berlabel eksperimental bisa berganti nama atau dinaikkan statusnya, jadi teks persisnya di SDK Manager bisa tidak cocok.
Diverifikasi terhadap dokumentasi Google pada 9 Agustus 2026. Ditinjau setiap bulan sampai sedikitnya satu bulan setelah aturan diberlakukan.