이노베이팅 컨설팅 신청하기 (클릭)
logo
|
Blog

    앱 MVP Android 패키지 가시성: queries·설치 확인·배포 검토를 나누는 5가지 기준

    Android 앱 MVP에서 다른 앱 가시성을 package·intent·provider, QUERY_ALL_PACKAGES, 설치·미설치 QA와 배포 검토로 나누는 기준입니다.
    Sep 21, 2026
    앱 MVP Android 패키지 가시성: queries·설치 확인·배포 검토를 나누는 5가지 기준

    앱 MVP Android 패키지 가시성: queries·설치 확인·배포 검토를 나누는 5가지 기준

    앱에서 다른 앱과 연동하려 할 때 “설치돼 있는지 확인하자”는 요구는 단순해 보입니다. 하지만 Android 11 이상을 대상으로 하면 다른 앱의 설치 정보는 기본적으로 필터링됩니다. 그래서 기능 화면에서 원하는 결과가 안 나온다고 바로 넓은 권한으로 대응하기보다, 실제로 필요한 상대 앱과 동작을 먼저 좁혀야 합니다.

    이 글은 Android MVP에서 다른 앱을 열거나, 특정 기능을 처리할 수 있는 앱이 있는지 확인하려는 팀을 위한 범위 결정 문서입니다. 특정 앱의 정책 준수나 Google Play 심사 결과를 보장하지 않습니다.

    1. 먼저 묻기: ‘설치 목록’이 필요한가, ‘이 동작을 처리할 앱’이 필요한가

    Android 공식 문서는 Android 11(API 30) 이상을 대상으로 하는 앱이 기기에 설치된 다른 앱의 정보를 조회할 때 그 정보가 기본적으로 필터링된다고 설명합니다. 이 제한은 앱이 현재 사용 사례에 필요하지 않은 설치 앱 정보를 얻지 않게 하기 위한 장치입니다.

    따라서 요구사항을 “설치 앱을 모두 확인한다”로 쓰기 전에 실제 사용자 행동을 한 문장으로 정리하세요. 예를 들어 특정 파트너 앱으로 화면을 넘기는 기능인지, 공유 인텐트를 처리할 수 있는 앱이 있는지, 또는 정해진 콘텐츠 제공자에 연결해야 하는지에 따라 필요한 가시성 범위가 다릅니다. 설치 목록을 받는 것과 단일 행동의 처리 가능 여부를 묶어 두면, 구현과 공개 설명이 모두 과해질 수 있습니다.

    제품 질문

    먼저 남길 결정

    QA에서 볼 결과

    특정 제휴 앱을 열 수 있는가

    대상 패키지와 미설치 때 대안

    설치·미설치 각각의 화면

    공유 기능을 제공할 앱이 있는가

    필요한 intent signature

    처리 앱 선택 화면 또는 안내

    콘텐츠 제공자와 연결하는가

    provider authority와 목적

    연결 성공·권한 거부 결과

    &lt;queries&gt;는 앱이 상호작용하려는 다른 앱을 패키지 이름, intent signature, provider authority로 표시할 수 있게 합니다. 이 세 방법 중 무엇을 쓸지는 제품 목적과 상대 앱의 형태에 따라 정하는 일이지, 하나를 만능 선언으로 쓰는 일이 아닙니다. Android의 <queries> 문서에서 선언 가능한 대상 형태를 직접 확인할 수 있습니다.

    2. 두 번째 기준: 최소 범위의 queries를 제품 요구와 한 쌍으로 기록하기

    패키지 가시성이 부족하면 queryIntentActivities(), getPackageInfo(), getInstalledApplications()처럼 다른 앱 정보를 돌려주는 메서드의 결과도 영향을 받을 수 있습니다. 하지만 이 사실은 관련 메서드가 보이면 모두 넓게 열어야 한다는 뜻이 아닙니다.

    MVP 기획서에는 선언 한 줄마다 다음 네 가지를 함께 적는 편이 좋습니다. 첫째, 사용자에게 보이는 기능은 무엇인지. 둘째, 어떤 패키지·intent·provider가 필요한지. 셋째, 그 대상이 없을 때 앱이 어떤 대안을 보여 줄지. 넷째, 다음 릴리스에서 이 선언을 유지할 근거가 남아 있는지입니다. 이렇게 하면 manifest 변경이 제품 요구에서 떨어져 나가지 않습니다.

    기능: 파트너 앱에서 본인인증 시작
    필요 대상: 특정 패키지 또는 해당 인증 intent
    미설치 때: 웹 또는 안내 화면으로 전환
    검증: Android 11 이상 기기에서 설치·미설치 결과 기록

    기능이 사라졌는데 선언만 남는 경우도 따로 확인하세요. 설치 앱 정보는 민감할 수 있으므로, 사용하지 않는 가시성은 출시 후보에서 다시 걷어내는 것이 바람직합니다. Android 패키지 가시성 가이드는 자동으로 보이는 패키지와 선택적으로 가시성을 늘리는 방법을 구분합니다.

    3. 세 번째 기준: QUERY_ALL_PACKAGES는 ‘조회 실패’의 해결책으로 넣지 않기

    &lt;queries&gt;만으로 충분하지 않은 드문 상황에는 QUERY_ALL_PACKAGES 권한이 있습니다. 다만 Google Play는 이 권한을 고위험 또는 민감한 권한으로 다루며, 기기에 설치된 앱 목록을 개인적·민감한 정보로 봅니다. Android API 30 이상 및 Android 11 이상에서 이 권한이 적용된다는 점도 별도 조건입니다.

    따라서 “테스트 기기에서 특정 앱이 안 보인다”는 현상만으로 이 권한을 추가하지 마세요. 먼저 필요한 것은 전체 목록인지, 특정 패키지인지, 특정 인텐트 처리자인지 다시 나눕니다. 전체 가시성이 앱의 사용자 대면 핵심 기능에 꼭 필요한 경우에도 Google Play 정책상 그 이유를 설명하고 Permissions Declaration Form을 제출해야 할 수 있습니다. 선언 없이 사용하거나 요구에 맞지 않으면 게시물에서 제거될 수 있다는 정책 안내도 있습니다.

    확인 순서

    질문

    다음 행동

    1

    한 개의 알려진 앱이면 되는가

    package 선언 검토

    2

    특정 작업 처리 앱이면 되는가

    intent signature 검토

    3

    콘텐츠 제공자 연결인가

    provider authority 검토

    4

    전체 설치 목록이 핵심 기능인가

    정책 적합성·선언 요건 검토

    넓은 권한은 앱이 현재 어떤 정보를 보고 있는지와 Play Console에 무엇을 설명해야 하는지까지 함께 바꿉니다. Google Play의 QUERY_ALL_PACKAGES 정책은 덜 침해적인 방법으로 핵심 기능을 충족할 수 없는지 설명할 수 있어야 한다고 안내합니다.

    4. 네 번째 기준: 실행 결과와 사용자 경험을 같은 테스트로 남기기

    manifest에 선언을 추가했다고 기능이 끝난 것은 아닙니다. 실제 기기에는 대상 앱이 없을 수 있고, 설치돼 있어도 해당 화면이나 서비스가 정상적으로 열리지 않을 수 있습니다. 반대로 개발 환경의 앱 구성만 보고 실제 배포 후보에서도 동일하게 보인다고 판단하는 것도 위험합니다.

    아래처럼 기능 경계와 결과를 한 줄씩 기록하세요. 이 기록은 테스트 실패를 숨기기 위한 표가 아니라, 어느 조건에서 앱의 다음 행동이 달라지는지 남기는 도구입니다.

    장면

    기대 결과

    실제 관찰

    다음 판단

    대상 앱 설치

    정해진 동작을 시작

    기기·빌드별 기록

    연결 흐름 유지 또는 수정

    대상 앱 미설치

    대체 경로 또는 안내

    버튼·복귀 결과 기록

    대안 문구·경로 수정

    처리 앱이 여러 개

    사용자가 선택하거나 정책에 따라 진행

    선택 화면 기록

    우선순위 정책 검토

    선언과 기능이 불일치

    불필요한 조회가 없음

    manifest·코드 재검토

    선언 제거 또는 요구 재정의

    다른 앱으로 화면을 넘길 때의 링크·복귀 흐름은 이미 다룬 Android App Links 도메인 검증 기준과 함께 볼 수 있습니다. 이 글의 초점은 링크 자체가 아니라, 앱이 다른 설치 앱을 발견할 수 있는 범위를 어떻게 좁혀 기록할지에 있습니다.

    패키지 가시성 요구를 제품 언어와 테스트 항목으로 바꾸는 과정이 필요하다면, 유인어스는 사용자 흐름과 출시 제약을 기준으로 MVP 범위를 함께 정리할 수 있습니다. MVP 범위 상담하기.

    5. 다섯 번째 기준: 출시 전에는 코드·manifest·Play 설명을 한 번에 대조하기

    마지막 점검은 ‘권한이 빌드에 있다’가 아니라 ‘왜 이 가시성이 필요한지 설명할 수 있다’여야 합니다. 코드에서 실제로 호출하는 다른 앱 조회, merged manifest에 남은 &lt;queries&gt; 또는 권한, 사용자에게 보이는 기능, 미설치 시 대안, 배포 채널의 정책 설명이 서로 맞는지 확인하세요.

    특히 기능을 접거나 연동 대상을 바꾼 뒤에는 과거 선언이 릴리스 후보에 남지 않았는지 재검토해야 합니다. Google Play의 정책은 권한 사용 방식이 달라지면 정보를 최신 상태로 갱신하라고 안내합니다. 다만 개별 앱의 적용 여부는 실제 기능, 배포 국가, 최신 Play Console 요구사항에 따라 달라질 수 있으므로 제출 직전에 공식 정책과 콘솔 표시를 다시 확인해야 합니다.

    출시 전 체크리스트

    • 사용자 기능을 ‘전체 설치 목록’이 아닌 실제 행동으로 썼는가

    • package·intent·provider 중 가장 좁은 대상 방식을 선택했는가

    • 대상 앱이 없거나 여러 개일 때의 사용자 안내를 정의했는가

    • Android 11 이상 기기와 실제 배포 후보에서 결과를 기록했는가

    • QUERY_ALL_PACKAGES가 있다면 핵심 기능·대안·정책 설명을 별도 검토했는가

    • 코드, merged manifest, Play Console 설명이 같은 범위를 말하는가

    패키지 가시성은 다른 앱 연동을 가능하게 하는 선언입니다. 앱이 어떤 설치 정보를 왜 알아야 하는지까지 대신 결정해 주지는 않습니다.

    자주 묻는 질문

    &lt;queries&gt;를 넣으면 모든 설치 앱을 볼 수 있나요?

    아닙니다. &lt;queries&gt;는 앱이 상호작용하려는 다른 앱을 package, intent signature, provider authority 기준으로 선언하는 요소입니다. 전체 설치 앱 목록이 필요한 것과는 다른 범위이며, 자동으로 보이는 패키지도 별도로 존재합니다.

    특정 앱이 테스트 기기에서 보이지 않으면 QUERY_ALL_PACKAGES를 넣어야 하나요?

    바로 그렇게 판단할 수는 없습니다. 먼저 특정 패키지나 필요한 intent로 기능을 충족할 수 있는지 확인하세요. Google Play는 더 좁은 방법으로 충족 가능한 작업을 위해 넓은 가시성을 사용하는 것을 허용하지 않는다고 안내합니다.

    Play Console에 추가 확인이 필요한 경우가 있나요?

    QUERY_ALL_PACKAGES를 Google Play에 게시하는 앱에서 사용하고 정책상 허용되는 경우, Permissions Declaration Form 제출이 요구될 수 있습니다. 실제 제출 요건은 최신 공식 정책과 콘솔의 안내를 확인해야 합니다.

    이 점검만으로 개인정보 또는 Play 심사가 완료되나요?

    아닙니다. 이 글은 다른 설치 앱 가시성의 제품 범위와 테스트 기록을 정리하는 기준입니다. 실제 앱의 데이터 처리, 권한, 사용자 고지, 배포 심사는 기능과 최신 정책에 맞춰 별도로 검토해야 합니다.

    다른 앱 연동을 MVP에 어디까지 넣을지 결정하기 어렵다면 현재 기능과 배포 조건을 기준으로 검토 범위를 정리해 보세요. 유인어스에 MVP 범위 문의하기.

    Share article
    유인어스 정책자금·혁신기업 전환 컨설팅

    유인어스는 주식회사 넥스트빌더가 운영하는 정책자금 및 혁신기업 전환 컨설팅 브랜드입니다. 기업의 업종·업력·재무상태를 진단해 적합한 정책금융기관과 준비 절차를 안내합니다.

    유인어스 홈 컨설팅 신청 RSS