앱 MVP Android 기본 앱 역할: 가용성·사용자 승인·회수·대체 흐름을 나누는 5가지 기준

Android MVP가 전화, SMS, 브라우저, 홈 화면처럼 시스템의 기본 처리자가 되어야 하는 기능을 검토할 때는 ‘권한 하나를 받으면 된다’라고 생각하기 쉽습니다. 그러나 기본 앱 역할은 일반 런타임 권한과 같은 상태가 아닙니다. 역할 자체가 기기에 있는지, 앱이 역할의 요건에 맞는지, 사용자가 시스템 화면에서 승인하는지, 나중에 다른 앱으로 바꾸는지에 따라 앱의 실제 동작이 달라집니다.

이 글은 Android RoleManager 기준으로 기본 역할을 요청할지 판단하는 방법을 정리합니다. 특정 역할의 승인, Play 등록, 사용자 전환이나 기능 결과를 보장하지 않습니다. 지원 OS, manifest 구성, 스토어 요구사항과 실제 기기 검수는 앱별로 따로 확인해야 합니다.

답부터: 시스템 기본 역할은 기능 목적이 분명할 때만 검토합니다

앱이 어떤 링크를 열거나 알림을 보내는 정도라면 기본 브라우저·SMS·전화 역할을 요구할 근거가 없는 경우가 많습니다. 반대로 전화 앱이 통화 흐름을 처리하거나 메시지 앱이 핵심 메시지 기능을 수행하는 것처럼, 운영체제의 특정 역할 없이는 제품의 주된 약속을 이행하기 어려운 경우라면 역할을 검토할 수 있습니다.

Android 문서에서 역할은 특정 권한과 연결된 시스템 내 고유 이름입니다. 여러 앱이 자격을 갖출 수 있어도 역할 보유자가 될 수 있는 수는 제한될 수 있습니다. 즉 ‘관련 기능을 만들었다’와 ‘기본 역할을 요청할 자격이 있다’를 같은 체크로 처리하면 안 됩니다.

출시 판단에서 나눌 5가지 상태

1. 기능 목적: 기본 처리자가 아니어도 가능한 보조 기능인가, 아니면 역할 없이는 핵심 흐름이 막히는가.

2. 역할 가용성: 목표 기기에서 isRoleAvailable()로 해당 역할을 실제 제공하는가. 시스템 업데이트에 따라 역할 목록이 바뀔 수 있다는 점을 전제로 한다.

3. 앱 적격성: manifest의 구성요소와 역할별 조건을 충족하는가. 버튼 노출 전에 개발·QA 기준으로 분리해 확인한다.

4. 사용자 선택 결과: createRequestRoleIntent()가 연 시스템 화면에서 사용자가 승인했는가, 취소했는가. 요청 화면을 열었다는 사실을 승인으로 세지 않는다.

5. 지속·회수 뒤 흐름: 앱이 현재 역할을 계속 보유하는가. 역할을 잃을 때 연결 권한도 회수될 수 있으므로, 기능 축소와 안내를 별도 상태로 둔다.

이 구분은 분석 이벤트에도 그대로 적용할 수 있습니다. role_request_started, role_request_result, role_held_after_resume, role_lost_fallback_shown처럼 관찰 사실을 나누면, 단순 버튼 클릭을 ‘기본 앱 전환 성공’으로 잘못 읽는 일을 줄일 수 있습니다. 사용자 식별자나 통화·메시지 내용처럼 불필요한 개인정보를 이 기록에 넣을 이유는 없습니다.

요청 전에는 필요성과 가용성을 먼저 확인합니다

Android의 일반 권한 안내도 앱이 정말 권한을 필요한지 먼저 평가하고, 사용자가 그 기능을 쓰려는 맥락에서 요청하라고 권합니다. 기본 역할도 같은 순서가 유용합니다. 온보딩 첫 화면에서 기본 앱 전환을 넓게 요구하기보다, 사용자가 실제로 전화·메시지·브라우저 처리와 같은 핵심 기능을 시작하려 할 때 이유와 대안을 보여주는 방식입니다.

RoleManager의 isRoleAvailable()는 요청하려는 역할이 해당 시스템에서 이용 가능한지 확인하는 API입니다. 가용성이 거짓이면 시스템 역할 요청 버튼을 보여 주기보다, 앱이 제공할 수 있는 보조 흐름을 안내해야 합니다. 가용성은 앱 설치 여부나 사용자의 선택 결과가 아닙니다.

기본 역할과 개별 권한 요청을 혼동하지 않는 것도 중요합니다. Android 문서는 통화 기록이나 SMS 권한처럼 민감한 정보를 다루는 일부 앱에서, Play 배포 시 관련 런타임 권한을 요청하기 전에 사용자가 핵심 시스템 기능의 기본 처리자로 설정하도록 요청해야 하는 경우가 있음을 안내합니다. 이는 ‘모든 권한은 기본 앱 전환으로 해결된다’는 뜻이 아닙니다. 어떤 역할과 어떤 권한이 제품에 필요한지는 별도 요구사항으로 확인해야 합니다.

이미 사용자가 선택한 기능의 진입·결과·복귀 상태를 다듬는 중이라면 앱 MVP Activity Result API: 등록·실행·복원을 나누는 5가지 기준도 함께 참고하세요. 여기서 말하는 결과는 시스템 역할 요청의 승인·취소이며, 앱의 업무 완료나 고객 가치 달성과는 다릅니다.

우리 앱 MVP의 기본 역할 필요성과 대체 흐름 점검하기

시스템 승인 화면은 앱이 통제하는 UI가 아닙니다

createRequestRoleIntent()는 사용자가 앱에 역할을 부여하도록 안내하는 Intent를 만듭니다. 역할이 승인되면 결과는 RESULT_OK, 승인되지 않으면 RESULT_CANCELED로 돌아올 수 있습니다. 따라서 앱은 ‘요청을 보냈다’, ‘결과가 승인이다’, ‘복귀 뒤 실제로 역할을 보유한다’를 나눠 다뤄야 합니다.

시스템 대화상자의 문구·배치·표시는 OS와 기기에 따라 달라질 수 있으므로, 앱이 이를 자체 화면처럼 설명하거나 자동 승인을 약속하면 안 됩니다. 앱이 할 수 있는 일은 요청 전에 왜 필요한지를 짧고 구체적으로 알리고, 취소했을 때도 현재 가능한 일을 제시하는 것입니다. Android 권한 안내도 거부·회수 시 기능을 우아하게 축소하고, 교육 UI에는 취소 선택지를 두라고 권합니다.

역할을 잃는 상황까지 QA 시나리오에 넣습니다

역할 보유 상태는 설치 시점에 고정되지 않습니다. 사용자가 설정에서 다른 앱을 선택하거나, 시스템·앱 상태가 바뀌면 앱은 역할을 잃을 수 있습니다. RoleManager 문서는 역할을 잃으면 역할별 권한도 회수될 수 있다고 설명합니다. 따라서 이전 세션의 성공값만 저장해 두고 이후에도 권한이 있다고 가정하면 위험합니다.

• 역할이 사용 가능한 기기와 사용할 수 없는 기기에서 각각 어떤 화면이 보이는가

• 요청을 열기 전 앱이 적격성을 어떻게 확인하는가

• 사용자가 승인·취소했을 때 각각 어떤 결과·안내가 남는가

• 앱 복귀 뒤 isRoleHeld() 기준으로 보유 상태를 다시 확인하는가

• 설정에서 다른 앱을 선택한 뒤 권한·기능·안내가 안전하게 바뀌는가

이 검수는 ‘기본 앱이 됐다’라는 하나의 체크보다 훨씬 유용합니다. 기기·OS·역할 이름, 요청 전 상태, 시스템 결과, 복귀 뒤 보유 여부, 실제 제공한 대체 기능을 남기면 다음 수정의 원인을 추적할 수 있습니다.

자주 묻는 질문

기본 앱 역할을 요청하면 항상 승인되나요?

아닙니다. createRequestRoleIntent()는 사용자의 부여 선택을 요청하는 시스템 Intent이며, 사용자가 승인하지 않으면 RESULT_CANCELED가 반환될 수 있습니다. 앱은 승인 결과와 복귀 뒤의 실제 역할 보유 상태를 따로 확인해야 합니다.

관련 기능이 있으면 역할을 요청할 수 있나요?

단정할 수 없습니다. Android 문서는 역할에 맞으려면 manifest 구성요소 등을 포함한 요구사항을 충족해야 한다고 안내합니다. 역할별 요건과 스토어 요구사항은 별도로 확인하세요.

역할이 없는 기기에서는 어떻게 해야 하나요?

역할 가용성을 먼저 확인하고, 사용할 수 없다면 요청 UI를 강제로 열지 않는 편이 안전합니다. 핵심 기능이 가능한지와 사용 가능한 대체 흐름을 분리해 안내하세요.

사용자가 나중에 다른 기본 앱을 선택하면요?

역할 보유 여부를 다시 확인해야 합니다. 역할을 잃으면 역할별 권한도 회수될 수 있으므로, 이전 상태를 가정하지 말고 기능·권한·안내를 함께 점검해야 합니다.

결론: 역할 요청·승인·보유·회수는 서로 다른 제품 상태입니다

Android 기본 앱 역할은 시스템 권한을 넓게 얻기 위한 일반적인 우회 수단이 아니라, 특정 시스템 기능을 책임지는 앱의 선택입니다. 기능 목적, 역할 가용성, 앱 적격성, 사용자의 승인 결과, 이후 보유·회수 상태를 분리하면 불필요한 요청을 줄이고 실제 출시 QA의 범위를 명확하게 만들 수 있습니다.

MVP 출시 전 권한·기본 역할·대체 흐름을 함께 정리하기