Sebagai pengakuan bahwa pengurasan baterai yang berlebihan menjadi perhatian utama bagi pengguna Android, Google telah mengambil langkah-langkah signifikan untuk membantu developer membangun aplikasi yang lebih hemat daya. Pada 1 Maret 2026, Google Play Store mulai meluncurkan penanganan kualitas teknis kunci tetap aktif untuk mengurangi pengurasan baterai. Perlakuan ini akan diluncurkan secara bertahap ke aplikasi yang terpengaruh selama beberapa minggu ke depan. Aplikasi yang secara konsisten melampaui batas "Penguncian Layar Saat Aktif Sebagian yang Berlebihan" di Android vitals dapat melihat dampak nyata pada kehadiran di Play Store, termasuk peringatan di listingan Play Store dan pengecualian dari platform penemuan seperti rekomendasi.

Pengguna mungkin melihat peringatan di listingan Play Store Anda jika aplikasi Anda melebihi batas perilaku buruk. 

Inisiatif ini meningkatkan efisiensi baterai menjadi metrik penting inti bersama metrik stabilitas seperti error dan ANR. "Batas perilaku buruk" didefinisikan sebagai penahanan penguncian layar saat aktif parsial yang tidak dikecualikan selama rata-rata dua jam saat layar nonaktif di lebih dari 5% sesi pengguna dalam 28 hari terakhir. Wake lock dikecualikan jika merupakan wake lock yang ditahan sistem yang menawarkan manfaat pengguna yang jelas yang tidak dapat dioptimalkan lebih lanjut, seperti pemutaran audio, akses lokasi, atau transfer data yang dimulai pengguna. Anda dapat melihat definisi lengkap penguncian layar saat aktif berlebihan di dokumentasi Android vitals kami.

Sebagai bagian dari inisiatif berkelanjutan kami untuk meningkatkan daya tahan baterai di seluruh ekosistem Android, kami telah menganalisis ribuan aplikasi dan cara aplikasi tersebut menggunakan kunci aktif sebagian. Meskipun kunci tetap aktif terkadang diperlukan, kami sering melihat aplikasi menahannya secara tidak efisien atau tidak perlu, padahal ada solusi yang lebih efisien. Blog ini akan membahas skenario paling umum saat wake lock berlebihan terjadi dan rekomendasi kami untuk mengoptimalkan wake lock.  Kami telah melihat kesuksesan yang terukur dari partner seperti WHOOP, yang memanfaatkan rekomendasi ini untuk mengoptimalkan perilaku latar belakang mereka.

Menggunakan layanan latar depan vs. kunci tetap aktif sebagian

Kami sering melihat developer kesulitan memahami perbedaan antara dua konsep saat melakukan eksekusi di latar belakang: layanan latar depan dan kunci tetap aktif sebagian.

Layanan latar depan adalah API siklus proses yang memberi sinyal kepada sistem bahwa aplikasi sedang melakukan pekerjaan yang dapat dirasakan pengguna dan tidak boleh dihentikan untuk merebut kembali memori, tetapi tidak secara otomatis mencegah CPU tidur saat layar dinonaktifkan. Sebaliknya, penguncian layar saat aktif parsial adalah mekanisme yang dirancang khusus untuk menjaga CPU tetap berjalan meskipun layar dinonaktifkan. 

Meskipun layanan latar depan sering kali diperlukan untuk melanjutkan tindakan pengguna, perolehan kunci tetap aktif sebagian secara manual hanya diperlukan bersama dengan layanan latar depan selama durasi aktivitas CPU. Selain itu, Anda tidak perlu menggunakan penguncian layar saat aktif jika sudah menggunakan API yang membuat perangkat tetap aktif. 

Lihat diagram alur di Memilih API yang tepat untuk menjaga perangkat tetap aktif untuk memastikan Anda memahami dengan baik alat yang harus digunakan untuk menghindari perolehan kunci tetap aktif dalam skenario yang tidak memerlukannya.

Library pihak ketiga yang mendapatkan penguncian layar saat aktif

Aplikasi biasanya mendapati bahwa aplikasi tersebut ditandai karena penggunaan kunci tetap aktif yang berlebihan oleh SDK pihak ketiga atau API sistem yang bertindak atas namanya. Untuk mengidentifikasi dan menyelesaikan masalah kunci aktif ini, sebaiknya lakukan langkah-langkah berikut:

• Periksa Android vitals: Temukan nama persis dari wake lock yang bermasalah di dasbor penguncian layar saat aktif parsial berlebihan. Bandingkan nama ini dengan panduan Mengidentifikasi kunci wake yang dibuat oleh API lain untuk melihat apakah kunci wake dibuat oleh API sistem atau library Jetpack yang dikenal. Jika ya, Anda mungkin perlu mengoptimalkan penggunaan API dan dapat melihat panduan yang direkomendasikan.
• Merekam Aktivitas Sistem: Jika kunci tetap aktif tidak dapat diidentifikasi dengan mudah, reproduksi masalah kunci tetap aktif secara lokal menggunakan rekaman aktivitas sistem dan periksa dengan UI Perfetto. Anda dapat mempelajari lebih lanjut cara melakukannya di bagian Men-debug jenis kunci aktif berlebihan lainnya dalam postingan blog ini.
• Evaluasi Alternatif: Jika library pihak ketiga yang tidak efisien menjadi penyebabnya dan tidak dapat dikonfigurasi untuk menghemat daya baterai, pertimbangkan untuk mengomunikasikan masalah ini dengan pemilik SDK, mencari SDK alternatif, atau membangun fungsi secara internal.

Skenario umum penguncian layar saat aktif

Di bawah ini adalah perincian beberapa kasus penggunaan spesifik yang telah kami tinjau, beserta jalur yang direkomendasikan untuk mengoptimalkan penerapan kunci tetap aktif Anda.

Upload atau Download yang Dimulai Pengguna

Contoh kasus penggunaan: 

• Aplikasi streaming video tempat pengguna memicu download file besar untuk akses offline.
• Aplikasi pencadangan media tempat pengguna memicu upload foto terbaru mereka melalui perintah notifikasi.

Cara mengurangi penguncian layar saat aktif: 

• Jangan dapatkan penguncian layar saat aktif secara manual. Sebagai gantinya, gunakan User-Initiated Data Transfer (UIDT) API. Ini adalah jalur yang ditetapkan untuk tugas transfer data yang berjalan lama yang dimulai oleh pengguna, dan dikecualikan dari perhitungan wake lock yang berlebihan.

Sinkronisasi Latar Belakang Sekali atau Berkala

Contoh kasus penggunaan: 

• Aplikasi melakukan sinkronisasi latar belakang berkala untuk mengambil data untuk akses offline. 
• Aplikasi pedometer yang mengambil jumlah langkah secara berkala.

Cara mengurangi penguncian layar saat aktif: 

• Jangan dapatkan penguncian layar saat aktif secara manual. Gunakan WorkManager yang dikonfigurasi untuk pekerjaan satu kali atau berkala. WorkManager menghormati kesehatan sistem dengan mengelompokkan tugas dan memiliki interval berkala minimum (15 menit), yang umumnya cukup untuk update latar belakang. 
• Jika Anda mengidentifikasi kunci aktif yang dibuat oleh WorkManager atau JobScheduler dengan penggunaan kunci aktif yang tinggi, hal ini mungkin karena Anda salah mengonfigurasi pekerja agar tidak selesai dalam skenario tertentu. Pertimbangkan untuk menganalisis alasan penghentian pekerja, terutama jika Anda melihat banyak STOP_REASON_TIMEOUT. 

  workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Selain mencatat alasan penghentian pekerja, lihat dokumentasi kami tentang men-debug pekerja. Selain itu, pertimbangkan untuk mengumpulkan dan menganalisis rekaman aktivitas sistem untuk memahami kapan kunci tetap aktif diperoleh dan dilepaskan.
• Terakhir, lihat studi kasus kami dengan WHOOP, yang berhasil menemukan masalah pada konfigurasi pekerja mereka dan mengurangi dampak kunci tetap aktif secara signifikan.

Komunikasi Bluetooth

Contoh kasus penggunaan: 

• Aplikasi perangkat pendamping meminta pengguna untuk menyambungkan perangkat eksternal Bluetooth mereka.
• Aplikasi perangkat pendamping memproses peristiwa hardware di perangkat eksternal dan perubahan yang terlihat pengguna dalam notifikasi.
• Pengguna aplikasi perangkat pendamping memulai transfer file antara perangkat seluler dan perangkat Bluetooth.
• Aplikasi perangkat pendamping melakukan update firmware sesekali ke perangkat eksternal melalui Bluetooth.

Cara mengurangi penguncian layar saat aktif: 

• Gunakan penyandingan perangkat pendamping untuk menyandingkan perangkat Bluetooth guna menghindari perolehan kunci tetap aktif manual selama penyandingan Bluetooth. 
• Lihat panduan Berkomunikasi di latar belakang untuk memahami cara melakukan komunikasi Bluetooth di latar belakang. 
• Penggunaan WorkManager sering kali sudah cukup jika tidak ada dampak pengguna terhadap komunikasi yang tertunda. Jika kunci tetap aktif manual dianggap perlu, hanya tahan kunci tetap aktif selama durasi aktivitas Bluetooth atau pemrosesan data aktivitas.

Pelacak Lokasi

Contoh kasus penggunaan: 

• Aplikasi kebugaran yang menyimpan data lokasi ke cache untuk diupload nanti, seperti memetakan rute lari
• Aplikasi pengiriman makanan yang menarik data lokasi dengan frekuensi tinggi untuk memperbarui progres pengiriman di UI notifikasi atau widget.

Cara mengurangi penguncian layar saat aktif: 

• Lihat panduan kami untuk Mengoptimalkan penggunaan lokasi. Pertimbangkan untuk menerapkan waktu tunggu, memanfaatkan pengelompokan permintaan lokasi, atau menggunakan update lokasi pasif untuk memastikan efisiensi baterai.
• Saat meminta pembaruan lokasi menggunakan FusedLocationProvider atau LocationManager API, sistem akan otomatis memicu pengaktifan perangkat selama callback peristiwa lokasi. Penguncian layar saat aktif singkat yang dikelola sistem ini dikecualikan dari perhitungan penguncian layar saat aktif parsial yang berlebihan.
• Hindari mendapatkan kunci aktif berkelanjutan yang terpisah untuk menyimpan data lokasi dalam cache, karena hal ini berlebihan. Sebagai gantinya, pertahankan peristiwa lokasi dalam memori atau penyimpanan lokal dan manfaatkan WorkManager untuk memprosesnya pada interval berkala.

  override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Pemantauan Sensor Frekuensi Tinggi

Contoh kasus penggunaan: 

• Aplikasi pedometer yang mengumpulkan langkah atau jarak yang ditempuh secara pasif. 
• Aplikasi keselamatan yang memantau sensor perangkat untuk mendeteksi perubahan cepat secara real time, guna menyediakan fitur seperti deteksi tabrakan atau deteksi jatuh.

Cara mengurangi penguncian layar saat aktif: 

• Jika menggunakan SensorManager, kurangi penggunaan ke interval berkala dan hanya saat pengguna telah memberikan akses secara eksplisit melalui interaksi UI. Pemantauan sensor frekuensi tinggi dapat menguras baterai secara signifikan karena jumlah proses dan aktivasi CPU yang terjadi.
• Jika Anda melacak jumlah langkah atau jarak yang ditempuh, daripada menggunakan SensorManager, manfaatkan Recording API atau pertimbangkan untuk menggunakan Health Connect untuk mengakses jumlah langkah perangkat historis dan gabungan guna merekam data secara hemat baterai.
• Jika Anda mendaftarkan sensor dengan SensorManager, tentukan maxReportLatencyUs 30 detik atau lebih untuk memanfaatkan pengelompokan sensor guna meminimalkan frekuensi interupsi CPU. Saat perangkat kemudian diaktifkan oleh pemicu lain seperti interaksi pengguna, pengambilan lokasi, atau tugas terjadwal, sistem akan segera mengirimkan data sensor yang di-cache.

  val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Jika aplikasi Anda memerlukan data lokasi dan sensor, sinkronkan pengambilan dan pemrosesan peristiwanya. Dengan memanfaatkan pembacaan sensor pada penguncian layar saat aktif singkat yang dipertahankan sistem untuk update lokasi, Anda tidak memerlukan penguncian layar saat aktif untuk menjaga CPU tetap aktif. Gunakan pekerja atau kunci aktif singkat untuk menangani upload dan pemrosesan data gabungan ini.

Pesan Jarak Jauh

Contoh kasus penggunaan: 

• Aplikasi pendamping pemantauan video atau suara yang perlu memantau peristiwa yang terjadi pada perangkat eksternal yang terhubung menggunakan jaringan lokal.
• Aplikasi pesan yang mempertahankan koneksi soket jaringan dengan varian desktop.

Cara mengurangi penguncian layar saat aktif: 

• Jika peristiwa jaringan dapat diproses di sisi server, gunakan FCM untuk menerima informasi di klien. Anda dapat memilih untuk menjadwalkan pekerja yang dipercepat jika pemrosesan data FCM tambahan diperlukan. 
• Jika peristiwa harus diproses di sisi klien melalui koneksi socket, kunci tetap aktif tidak diperlukan untuk memproses gangguan peristiwa. Saat paket data tiba di radio Wi-Fi atau Seluler, hardware radio akan memicu interupsi hardware dalam bentuk kunci aktif kernel. Kemudian, Anda dapat memilih untuk menjadwalkan pekerja atau mendapatkan kunci aktif untuk memproses data.
• Misalnya, jika Anda menggunakan ktor-network untuk memantau paket data pada soket jaringan, Anda hanya boleh mendapatkan kunci tetap aktif saat paket telah dikirimkan ke klien dan perlu diproses.

  val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Ringkasan

Dengan menerapkan solusi yang direkomendasikan ini untuk kasus penggunaan umum seperti sinkronisasi latar belakang, pelacakan lokasi, pemantauan sensor, dan komunikasi jaringan, developer dapat berupaya mengurangi penggunaan kunci wake yang tidak perlu. Untuk terus mempelajari, baca postingan blog teknis kami yang lain atau tonton video teknis kami tentang cara menemukan dan men-debug penguncian layar saat aktif: Mengoptimalkan baterai aplikasi menggunakan metrik penguncian layar saat aktif Android vitals. Selain itu, lihat dokumentasi wakelock yang diperbarui. Untuk membantu kami terus meningkatkan kualitas sumber daya teknis, berikan masukan tambahan tentang panduan kami dalam survei masukan dokumentasi kami.