앱 MVP Android BroadcastReceiver: 등록·노출·후속 작업을 나누는 5가지 기준
Android MVP에서 충전 상태, 네트워크 변화, 앱 내부 갱신 같은 사건을 받으려 할 때 BroadcastReceiver를 추가하면 “이벤트를 받았다”와 “사용자 작업이 끝났다”를 한 성공 신호로 적기 쉽습니다. 하지만 등록 방식, 외부 앱이 호출할 수 있는 범위, onReceive() 뒤의 작업, 실제 기기에서 관찰한 결과는 서로 다른 질문입니다. 이 글은 이 네 경계를 나눠 Android MVP의 출시 범위와 QA 기록을 정하는 방법을 설명합니다.
Android Developers는 브로드캐스트 수신 방법을 컨텍스트 등록과 매니페스트 선언으로 구분합니다(C001). Android 8.0 이상을 타깃으로 하는 앱은 대부분의 암시적 브로드캐스트를 매니페스트에서 받을 수 없습니다(C002).
Android 7.0 이상을 타깃으로 하는 앱의 CONNECTIVITY_ACTION은 컨텍스트 등록이 필요합니다(C002). 그러므로 수신기를 추가하기 전에 “무슨 사건을, 앱이 어느 상태일 때, 누구에게 열어 둘 것인가”를 먼저 적는 편이 안전합니다.
먼저 완료 상태를 다섯 줄로 나눕니다
기록할 상태 | 확인할 질문 | 이것만으로 말할 수 없는 것 |
|---|---|---|
사건 정의 | 시스템 사건·앱 내부 사건·다른 앱의 요청 중 무엇인가 | 수신 방식이 적절하다는 결론 |
등록 범위 | 화면/앱 실행 중에만 등록할지, 매니페스트 진입점이 필요한지 | 항상 전달된다는 보장 |
외부 노출 | 다른 앱의 메시지를 받을 필요가 있는지, 권한 제한이 필요한지 | 인텐트 필터만으로 안전하다는 판단 |
후속 작업 |
| 수신 즉시 긴 작업이 완료됐다는 뜻 |
실기기 관찰 | 대상 OS·앱 상태·사건·화면 결과를 어떻게 남길지 | 모든 기기에서 같은 결과 |
이 표는 API를 늘리는 설계도가 아니라, 실패 원인을 한 문장으로 뭉치지 않기 위한 기록 방식입니다. 예를 들어 네트워크 연결 신호를 받지 못했을 때 원인이 매니페스트 등록 제한인지, 앱이 실행 중이 아니어서 컨텍스트가 사라졌는지, 수신 뒤 예약한 작업이 다른 조건에서 대기 중인지 분리해서 볼 수 있습니다.
기준 1: 사건이 ‘계속 감시할 일’인지 먼저 구분합니다
브로드캐스트는 시스템이나 앱이 사건을 알리는 메시지 방식입니다. 그렇다고 해서 모든 변화 감시를 수신기에 넣을 이유는 없습니다. Android 문서는 많은 앱이 같은 사건을 받으면 프로세스가 여럿 시작돼 성능과 사용자 경험에 영향을 줄 수 있다고 설명합니다(C001). 특정 시각에 실행할 일, 네트워크·충전 조건에서 처리할 일, 사용자가 시작한 오래 걸리는 작업은 각각 목적에 맞는 백그라운드 API가 더 적합할 수 있습니다.
MVP 기획서에는 “연결됨”처럼 사건 이름만 적지 말고, 사건 뒤에 사용자에게 약속할 결과를 적으세요. 예를 들어 “앱이 열려 있는 동안 연결 상태 안내를 갱신한다”와 “연결 가능해지면 보류한 업로드를 조건에 맞춰 다시 시도한다”는 다른 범위입니다.
전자는 화면 수신 범위, 후자는 실행 조건과 재시도 정책이 핵심입니다. 기존의 작업 중복·조건 설계가 필요하다면 Android WorkManager에서 즉시 처리·조건·중복 작업을 나누는 기준도 함께 확인할 수 있습니다.
기준 2: 컨텍스트 등록과 매니페스트 선언을 같은 수신으로 보지 않습니다
컨텍스트 등록 수신기는 등록한 컨텍스트가 유효한 동안만 수신합니다(C001). 화면에서만 의미 있는 변화라면 화면 수명주기와 함께 등록·해제할 수 있습니다. 반면 매니페스트에 선언한 수신기는 앱의 다른 구성요소가 실행 중이 아니어도 시스템이 앱을 시작해 전달할 수 있는 진입점입니다(C004). 이 차이는 단순한 코드 위치가 아니라, 사용자가 앱을 떠난 뒤에도 무엇을 처리 대상으로 둘지 정하는 제품 결정입니다.
여기서 “매니페스트면 백그라운드에서도 확실하다”라고 쓰면 안 됩니다. 대부분의 암시적 브로드캐스트에는 Android 버전과 타깃 SDK에 따른 제한이 있고, 예외 목록도 따로 관리됩니다(C002). 특히 연결 상태를 매니페스트로 기다리는 설계는 기대대로 동작하지 않을 수 있습니다. 사건 이름, 대상 SDK, 등록 위치, 앱 상태, 대안 API를 하나의 QA 항목으로 기록해야 합니다.
앱 MVP의 이벤트 처리 범위와 출시 QA 기준 정리하기
기준 3: 외부 노출은 인텐트 필터와 별도로 판단합니다
다른 앱이나 시스템이 보낸 메시지를 받아야 하는 수신기라면 android:exported 값과 필요한 권한을 의도적으로 정해야 합니다. 매니페스트 기준으로 exported=true는 앱 밖의 비시스템 소스에서도 메시지를 받을 수 있다는 뜻입니다.
exported=false라면 시스템·같은 앱·같은 사용자 ID 앱의 메시지로 범위가 좁아집니다(C004). 수신 인텐트에 민감한 값이 있거나 외부 앱 요청이 필요 없다면, “열어 둔 이유”가 없는 공개 진입점은 만들지 않는 것이 좋습니다.
인텐트 필터만으로 접근을 막을 수 있다고 가정해서도 안 됩니다. Android 문서는 필터가 보안 경계가 아니며, 중요한 내부 구성요소라면 exported=false를 사용하라고 안내합니다(C005). Android 12 이상에서는 인텐트 필터가 있는 활동·서비스·수신기에 android:exported를 명시하지 않으면 설치할 수 없습니다(C005).
Android 14 이상을 타깃으로 하는 런타임 등록 수신기는 외부 앱에 노출할지 나타내는 플래그가 필요하지만, 시스템 브로드캐스트만 받는 경우는 예외입니다(C006). 이 차이는 앱의 실제 target SDK와 수신하는 사건 종류를 함께 확인해야 합니다.
기준 4: onReceive()는 완료 처리 장소가 아니라 분기점으로 둡니다
수신기의 onReceive()가 호출됐다는 사실은 메시지가 도착했다는 관찰입니다. 긴 네트워크 요청, 대용량 파일 처리, 복잡한 동기화를 그 안에서 끝낼 수 있다는 보장은 아닙니다. Android는 onReceive()가 끝난 뒤 프로세스가 회수될 수 있으므로 장시간 스레드를 시작하지 말고, 후속 작업은 JobScheduler 같은 예약 방식으로 넘기라고 안내합니다(C003).
그래서 작업 기록을 두 단계로 나누는 편이 좋습니다. 첫째, 수신 시에는 예상한 action인지 확인하고 필요한 최소 정보만 저장하거나 다음 작업을 예약합니다. 둘째, 예약된 작업에서는 조건 충족, 실제 처리 결과, 실패 원인, 재시도 여부를 별도로 기록합니다. “수신 로그가 있다”는 “서버 반영·사용자 화면 갱신·업로드 완료”의 근거가 아닙니다.
기준 5: 테스트는 사건 하나가 아니라 조합으로 합니다
출시 전에는 수신기를 단위 테스트 하나로 닫지 말고, 아래처럼 상태 조합을 고르세요.
대상 OS와 target SDK는 무엇인가.
수신기는 매니페스트 선언인지, 어떤 컨텍스트에서 등록·해제되는지.
앱이 화면에 있는지, 백그라운드인지, 종료 상태인지.
시스템 사건인지, 같은 앱의 명시적 메시지인지, 외부 앱 요청인지.
수신 뒤 실제 사용자 화면·예약 작업·서버 결과 중 무엇을 관찰했는지.
이 다섯 줄은 모든 기기나 상황에서의 전달을 보장하지 않습니다. 대신 지원할 Android 버전과 제품 흐름 안에서 수신 경계가 무엇인지 드러냅니다. 문제가 생기면 “브로드캐스트가 안 됐다”가 아니라 등록 범위, 노출 설정, 플랫폼 제한, 후속 작업, 관찰 지점 중 어디를 다시 봐야 하는지 결정할 수 있습니다.
앱 MVP의 이벤트 처리 범위와 출시 QA 기준 정리하기
자주 묻는 질문
매니페스트에 수신기를 선언하면 앱이 꺼져 있어도 모든 이벤트를 받나요?
아닙니다. 매니페스트 선언 수신기는 앱의 진입점이 될 수 있지만, Android 버전·target SDK·브로드캐스트 종류에 따른 제한이 있습니다. 특히 대부분의 암시적 브로드캐스트는 Android 8.0 이상 타깃 앱에서 매니페스트 선언으로 받을 수 없습니다. 사건별 공식 문서와 현재 앱 조건을 확인해야 합니다.
인텐트 필터가 있으면 다른 앱의 호출을 막을 수 있나요?
아닙니다. 인텐트 필터는 보안 경계가 아닙니다. 외부 호출이 필요 없는 구성요소는 exported=false를 검토하고, 외부 발신을 받아야 하면 필요한 권한과 입력 검증을 함께 설계하세요.
onReceive()에서 바로 서버 동기화를 해도 되나요?
긴 작업 완료를 그 호출에 의존하지 않는 편이 좋습니다. Android는 수신기 반환 뒤 프로세스가 회수될 수 있다고 안내합니다. 수신과 실제 후속 처리의 상태를 나누고, 목적에 맞는 예약 작업으로 넘긴 뒤 결과를 별도로 확인하세요.
Android 14 타깃 앱의 런타임 수신기는 무엇을 더 확인해야 하나요?
외부 앱에 노출할 런타임 등록 수신기라면 exported 여부를 나타내는 플래그가 필요합니다. 다만 시스템 브로드캐스트만 받는 등록은 예외가 있으므로, 수신하는 action과 현재 target SDK를 함께 확인해야 합니다.
공식 출처
Android Developers: Broadcasts overview — 등록 방식, 암시적 브로드캐스트 제한, 후속 작업과 권한 안내 확인. 2026-09-21.
Android Developers: <receiver> — 매니페스트 수신기와 android:exported, 권한 범위 안내 확인. 2026-09-21.
Android Developers: Intents and intent filters — 필터의 한계와 exported 명시 요구사항 확인. 2026-09-21.
Android Developers: Android 14 behavior changes — 런타임 등록 수신기의 exported 플래그 안내 확인. 2026-09-21.
발행일: 2026-09-21 · 작성: 유인어스 앱 MVP 인사이트