App Standby — co to jest, poziomy oczekiwania i zasada działania

Co to jest App Standby

App Standby to komponent systemu zarządzania energią w Androidzie, wprowadzony w Android 6.0 (API 23) i znacznie przebudowany w Android 9 (API 28). Jego zadaniem jest określenie, które aplikacje są rzadko używane przez użytkownika, i ograniczenie ich aktywności w tle: zapytań sieciowych, synchronizacji, JobScheduler i AlarmManager. W przeciwieństwie do Doze, App Standby nie zależy od stanu ekranu ani ruchu urządzenia.

System klasyfikuje aplikacje według czterech bucket (poziomów): Active, Working Set, Frequent i Rare. Każdy poziom określa, jak bardzo ograniczona jest aktywność w tle. Przejście między poziomami odbywa się automatycznie na podstawie wzorców użytkowania aplikacji: jak często użytkownik ją otwiera, otrzymuje powiadomienia, wchodzi w interakcję z widgetami.

App Standby działa w parze z Doze Mode, ale go nie zastępuje. Jeśli Doze ogranicza aktywność w tle wszystkich aplikacji podczas bezczynności urządzenia, to App Standby ogranicza konkretne aplikacje niezależnie od stanu urządzenia. Aplikacja z poziomem Rare będzie miała ograniczenia nawet przy aktywnym używaniu telefonu, jeśli użytkownik nie otwierał jej przez kilka dni.

Bucket w Android 9+

Począwszy od Android 9 (API 28), Google wprowadziła App Standby Buckets — formalną klasyfikację z wartościami liczbowymi. System używa uczenia maszynowego do przewidywania następnego uruchomienia aplikacji. Jeśli model przewiduje, że aplikacja zostanie otwarta w ciągu najbliższych godzin, otrzymuje bucket Active. Jeśli przewidywanie wskazuje na rzadkie użytkowanie — przypisywany jest Rare.

Jak działa App Standby

App Standby analizuje kilka czynników do określenia bucket: czas od ostatniego otwarcia aplikacji przez użytkownika, częstotliwość interakcji (liczba uruchomień dziennie/tygodniowo), otrzymywanie powiadomień FCM, obecność aktywnych widgetów na pulpicie oraz subskrypcję AlarmManager. Im dłużej aplikacja nie jest używana, tym niższy jej bucket i tym ostrzejsze ograniczenia.

Systemowy serwis UsageStatsManager zbiera statystyki użytkowania aplikacji i przekazuje je do StandbyController — komponentu framework, który oblicza bucket dla każdej aplikacji. StandbyController uwzględnia również zdarzenia systemowe: po aktualizacji aplikacji jej bucket jest resetowany do Active na kilka dni, aby użytkownik mógł ocenić nowe funkcje.

Ważna cecha: App Standby nie zabija procesu aplikacji, ale ogranicza jej możliwości w tle. Aplikacja działa nadal, jeśli użytkownik z nią współpracuje (bucket Active). Gdy użytkownik zminimalizuje aplikację i nie wraca do niej, system rozpoczyna odliczanie czasu bezczynności i może obniżyć bucket do Working Set lub Frequent.

Wpływ FCM na bucket

Otrzymanie wiadomości FCM high-priority może tymczasowo podnieść bucket aplikacji do Active. Daje to aplikacji możliwość wykonania zadania (przetworzenia wiadomości, synchronizacji danych) bez ograniczeń. Jednak po zakończeniu przetwarzania bucket wraca do pierwotnej wartości. Google zaleca używanie tego mechanizmu do dostarczania ważnych powiadomień, a nie do utrzymywania aplikacji „przy życiu”.

Poziomy App Standby

App Standby używa czterech poziomów (bucket) do klasyfikacji aplikacji. Każdy poziom określa czas opóźnienia dla zadań w tle: im niższy poziom, tym dłuższe opóźnienie. System automatycznie przesuwa aplikację między poziomami na podstawie statystyk użytkowania zebranych w ciągu ostatnich 7–14 dni.

Active — aktywna aplikacja

Active — aplikacja, z którą użytkownik niedawno wchodził w interakcję (uruchamiał, otrzymywał powiadomienie lub używał widżetu). W tym bucket nie ma ograniczeń: JobScheduler uruchamia się natychmiast, sieć jest dostępna, AlarmManager działa dokładnie. Aplikacja pozostaje w Active, dopóki użytkownik nie przestanie z nią wchodzić w interakcję przez kilka godzin.

Working Set i Frequent

Working Set — aplikacja używana regularnie (kilka razy w tygodniu). Opóźnienie zadań w tle do 2 godzin. Frequent — aplikacja używana kilka razy w miesiącu. Opóźnienie do 4 godzin. Na obu poziomach sieć jest dostępna tylko w oknach obsługi, a AlarmManager może być opóźniony. JobScheduler wykonuje zadania w najbliższym oknie.

Rare — rzadko używana

Rare — najsurowszy poziom, przypisywany aplikacjom, których użytkownik nie otwierał od ponad 30 dni. Opóźnienie zadań w tle sięga 24 godzin. Sieć jest całkowicie blokowana poza oknami obsługi, AlarmManager działa tylko z flagami setAndAllowWhileIdle() z ograniczeniem 1 raz na 9 minut. Powiadomienia FCM high-priority są nadal dostarczane, ale nie mogą podnieść bucket.

Ograniczenia w App Standby

App Standby nakłada ograniczenia na kilka kategorii operacji w tle. W przeciwieństwie do Doze, ograniczenia App Standby działają niezależnie od stanu ekranu i ładowarki. Deweloper powinien projektować aplikację z uwzględnieniem tych ograniczeń, szczególnie jeśli grupa docelowa używa aplikacji nieregularnie.

JobScheduler i WorkManager

JobScheduler — główne API, na które wpływa App Standby. W zależności od bucket opóźnienie wykonywania zadań wynosi od 2 do 24 godzin. WorkManager, używający JobScheduler pod maską (na API 23+), również podlega tym opóźnieniom. W przypadku zadań krytycznych czasowo używaj Expedited Work, który uruchamia Foreground Service pod maską i nie zależy od bucket.

Ograniczenia sieciowe

Aplikacje w bucket Working Set, Frequent i Rare nie mogą wykonywać dowolnych zapytań sieciowych w dowolnym czasie. System zezwala na dostęp do sieci tylko w oknach obsługi, które są zsynchronizowane z Doze. Do wysyłania krytycznych danych używaj FCM high-priority z późniejszą synchronizacją w oknie obsługi.

AlarmManager

AlarmManager w App Standby podlega tym samym zasadom co w Doze: dokładne alarmy (setExact()) są opóźniane, a setAndAllowWhileIdle() jest ograniczony do 1 wyzwolenia na 9 minut. Dla bucket Rare opóźnienie może sięgać 24 godzin, co czyni AlarmManager nieodpowiednim do dokładnego planowania zadań w rzadko używanych aplikacjach.

• JobScheduler — zadania są opóźniane o 2–24 godziny w zależności od bucket
• Sieć — dostęp tylko w oknach obsługi dla Working Set i niższych
• AlarmManager — dokładne alarmy są opóźniane; setAndAllowWhileIdle — 1/9 min
• SyncManager — synchronizacja kont jest opóźniana do okna obsługi
• Widget updates — częstotliwość aktualizacji widgetów może być zmniejszona

Jak uzyskać wyłączenie

Wyłączenie z App Standby można uzyskać na dwa sposoby: przez ustawienia baterii użytkownika (ręczna Whitelist) lub przez systemowy Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google jednak ściśle reguluje dostęp do wyłączeń — aplikacje, które nie mają ważnego powodu do wyłączenia, ryzykują odrzuceniem w Google Play.

Użytkownik może ręcznie wyłączyć ograniczenia dla konkretnej aplikacji poprzez Ustawienia → Aplikacje → [Aplikacja] → Bateria → Optymalizacja → Nie optymalizuj. To całkowicie usuwa ograniczenia App Standby i Doze dla wybranej aplikacji. Deweloper może pokazać użytkownikowi instrukcję lub systemowe okno dialogowe, ale nie może wymusić dodania aplikacji do wyjątków.

Foreground Service z powiadomieniem automatycznie otrzymuje tymczasowe wyłączenie z App Standby. Dopóki serwis działa i wyświetla powiadomienie, aplikacja jest przenoszona do bucket Active niezależnie od jej rzeczywistego poziomu. Po zatrzymaniu serwisu bucket wraca do pierwotnej wartości. To najpewniejszy sposób zagwarantowania pracy w tle bez żądania wyjątków systemowych.

Kiedy żądać wyłączenia

Żądanie Whitelist ma sens tylko dla aplikacji o krytycznie ważnej funkcjonalności w tle: nawigacja w czasie rzeczywistym, monitorowanie zdrowia, połączenia VoIP, ochrona urządzenia. Dla większości aplikacji wystarczy użyć Foreground Service lub WorkManager. Google Play może odrzucić publikację, jeśli aplikacja żąda wyłączenia bez oczywistej potrzeby.

// Żądanie wyłączenia z App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Sprawdzenie bieżącego statusu
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testowanie App Standby

Testowanie App Standby przez ADB pozwala wymusić przypisanie aplikacji dowolnego bucket i sprawdzić jej zachowanie. Jest to krytycznie ważne dla aplikacji, które polegają na synchronizacji w tle, powiadomieniach lub okresowych aktualizacjach. Testowanie należy przeprowadzać na fizycznym urządzeniu lub emulatorze z Android 9+.

Do wymuszonego ustawienia bucket używa się polecenia adb shell am set-standby-bucket [package] [bucket], gdzie bucket może być: active, working_set, frequent lub rare. Do przeglądania bieżącego bucket — adb shell am get-standby-bucket [package]. System pozwala również symulować długotrwałą bezczynność aplikacji poprzez polecenie adb shell dumpsys usagestats.

# Ustawienie bucket Rare dla aplikacji
$ adb shell am set-standby-bucket com.example.app rare

# Podgląd bieżącego bucket
$ adb shell am get-standby-bucket com.example.app

# Reset wszystkich bucket do Active
$ adb shell dumpsys usagestats clear

# Podgląd wszystkich bucket systemu
$ adb shell dumpsys usagestats

Co sprawdzać

Po ustawieniu bucket Rare sprawdź: czy zadanie WorkManager wykonuje się w ciągu 24 godzin, czy AlarmManager wyzwala się, czy powiadomienia FCM są dostarczane, czy Foreground Service działa bez ograniczeń. WorkManager z polityką Expedited Work powinien wykonać się natychmiast nawet w bucket Rare, ponieważ używa Foreground Service. Zwykłe zadania WorkManager zostaną opóźnione zgodnie z bucket.

Najlepsze praktyki

Tworzenie aplikacji odpornej na App Standby wymaga świadomego podejścia do zadań w tle. Główna zasada: nie zakładać, że aplikacja zawsze znajduje się w bucket Active. Projektuj pracę w tle tak, aby poprawnie działała z opóźnieniami charakterystycznymi dla bucket Frequent i Rare.

Używaj WorkManager z Expedited Work

Expedited Work (WorkManager 2.7+) uruchamia Foreground Service pod maską, co daje zadaniu natychmiastowe wykonanie niezależnie od bucket. To optymalny wybór dla zadań, które nie mogą być opóźnione: wysyłanie wiadomości, synchronizacja po płatności, obsługa połączenia przychodzącego. Zwykłe zadania WorkManager wykonują się w oknach obsługi z uwzględnieniem bucket.

FCM do reaktywacji

Używaj wiadomości FCM high-priority do wybudzania aplikacji z App Standby. Gdy aplikacja otrzymuje taką wiadomość, jej bucket tymczasowo wzrasta do Active i może wykonać niezbędne zadania (synchronizacja, aktualizacja danych). Po zakończeniu przetwarzania bucket wraca do pierwotnego poziomu.

Unikaj stałego utrzymywania w pamięci

Nie próbuj omijać App Standby za pomocą stałych serwisów w tle, WakeLock lub okresowych wiadomości FCM. Google aktywnie zwalcza takie praktyki — aplikacja może zostać oznaczona jako energochłonna i ograniczona jeszcze bardziej. Używaj WorkManager do zadań okresowych i Foreground Service tylko wtedy, gdy zadanie jest rzeczywiście widoczne dla użytkownika.

• WorkManager — preferowane API; Expedited Work wykonuje zadania bez opóźnienia
• FCM high-priority — tymczasowo podnosi bucket do Active do przetworzenia wiadomości
• Nie omijaj App Standby — prowadzi to do blokady aplikacji przez system
• Foreground Service — tymczasowo przenosi aplikację do Active na czas działania
• Testuj aplikację w bucket Rare i Frequent przez ADB przed każdą wersją