Google Perketat Penggunaan RAM Android Mulai 2027, Bagaimana Nasib React Native, NativeScript, Capacitor, dan Cordova?

Google akan menerapkan persyaratan teknis baru untuk aplikasi dan game Android yang didistribusikan melalui Google Play mulai Februari 2027. Salah satu perubahan pentingnya adalah hadirnya batas penggunaan memori sebagai bagian dari Android vitals.

Kebijakan ini kemudian menimbulkan pertanyaan menarik bagi developer: apakah aplikasi cross-platform dan hybrid seperti React Native, NativeScript, Capacitor, hingga Cordova akan semakin sulit bertahan karena memiliki runtime atau abstraction layer tambahan?

Google Resmi Memperketat Penggunaan Memori Android

Pada 26 Agustus 2026, Google mengumumkan sejumlah persyaratan kualitas teknis baru untuk aplikasi dan game yang dipublikasikan melalui Google Play.

Salah satu perubahan terbesarnya adalah penambahan penggunaan memori sebagai bagian dari core vitals.

Mulai Februari 2027, Google Play akan menggunakan dua metrik baru untuk mengevaluasi penggunaan memori aplikasi:

• Memory Usage (Anonymous RSS + Swap)
• Bitmap Memory Usage

Google akan mengevaluasi data aplikasi dalam periode 28 hari. Pengukuran menggunakan persentil ke-90 atau P90, yang berarti Google melihat tingkat penggunaan memori yang berada di bawah 90 persen sampel yang dikumpulkan.

Dengan pendekatan ini, aplikasi tidak dinilai hanya berdasarkan satu kejadian ketika konsumsi RAM tiba-tiba tinggi, melainkan berdasarkan pola penggunaan memori yang terjadi pada perangkat pengguna.

Berapa Batas RAM yang Ditetapkan Google?

Batas penggunaan memori berbeda berdasarkan kapasitas RAM perangkat serta kondisi aplikasi ketika berada di foreground, menjalankan layanan yang dirasakan pengguna, atau berada di background.

RAM Perangkat	Foreground	User-Perceived Services	Background
4 GB	2 GB	1 GB	1 GB
6 GB	2,25 GB	1,25 GB	1,25 GB
8 GB	2,25 GB	1,5 GB	1,5 GB
12 GB	3,25 GB	1,75 GB	1,75 GB
16 GB	4,25 GB	2 GB	2 GB

Angka tersebut menunjukkan bahwa Google tidak sedang memaksa seluruh aplikasi Android menjadi super ringan.

Sebuah aplikasi CRUD, aplikasi keuangan, toko online, atau aplikasi bisnis sederhana yang menggunakan beberapa ratus MB RAM kemungkinan masih berada sangat jauh di bawah batas tersebut.

Kebijakan ini lebih ditujukan untuk mendeteksi aplikasi yang menggunakan memori secara berlebihan atau gagal melepaskan resource ketika tidak lagi diperlukan.

Bitmap dan Gambar Juga Mulai Mendapat Perhatian Serius

Selain total penggunaan RAM, Google juga membuat Bitmap Memory Usage sebagai core vital tersendiri.

Ini penting karena gambar beresolusi tinggi dapat menggunakan memori yang jauh lebih besar daripada ukuran file gambarnya.

Sebagai contoh, sebuah gambar yang hanya berukuran beberapa megabyte sebagai JPEG atau WebP dapat membutuhkan puluhan megabyte ketika sudah didekode menjadi bitmap di dalam RAM.

Karena itu developer harus semakin memperhatikan beberapa hal seperti:

• ukuran dan resolusi gambar,
• image caching,
• infinite scrolling,
• bitmap yang tidak dilepaskan,
• memory leak,
• serta resource yang tetap tersimpan ketika aplikasi masuk ke background.

Apakah Android Akan Langsung Menutup Aplikasi yang Melebihi Batas?

Ada sedikit kesalahpahaman yang beredar mengenai aturan baru ini.

Melewati threshold Android vitals tidak sesederhana:

RAM terlalu besar → Android langsung mematikan aplikasi.

Android memang memiliki mekanisme untuk menghentikan proses ketika perangkat mengalami tekanan memori. Android vitals bahkan sudah memiliki metrik Low Memory Kill (LMK) untuk mengukur kejadian tersebut.

Namun threshold Google Play lebih berkaitan dengan penilaian terhadap kualitas aplikasi.

Seperti metrik Android vitals lainnya, aplikasi yang menunjukkan perilaku buruk secara konsisten dapat mengalami dampak terhadap kualitas pengalaman pengguna dan visibilitasnya di Google Play.

Ada Aturan Lain: Optimasi DEX Minimal 25 Persen

Bersamaan dengan aturan penggunaan memori, Google juga memperkenalkan persyaratan optimasi kode yang akan berlaku mulai Februari 2027.

Bagian inilah yang sering disalahartikan menjadi:

"Google mewajibkan semua aplikasi Android menjadi 25 persen lebih kecil."

Pernyataan tersebut tidak sepenuhnya tepat.

Google sebenarnya mensyaratkan aplikasi dengan ukuran DEX yang signifikan untuk mencapai sedikitnya:

• 25% shrinking
• 25% optimization
• 25% obfuscation

Untuk aplikasi biasa, requirement tersebut berlaku ketika ukuran DEX lebih dari 10 MB. Sementara untuk game, batasnya adalah lebih dari 50 MB DEX.

Developer dapat menggunakan R8 atau tool shrinker lainnya untuk memenuhi requirement tersebut.

Jadi angka 25 persen tersebut bukan berarti aplikasi harus menggunakan RAM 25 persen lebih sedikit.

Lalu Bagaimana Nasib React Native?

React Native kemungkinan tidak memiliki masalah fundamental dengan aturan baru Google.

React Native modern sudah menggunakan arsitektur yang jauh berbeda dibanding generasi awalnya. New Architecture React Native menggunakan komponen seperti Hermes, JSI, Fabric, dan native C++ untuk menjembatani JavaScript dengan platform native.

JavaScript / TypeScript
        ↓
      Hermes
        ↓
       JSI
        ↓
   C++ / Fabric
        ↓
 Android Native

Karena UI akhirnya berinteraksi dengan komponen native Android, React Native bukan aplikasi berbasis WebView seperti Cordova atau Capacitor.

Meski demikian, developer tetap harus memperhatikan penggunaan JavaScript heap, native modules, image caching, serta jumlah dependency.

Masalah biasanya bukan muncul hanya karena menggunakan React Native, melainkan karena aplikasi membawa terlalu banyak library dan native SDK.

React Native
+ Firebase
+ Maps
+ Analytics
+ Camera
+ Animation Library
+ Image Processing
+ Advertising SDK
+ Puluhan Native Module

Kombinasi tersebut secara alami dapat meningkatkan baseline penggunaan memory dan ukuran aplikasi.

Bagaimana dengan NativeScript?

NativeScript memiliki karakteristik yang cukup menarik dalam menghadapi perubahan ini.

Berbeda dengan Capacitor dan Cordova, NativeScript tidak menggunakan WebView sebagai sistem utama untuk menampilkan UI.

NativeScript memberikan JavaScript atau TypeScript akses langsung terhadap platform API.

JavaScript / TypeScript
        ↓
JavaScript Runtime
        ↓
NativeScript Runtime
        ↓
Android Native APIs

Komponen UI NativeScript pada akhirnya direpresentasikan menggunakan komponen platform native.

Konsekuensinya, NativeScript memang memiliki overhead dari JavaScript runtime dan runtime NativeScript sendiri, tetapi tidak harus membawa seluruh rendering engine browser untuk menjalankan UI aplikasinya.

Secara arsitektural, hal tersebut membuat NativeScript tetap relevan di era Android yang semakin sensitif terhadap penggunaan resource.

Namun bukan berarti semua aplikasi NativeScript otomatis hemat RAM. Memory leak, object yang tidak dilepaskan, image berukuran besar, plugin native, dan dependency tetap dapat membuat aplikasi NativeScript menjadi boros.

Capacitor Memiliki Tantangan yang Berbeda

Capacitor menggunakan pendekatan Web Native. Developer dapat membangun aplikasi menggunakan HTML, CSS, JavaScript serta framework seperti React, Vue, Angular, Svelte, atau framework web lainnya.

Aplikasi tersebut kemudian berjalan di dalam native container dan dapat mengakses kemampuan perangkat melalui plugin Capacitor.

HTML + CSS + JavaScript
          ↓
       WebView
          ↓
      Capacitor
          ↓
   Native Plugins
          ↓
    Android APIs

Artinya terdapat komponen browser/WebView yang ikut menjalankan aplikasi, termasuk DOM, CSS layout, JavaScript engine, dan rendering layer.

Secara teori, aplikasi berbasis WebView dapat memiliki baseline memory berbeda dibanding aplikasi native sederhana.

Tetapi ini tidak berarti Capacitor akan dilarang atau otomatis gagal memenuhi persyaratan Google.

Threshold RAM yang diterapkan Google relatif tinggi untuk aplikasi biasa. Aplikasi berbasis Capacitor yang dirancang dengan baik masih dapat menggunakan RAM jauh di bawah threshold tersebut.

Risiko biasanya meningkat jika aplikasi memiliki:

• DOM yang sangat besar,
• banyak gambar resolusi tinggi,
• infinite scroll tanpa virtualisasi,
• JavaScript object yang terus tersimpan,
• canvas atau video berat,
• banyak plugin native,
• atau memory leak.

Bagaimana Nasib Apache Cordova?

Secara konsep dasar, Cordova mempunyai kemiripan dengan Capacitor karena aplikasi web dijalankan melalui WebView di dalam native wrapper.

HTML + CSS + JavaScript
          ↓
    Cordova WebView
          ↓
     Cordova Plugins
          ↓
      Native APIs

Dokumentasi resmi Apache Cordova bahkan menjelaskan bahwa aplikasi Cordova pada Android dijalankan dalam WebView yang tertanam di dalam Android Activity.

Karena itu Cordova menghadapi tantangan memory yang mirip dengan aplikasi WebView lainnya.

Tetapi ancaman terbesar Cordova ke depan mungkin bukan sekadar konsumsi RAM.

Developer juga perlu memastikan plugin dan native dependency yang digunakan tetap mengikuti perkembangan persyaratan Android dan Google Play.

16 KB Memory Page Size Juga Menjadi Hal Penting

Selain threshold penggunaan RAM, developer Android juga perlu memperhatikan requirement 16 KB memory page size.

Google menyatakan bahwa aplikasi yang menargetkan Android 15 atau API level 35 dan lebih tinggi harus mendukung perangkat 64-bit dengan ukuran halaman memori 16 KB di Google Play.

Mulai 1 Februari 2027, developer tidak dapat merilis update aplikasi yang tidak memenuhi requirement tersebut.

Aplikasi yang sepenuhnya menggunakan Java atau Kotlin umumnya kompatibel secara default.

Namun developer yang menggunakan native library atau file .so perlu memastikan library tersebut sudah kompatibel dengan 16 KB page size.

Persyaratan ini juga relevan bagi aplikasi cross-platform karena plugin React Native, NativeScript, Capacitor, Cordova, Flutter, atau framework lainnya dapat membawa native library.

Apakah Framework Hybrid dan Cross-Platform Akan Tersingkir?

Jawaban singkatnya: tidak.

Tidak ada indikasi bahwa Google sedang berusaha menyingkirkan React Native, NativeScript, Flutter, Capacitor, Cordova, atau teknologi cross-platform lainnya.

Google juga tidak menetapkan threshold berbeda berdasarkan framework yang digunakan.

Yang dinilai adalah hasil akhirnya di perangkat pengguna.

Dengan kata lain:

Yang terancam bukan aplikasi hybrid, tetapi aplikasi yang secara nyata boros resource.

Aplikasi Native Android yang buruk tetap dapat menggunakan RAM lebih besar daripada aplikasi React Native atau Capacitor yang dioptimalkan dengan baik.

Sebaliknya, aplikasi cross-platform yang menggunakan terlalu banyak dependency, image besar, native library, serta gagal membersihkan resource dapat lebih mudah mengalami masalah.

Perbandingan Risiko Secara Arsitektural

Jika hanya melihat karakteristik arsitekturnya, bukan berdasarkan benchmark absolut, gambaran kasarnya dapat terlihat seperti berikut:

Teknologi	Rendering Utama	Runtime Tambahan	Perhatian Utama
Native Kotlin/Java	Native	ART/JVM	Dependency, bitmap, native allocation
NativeScript	Native	JavaScript runtime + NativeScript runtime	JS heap, object lifecycle, plugin
React Native	Native	Hermes + React Native runtime	JS heap, native modules, dependency
Flutter	Flutter rendering engine	Dart runtime + engine	Engine, image, plugin, allocation
Capacitor	WebView	WebView + web runtime	DOM, image, JS heap, plugin
Cordova	WebView	WebView + Cordova runtime	DOM, plugin, compatibility native

Tabel tersebut tidak boleh dibaca sebagai ranking mutlak mengenai framework mana yang paling hemat RAM.

Penggunaan memory sebenarnya tetap harus diukur melalui profiling pada aplikasi nyata karena kompleksitas UI, jumlah dependency, plugin, image, background task, dan desain aplikasi dapat memberikan dampak jauh lebih besar daripada pemilihan framework semata.

Dependency Akan Menjadi Semakin Penting

Salah satu konsekuensi menarik dari perubahan Google adalah developer akan semakin sulit mengabaikan dependency yang digunakan aplikasi.

Praktik seperti menambahkan library hanya untuk menjalankan fungsi sederhana akan semakin perlu dipertimbangkan.

App
├── Firebase
├── Maps SDK
├── Analytics SDK
├── Camera Library
├── Image Processing
├── Animation Engine
├── Advertising SDK
├── Social Login SDK
└── Puluhan library lainnya

Setiap dependency berpotensi membawa kode Java/Kotlin, native library, object allocation, background worker, serta resource tambahan.

Requirement DEX optimization Google juga semakin mendorong developer menggunakan code shrinking dan menghapus kode yang tidak digunakan.

Filosofi pengembangan Android ke depan kemungkinan semakin bergerak menuju:

Gunakan dependency karena benar-benar dibutuhkan, bukan hanya karena tersedia.

Apakah Kebijakan Ini Disebabkan Krisis RAM Akibat AI?

Beberapa unggahan di media sosial menghubungkan kebijakan Google dengan meningkatnya permintaan memori untuk data center AI.

Namun bagian ini perlu dipisahkan antara fakta dan interpretasi.

Dalam pengumuman resminya, Google memang menyebut bahwa industri mobile sedang menghadapi hardware supply constraints yang memengaruhi ketersediaan memory pada perangkat.

Akan tetapi, Google tidak secara eksplisit mengatakan bahwa aturan Android tersebut dibuat karena AI data center menghabiskan pasokan RAM dunia.

Permintaan komponen memori untuk AI dan data center memang dapat menjadi bagian dari dinamika industri semikonduktor yang lebih luas, tetapi menghubungkannya secara langsung sebagai satu-satunya penyebab kebijakan Google akan terlalu menyederhanakan masalah.

Apa yang Sebaiknya Dilakukan Developer Mulai Sekarang?

Developer sebenarnya masih memiliki waktu sebelum requirement mulai diberlakukan pada Februari 2027.

Beberapa langkah yang dapat mulai dilakukan antara lain:

1. Memantau bagian Memory pada Android vitals di Play Console.
2. Menggunakan Android Studio Memory Profiler untuk mendeteksi memory leak.
3. Memastikan bitmap dan image tidak dipertahankan ketika sudah tidak digunakan.
4. Menguji aplikasi ketika berpindah dari foreground ke background.
5. Mengurangi dependency yang tidak diperlukan.
6. Mengaktifkan dan mengonfigurasi R8 dengan benar.
7. Memeriksa ukuran DEX melalui App Bundle Explorer.
8. Mengaudit native library dan file .so.
9. Memastikan native dependency kompatibel dengan 16 KB memory page size.
10. Melakukan pengujian pada perangkat dengan RAM rendah, bukan hanya flagship.

Kesimpulan

Kebijakan Google Play yang berlaku mulai Februari 2027 bukanlah akhir bagi aplikasi hybrid maupun cross-platform.

React Native, NativeScript, Flutter, Capacitor, Cordova, hingga aplikasi Android native tetap dapat dipublikasikan selama memenuhi requirement teknis yang ditentukan Google.

Yang berubah adalah developer akan semakin dituntut untuk membuktikan bahwa aplikasi mereka menggunakan resource secara masuk akal.

Google bukan sedang membunuh hybrid apps. Google sedang membuat aplikasi Android yang boros resource semakin sulit untuk diabaikan.

Framework hanyalah salah satu bagian dari persoalan.

Arsitektur aplikasi, dependency, pengelolaan bitmap, lifecycle, native library, caching, serta disiplin developer dalam mengelola memory pada akhirnya jauh lebih menentukan.

Bahkan aplikasi native Kotlin dapat lebih boros daripada aplikasi React Native, NativeScript, atau Capacitor apabila implementasinya buruk.

Sebaliknya, aplikasi cross-platform yang dibangun dengan dependency minimal dan pengelolaan resource yang baik kemungkinan tidak perlu khawatir menghadapi perubahan Android pada 2027.

Referensi

• Google Play Console Help - Technical Quality Requirements:
  Play Console Technical Quality Requirements
• Android Developers Blog - Elevating App Quality: Reducing Memory Usage and Improving Device Migration:
  Android Developers Blog
• Google Play Console - Android Vitals:
  Memantau Kualitas Teknis Aplikasi dengan Android Vitals
• Android Developers - 16 KB Page Size Support:
  Support 16 KB Page Sizes
• React Native - Architecture Overview:
  React Native Architecture
• NativeScript Documentation:
  NativeScript Documentation
• Capacitor Documentation:
  Capacitor Documentation
• Apache Cordova - Android WebView Documentation:
  Apache Cordova Android WebViews