Background Processing & Intents Physics

1. Overview

백그라운드 처리와 인텐트 역학(Background Processing & Intents Physics)은 안드로이드 운영체제가 한정된 배터리와 RAM을 지키기 위해 설정한 철저한 백그라운드 제한(Doze Mode) 속에서, 앱이 어떻게 무거운 작업과 스케줄링을 합법적으로 수행하는지 다루는 생존 물리입니다.

유저가 홈 버튼을 누르면 안드로이드 OS는 배터리 절약을 위해 수 분 내에 프로세스를 얼리거나 죽입니다(App Standby). 이 엄격한 규제 속에서 사진 백업, 위치 추적, 알람 기능을 수행하려면 OS의 허가를 받아야 합니다. 학습자는 앱과 OS, 앱과 앱 사이를 이어주는 비동기 통신 규약인 인텐트(Intent)의 구조를 분해하고, 배터리를 아끼면서도 안정적으로 백그라운드 작업을 완수하는 현대 안드로이드의 표준 처방인 워크매니저(WorkManager)와 포그라운드 서비스(Foreground Service)의 생명주기를 통제합니다.

2. Scope & Boundaries

In-Scope

인텐트 통신(Intents): 명시적/암시적(Explicit/Implicit) 인텐트, 프로세스 간 통신(IPC), Intent Filter.
백그라운드 제한 구조: Doze Mode, App Standby Buckets, 배터리 최적화 물리.
스케줄링 및 서비스: WorkManager, Foreground Service, AlarmManager, Broadcast Receiver.
생명주기 제어: 앱이 죽은(Terminated) 상태에서 OS에 의해 강제로 깨어나는 Wakeup 매커니즘.

Out-of-Scope

UI 렌더링 및 코루틴 흐름: 앱이 켜져 있을 때 비동기로 다운로드를 돌리는 코루틴 로직 $ightarrow$ 13-02-01. Kotlin & JVM-ART Mechanics 영역으로 위임.
리눅스 커널 프로세스 스케줄링: 스레드 컨텍스트 스위칭의 하드웨어적 관점 $ightarrow$ 03-01. OS Processes & Thread Physics 영역으로 위임.

Boundaries

iOS Sandbox vs Android Doze (13-01-04 vs 13-02-03): iOS(13-01-04)는 백그라운드 진입 시 3초 만에 무조건 스레드를 얼려버리는 극단적 통제 방식을 쓰지만, 안드로이드(13-02-03)는 Foreground Service를 띄우면 유저에게 알림(Notification)을 보여준다는 조건 하에 무한정 백그라운드 연산을 허용하는 개방적 차이를 보입니다.

3. Counterexample

구시대적 백그라운드 맹신 (Legacy Service Fallacy): 앱을 끄고 나서도 몰래 GPS를 수집하겠다며 과거 방식인 일반 Service를 띄워두는 무지. 안드로이드 8.0(Oreo) 이후부터 OS는 유저 모르게 도는 백그라운드 서비스를 1분 내외로 무자비하게 학살(Crash)합니다. 작업을 유지하려면 반드시 상단바에 "이 앱이 위치를 수집 중입니다"라는 영구 알림을 박아 유저에게 물리적으로 노출하는 Foreground Service를 써야 합니다.
무조건 즉시 실행 (Immediate Execution Fallacy): 유저 행동 로그 10개를 서버로 보내기 위해 1분에 한 번씩 기기를 깨우는(Wake Lock) 알람을 세팅하는 행위. 이로 인해 기기가 잠(Doze Mode)에 들지 못해 배터리가 광탈합니다. 당장 보내지 않아도 되는 작업은 WorkManager에 던져두어, OS가 기기가 충전기에 꽂혔거나 와이파이가 연결될 때 한꺼번에 모아서 처리(Batching)하도록 시스템에 양보해야 합니다.

4. Prerequisites

운영체제 프로세스 간 통신 (Basic): 인텐트(Intent)가 본질적으로 어떻게 다른 메모리 공간의 프로세스를 깨우고 데이터를 넘기는지(IPC) 구조를 이해해야 합니다. (03-01. OS Processes)
배터리와 모바일 하드웨어 물리 (Recommended): 기기가 절전 상태에 진입할 때 무선 통신 칩(Radio)과 CPU가 어떻게 슬립(Sleep)하는지 알면 Doze Mode를 이해하기 쉽습니다. (02-02. Embedded Architecture)

5. Learning Map

Sequence	Core Cluster	Objective & Description	Evidence (BoK)
1	Intents & IPC	다른 앱(카메라 등)을 호출하고 데이터를 주고받는 안드로이드 고유의 비동기 메신저(Intent) 체계를 이해합니다.	Industry
2	Battery & Doze Mode	스마트폰 화면이 꺼진 뒤 OS가 어떻게 백그라운드 앱들의 숨통을 조이고 전력을 차단하는지(Doze) 배터리 물리를 파악합니다.	Primary
3	WorkManager	폰을 재부팅하거나 앱을 강제로 꺼도, "충전 중일 때 동기화해 줘"라는 스케줄링 약속이 100% 이행되도록 시스템에 등록합니다.	Primary
4	Foreground Service	내비게이션이나 음악 앱처럼, 화면을 꺼도 절대 죽으면 안 되는 작업을 OS에게 합법적으로 승인받는 방법을 익힙니다.	Industry

6. Learning Topics

Basic

Core Topic 01: 인텐트(Intent)와 컴포넌트 통신 역학

Why to Learn: 내가 만든 앱 안에서만 놀지 않고, 시스템 카메라를 열거나 지도 앱에 좌표를 넘겨주는 등 OS 생태계와 융합하기 위함입니다.
What to Learn: 명시적 인텐트(앱 내부), 암시적 인텐트(외부 앱), Intent Filter, startActivity, BroadcastReceiver.
How to Learn: 앱 A에서 "https://..."를 담은 암시적 인텐트를 우주(OS)로 쏘아 올리면, 이 주소를 처리할 수 있다고 Intent Filter에 등록해 둔 여러 웹 브라우저 앱들이 손을 들고 나타나는(Resolving) 라우팅 물리학을 관찰합니다.
Implement: 특정 이메일 주소와 제목(Subject)을 담은 암시적 인텐트를 생성하여, 유저 기기에 설치된 이메일 클라이언트(Gmail 등)를 자동으로 깨워 작성 창을 띄우는 브릿지 코드 구현.

Core Topic 02: Doze Mode와 앱 대기 상태(App Standby)

Why to Learn: 코딩을 잘못해서 유저 폰의 배터리를 빨아먹는 악성 앱으로 낙인찍혀 삭제당하는 것을 피하기 위해서입니다.
What to Learn: Doze Mode(절전 모드), Maintenance Window(유지보수 창), Wake Lock(기기 깨움 방지), App Standby Buckets.
How to Learn: 폰을 책상에 올려두고 화면이 꺼지면, OS가 네트워크를 끊고 알람을 지연시키다가 잠깐씩(Window) 몰아서 통신을 열어주고 다시 잠드는 배터리 호흡 주기를 그래프로 분석합니다.
Implement: (이론/테스트) ADB 명령어로 강제로 기기를 Doze Mode에 빠뜨린 뒤, 일반 타이머나 네트워킹 코드가 어떻게 무시되고 정지되는지 콘솔 로그를 통해 디버깅.

Why to Learn: 대용량 파일 백업이나 데이터베이스 동기화처럼, 앱이 중간에 죽더라도 언젠가는 '반드시' 완료되어야 하는 끈질긴 작업을 시스템에 위임하기 위함입니다.
What to Learn: WorkManager, Worker, 제약 조건(Constraints: Wi-Fi, 충전 중), 체이닝(Chaining), 지속성(Persistence).
How to Learn: 코루틴이나 일반 스레드는 유저가 앱을 스와이프해서 끄면 즉각 파괴되지만, WorkManager에 던진 일(Work)은 SQLite 데이터베이스에 각인되어 폰을 껐다 켜도 살아나서 실행되는 영속성의 마법을 뜯어봅니다.
Implement: "기기가 Wi-Fi에 연결되어 있고, 충전 중일 때만" 실행되도록 락(Constraints)을 건 데이터 백업 CoroutineWorker를 정의하고 OS의 스케줄러 큐에 던지는 로직 작성.

Practical

Core Topic 04: Foreground Service와 영구 생존권

Why to Learn: 달리기 트래킹, 음악 재생, 파일 다운로드 등 유저가 앱을 내려도 절대 죽으면 안 되는 미션을 안드로이드의 강제 킬(Kill)로부터 지켜내기 위함입니다.
What to Learn: Foreground Service, Notification(상단바 알림), OOM(Out of Memory) 우선순위 역학.
How to Learn: 일반 서비스를 띄우면 1분 뒤 강제 종료(Crash)되지만, startForeground()를 호출하며 상단바 알림을 고정(Pin)하는 순간 프로세스의 메모리 생존 우선순위가 최상위로 격상되는 권력 이동을 이해합니다.
Implement: 음악 재생이나 타이머 기능을 담당하는 서비스를 구축하고, 상단바에 해제 불가능한(Ongoing) 알림을 박아 유저가 직접 끄기 전까지 백그라운드에서 CPU 연산을 강제로 쟁취하는 코드 구현.

7. Terminology

Term (EN / ko, abbr)	1문장 정의	단계(기본/권장/실무/심화)	역할/맥락	관련 개념	유사/대비/함께 사용	오해 포인트	Evidence(Primary/Secondary/Industry)	Flags(core)
Intent	안드로이드 시스템 내에서 다른 컴포넌트나 외부 앱을 깨우고 데이터를 넘기기 위해 발송하는 비동기 메시지 버스입니다.	기본	IPC 통신	Intent Filter	vs. Direct Method Call	다른 화면을 띄울 때 객체를 직접 생성해 부른다는 전통적 OOP 착각	Industry Docs	core
Doze Mode	화면이 꺼지고 기기가 정지 상태일 때, 배터리를 아끼기 위해 앱의 네트워크와 백그라운드 작업을 OS가 강제로 차단하는 물리적 수면 모드입니다.	권장	자원 제어	Standby Buckets	vs. Wake Lock	백그라운드 스레드는 24시간 내내 자유롭게 돌 수 있다는 과거의 오해	Primary	core
WorkManager	앱이 강제 종료되거나 폰이 재부팅되더라도, 설정된 조건(Wi-Fi 등)이 만족되면 반드시 실행을 보장해주는 시스템 레벨 스케줄러입니다.	실무	예약 실행	JobScheduler	vs. Coroutine	WorkManager가 무거운 연산을 당장 0.1초 만에 실행해줄 거라는 오해	Industry	core
Foreground Service	유저에게 상단바 알림(Notification)을 보여줌으로써 "나 지금 돌아가고 있다"고 인지시키고 백그라운드 생존 우선순위를 획득하는 서비스입니다.	실무	생명 연장	Background Kill	vs. Background Service	포그라운드 서비스는 알림을 안 띄우고 몰래 돌릴 수 있다는 불법적 착각	Primary	core

8. References

Primary References

[CS2023: Operating Systems] — 모바일 운영체제의 전력 관리 모델(Power Management) 및 프로세스 생명주기 격리 구조.
[SWEBOK v3: Software Construction] — 이벤트 기반 스케줄링 아키텍처 및 무중단 백그라운드 태스크 처리 설계.

Secondary References

[Android Architecture Components Documentation] — WorkManager의 SQLite 기반 작업 영속성(Persistence) 아키텍처 및 체이닝 구조.
[Inside Android OS] — Zygote 프로세스 분기와 OOM(Out of Memory) Killer의 프로세스 점수(oom_adj) 책정 역학.

Industry References

[Android Developers: Power Management Restrictions] — Doze Mode, App Standby 버킷 체계 및 백그라운드 서비스 강제 종료 정책.
[Android Developers: Intents and Intent Filters] — 앱 간 프로세스(IPC) 메시지 라우팅 및 명시적/암시적 인텐트 분기 처리 백서.

9. Final Checklist

Primary Checklist

백그라운드에서 반드시 실행이 보장되어야 하는 무거운 작업(동기화, 파일 백업)에 일반 스레드나 코루틴 대신 영속성을 가진 WorkManager를 사용했는가?
음악 재생이나 내비게이션처럼 백그라운드에서 장시간 CPU를 잡아먹는 프로세스를 돌릴 때, Foreground Service를 선언하고 상단바 알림(Notification)을 반드시 노출하는가?

Secondary Checklist

다른 앱이나 카메라 등을 호출할 때 직접 의존성을 갖지 않고, 암시적 인텐트(Implicit Intent)를 통해 OS가 최적의 앱을 찾아 라우팅하도록 열어두었는가?
WorkManager 스케줄링 시 네트워크 환경(Unmetered Wi-Fi), 배터리 충전 상태 등 제약 조건(Constraints)을 걸어 배터리 광탈 현상을 방어했는가?

Industry Checklist

운영체제 레벨의 배터리 절전 모드(Doze Mode) 진입 시, 짧은 주기로 무한정 기기를 깨우는 낡은 타이머(AlarmManager)나 WakeLock 코드를 완전히 제거했는가?
안드로이드 12(API 31) 이상의 엄격한 보안 정책에 맞춰, 백그라운드 상태에서 갑작스럽게 포그라운드 서비스를 띄우다 발생하는 ForegroundServiceStartNotAllowedException 충돌을 방어했는가?