앱 MVP Android 알림 탭: PendingIntent·중간 경유·도착 화면을 나누는 5가지 기준
알림을 눌렀는데 잠깐 빈 화면이 보이거나 기대한 화면 대신 다른 화면이 열리면, 문제를 “푸시가 도착했다”는 한 문장으로 닫기 쉽습니다. 하지만 Android MVP에서는 알림 생성, 사용자의 탭, 앱이 받을 PendingIntent, 최종 Activity의 상태 복원, 화면 도착 뒤의 측정을 각각 구분해야 합니다. 특히 Android 12(API 31) 이상을 타깃으로 하는 앱은 알림 탭 뒤 서비스나 BroadcastReceiver가 다시 startActivity()를 호출하는 notification trampoline 패턴을 사용할 수 없습니다.
이 글은 알림 탭의 목적지를 직접 연결하고, 필요한 출처 정보는 extras와 앱 생명주기 관찰로 남기는 출시 전 점검 기준입니다. 특정 구현 하나가 모든 앱에 맞는다는 뜻은 아닙니다. 로그인 만료, 권한 거부, 삭제된 콘텐츠처럼 실제 목적지를 바로 보여줄 수 없는 조건은 별도 화면과 안내를 설계해야 합니다.
먼저 5개의 상태를 한 결과로 섞지 마세요
알림 탭 흐름은 아래 다섯 기록으로 나누면 QA와 장애 분석이 쉬워집니다. “전송 성공”은 사용자가 원하는 화면을 보았다는 증거가 아니며, Activity가 열렸다고 해도 그 안의 콘텐츠가 유효한지는 별도 확인 대상입니다.
알림 사건: 어떤 사용자 행동 또는 서버 사건이 알림을 만들었는가.
탭 대상: 사용자가 탭했을 때 열어야 하는 최종 화면은 무엇인가.
직접 연결: Notification의
PendingIntent가 그 Activity를 가리키는가.도착 뒤 상태: 로그인, 권한, 삭제·종료된 리소스에서 무엇을 보여주는가.
관찰 결과: 탭 시도·Activity 도착·콘텐츠 표시를 어떤 범위에서 구분해 확인했는가.
이미 알림 수신 자체를 점검하고 있다면, 알림 권한·전송·기기 표시를 나누는 점검 글을 함께 보세요. 수신·표시가 정상이어도 탭 뒤의 이동 규칙은 따로 검수해야 합니다.
왜 서비스·리시버를 거친 화면 이동이 문제가 되나요?
Android 공식 문서는 알림 또는 알림 액션을 누른 뒤 서비스나 BroadcastReceiver가 Activity를 시작하는 중간 경유 컴포넌트를 notification trampoline이라고 설명합니다. Android 12 이상을 타깃으로 하면 이 패턴에서 Activity 시작이 차단될 수 있습니다. 따라서 “탭 로그를 남긴 다음 화면을 열자”처럼 보이는 간단한 분기도, 최종 화면 진입을 중간 컴포넌트에 의존하게 만들 수 있습니다.
출시 판단에서 중요한 것은 우회 경로를 완전히 없애는 구호가 아니라 역할을 바꾸는 일입니다. 화면 이동은 Notification에 연결한 PendingIntent가 담당하고, 출처·캠페인·콘텐츠 식별자는 intent extras로 전달합니다. 화면이 실제로 만들어진 뒤의 관찰은 ActivityLifecycleCallbacks 또는 Jetpack lifecycle 관찰자처럼 화면 생명주기 범위에서 처리할 수 있습니다. 이 분리는 전송 이벤트와 화면 도착 이벤트를 같은 성공으로 잘못 세지 않게 합니다.
직접 연결을 설계하는 5가지 기준
확인 대상 | 출시 전 질문 | 기록 예시 |
|---|---|---|
최종 Activity | 탭 후 사용자가 볼 화면이 하나로 정해졌는가? | 콘텐츠 상세, 주문 상태, 인앱 공지처럼 목적 화면 이름 |
PendingIntent | 서비스·리시버가 아닌 최종 Activity로 직접 연결되는가? | Intent 대상과 request code, 생성 위치 |
출처 정보 | 화면을 여는 대신 필요한 추적 정보를 extras로 전달했는가? | 알림 종류, 사건 ID, 탭 시각은 최소 범위로 |
도착 예외 | 세션 만료·권한 거부·삭제된 항목에서 복구 경로가 있는가? | 로그인 뒤 복귀, 목록 이동, 이유 안내 |
관찰 | 탭·Activity 도착·콘텐츠 표시를 구분해 확인했는가? | 테스트 기기, OS, 계정 상태, 결과 |
여기서 extras에 민감한 원문이나 장기 식별자를 과도하게 넣지 않는 것도 중요합니다. 화면이 필요한 최소 식별자만 받고, 서버에서 다시 권한과 현재 상태를 확인하는 구조가 더 안전합니다. 알림을 눌렀다는 사실만으로 사용자가 해당 데이터에 계속 접근할 권한이 있다는 뜻은 아닙니다.
우리 앱 MVP의 알림 탭·화면 도착 QA 범위 점검하기
실제 QA는 네 가지 조건을 바꿔서 확인하세요
한 대의 로그인된 최신 기기에서 알림을 한 번 탭해 보는 것만으로는 충분하지 않습니다. 최소한 앱이 완전히 종료된 상태와 백그라운드 상태, 로그인 유지와 만료 상태, 대상 콘텐츠가 정상인 경우와 사라진 경우, 지원하는 OS 범위를 나누어 확인하세요. 알림 본문이 아닌 액션 버튼이 있다면 그 버튼도 별도 탭 대상으로 봐야 합니다.
테스트 결과에는 “알림이 왔다” 대신 최종 화면 이름, 보인 콘텐츠 상태, 예외 안내, 재시도 가능 여부를 남깁니다. Android 문서는 디버그 빌드에서 호환성 변경을 조절해 시험할 수 있다고 안내하지만, 그 토글은 출시 준비 완료 증명이 아닙니다. 실제 타깃 SDK와 지원 기기 조건에서 다시 확인해야 합니다.
자주 묻는 질문
알림 탭 뒤에 로그를 남기려면 리시버가 꼭 필요한가요?
그렇지 않습니다. Android 문서는 notification trampoline을 피하면서 출처 정보는 알림 게시 시 extras로 전달하고, 중앙 관찰은 ActivityLifecycleCallbacks 또는 Jetpack lifecycle 관찰자를 사용할 수 있다고 안내합니다. 다만 실제 분석 도구와 개인정보 처리 범위는 앱의 정책과 구현을 별도로 검토해야 합니다.
알림이 도착했으면 탭 뒤 화면도 정상이라고 볼 수 있나요?
아닙니다. 도착·표시·탭·Activity 도착·콘텐츠 표시에는 서로 다른 실패 지점이 있습니다. 수신 점검 결과와 탭 뒤 목적지 QA를 같은 지표로 합치지 말고, 기기·OS·세션·콘텐츠 상태별 결과를 남기세요.
PendingIntent를 쓰면 로그인 만료나 삭제된 콘텐츠도 해결되나요?
아닙니다. PendingIntent는 탭 뒤 최종 Activity로 연결하는 방식의 일부입니다. Activity가 열린 뒤에는 현재 로그인 상태, 권한, 콘텐츠 존재 여부를 다시 확인하고 로그인·목록·안내 같은 복구 화면을 정해야 합니다.
Android 12보다 낮은 버전만 지원하면 중간 경유를 계속 써도 되나요?
지원 OS와 target SDK, 사용자 경험, 유지보수 비용을 함께 봐야 합니다. Android 공식 문서의 차단 조건은 Android 12 이상을 타깃으로 하는 앱에 관한 것이지만, 직접적인 목적지 연결과 분리된 관찰 기록은 버전과 무관하게 흐름을 이해하고 테스트하기 쉽게 만듭니다.
출시 전 결론: 탭 목적지와 관찰을 분리하세요
알림을 누른 사용자를 중간 컴포넌트가 다시 화면으로 보내는 구조는 Android 12 이상 타깃 앱에서 출시 위험이 될 수 있습니다. 최종 Activity로 향하는 PendingIntent, 필요한 최소 extras, 도착 뒤의 세션·콘텐츠 확인, 그리고 분리된 관찰 기록을 한 묶음으로 검수하세요. 이 체크는 알림 성과를 보장하지 않으며, 실제 기기와 지원 범위에서 확인한 결과만 출시 기록으로 남겨야 합니다.