App Standby — 정의, 대기 수준 및 작동 원리

App Standby란

App Standby는 Android 에너지 관리 시스템의 구성 요소로, Android 6.0(API 23)에서 도입되고 Android 9(API 28)에서 크게 재설계되었습니다. 그 역할은 사용자가 어떤 앱을 거의 사용하지 않는지 확인하고 해당 앱의 백그라운드 활동(네트워크 요청, 동기화, JobScheduler 및 AlarmManager)을 제한하는 것입니다. Doze와 달리 App Standby는 화면이나 기기 움직임 상태에 의존하지 않습니다.

시스템은 앱을 4개의 bucket(수준)으로 분류합니다: Active, Working Set, Frequent, Rare. 각 수준은 백그라운드 활동이 얼마나 제한되는지 결정합니다. 수준 간 전환은 앱 사용 패턴(사용자가 앱을 여는 빈도, 알림 수신, 위젯과의 상호작용)에 따라 자동으로 이루어집니다.

App Standby는 Doze Mode와 함께 작동하지만 이를 대체하지는 않습니다. Doze가 기기 비활성 시 모든 앱의 백그라운드 활동을 제한하는 반면, App Standby는 기기 상태와 관계없이 특정 앱을 제한합니다. Rare 수준의 앱은 사용자가 며칠 동안 열지 않은 경우, 전화를 적극적으로 사용하는 중에도 제한을 받습니다.

Android 9+의 Bucket

Android 9(API 28)부터 Google은 App Standby Buckets(숫자 값이 있는 공식 분류)를 도입했습니다. 시스템은 기계 학습을 사용하여 앱의 다음 실행을 예측합니다. 모델이 앱이 몇 시간 내에 열릴 것으로 예측하면 Active bucket이 할당됩니다. 예측이 드문 사용을 나타내면 Rare가 할당됩니다.

App Standby 작동 방식

App Standby는 bucket을 결정하기 위해 여러 요소를 분석합니다: 사용자가 앱을 마지막으로 연 시간, 상호작용 빈도(일/주당 실행 횟수), FCM 알림 수신, 데스크톱의 활성 위젯 존재, AlarmManager 구독. 앱이 사용되지 않는 기간이 길수록 bucket이 낮아지고 제한이 더 엄격해집니다.

시스템 서비스 UsageStatsManager가 앱 사용 통계를 수집하여 StandbyController(각 앱의 bucket을 계산하는 프레임워크 구성 요소)로 보냅니다. StandbyController는 시스템 이벤트도 고려합니다: 앱 업데이트 후, 사용자가 새 기능을 평가할 수 있도록 bucket이 며칠 동안 Active로 재설정됩니다.

중요한 특징: App Standby는 앱 프로세스를 종료하지 않고 백그라운드 기능을 제한합니다. 사용자가 앱과 상호작용하는 동안(bucket Active) 앱은 계속 작동합니다. 사용자가 앱을 닫고 돌아오지 않으면 시스템은 비활성 시간을 계산하기 시작하고 bucket을 Working Set 또는 Frequent로 낮출 수 있습니다.

FCM이 bucket에 미치는 영향

FCM high-priority 메시지를 수신하면 앱의 bucket이 일시적으로 Active까지 올라갈 수 있습니다. 이는 앱이 제한 없이 작업(메시지 처리, 데이터 동기화)을 수행할 수 있는 기회를 제공합니다. 그러나 처리가 완료되면 bucket은 원래 값으로 돌아갑니다. Google은 앱을 "살아있는" 상태로 유지하기 위한 것이 아니라 중요한 알림을 전달하기 위해 이 메커니즘을 사용할 것을 권장합니다.

App Standby 수준

App Standby는 앱을 분류하기 위해 4개의 수준(bucket)을 사용합니다. 각 수준은 백그라운드 작업의 지연 시간을 결정합니다: 수준이 낮을수록 지연이 길어집니다. 시스템은 지난 7~14일 동안 수집된 사용 통계를 기반으로 앱을 수준 간에 자동으로 이동시킵니다.

Active — 활성 앱

Active — 사용자가 최근에 상호작용한 앱(실행, 알림 수신 또는 위젯 사용). 이 bucket에는 제한이 없습니다: JobScheduler가 즉시 실행되고, 네트워크를 사용할 수 있으며, AlarmManager가 정확하게 작동합니다. 앱은 사용자가 몇 시간 동안 상호작용을 중단할 때까지 Active 상태를 유지합니다.

Working Set 및 Frequent

Working Set — 앱이 정기적으로 사용됨(주에 여러 번). 백그라운드 작업 지연 최대 2시간. Frequent — 앱이 한 달에 여러 번 사용됨. 지연 최대 4시간. 두 수준 모두 네트워크는 유지 관리 윈도우에서만 사용 가능하며 AlarmManager가 지연될 수 있습니다. JobScheduler는 가장 가까운 윈도우에서 작업을 실행합니다.

Rare — 거의 사용되지 않음

Rare — 가장 엄격한 수준으로, 사용자가 30일 이상 열지 않은 앱에 할당됩니다. 백그라운드 작업 지연 최대 24시간. 유지 관리 윈도우 외부에서는 네트워크가 완전히 차단되고, AlarmManager는 setAndAllowWhileIdle() 플래그로만 9분에 1회 제한으로 작동합니다. FCM high-priority 알림은 계속 전달되지만 bucket을 높일 수 없습니다.

App Standby 제한 사항

App Standby는 백그라운드 작업의 여러 범주에 제한을 적용합니다. Doze와 달리 App Standby의 제한은 화면 및 충전기 상태와 관계없이 작동합니다. 개발자는 특히 대상 사용자가 앱을 불규칙하게 사용하는 경우 이러한 제한을 고려하여 앱을 설계해야 합니다.

JobScheduler 및 WorkManager

JobScheduler — App Standby의 영향을 받는 주요 API입니다. bucket에 따라 작업 실행이 2~24시간 지연됩니다. 내부적으로 JobScheduler를 사용하는 WorkManager(API 23+에서)도 이러한 지연의 영향을 받습니다. 시간에 민감한 작업의 경우 내부적으로 Foreground Service를 실행하고 bucket에 의존하지 않는 Expedited Work를 사용하세요.

네트워크 제한

Working Set, Frequent 및 Rare bucket의 앱은 언제든지 임의의 네트워크 요청을 수행할 수 없습니다. 시스템은 Doze와 동기화된 유지 관리 윈도우 내에서만 네트워크 액세스를 허용합니다. 중요한 데이터를 보내려면 FCM high-priority를 사용한 후 유지 관리 윈도우에서 동기화하세요.

AlarmManager

AlarmManager는 App Standby에서 Doze와 동일한 규칙을 따릅니다: 정확한 알람(setExact())은 지연되고 setAndAllowWhileIdle()은 9분에 1회로 제한됩니다. Rare bucket의 경우 지연이 최대 24시간에 달할 수 있어, 거의 사용되지 않는 앱에서 정확한 작업 스케줄링에 AlarmManager를 부적합하게 만듭니다.

• JobScheduler — bucket에 따라 작업이 2~24시간 지연
• 네트워크 — Working Set 이하의 앱은 유지 관리 윈도우에서만 액세스 가능
• AlarmManager — 정확한 알람 지연, setAndAllowWhileIdle — 1회/9분
• SyncManager — 계정 동기화가 유지 관리 윈도우까지 지연
• Widget updates — 위젯 업데이트 빈도가 줄어들 수 있음

제외 받는 방법

제외는 사용자 배터리 설정(수동 화이트리스트) 또는 시스템 Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS의 두 가지 방법으로 얻을 수 있습니다. 그러나 Google은 제외 액세스를 엄격하게 규제합니다 — 제외에 대한 충분한 이유가 없는 앱은 Google Play에서 거부될 위험이 있습니다.

사용자는 설정 → 앱 → [앱] → 배터리 → 최적화 → 최적화하지 않음을 통해 특정 앱에 대한 제한을 수동으로 해제할 수 있습니다. 이렇게 하면 선택한 앱에 대한 App Standby 및 Doze 제한이 완전히 해제됩니다. 개발자는 사용자에게 지침이나 시스템 대화상자를 표시할 수 있지만 앱을 강제로 제외 목록에 추가할 수는 없습니다.

Foreground Service는 알림과 함께 자동으로 App Standby에서 일시적으로 제외됩니다. 서비스가 실행되고 알림을 표시하는 동안 앱은 실제 수준에 관계없이 Active bucket으로 전환됩니다. 서비스가 중지되면 bucket은 원래 값으로 돌아갑니다. 시스템 제외를 요청하지 않고 백그라운드 작업을 보장하는 가장 안정적인 방법입니다.

제외를 요청해야 하는 경우

Whitelist 요청은 실시간 내비게이션, 건강 모니터링, VoIP 통화, 기기 보안 등 미션 크리티컬한 백그라운드 기능이 있는 앱에만 의미가 있습니다. 대부분의 앱은 Foreground Service 또는 WorkManager를 사용하는 것으로 충분합니다. 명확한 필요성 없이 제외를 요청하는 앱은 Google Play에서 게시가 거부될 수 있습니다.

// 앱 스탠바이에서 제외 요청
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// 현재 상태 확인
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

App Standby 테스트

테스트는 ADB를 통해 App Standby에서 앱을 임의의 bucket으로 강제 설정하고 해당 동작을 확인할 수 있습니다. 이는 백그라운드 동기화, 알림 또는 정기적인 업데이트에 의존하는 앱에 중요합니다. 테스트는 Android 9+의 물리적 기기 또는 에뮬레이터에서 수행해야 합니다.

bucket을 강제로 설정하려면 명령어 adb shell am set-standby-bucket [package] [bucket]을 사용합니다. bucket은 active, working_set, frequent 또는 rare가 될 수 있습니다. 현재 bucket을 보려면 — adb shell am get-standby-bucket [package]. 시스템은 명령어 adb shell dumpsys usagestats를 통해 앱의 장기 비활성화를 시뮬레이션할 수도 있습니다.

# 앱에 Rare bucket 설정
$ adb shell am set-standby-bucket com.example.app rare

# 현재 bucket 보기
$ adb shell am get-standby-bucket com.example.app

# 모든 bucket을 Active로 재설정
$ adb shell dumpsys usagestats clear

# 시스템의 모든 bucket 보기
$ adb shell dumpsys usagestats

확인할 사항

Rare bucket을 설정한 후 확인하세요: WorkManager 작업이 24시간 내에 실행되는지, AlarmManager가 작동하는지, FCM 알림이 전달되는지, Foreground Service가 제한 없이 작동하는지. Expedited Work 정책의 WorkManager는 Foreground Service를 사용하므로 Rare bucket에서도 즉시 실행되어야 합니다. 일반 WorkManager 작업은 bucket에 따라 지연됩니다.

모범 사례

App Standby에 내성이 있는 앱 개발에는 백그라운드 작업에 대한 의식적인 접근 방식이 필요합니다. 기본 원칙: 앱이 항상 Active bucket에 있다고 가정하지 마세요. Frequent 및 Rare bucket의 특징적인 지연이 있어도 올바르게 실행되도록 백그라운드 작업을 설계하세요.

Expedited Work로 WorkManager 사용

Expedited Work(WorkManager 2.7+)는 내부적으로 Foreground Service를 실행하여 bucket에 관계없이 작업을 즉시 실행할 수 있습니다. 이는 메시지 전송, 결제 후 동기화, 수신 전화 처리 등 지연할 수 없는 작업에 최적의 선택입니다. 일반 WorkManager 작업은 bucket을 고려하여 유지 관리 윈도우에서 실행됩니다.

재활성화를 위한 FCM

App Standby에서 앱을 깨우려면 FCM high-priority 메시지를 사용하세요. 앱이 이러한 메시지를 수신하면 bucket이 일시적으로 Active로 올라가고 필요한 작업(동기화, 데이터 업데이트)을 수행할 수 있습니다. 처리가 완료되면 bucket은 원래 수준으로 돌아갑니다.

메모리에 계속 상주하는 것 방지

지속적인 백그라운드 서비스, WakeLock 또는 정기적인 FCM 메시지로 App Standby를 우회하려고 하지 마세요. Google은 이러한 관행에 적극적으로 대처합니다 — 앱이 에너지 소모가 많은 것으로 표시되어 더 엄격하게 제한될 수 있습니다. 정기적인 작업에는 WorkManager를 사용하고, Foreground Service는 작업이 실제로 사용자에게 표시될 때만 사용하세요.

• WorkManager — 선호 API, Expedited Work는 지연 없이 작업 실행
• FCM high-priority — 메시지 처리를 위해 bucket을 일시적으로 Active로 상승
• 우회하지 마세요 App Standby — 시스템에 의한 앱 차단으로 이어짐
• Foreground Service — 작업 시간 동안 앱을 일시적으로 Active로 전환
• 테스트하세요 각 릴리스 전에 ADB를 통해 Rare 및 Frequent bucket에서 앱을