Mendukung ukuran halaman 16 KB

Sebelumnya, Android hanya mendukung ukuran halaman memori 4 KB, yang telah mengoptimalkan performa memori sistem untuk jumlah total memori rata-rata yang biasanya dimiliki perangkat Android. Mulai dari Android 15, AOSP mendukung perangkat yang dikonfigurasi untuk menggunakan ukuran halaman 16 KB (perangkat 16 KB). Jika aplikasi Anda menggunakan library NDK, baik secara langsung maupun tidak langsung melalui SDK, Anda harus membangun ulang aplikasi agar dapat berfungsi di perangkat 16 KB ini.

Seiring produsen perangkat terus membuat perangkat dengan jumlah memori fisik (RAM) yang lebih besar, banyak perangkat ini akan mengadopsi ukuran halaman 16 KB (dan pada akhirnya lebih besar) untuk mengoptimalkan performa perangkat. Menambahkan dukungan untuk perangkat dengan ukuran halaman 16 KB memungkinkan aplikasi Anda berjalan di perangkat ini dan membantu aplikasi Anda mendapatkan manfaat dari peningkatan performa terkait. Tanpa dikompilasi ulang, aplikasi tidak akan berfungsi di perangkat 16 KB dalam rilis Android mendatang.

Untuk membantu Anda menambahkan dukungan bagi aplikasi, kami telah memberikan panduan tentang cara memeriksa apakah aplikasi Anda terpengaruh, cara membangun ulang aplikasi (jika berlaku), dan cara menguji aplikasi Anda di lingkungan 16 KB menggunakan emulator (termasuk image sistem Android 15 untuk Android Emulator).

Persyaratan kompatibilitas Google Play

Untuk memastikan aplikasi Anda berfungsi dengan benar di versi Android terbaru, semua aplikasi yang menargetkan Android 15 (level API 35) dan yang lebih tinggi harus mendukung ukuran halaman memori 16 KB di perangkat 64-bit di Google Play. Mulai 1 Februari 2027, jika update aplikasi Anda tidak mendukung ukuran halaman memori 16 KB, Anda tidak akan dapat merilis update tersebut.

Manfaat dan peningkatan performa

Perangkat yang dikonfigurasi dengan ukuran halaman 16 KB menggunakan memori yang sedikit lebih banyak secara rata-rata, tetapi juga mendapatkan berbagai peningkatan performa untuk sistem dan aplikasi:

• Waktu peluncuran aplikasi lebih rendah saat sistem berada dalam tekanan memori: rata-rata 3,16% lebih rendah, dengan peningkatan yang lebih signifikan (hingga 30%) untuk beberapa aplikasi yang kami uji
• Mengurangi penggunaan daya selama peluncuran aplikasi: Pengurangan rata-rata 4,56%
• Peluncuran kamera lebih cepat: rata-rata hot start 4,48% lebih cepat dan cold start 6,60% lebih cepat
• Waktu booting sistem yang lebih baik: rata-rata meningkat sebesar 8% (sekitar 950 milidetik)

Peningkatan ini didasarkan pada pengujian awal kami, dan hasil pada perangkat aktual kemungkinan akan berbeda. Kami akan memberikan analisis tambahan tentang potensi keuntungan untuk aplikasi saat kami melanjutkan pengujian.

Memeriksa apakah aplikasi Anda terpengaruh

Jika aplikasi Anda menggunakan kode native, Anda harus membangun ulang aplikasi dengan dukungan untuk perangkat 16 KB. Jika tidak yakin apakah aplikasi Anda menggunakan kode native atau tidak, Anda dapat menggunakan APK Analyzer untuk mengidentifikasi apakah ada kode native atau tidak, lalu memeriksa perataan segmen ELF untuk library bersama yang Anda temukan. Android Studio juga menyediakan fitur yang membantu Anda mendeteksi masalah perataan secara otomatis.

Jika aplikasi Anda hanya menggunakan kode yang ditulis dalam bahasa pemrograman Java atau di Kotlin, termasuk semua library atau SDK, berarti aplikasi Anda sudah mendukung perangkat 16 KB. Namun, sebaiknya Anda menguji aplikasi di lingkungan 16 KB untuk memverifikasi bahwa tidak ada regresi perilaku aplikasi yang tidak terduga.

Apakah aplikasi Anda menggunakan kode native?

Aplikasi Anda menggunakan kode native jika salah satu hal berikut berlaku:

• Aplikasi Anda menggunakan kode C/C++ (native). Jika aplikasi Anda menggunakan Android NDK, berarti aplikasi Anda menggunakan kode native.
• Aplikasi Anda terhubung dengan library atau dependensi native pihak ketiga (seperti SDK) yang menggunakannya.
• Aplikasi Anda dibuat oleh pembuat aplikasi pihak ketiga yang menggunakan library native di perangkat.

Mengidentifikasi library native menggunakan APK Analyzer

APK Analyzer adalah alat yang memungkinkan Anda mengevaluasi berbagai aspek APK yang telah dibangun. Untuk memeriksa apakah aplikasi Anda menggunakan kode native (terlepas dari apakah aplikasi tersebut kompatibel dengan 16 KB):

1. Buka Android Studio, lalu klik File > Open dan pilih project apa saja.

2. Dari panel menu, klik Build > Analyze APK...

   

3. Pilih APK yang ingin Anda analisis.

4. Lihat di dalam folder lib, yang menghosting file objek bersama (.so) jika ada. Jika ada file objek bersama, aplikasi Anda menggunakan kode native. Kolom Penyejajaran menampilkan pesan peringatan untuk file yang memiliki masalah penyejajaran. Jika tidak ada file objek bersama atau tidak ada folder lib, berarti aplikasi Anda tidak menggunakan kode native.

   

Mendeteksi masalah perataan dengan pemeriksaan otomatis

Android Studio akan memberikan peringatan secara proaktif jika library atau APK bawaan Anda tidak mematuhi ukuran halaman 16 KB. Gunakan alat APK Analyzer untuk meninjau library mana yang perlu diupdate atau apakah ada perubahan kode yang diperlukan.

Lint di Android Studio juga menandai library native yang tidak selaras dengan 16 KB.

Memeriksa keselarasan segmen ELF untuk pustaka bersama

Untuk library bersama, pastikan segmen ELF library bersama diselaraskan dengan benar menggunakan penyelarasan ELF 16 KB. Jika Anda mengembangkan di Linux atau macOS, Anda dapat menggunakan skrip check_elf_alignment.sh seperti yang dijelaskan di bagian berikut. Anda juga dapat menggunakan alat command line secara langsung.

Menggunakan skrip check_elf_alignment.sh (Linux atau macOS)

Ikuti langkah-langkah berikut untuk memeriksa keselarasan segmen ELF menggunakan skrip check_elf_alignment.sh:

1. Simpan skrip check_elf_alignment.sh ke file.

2. Jalankan skrip pada file APK aplikasi Anda:

   check_elf_alignment.sh APK_NAME.apk
   

   Skrip akan menghasilkan ALIGNED atau UNALIGNED untuk semua pustaka bersama arm64-v8a.

3. Jika ada library bersama arm64-v8a atau x86_64 yang UNALIGNED, Anda harus memperbarui pengemasan untuk library tersebut, lalu mengompilasi ulang aplikasi dan menguji ulang dengan mengikuti langkah-langkah di bagian ini.

Menggunakan alat command line secara langsung

Ikuti langkah-langkah berikut untuk memeriksa penyelarasan segmen ELF menggunakan alat command line secara langsung:

1. Pastikan Android SDK Build-Tools versi 35.0.0 atau yang lebih tinggi dan Android NDK diinstal menggunakan SDK Manager di Android Studio atau alat command line sdkmanager.

2. Ekstrak file APK aplikasi Anda:

   Linux atau macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. Di direktori sementara tempat Anda mengekstrak file APK, periksa konten direktori lib untuk file objek bersama (.so). Ini adalah file objek bersama yang sama yang akan Anda lihat saat mengidentifikasi library native menggunakan APK Analyzer. Jalankan perintah berikut pada setiap file objek bersama:

   Linux atau macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   Dengan SDK_ROOT_LOCATION adalah jalur ke direktori tempat Anda menginstal Android SDK, SHARED_OBJECT_FILE adalah nama file objek bersama yang Anda periksa, dan NDK_VERSION adalah versi Android NDK yang telah Anda instal (misalnya, 28.0.12433566). Outputnya akan terlihat seperti berikut untuk setiap file yang Anda periksa:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Periksa baris output untuk memastikan segmen pemuatan tidak memiliki nilai kurang dari 2**14. Jika ada segmen pemuatan yang bernilai 2**13, 2**12, atau lebih rendah, Anda harus mengupdate pengemasan untuk library tersebut, lalu mengompilasi ulang aplikasi dan menguji ulang dengan mengikuti langkah-langkah di bagian ini.

5. Selanjutnya, jalankan alat command line zipalign pada file APK aplikasi Anda:

   Linux atau macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   Dengan SDK_ROOT_LOCATION adalah jalur ke direktori tempat Anda menginstal Android SDK, dan APK_NAME adalah nama file APK aplikasi Anda. Baris terakhir output akan menampilkan "Verification successful" jika semua pustaka bersama sudah diselaraskan dengan benar.

   Jika verifikasi gagal, beberapa library bersama perlu disesuaikan, jadi Anda harus mengupdate paket untuk library tersebut, lalu mengompilasi ulang aplikasi dan menguji ulang dengan mengikuti langkah-langkah di bagian ini.

Memeriksa tanda keamanan RELRO

Untuk mengurangi eksploitasi keamanan, penaut modern menggunakan flag Relocation Read-Only (RELRO) untuk membuat bagian relokasi file objek bersama menjadi hanya baca setelah dimuat. Aktifkan flag RELRO di build Anda.

Bagian RELRO yang memiliki alamat awal ditambah ukuran segmen (MemSize) yang tidak selaras dengan 16 KB akan membuat aplikasi error saat runtime dengan kesalahan segmentasi. Hal ini terjadi jika file .so dibuat dengan toolchain NDK r27 dan yang lebih rendah tanpa mengaktifkan flag yang relevan.

Jalankan perintah berikut pada setiap file objek bersama (Linux atau macOS):

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'

String GNU_RELRO dicetak jika ada segmen RELRO.

Selanjutnya, periksa perataan segmen RELRO dengan menjumlahkan alamat offset virtualnya (VirtAddr) dengan ukuran memori segmen (MemSiz) dan membaginya dengan 16 KB (0x4000). Jika sisanya (modulo) adalah nol, berarti segmen RELRO selaras dengan 16 KB.

Berikut contoh file .so yang tidak selaras:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

Formula: (VirtAddr + MemSiz) % 0x4000 == 0

Hasil: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

Karena 0x1000 bukan nol, file .so ini tidak sesuai dengan ukuran halaman 16 KB. Rentang perlindungan RELRO dari DC000 (break halaman sebelumnya) hingga E4000 bersifat hanya baca, tetapi Android Linker mengharapkan sub-rentang dari E1000 hingga E4000 dapat ditulis, sehingga menyebabkan kesalahan segmentasi. Dalam hal ini, bangun kembali file .so seperti yang dijelaskan di bagian Mengompilasi aplikasi menggunakan perataan ELF 16 KB.

Berikut adalah contoh file .so yang selaras, dengan segmen RELRO:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1  

Berikut adalah contoh file .so tanpa segmen RELRO:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align

Ini adalah file .so yang mematuhi 16 KB tanpa memiliki segmen RELRO apa pun.

Berikut contoh file .so yang selaras dengan GNU_RELRO dalam segmen LOAD-nya sendiri:

Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000680 0x000680 R E 0x4000
LOAD           0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 RW  0x4000
GNU_RELRO      0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 R   0x1

Formula: (VirtAddr + MemSiz) % 0x4000 == 0

Hasil: (0x4680 + 0x0980) % 0x4000 = 0x5000 % 0x4000 == 0x1000

Meskipun 0x1000 bukan nol, file .so ini tetap sesuai dengan 16 KB.

Formula modulo berlaku saat GNU_RELRO berbagi segmen LOAD dengan data berikutnya yang dapat ditulis (seperti .data atau .bss).

Untuk memeriksa apakah GNU_RELRO berada di segmen LOAD-nya sendiri, periksa header program dengan menjalankan llvm-readelf -Wl dan memfilter dengan grep 'LOAD\|RELRO\|Type'. Bandingkan VirtAddr dan MemSiz dari GNU_RELRO dengan segmen LOAD yang memuatnya. Dalam contoh ini, keduanya memiliki VirtAddr 0x4680 dan MemSiz 0x0980.

Karena seluruh segmen LOAD hanya berisi data RELRO, tidak ada data yang dapat ditulis dalam sub-rentang dari 0x5000 hingga 0x8000. Selain itu, segmen LOAD yang dapat ditulis berikutnya dimulai pada batas halaman 16 KB terpisah (di 0x8000 atau lebih). Perlindungan hanya baca penaut tidak akan tumpang-tindih dengan data yang dapat ditulis, sehingga tidak terjadi kesalahan segmentasi.

Membangun aplikasi dengan dukungan untuk perangkat 16 KB

Jika aplikasi Anda menggunakan kode native, selesaikan langkah-langkah yang diuraikan di bagian berikut untuk memastikan aplikasi Anda mendukung perangkat 16 KB:

1. Mengupdate paket pustaka bersama
2. Kompilasi aplikasi Anda menggunakan penyelarasan ELF 16 KB
3. Memperbaiki kode dan menyelesaikan masalah runtime
4. Mengoptimalkan pengalokasi memori kustom (jika ada)
5. Memeriksa dukungan 16 KB pada SDK

Mengupdate paket pustaka bersama

Upgrade ke AGP versi 8.5.1 atau yang lebih tinggi dan gunakan pustaka bersama yang tidak dikompresi.

Gunakan bundletool untuk memverifikasi penyelarasan ritsleting

Untuk melihat penyelarasan paket, gunakan:

bundletool dump config --bundle=<my .aab>  | grep alignment

Jika melihat PAGE_ALIGNMENT_16K, berarti Anda tahu bahwa paket Anda meminta perataan zip 16 KB. Jika Anda melihat PAGE_ALIGNMENT_4K, ini akan menginstruksikan APK yang di-build dari AAB ini untuk memiliki file .so yang diratakan 4 KB dalam file ZIP.

AGP versi 8.5.1 atau yang lebih tinggi

Perangkat 16 KB memerlukan aplikasi yang dikirim dengan pustaka bersama yang tidak dikompresi untuk menyelaraskannya pada batas zip-aligned 16 KB. Untuk melakukannya, Anda harus mengupgrade ke Plugin Android Gradle (AGP) versi 8.5.1 atau yang lebih tinggi. Lihat bagian Asisten Upgrade plugin Android Gradle untuk mengetahui detail tentang proses upgrade.

AGP versi 8.5 atau yang lebih rendah

Jika Anda tidak dapat mengupgrade AGP ke versi 8.5.1 atau yang lebih tinggi, alternatifnya adalah beralih ke penggunaan pustaka bersama yang dikompresi. Perbarui konfigurasi Gradle Anda agar Gradle mengompresi pustaka bersama saat memaketkan aplikasi untuk menghindari masalah penginstalan aplikasi dengan pustaka bersama yang tidak selaras.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

AGP versi 8.0 atau yang lebih rendah

Jika Anda menggunakan versi AGP yang sama atau lebih rendah dari 8.0, Anda juga harus menonaktifkan opsi library native yang tidak dikompresi untuk App Bundle di file gradle.properties:

android.bundle.enableUncompressedNativeLibs=false

Mengompilasi aplikasi Anda menggunakan penyelarasan ELF 16 KB

Perangkat 16 KB memerlukan segmen ELF library bersama untuk diselaraskan dengan benar menggunakan penyelarasan ELF 16 KB agar aplikasi Anda dapat berjalan.

Untuk developer game, jika game Anda berjalan di atas game engine Unity, lihat panduan Unity. Jika game Anda berjalan di atas game engine Unreal, lihat panduan Unreal.Untuk game engine native, lanjutkan dengan panduan ini.

Untuk mengompilasi aplikasi menggunakan perataan ELF 16 KB, selesaikan langkah-langkah di salah satu bagian berikut, bergantung pada versi Android NDK yang Anda gunakan.

Android NDK r28 dan yang lebih baru

NDK versi r28 dan yang lebih tinggi mengompilasi perataan 16 KB secara default.

Android NDK r27 dan yang lebih lama

Untuk mendukung kompilasi pustaka bersama yang selaras dengan 16 KB menggunakan Android NDK versi r27 atau yang lebih rendah, gunakan flag penaut berikut:

-Wl,-z,max-page-size=16384
-Wl,-z,common-page-size=16384

Berikut cara mengupdate file konfigurasi sistem build Anda:

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

Memperbaiki kode dan menyelesaikan masalah runtime

Meskipun diselaraskan dengan 16 KB, aplikasi Anda dapat mengalami error jika ada bagian dalam kode Anda yang mengasumsikan bahwa perangkat menggunakan ukuran halaman tertentu. Untuk menghindari hal ini, selesaikan langkah-langkah berikut:

1. Hapus dependensi hardcode yang mereferensikan konstanta PAGE_SIZE atau instance dalam logika kode Anda yang mengasumsikan bahwa ukuran halaman perangkat adalah 4 KB (4096).

   Sebagai gantinya, gunakan getpagesize() atau sysconf(_SC_PAGESIZE).

2. Cari penggunaan mmap() dan API lain yang memerlukan argumen yang selaras dengan halaman dan ganti dengan alternatif jika diperlukan.

Dalam beberapa kasus, jika aplikasi Anda menggunakan PAGE_SIZE sebagai nilai praktis yang tidak terikat dengan ukuran halaman yang mendasarinya, hal ini tidak akan menyebabkan aplikasi Anda rusak saat digunakan dalam mode 16 KB. Namun, jika nilai ini diteruskan ke kernel dengan mmap tanpa MAP_FIXED, kernel tetap menggunakan seluruh halaman, yang membuang-buang beberapa memori. Oleh karena itu, PAGE_SIZE tidak ditentukan saat mode 16 KB diaktifkan di NDK r27 dan yang lebih tinggi.

Jika aplikasi Anda menggunakan PAGE_SIZE dengan cara ini dan tidak pernah meneruskan nilai ini secara langsung ke kernel, maka alih-alih menggunakan PAGE_SIZE, buat variabel baru dengan nama baru untuk mencerminkan bahwa variabel tersebut digunakan untuk tujuan lain dan tidak mencerminkan halaman memori yang sebenarnya.

Mengoptimalkan pengalokasi memori kustom

Pada sistem 16 KB, unit memori fisik terkecil yang dialokasikan sistem operasi berukuran empat kali lebih besar daripada sistem 4 KB. Jika alokator kustom didesain berdasarkan asumsi 4 KB, alokator tersebut dapat menyebarkan objek kecil di beberapa halaman 16 KB dan mempertahankan memori kosong yang tidak perlu. Hal ini dapat meningkatkan penggunaan memori fisik (RSS) secara signifikan dan menurunkan efisiensi swap terkompresi (ZRAM).

Jika kode Anda mengelola kumpulan memorinya sendiri, ikuti rekomendasi berikut:

1. Menghindari nilai minimum byte hard code untuk mengosongkan memori

Banyak pengalokasi menggunakan batas byte tetap untuk memutuskan kapan harus melepaskan memori kembali ke OS menggunakan madvise(MADV_DONTNEED) (misalnya, hanya melepaskan memori jika objek aktif menggunakan kurang dari 8 KB).

Pada sistem 16 KB, bahkan satu objek aktif 16 byte akan menyematkan seluruh halaman 16 KB (yang lebih besar dari 8 KB). Akibatnya, nilai minimum rilis tidak pernah terpenuhi, dan pengalokasi tidak pernah mengembalikan memori yang tidak digunakan di sekitarnya ke kernel.

Yang harus dilakukan: Jangan pernah menggunakan konstanta byte hard code untuk heuristik rilis halaman. Skalakan nilai minimum rilis secara dinamis saat runtime berdasarkan ukuran halaman sebenarnya menggunakan sysconf(_SC_PAGESIZE).

2. Mengisi halaman yang sudah digunakan terlebih dahulu (alokasi dense-first)

Jika pengalokasi membagikan memori dalam urutan first-in-first-out (FIFO) atau round-robin, alokasi baru akan tersebar di banyak halaman 16 KB yang terisi sebagian. Satu objek di halaman membuat semua 16 KB tetap berada di RAM fisik.

Yang harus dilakukan: Selalu alokasikan objek baru dari halaman atau slab yang paling penuh (paling padat) sebelum menyentuh halaman yang kosong atau jarang digunakan. Memusatkan alokasi baru pada halaman yang sudah kotor memungkinkan halaman yang jarang digunakan secara alami terkuras hingga nol objek aktif, sehingga seluruh halaman 16 KB dapat dirilis ke OS.

3. Menyelaraskan kumpulan memori ke 16 KB dan menjaga ukuran kumpulan tetap sedang

Rentang multi-halaman yang dirancang untuk sistem 4 KB dapat menampung kelonggaran memori yang belum dirilis secara berlebihan pada kernel 16 KB. Selain itu, class ukuran yang tidak dibagi secara merata menjadi 16 KB akan menyebabkan fragmentasi di akhir setiap halaman.

Yang harus dilakukan:

• Pastikan semua kumpulan memori, batas slab, dan perataan buffer adalah kelipatan persis dari ukuran halaman runtime.
• Evaluasi ulang ukuran span multi-halaman untuk class objek kecil guna menghindari alokasi slab yang terlalu besar yang menjebak memori tidak ada aktivitas.

4. Segera melepaskan memori fisik untuk buffer besar yang di-cache

Alokator kustom sering kali meng-cache buffer besar (> 64 KB) dalam kumpulan dalam memori sehingga dapat digunakan kembali tanpa membayar overhead panggilan sistem mmap atau munmap. Namun, menyimpan buffer kotor ini dalam memori akan membuang-buang megabyte RAM fisik saat menunggu timer pengosongan.

Yang harus dilakukan: Tetap cadangkan rentang alamat memori virtual untuk penggunaan kembali yang cepat, tetapi segera panggil madvise(..., MADV_DONTNEED) atau madvise(..., MADV_FREE) saat mengembalikan buffer ke cache. Sistem operasi akan segera mengklaim kembali RAM fisik, sementara aplikasi Anda masih dapat menggunakan kembali alamat virtual secara instan tanpa mengalokasikan ulang.

5. Mengosongkan memori saat bebas, bukan saat alokasi untuk kompresi ZRAM

Android menggunakan swap terkompresi (ZRAM) untuk menyimpan aplikasi latar belakang dalam memori. Di perangkat 16 KB, jika halaman menyimpan satu objek aktif, seluruh halaman 16 KB akan tetap berada di memori atau ditukar ke ZRAM. Data sampah yang tersisa (seperti pointer dan string yang tidak berlaku) di bagian halaman yang sebelumnya dibebaskan dikompresi dengan buruk.

Jika pengalokasi Anda melakukan inisialisasi nol pada memori (seperti untuk keamanan atau alokasi yang diinisialisasi nol), pertimbangkan untuk melakukan inisialisasi nol saat dealokasi (free()), bukan saat alokasi:

• Halaman yang disematkan lebih hemat biaya: Memori tidak ada aktivitas di halaman 16 KB yang terisi sebagian dikompresi hingga hampir tidak ada di ZRAM, sehingga halaman yang disematkan tidak membuang-buang ruang swap fisik.
• Overhead cache minimal: Pada saat free() dipanggil, memori sudah panas di cache CPU, sehingga menghindari cache tidak ditemukan tambahan di kemudian hari.

Ringkasan rekomendasi

Memeriksa dukungan 16 KB pada SDK

Banyak SDK kompatibel dengan ukuran halaman 16 KB, terutama jika Anda membuatnya sendiri atau mendapatkan versi pra-build terbaru. Namun, karena beberapa SDK bawaan atau versi SDK tidak kompatibel dengan 16 KB, Anda harus memeriksa situs setiap penyedia SDK untuk menentukan versi yang akan digunakan dengan 16 KB.

Menguji aplikasi Anda di lingkungan 16 KB

Setelah membangun aplikasi dengan dukungan untuk perangkat 16 KB, Anda harus menguji aplikasi di lingkungan 16 KB untuk melihat apakah aplikasi Anda mengalami regresi. Untuk melakukannya, ikuti langkah-langkah ini:

1. Siapkan Android 15 SDK atau yang lebih baru.

2. Siapkan salah satu lingkungan pengujian berikut:

   • Menyiapkan Android Emulator dengan image sistem Android 15 berbasis 16 KB
   • Menggunakan Cuttlefish dengan ukuran halaman 16 KB di ARM64
   • Simulasikan Cuttlefish dengan ukuran halaman 16 KB di x86-64
   • Mengaktifkan mode 16 KB di perangkat menggunakan opsi developer
   • Menggunakan Samsung Remote Test Lab di 16 KB perangkat yang didukung

3. Mulai perangkat pengujian, lalu jalankan perintah berikut untuk memverifikasi bahwa perangkat menggunakan lingkungan 16 KB:

   adb shell getconf PAGE_SIZE
   

   Perintah akan menampilkan nilai 16384.

4. Jalankan perintah zipalign berikut untuk memverifikasi bahwa aplikasi Anda selaras dengan 16 KB, dengan APK_NAME adalah nama file APK aplikasi Anda:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. Uji aplikasi Anda secara menyeluruh, dengan berfokus pada area yang mungkin terpengaruh oleh perubahan instance kode yang mereferensikan ukuran halaman tertentu.

Menyiapkan Android Emulator dengan image sistem berbasis 16 KB

Untuk menyiapkan lingkungan 16 KB menggunakan Android Emulator, ikuti langkah-langkah berikut:

1. Di Android Studio, klik Tools > SDK Manager.

2. Di tab SDK Platforms, pilih Show Package Details, lalu luaskan bagian Android VanillaIceCream atau yang lebih tinggi dan pilih salah satu atau kedua image sistem emulator berikut, bergantung pada perangkat virtual yang ingin Anda buat:

   • Image Sistem ARM 64 v8a Google APIs Experimental dengan Ukuran Halaman 16 KB
   • Image Sistem Atom Intel x86_64 Ukuran Halaman 16 KB Eksperimental Google API

   

3. Klik Terapkan > Oke untuk mendownload image sistem yang Anda pilih.

4. Ikuti langkah-langkah untuk menyiapkan perangkat virtual untuk Android 15, dan saat diminta untuk memilih image sistem, pilih image sistem 16 KB yang Anda download. Jika tidak direkomendasikan secara otomatis, Anda dapat menemukan image sistem 16 KB di tab Other Images.

   

Luncurkan emulator

Setelah Anda selesai menyiapkan Android Emulator dan perangkat virtual, luncurkan emulator dari menu perangkat target, atau dari command line.

Mengaktifkan mode 16 KB di perangkat menggunakan opsi developer

Aktifkan opsi developer Boot dengan ukuran halaman 16 KB untuk mem-boot perangkat dalam mode 16 KB.

Dalam versi QPR Android 15, Anda dapat menggunakan opsi developer yang tersedia di perangkat tertentu untuk mem-boot perangkat dalam mode 16 KB dan melakukan pengujian di perangkat. Sebelum menggunakan opsi developer, buka Setelan > Sistem > Update software dan terapkan update yang tersedia.

Opsi developer ini tersedia di perangkat berikut:

• Pixel 8 dan 8 Pro (dengan Android 15 QPR1 atau yang lebih tinggi)

• Pixel 8a (dengan Android 15 QPR1 atau yang lebih baru)

• Pixel 9, 9 Pro, dan 9 Pro XL (dengan Android 15 QPR2 atau yang lebih baru)

• Pixel 9a (dengan Android 16 atau yang lebih baru)

Mode kompatibilitas mundur 16 KB

Peringatan dalam mode kompatibilitas ukuran halaman

Opsi kompatibilitas mundur 16 KB tersedia saat perangkat berjalan dengan kernel 16 KB. Pengelola paket menjalankan aplikasi dalam mode kompatibilitas mundur 16 KB jika kondisi berikut terpenuhi:

• Jika aplikasi memiliki file ELF (dengan ekstensi .so) dengan perataan segmen LOAD sebesar 4 KB.
• Jika APK yang di-ZIP memiliki file ELF yang tidak dikompresi dan diselaraskan dengan ZIP 4 KB

Jika pengelola paket telah mengaktifkan mode kompatibilitas mundur 16 KB untuk aplikasi, aplikasi akan menampilkan peringatan saat pertama kali diluncurkan yang menyatakan bahwa aplikasi berjalan dalam mode kompatibilitas mundur 16 KB.

Mode kompatibilitas mundur 16 KB memungkinkan beberapa aplikasi berfungsi, tetapi untuk keandalan dan stabilitas terbaik, aplikasi tetap harus selaras dengan 16 KB.

Di halaman info aplikasi, di bagian Lanjutan, aktifkan atau nonaktifkan setelan Jalankan aplikasi dengan mode kompatibilitas ukuran halaman untuk mengaktifkan atau menonaktifkan mode kompatibilitas mundur 16 KB untuk aplikasi tertentu. Setelan ini hanya terlihat saat perangkat berjalan dengan ukuran halaman 16 KB.

Setelan mode kompatibilitas ukuran halaman

Untuk mengaktifkan kompatibilitas mundur 16 KB secara paksa untuk setiap aplikasi di perangkat:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

Untuk menonaktifkan kompatibilitas mundur 16 KB secara paksa untuk setiap aplikasi di perangkat:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

Di Android 17, Anda juga dapat menonaktifkan kompatibilitas mundur 16 KB secara paksa untuk setiap aplikasi dan menyebabkan biner yang tidak kompatibel segera dibatalkan:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

Tetapkan properti android:pageSizeCompat ke diaktifkan atau dinonaktifkan untuk mengaktifkan atau menonaktifkan mode kompatibilitas mundur untuk aplikasi tertentu di AndroidManifest.xml-nya. Jika properti ini disetel, aplikasi tidak akan menampilkan peringatan mode kompatibilitas mundur saat diluncurkan.