피드로 돌아가기
Dev.toInfrastructure
원문 읽기
다중 복구 경로로 인한 OEM 배터리 최적화 예외 박탈 해결
Honor watched my Android app come back from the dead — and revoked the battery exemption that let it
AI 요약
Context
다양한 Android OEM 제조사의 백그라운드 제한을 극복하기 위해 11단계의 Service-recovery chain을 구축한 구조임. 하지만 특정 OEM(Honor)의 전력 관리 휴리스틱이 짧은 시간 내 발생하는 다중 복구 신호를 악성 좀비 프로세스로 오판하여 Battery exemption 권한을 강제로 회수하는 부작용 발생.
Technical Solution
- 복구 경로의 분산 발생 지점이 아닌 최종 실행 지점인 onStartCommand에서 요청을 통합하는 Deduplication 레이어 도입
- 동일한 wall-clock second 내에 발생하는 중복된 startForeground() 및 watchdog 재스케줄링 호출을 단일 실행으로 제어
- 각 OEM별로 상이한 제한 사항(Pixel의 AlarmManager 스로틀링, Samsung의 JobScheduler 소멸 등)을 대응하는 기존 11개 레이어의 기능은 유지
- 실행 시점의 동시성 제어를 통해 OS 관점의 가시적 공격성을 낮추는 'Whispering' 전략 채택
- 실기기 진단 로그 분석을 통해 문서화되지 않은 OEM 전용 PowerGenie 휴리스틱 패턴 식별 및 대응
실천 포인트
1. 백그라운드 서비스 복구 로직 설계 시, 다중 경로(Multi-path) 진입점이 최종 실행 지점에서 중복 호출되지 않도록 Idempotency 보장 여부 확인
2. OEM별로 상이한 전력 관리 정책이 존재하므로, 에뮬레이터 테스트 외에 실제 기기 기반의 Diagnostic export 로그 분석 프로세스 구축
3. 과도한 self-healing 메커니즘이 OS의 보안/전력 휴리스틱에 의해 Malware 패턴으로 오인될 가능성을 고려한 설계 검토