App Standby — nedir, bekleme seviyeleri ve çalışma prensibi

App Standby Nedir

App Standby, Android 6.0’da (API 23) tanıtılan ve Android 9’da (API 28) önemli ölçüde yeniden düzenlenen Android güç yönetimi sisteminin bir bileşenidir. Görevi, kullanıcının nadiren kullandığı uygulamaları belirlemek ve arka plan etkinliklerini (ağ istekleri, senkronizasyon, JobScheduler ve AlarmManager) sınırlamaktır. Doze’un aksine, App Standby ekran durumuna veya cihaz hareketine bağlı değildir.

Sistem, uygulamaları dört bucket (seviye) halinde sınıflandırır: Active, Working Set, Frequent ve Rare. Her seviye, arka plan etkinliğinin ne kadar sıkı şekilde kısıtlandığını belirler. Seviyeler arasındaki geçişler, uygulamanın kullanım modellerine göre otomatik olarak gerçekleşir: kullanıcının uygulamayı ne sıklıkta açtığı, bildirim aldığı, widget'larla etkileşime geçtiği.

App Standby, Doze Mode ile birlikte çalışır ancak onun yerini almaz. Doze, cihaz boştayken tüm uygulamaların arka plan etkinliğini sınırlarken, App Standby belirli uygulamaları cihaz durumundan bağımsız olarak kısıtlar. Rare seviyesindeki bir uygulama, kullanıcı onu birkaç gündür açmamış olsa bile, telefon aktif olarak kullanılırken bile kısıtlamalarla karşılaşır.

Android 9+’da Bucket'lar

Android 9’dan (API 28) itibaren Google, sayısal değerlere sahip resmi bir sınıflandırma olan App Standby Buckets'ları tanıttı. Sistem, uygulamanın bir sonraki başlatılmasını tahmin etmek için makine öğrenimini kullanır. Model, uygulamanın önümüzdeki birkaç saat içinde açılacağını tahmin ederse, Active bucket alır. Tahmin nadir kullanımı gösteriyorsa — Rare atanır.

App Standby Nasıl Çalışır

App Standby, bucket’ı belirlemek için birkaç faktörü analiz eder: kullanıcının uygulamayı en son açmasından bu yana geçen süre, etkileşim sıklığı (günde/haftada başlatma sayısı), FCM bildirimlerinin alınması, ana ekranda aktif widget'ların varlığı ve AlarmManager'a abonelik. Bir uygulama ne kadar uzun süre kullanılmazsa, bucket’ı o kadar düşer ve kısıtlamalar o kadar katı olur.

Sistem hizmeti UsageStatsManager, uygulama kullanım istatistiklerini toplar ve bunları StandbyController’a (her uygulama için bucket’ı hesaplayan bir framework bileşeni) iletir. StandbyController ayrıca sistem olaylarını da dikkate alır: bir uygulama güncellemesinden sonra, bucket’ı birkaç günlüğüne Active’e sıfırlanır, böylece kullanıcı yeni özellikleri değerlendirebilir.

Önemli bir özellik: App Standby uygulama sürecini öldürmez, ancak arka plan yeteneklerini sınırlar. Kullanıcı uygulamayla etkileşime geçtiği sürece (Active bucket) uygulama çalışmaya devam eder. Kullanıcı uygulamayı küçültür ve geri dönmezse, sistem boşta kalma süresini saymaya başlar ve bucket’ı Working Set veya Frequent’e düşürebilir.

FCM’in Bucket Üzerindeki Etkisi

FCM yüksek öncelikli bir mesaj almak, uygulamanın bucket’ını geçici olarak Active’e yükseltebilir. Bu, uygulamaya bir görevi (mesajı işleme, verileri senkronize etme) kısıtlama olmadan gerçekleştirme fırsatı verir. Ancak işlem tamamlandıktan sonra bucket orijinal değerine döner. Google, bu mekanizmanın uygulamayı canlı tutmak için değil, önemli bildirimleri iletmek için kullanılmasını önerir.

App Standby Seviyeleri

App Standby, uygulamaları sınıflandırmak için dört seviye (bucket) kullanır. Her seviye, arka plan görevleri için gecikme süresini belirler: seviye ne kadar düşükse, gecikme o kadar uzun olur. Sistem, son 7–14 günde toplanan kullanım istatistiklerine göre uygulamayı seviyeler arasında otomatik olarak hareket ettirir.

Active — Aktif Uygulama

Active — kullanıcının yakın zamanda etkileşime geçtiği bir uygulama (başlattı, bildirim aldı veya widget kullandı). Bu bucket’ta hiçbir kısıtlama yoktur: JobScheduler hemen çalışır, ağ kullanılabilir, AlarmManager hassas bir şekilde çalışır. Kullanıcı birkaç saat boyunca uygulamayla etkileşime girmeyi bırakana kadar uygulama Active’te kalır.

Working Set ve Frequent

Working Set — uygulama düzenli olarak kullanılır (haftada birkaç kez). Arka plan görev gecikmesi 2 saate kadar. Frequent — uygulama ayda birkaç kez kullanılır. Gecikme 4 saate kadar. Her iki seviyede de ağ yalnızca bakım pencerelerinde kullanılabilir ve AlarmManager ertelenebilir. JobScheduler görevleri en yakın pencerede çalıştırır.

Rare — Nadiren Kullanılan

Rare — kullanıcının 30 günden uzun süredir açmadığı uygulamalara atanan en katı seviye. Arka plan görev gecikmesi 24 saate ulaşır. Bakım pencereleri dışında ağ tamamen engellenir, AlarmManager yalnızca setAndAllowWhileIdle() bayraklarıyla 9 dakikada 1 kez sınırıyla çalışır. FCM yüksek öncelikli bildirimler hala iletilir ancak bucket’ı yükseltemez.

App Standby’deki Kısıtlamalar

App Standby, arka plan işlemlerinin birkaç kategorisine kısıtlamalar getirir. Doze’un aksine, App Standby kısıtlamaları ekran durumu ve şarj durumundan bağımsız olarak uygulanır. Geliştirici, özellikle hedef kitle uygulamayı düzensiz kullanıyorsa, bu kısıtlamaları göz önünde bulundurarak uygulamayı tasarlamalıdır.

JobScheduler ve WorkManager

JobScheduler — App Standby’den etkilenen ana API. Bucket’a bağlı olarak, görev yürütme gecikmesi 2 ila 24 saat arasında değişir. Perde arkasında JobScheduler’ı kullanan WorkManager (API 23+), bu gecikmelere de tabidir. Zamana duyarlı görevler için, perde arkasında bir Foreground Service başlatan ve bucket’tan etkilenmeyen Expedited Work’ü kullanın.

Ağ Kısıtlamaları

Working Set, Frequent ve Rare bucket’larındaki uygulamalar herhangi bir zamanda rastgele ağ istekleri yapamaz. Sistem, yalnızca Doze ile senkronize edilen bakım pencerelerinde ağ erişimine izin verir. Kritik verileri göndermek için, bakım penceresinde müteakip senkronizasyonla birlikte FCM yüksek öncelikli kullanın.

AlarmManager

App Standby’deki AlarmManager, Doze ile aynı kuralları izler: hassas alarmlar (setExact()) ertelenir ve setAndAllowWhileIdle() 9 dakikada 1 kez ile sınırlıdır. Rare bucket için gecikme 24 saate ulaşabilir, bu da AlarmManager’ı nadiren kullanılan uygulamalarda hassas görev zamanlaması için uygunsuz hale getirir.

• JobScheduler — bucket’a bağlı olarak görevler 2–24 saat ertelenir
• Ağ — Working Set ve altı için yalnızca bakım pencerelerinde erişim
• AlarmManager — hassas alarmlar ertelenir; setAndAllowWhileIdle — 1/9 dk
• SyncManager — hesap senkronizasyonu bakım penceresine kadar ertelenir
• Widget güncellemeleri — widget güncelleme sıklığı azaltılabilir

Muafiyet Nasıl Alınır

App Standby’den muafiyet iki şekilde elde edilebilir: kullanıcının pil ayarları (manuel Whitelist) veya sistem Intent’i ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS aracılığıyla. Ancak Google, muafiyetlere erişimi sıkı bir şekilde düzenler — geçerli bir nedeni olmayan uygulamalar Google Play’de reddedilme riski taşır.

Kullanıcı, Ayarlar → Uygulamalar → [Uygulama] → Pil → Optimizasyon → Optimize etme yoluyla belirli bir uygulama için kısıtlamaları manuel olarak devre dışı bırakabilir. Bu, seçilen uygulama için App Standby ve Doze kısıtlamalarını tamamen kaldırır. Geliştirici, kullanıcıya talimatlar veya bir sistem diyaloğu gösterebilir, ancak bir uygulamayı zorla muafiyetlere ekleyemez.

Bildirim içeren Foreground Service, App Standby’den otomatik olarak geçici bir muafiyet alır. Hizmet çalışırken ve bir bildirim görüntülerken, uygulama gerçek seviyesinden bağımsız olarak Active bucket’a taşınır. Hizmet durduktan sonra, bucket orijinal değerine döner. Sistem muafiyetleri talep etmeden arka plan çalışmasını garanti etmenin en güvenilir yolu budur.

Ne Zaman Muafiyet İstenmeli

Whitelist talep etmek yalnızca kritik arka plan işlevselliğine sahip uygulamalar için anlamlıdır: gerçek zamanlı navigasyon, sağlık izleme, VoIP aramaları, cihaz koruması. Çoğu uygulama için Foreground Service veya WorkManager kullanmak yeterlidir. Google Play, uygulama belirgin bir gereklilik olmadan muafiyet talep ederse yayınlamayı reddedebilir.

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

// Mevcut durumu kontrol et
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

App Standby Test Etme

ADB aracılığıyla App Standby test etme, bir uygulamaya zorla herhangi bir bucket atamanıza ve davranışını doğrulamanıza olanak tanır. Bu, arka plan senkronizasyonu, bildirimler veya periyodik güncellemelere dayanan uygulamalar için kritik öneme sahiptir. Test, Android 9+ olan fiziksel bir cihaz veya öykünücüde yapılmalıdır.

Bir bucket’ı zorla ayarlamak için adb shell am set-standby-bucket [package] [bucket] komutunu kullanın, burada bucket şunlar olabilir: active, working_set, frequent veya rare. Geçerli bucket’ı görüntülemek için — adb shell am get-standby-bucket [package]. Sistem ayrıca adb shell dumpsys usagestats komutuyla uygulamanın uzun süreli hareketsizliğini simüle etmeye izin verir.

# Uygulama için Rare bucket ayarla
$ adb shell am set-standby-bucket com.example.app rare

# Mevcut bucket’ı görüntüle
$ adb shell am get-standby-bucket com.example.app

# Tüm bucket’ları Active’e sıfırla
$ adb shell dumpsys usagestats clear

# Tüm sistem bucket’larını görüntüle
$ adb shell dumpsys usagestats

Neler Kontrol Edilmeli

Bucket’ı Rare olarak ayarladıktan sonra şunları kontrol edin: WorkManager görevinin 24 saat içinde yürütülüp yürütülmediği, AlarmManager’ın çalışıp çalışmadığı, FCM bildirimlerinin iletilip iletilmediği ve Foreground Service’in kısıtlama olmadan çalışıp çalışmadığı. WorkManager, Expedited Work politikasıyla Rare bucket’ta bile hemen yürütülmelidir, çünkü Foreground Service kullanır. Normal WorkManager görevleri bucket’a göre ertelenecektir.

En İyi Uygulamalar

App Standby’ye dayanıklı bir uygulama geliştirmek, arka plan görevlerine bilinçli bir yaklaşım gerektirir. Ana ilke: uygulamanın her zaman Active bucket’ta olduğunu varsaymayın. Arka plan çalışmasını, Frequent ve Rare bucket’larının karakteristik gecikmeleriyle doğru bir şekilde gerçekleştirilecek şekilde tasarlayın.

WorkManager’ı Expedited Work ile Kullanın

Expedited Work (WorkManager 2.7+), perde arkasında bir Foreground Service başlatarak göreve bucket’tan bağımsız olarak anında yürütme sağlar. Bu, ertelenemeyecek görevler için en uygun seçimdir: mesaj gönderme, ödeme sonrası senkronizasyon, gelen çağrıyı işleme. Normal WorkManager görevleri, bucket’a göre bakım pencerelerinde çalışır.

Yeniden Etkinleştirme İçin FCM

Uygulamayı App Standby’den uyandırmak için FCM yüksek öncelikli mesajları kullanın. Uygulama böyle bir mesaj aldığında, bucket’ı geçici olarak Active’e yükseltilir ve gerekli görevleri (senkronizasyon, veri güncelleme) gerçekleştirmesine olanak tanır. İşlem tamamlandıktan sonra, bucket orijinal seviyesine döner.

Sürekli Bellekte Tutmaktan Kaçının

App Standby’yi kalıcı arka plan hizmetleri, WakeLock veya periyodik FCM mesajlarıyla aşmaya çalışmayın. Google bu tür uygulamalarla aktif olarak mücadele eder — uygulama enerji tüketimi yüksek olarak işaretlenebilir ve daha da katı bir şekilde kısıtlanabilir. Periyodik görevler için WorkManager’ı ve yalnızca görev gerçekten kullanıcı tarafından görülebildiğinde Foreground Service’i kullanın.

• WorkManager — tercih edilen API; Expedited Work görevleri gecikmesiz yürütür
• FCM yüksek öncelikli — mesaj işleme için bucket’ı geçici olarak Active’e yükseltir
• App Standby’yi aşmayın — bu, uygulamanın sistem tarafından engellenmesine yol açar
• Foreground Service — çalışırken uygulamayı geçici olarak Active’e taşır
• Test edin uygulamayı Rare ve Frequent bucket’larında ADB ile her sürümden önce