Android 6.0 이상에서는 Android 애플리케이션 권한 모델이 사용자를 위한 좀 더 이해하기 쉽고 유용하고 안전한 권한을 생성하도록 설계되어 있습니다. 이 모델에서는 위험한 권한(영향을 받는 권한 참고)을 요구하는 Android 애플리케이션이 설치 시간 권한 모델에서 런타임 권한 모델로 이전되었습니다.
- 설치 시간 권한
(Android 5.1 이하) 사용자가 앱을 설치하거나 업데이트할 때 위험한 권한을 앱에 부여합니다. 기기 제조업체와 이동통신사는 사용자에게 알리지 않고 사전 부여된 권한으로 앱을 사전 설치할 수 있습니다.
- 런타임 권한
(Android 6.0 - 9) 사용자가 앱을 실행할 때 위험한 권한을 앱에 부여합니다. 권한 요청 시점(앱이 실행될 때 또는 사용자가 특정 기능에 액세스할 때 등)은 애플리케이션에 따라 다르지만 사용자가 특정 권한 그룹에 대한 애플리케이션 액세스를 부여/거부합니다. OEM/이동통신사는 앱을 사전 설치할 수 있지만, 예외 프로세스를 거치지 않는 이상 권한을 미리 부여할 수는 없습니다. (예외 생성 참고)
(Android 10) 사용자가 개선된 투명성을 확인하고 어떤 앱이 활동 감지(AR) 런타임 권한을 보유하도록 할지 제어할 수 있습니다. 사용자에게는 항상 허용할지, 사용 중에만 허용할지 아니면 권한을 거부할지 묻는 런타임 권한 대화상자가 표시됩니다. OS가 Android 10으로 업그레이드되면 앱에 주어진 권한이 유지되지만 사용자가 설정으로 이동하여 권한을 변경할 수 있습니다.
런타임 권한은 앱이 사용자의 동의 없이 비공개 데이터에 액세스하지 못하도록 하지만 애플리케이션이 찾고 있거나 부여받은 권한 유형에 대한 추가적인 컨텍스트와 가시성을 앱에 제공합니다. 런타임 모델은 애플리케이션에 요청된 권한이 필요한 이유를 사용자가 이해하도록 돕고 사용자가 권한 부여 또는 거부에 대한 더 나은 결정을 내릴 수 있게 향상된 투명성을 제공하도록 개발자를 독려합니다.
영향을 받는 권한
Android 6.0 이상에서는 런타임 권한 모델 사용을 위한 위험한 권한을 요구합니다.
위험한 권한은 요청이 발생한 애플리케이션에서 비공개 사용자 데이터에 액세스하거나 기기를 제어할 수 있게 해주는 위험성이 비교적 높은 권한입니다(예: READ_CALENDAR). 이러한 경우 사용자에게 부정적인 영향을 미칠 수 있습니다. 위험한 권한 목록을 보려면 다음 명령어를 실행합니다.
adb shell pm list permissions -g -d
Android 6.0 이상에서는 일반 권한의 동작을 변경하지 않습니다. 이는 일반, 시스템 및 서명 권한을 포함하여 모두 위험하지 않은 권한입니다. 일반 권한은 요청하는 애플리케이션이 다른 애플리케이션, 시스템 또는 사용자에 최소한의 위험을 미치는 격리된 애플리케이션 수준 기능에 액세스할 수 있게 해주는 위험성이 비교적 낮은 권한입니다(예: SET_WALLPAPER). Android 5.1 이하 버전의 경우처럼 시스템은 설치 시 요청하는 애플리케이션에 일반 권한을 자동으로 부여하며, 사용자의 승인을 요청하지 않습니다. 권한에 관한 자세한 내용은 <permission> 요소 문서를 참고하세요.
Android 10의 엄격한 제한 및 유연한 제한
권한은 위험할 수 있을 뿐만 아니라 엄격하게 또는 유연하게 제한될 수도 있습니다. 어떤 경우이든 제한된 권한도 허용 목록에 있어야 합니다. 허용 목록에 추가되지 않은 엄격한 제한은 허용 목록에 추가되지 않은 유연한 제한과 다르게 작동합니다.
- (엄격한 제한) 앱에 허용 목록에 없는 권한을 부여할 수 없습니다.
- (유연한 제한) 허용 목록에 없는 앱은 앱이 요청한 구체적인 권한에 따라 동작합니다. 동작은 요청된 권한과 관련된 공개 문서에 설명되어 있습니다.
앱을 설치할 때 Google Play 스토어와 같은 설치 프로그램에서 앱의 제한된 권한을 허용 목록에 포함하지 않도록 선택할 수 있습니다. 권한은 플랫폼에서 제한하며 앱이 플랫폼 정책에 따라 특정 기준을 충족하는 경우에만 부여될 수 있습니다. 엄격하게 제한된 권한 유형의 예로는 SMS 및 통화 기록 권한 등이 있습니다.
허용 목록에 추가하는 작업은 설치 중 그리고 다음과 같은 경우에 발생합니다.
- 앱이 Android 9에서 10으로 업그레이드되는 도중에 이미 설치되는 경우
- 권한이 미리 부여되었거나 앱이 사전 설치된 경우
- 권한을 허용 목록에 추가하도록 이미 정의된 역할에 권한이 필요한 경우
- Google Play 스토어와 같은 설치 프로그램이 권한을 허용 목록에 추가된 것으로 표시한 경우
사용자는 권한을 수동으로 허용 목록에 추가할 수 없습니다.
요구사항
런타임 권한 모델은 사전 설치된 앱과 설정 프로세스의 일부로 기기에 제공된 앱을 포함한 모든 애플리케이션에 적용됩니다. 애플리케이션 소프트웨어의 요구사항은 다음과 같습니다.
- 런타임 권한 모델이 Android 6.0 이상을 실행하는 모든 기기에 걸쳐 일관적이야 합니다. 이는 Android 호환성 테스트 모음(CTS) 테스트에 의해 적용됩니다.
- 앱이 런타임 시 애플리케이션에 권한을 부여하도록 사용자에게 요청해야 합니다. 자세한 내용은 애플리케이션 업데이트를 참고하세요. 예상되는 기기 작업에 필수적인 기기의 기본 기능을 제공하는 기본 애플리케이션과 핸들러에 제한된 예외가 부여될 수 있습니다.
예를 들어
ACTION_CALL을 처리하는 기기의 기본 다이얼러 앱에는 전화 액세스 권한이 있을 수 있습니다. 자세한 내용은 예외 생성을 참고하세요. - 위험한 권한을 가진 미리 로드된 앱은 API 수준 23을 타겟팅하고 런타임 권한 모델을 유지해야 합니다. 즉, 앱 설치 중의 UI 흐름이 PermissionController의 AOSP 구현에서 벗어나면 안 되며 사용자는 사전 설치된 앱의 위험한 권한을 취소할 수 있어야 합니다.
- 헤드리스 애플리케이션은 활동을 사용하여 권한을 요청하거나 필요한 권한을 보유한 다른 애플리케이션과 UID를 공유해야 합니다. 자세한 내용은 헤드리스 애플리케이션을 참고하세요.
권한 이전
Android 5.x의 애플리케이션에 부여된 권한은 Android 6.0 이상으로 업데이트한 후에도 유지되지만 사용자가 언제든지 이러한 권한을 취소할 수 있습니다.
Android 9에서 10으로 업데이트하면 엄격하게 제한된 권한은 모두 허용 목록에 추가됩니다. 포그라운드/백그라운드 분할 권한 구현에 관한 자세한 내용은 Android 10 개인 정보 보호 변경을 참고하세요. 백그라운드 위치 액세스 요청부터 살펴보는 것이 좋습니다.
통합
Android 6.0 이상의 애플리케이션 런타임 권한 모델을 통합할 때는 사전 설치된 애플리케이션이 새 모델과 호환되도록 업데이트해야 합니다. 핵심 기능의 기본 핸들러/제공업체인 앱의 예외를 정의하고 맞춤 권한을 정의하며 PermissionController 앱에 사용되는 테마를 맞춤설정할 수도 있습니다.
애플리케이션 업데이트
시스템 이미지의 애플리케이션과 사전 설치된 애플리케이션에는 자동으로 권한이 사전 부여되지 않습니다. 따라서 사전 설치된 앱 개발자(OEM, 이동통신사 및 서드 파티)와의 협의하에 개발자 가이드라인을 활용하여 앱에 필요한 수정사항을 적용하는 것이 좋습니다. 구체적으로는 사용자가 권한을 취소할 때 사전 설치된 애플리케이션에 비정상 종료 및 기타 문제가 발생하지 않도록 수정해야 합니다.
미리 로드된 애플리케이션
Android 9 이하에서는 위험한 권한을 사용하는 미리 로드된 앱이 API 수준 23 이상을 타겟팅하고 Android 6.0 이상의 AOSP 권한 모델을 유지해야 합니다. 예를 들어 앱 설치 중의 UI 흐름이 PermissionController의 AOSP 구현에서 벗어나면 안 됩니다. 사용자는 사전 설치된 앱의 위험한 권한을 취소할 수도 있습니다.
Android 6.0부터 9까지는 일부 권한이 설치 흐름 도중에 부여됩니다. 하지만 10부터는 Package
Installer 앱에 의해 실행되는 설치 흐름이 Permission Controller 앱의 권한 부여와는 별도로 기능합니다.
헤드리스 애플리케이션
활동만 권한을 요청할 수 있으며, 서비스는 권한을 직접적으로 요청할 수 없습니다.
- Android 5.1 이하에서는 헤드리스 애플리케이션이 권한을 요청할 수 있습니다(설치 시 또는 활동의 사용 없이 사전 설치된 경우).
- Android 6.0 이상에서는 헤드리스 애플리케이션이 다음 방법 중 하나를 사용하여 권한을 요청해야 합니다.
- 활동을 추가하여 권한을 요청합니다 - 권장
- 필요한 권한을 보유한 다른 애플리케이션과 UID를 공유합니다. 이 방법은 플랫폼에서 여러 APK를 단일 애플리케이션으로 처리해야 하는 경우에만 사용하세요.
목표는 갑자기 표시되는 권한 요청으로 사용자에게 혼란을 주지 않는 것입니다.
PackageInstaller UI 맞춤설정
원하는 경우 PackageInstaller에서 사용하는 기본 기기 테마(Theme.DeviceDefault.Settings 및 Theme.DeviceDefault.Light.Dialog.NoActionBar)를 업데이트하여 권한 UI 테마를 맞춤설정할 수 있습니다. 하지만 앱 개발자에게는 일관성이 중요합니다. 따라서 권한 UI가 표시될 때 배치, 위치 및 규칙을 맞춤설정할 수 없습니다.
추가 언어를 위한 문자열을 포함하려면 문자열을 AOSP에 제공합니다.
예외 생성
PackageManager에서 DefaultPermissionGrantPolicy.java 클래스를 사용하면 핵심 OS 기능의 기본 핸들러 또는 제공업체인 애플리케이션에 권한을 사전 부여할 수 있습니다. 예:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
맞춤 권한 정의
Android 5.x 및 이전 버전과 마찬가지로 맞춤 권한 및 그룹을 일반 또는 위험으로 정의하고 OEM/이동통신사별 권한을 기존 권한 그룹에 추가할 수 있습니다.
Android 6.0 이상에서는 위험한 권한을 새로 추가할 경우 이러한 권한이 다른 위험한 권한과 같은 방식(런타임 도중에 요청되고 사용자가 취소할 수 있음)으로 처리되어야 합니다. 특히 다음에 주의해야 합니다.
- 현재 그룹에 새 권한을 추가할 수 있지만 위험한 권한과 위험한 권한 그룹의 AOSP 매핑은 수정할 수 없습니다. 즉, 그룹에서 권한을 삭제하여 다른 그룹에 할당할 수 없습니다.
- 기기에 설치된 애플리케이션에 새 권한 그룹을 추가할 수는 있지만 새 권한 그룹을 플랫폼 매니페스트에 추가할 수는 없습니다.
권한 테스트
Android에는 개별 권한이 올바른 그룹에 매핑되었는지 확인하는 호환성 테스트 모음(CTS)이 포함되어 있습니다. 이러한 테스트를 통과하는 것이 Android 6.0 이상의 CTS 호환성 요구사항입니다.
권한 취소
Android 13 이상에서는 Context.revokeSelfPermissionsOnKill()을 사용하여 부여된 자체 런타임 권한을 취소할 수 있습니다.
취소는 비동기식으로 이루어지며 사용자를 방해하지 않으면서 안전하게 실행할 수 있을 때 트리거됩니다. 취소가 트리거되면 호출 UID에서 실행되는 모든 프로세스가 종료됩니다.
설정 UI는 그룹 단위로 권한을 처리하기 때문에 권한 하나를 취소하는 경우 설정 UI에 반영되지 않을 수 있다는 점을 알아야 합니다. 일반적으로 권한 그룹의 권한이 하나 이상 부여되면 해당 권한 그룹에 권한이 부여된 것으로 표시됩니다. 사용자가 설정에서 취소를 확인할 수 있게 하는 것이 중요하다면 권한 그룹의 모든 권한을 취소해야 합니다. 특정 그룹에 속한 권한을 알아보려면 PackageManager.getGroupOfPlatformPermission과 PackageManager.getPlatformPermissionsForGroup을 사용하면 됩니다.
시스템이 요청된 권한을 취소할 때 해당하는 포그라운드 권한 중 부여된 것이 없으면 상응하는 백그라운드 권한도 취소됩니다.
프로세스가 계속 포그라운드에서 이루어지는 한 취소가 트리거되지 않지만, 현재 UID에서 실행 중인 모든 프로세스를 직접 종료하여(예: System.exit() 사용) 곧바로 트리거할 수도 있습니다.
하지만 시스템에서 취소 작업의 트리거 시점을 결정하도록 하는 것이 좋습니다.
권한 취소가 적용된 후 다시 요청할 수 있으며 사용자에게 요청을 승인하거나 거부하라는 메시지가 표시됩니다. 사용자가 이전에 거부한 권한은 요청할 수 없습니다. 현재 보유하고 있지만 더 이상 필요하지 않은 권한은 취소하는 것이 좋지만, 취소가 적용될 때까지 사용자에게 취소에 대해 알리지 않아야 합니다.