App Standby — apa itu, level siaga dan prinsip kerja

Apa itu App Standby

App Standby adalah komponen sistem manajemen energi Android, diperkenalkan di Android 6.0 (API 23) dan didesain ulang secara signifikan di Android 9 (API 28). Tugasnya adalah menentukan aplikasi mana yang jarang digunakan oleh pengguna dan membatasi aktivitas latar belakang mereka: permintaan jaringan, sinkronisasi, JobScheduler dan AlarmManager. Berbeda dengan Doze, App Standby tidak tergantung pada status layar atau gerakan perangkat.

Sistem mengklasifikasikan aplikasi ke dalam empat bucket (level): Active, Working Set, Frequent dan Rare. Setiap level menentukan seberapa besar aktivitas latar belakang dibatasi. Transisi antar level terjadi secara otomatis berdasarkan pola penggunaan aplikasi: seberapa sering pengguna membukanya, menerima notifikasi, berinteraksi dengan widget.

App Standby bekerja bersama Doze Mode, tetapi tidak menggantikannya. Jika Doze membatasi aktivitas latar belakang semua aplikasi saat perangkat tidak aktif, maka App Standby membatasi aplikasi tertentu terlepas dari status perangkat. Aplikasi dengan level Rare akan memiliki pembatasan bahkan saat penggunaan telepon aktif, jika pengguna tidak membukanya selama beberapa hari.

Bucket di Android 9+

Mulai Android 9 (API 28), Google memperkenalkan App Standby Buckets — klasifikasi formal dengan nilai numerik. Sistem menggunakan pembelajaran mesin untuk memprediksi peluncuran aplikasi berikutnya. Jika model memprediksi bahwa aplikasi akan dibuka dalam beberapa jam mendatang, ia mendapatkan bucket Active. Jika prediksi menunjukkan penggunaan yang jarang — Rare ditetapkan.

Cara Kerja App Standby

App Standby menganalisis beberapa faktor untuk menentukan bucket: waktu sejak pembukaan terakhir aplikasi oleh pengguna, frekuensi interaksi (jumlah peluncuran per hari/minggu), penerimaan notifikasi FCM, keberadaan widget aktif di layar utama dan langganan AlarmManager. Semakin lama aplikasi tidak digunakan, semakin rendah bucket-nya dan semakin ketat pembatasannya.

Layanan sistem UsageStatsManager mengumpulkan statistik penggunaan aplikasi dan meneruskannya ke StandbyController — komponen framework yang menghitung bucket untuk setiap aplikasi. StandbyController juga mempertimbangkan peristiwa sistem: setelah pembaruan aplikasi, bucket-nya direset ke Active selama beberapa hari agar pengguna dapat mengevaluasi fitur baru.

Fitur penting: App Standby tidak mematikan proses aplikasi, tetapi membatasi kemampuan latar belakangnya. Aplikasi terus berjalan jika pengguna berinteraksi dengannya (bucket Active). Segera setelah pengguna menutup aplikasi dan tidak kembali, sistem mulai menghitung waktu tidak aktif dan dapat menurunkan bucket ke Working Set atau Frequent.

Pengaruh FCM pada bucket

Menerima pesan FCM high-priority dapat sementara meningkatkan bucket aplikasi ke Active. Ini memberi aplikasi kemampuan untuk melakukan tugas (memproses pesan, menyinkronkan data) tanpa batasan. Namun, setelah pemrosesan selesai, bucket kembali ke nilai aslinya. Google merekomendasikan menggunakan mekanisme ini untuk mengirimkan notifikasi penting, bukan untuk menjaga aplikasi tetap “hidup”.

Level App Standby

App Standby menggunakan empat level (bucket) untuk klasifikasi aplikasi. Setiap level menentukan waktu penundaan untuk tugas latar belakang: semakin rendah level, semakin lama penundaannya. Sistem secara otomatis memindahkan aplikasi antar level berdasarkan statistik penggunaan yang dikumpulkan dalam 7–14 hari terakhir.

Active — aplikasi aktif

Active — aplikasi yang baru saja berinteraksi dengan pengguna (diluncurkan, menerima notifikasi atau menggunakan widget). Di bucket ini tidak ada batasan: JobScheduler langsung berjalan, jaringan tersedia, AlarmManager bekerja tepat. Aplikasi tetap di Active sampai pengguna berhenti berinteraksi dengannya selama beberapa jam.

Working Set dan Frequent

Working Set — aplikasi digunakan secara teratur (beberapa kali seminggu). Penundaan tugas latar belakang hingga 2 jam. Frequent — aplikasi digunakan beberapa kali sebulan. Penundaan hingga 4 jam. Di kedua level, jaringan hanya tersedia di jendela layanan, dan AlarmManager dapat ditunda. JobScheduler menjalankan tugas di jendela terdekat.

Rare — jarang digunakan

Rare — level paling ketat, ditetapkan untuk aplikasi yang tidak dibuka pengguna selama lebih dari 30 hari. Penundaan tugas latar belakang mencapai 24 jam. Jaringan sepenuhnya diblokir di luar jendela layanan, AlarmManager hanya bekerja dengan flag setAndAllowWhileIdle() dengan batasan 1 kali per 9 menit. Notifikasi FCM high-priority masih dikirim, tetapi tidak dapat meningkatkan bucket.

Pembatasan di App Standby

App Standby memberlakukan pembatasan pada beberapa kategori operasi latar belakang. Berbeda dengan Doze, pembatasan App Standby bekerja terlepas dari status layar dan pengisi daya. Pengembang harus merancang aplikasi dengan mempertimbangkan pembatasan ini, terutama jika audiens target menggunakan aplikasi secara tidak teratur.

JobScheduler dan WorkManager

JobScheduler — API utama yang dipengaruhi App Standby. Tergantung pada bucket, penundaan eksekusi tugas berkisar antara 2 hingga 24 jam. WorkManager, yang menggunakan JobScheduler di bawah kap (pada API 23+), juga mengalami penundaan ini. Untuk tugas yang kritis waktu, gunakan Expedited Work, yang meluncurkan Foreground Service di bawah kap dan tidak tergantung pada bucket.

Pembatasan Jaringan

Aplikasi di bucket Working Set, Frequent dan Rare tidak dapat melakukan permintaan jaringan sembarangan kapan saja. Sistem mengizinkan akses ke jaringan hanya di jendela layanan yang disinkronkan dengan Doze. Untuk mengirim data kritis, gunakan FCM high-priority dengan sinkronisasi berikutnya di jendela layanan.

AlarmManager

AlarmManager di App Standby tunduk pada aturan yang sama seperti di Doze: alarm tepat (setExact()) ditunda, dan setAndAllowWhileIdle() dibatasi 1 kali per 9 menit. Untuk bucket Rare, penundaan bisa mencapai 24 jam, membuat AlarmManager tidak cocok untuk penjadwalan tugas yang tepat di aplikasi yang jarang digunakan.

• JobScheduler — tugas ditunda 2–24 jam tergantung bucket
• Jaringan — akses hanya di jendela layanan untuk Working Set dan di bawahnya
• AlarmManager — alarm tepat ditunda; setAndAllowWhileIdle — 1/9 menit
• SyncManager — sinkronisasi akun ditunda hingga jendela layanan
• Widget updates — frekuensi pembaruan widget dapat dikurangi

Cara Mendapatkan Pengecualian

Pengecualian dari App Standby dapat diperoleh dengan dua cara: melalui pengaturan baterai pengguna (Whitelist manual) atau melalui Intent sistem ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Namun, Google secara ketat mengatur akses ke pengecualian — aplikasi yang tidak memiliki alasan kuat untuk pengecualian berisiko ditolak di Google Play.

Pengguna dapat secara manual menonaktifkan pembatasan untuk aplikasi tertentu melalui Pengaturan → Aplikasi → [Aplikasi] → Baterai → Optimasi → Jangan optimalkan. Ini sepenuhnya menghapus pembatasan App Standby dan Doze untuk aplikasi yang dipilih. Pengembang dapat menampilkan instruksi atau dialog sistem kepada pengguna, tetapi tidak dapat memaksa menambahkan aplikasi ke pengecualian.

Foreground Service dengan notifikasi secara otomatis mendapatkan pengecualian sementara dari App Standby. Selama layanan berjalan dan menampilkan notifikasi, aplikasi dipindahkan ke bucket Active terlepas dari level sebenarnya. Setelah layanan berhenti, bucket kembali ke nilai aslinya. Ini adalah cara paling andal untuk menjamin kerja latar belakang tanpa meminta pengecualian sistem.

Kapan Meminta Pengecualian

Meminta Whitelist hanya masuk akal untuk aplikasi dengan fungsionalitas latar belakang yang sangat penting: navigasi real-time, pemantauan kesehatan, panggilan VoIP, perlindungan perangkat. Untuk sebagian besar aplikasi, cukup menggunakan Foreground Service atau WorkManager. Google Play dapat menolak publikasi jika aplikasi meminta pengecualian tanpa kebutuhan yang jelas.

// Permintaan pengecualian dari App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Pemeriksaan status saat ini
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Pengujian App Standby

Pengujian App Standby melalui ADB memungkinkan menetapkan bucket apa pun secara paksa ke aplikasi dan memeriksa perilakunya. Ini sangat penting untuk aplikasi yang mengandalkan sinkronisasi latar belakang, notifikasi, atau pembaruan berkala. Pengujian harus dilakukan pada perangkat fisik atau emulator dengan Android 9+.

Untuk pengaturan paksa bucket, gunakan perintah adb shell am set-standby-bucket [package] [bucket], di mana bucket dapat berupa: active, working_set, frequent atau rare. Untuk melihat bucket saat ini — adb shell am get-standby-bucket [package]. Sistem juga memungkinkan simulasi tidak aktifnya aplikasi dalam waktu lama melalui perintah adb shell dumpsys usagestats.

# Mengatur bucket Rare untuk aplikasi
$ adb shell am set-standby-bucket com.example.app rare

# Melihat bucket saat ini
$ adb shell am get-standby-bucket com.example.app

# Mereset semua bucket ke Active
$ adb shell dumpsys usagestats clear

# Melihat semua bucket sistem
$ adb shell dumpsys usagestats

Apa yang Periksa

Setelah menetapkan bucket Rare periksa: apakah tugas WorkManager dijalankan dalam 24 jam, apakah AlarmManager aktif, apakah notifikasi FCM terkirim, apakah Foreground Service bekerja tanpa batasan. WorkManager dengan kebijakan Expedited Work harus segera dijalankan bahkan di bucket Rare, karena menggunakan Foreground Service. Tugas WorkManager biasa akan ditunda sesuai dengan bucket.

Praktik Terbaik

Mengembangkan aplikasi yang tahan terhadap App Standby memerlukan pendekatan yang sadar terhadap tugas latar belakang. Prinsip dasar: jangan berasumsi bahwa aplikasi selalu berada di bucket Active. Rancang kerja latar belakang sehingga berfungsi dengan benar dengan penundaan yang khas untuk bucket Frequent dan Rare.

Gunakan WorkManager dengan Expedited Work

Expedited Work (WorkManager 2.7+) meluncurkan Foreground Service di bawah kap, memberikan eksekusi segera pada tugas terlepas dari bucket. Ini adalah pilihan optimal untuk tugas yang tidak dapat ditunda: mengirim pesan, sinkronisasi setelah pembayaran, memproses panggilan masuk. Tugas WorkManager biasa dijalankan di jendela layanan dengan mempertimbangkan bucket.

FCM untuk Reaktivasi

Gunakan pesan FCM high-priority untuk membangunkan aplikasi dari App Standby. Ketika aplikasi menerima pesan seperti itu, bucket-nya sementara naik ke Active dan dapat melakukan tugas yang diperlukan (sinkronisasi, pembaruan data). Setelah pemrosesan selesai, bucket kembali ke level awal.

Hindari Penyimpanan Tetap di Memori

Jangan mencoba menghindari App Standby dengan layanan latar belakang permanen, WakeLock, atau pesan FCM berkala. Google secara aktif memerangi praktik semacam itu — aplikasi dapat ditandai sebagai boros energi dan dibatasi lebih ketat. Gunakan WorkManager untuk tugas berkala dan Foreground Service hanya ketika tugas benar-benar terlihat oleh pengguna.

• WorkManager — API yang disarankan; Expedited Work menjalankan tugas tanpa penundaan
• FCM high-priority — sementara meningkatkan bucket ke Active untuk memproses pesan
• Jangan hindari App Standby — ini menyebabkan pemblokiran aplikasi oleh sistem
• Foreground Service — sementara memindahkan aplikasi ke Active selama bekerja
• Uji aplikasi di bucket Rare dan Frequent melalui ADB sebelum setiap rilis