키워드: wear, permissions, collection_guideslandingwear image_path: images/training/wear/multiple_permissions.png
Wear OS에서 권한을 요청하는 것은 모바일 앱에서 권한을 요청하는 것과 비슷하지만 몇 가지 추가 사용 사례가 있습니다. 이 문서에서는 Android 권한 작동 방식을 개발자가 이해하고 있다고 가정합니다. 잘 모른다면 Android에서 권한이 작동하는 방식을 확인하세요.
모바일 앱에서와 마찬가지로 사용자는 특정 기능에 액세스할 수 있도록 Wear 앱에 권한을 부여해야 합니다. Wear 앱에서 권한을 요청하지 않고 의미 있는 기능을 제공합니다.
권한 시나리오
Wear OS에서 위험한 권한을 요청할 때 발생할 수 있는 몇 가지 시나리오는 다음과 같습니다.
Wear 앱이 웨어러블 기기에서 실행 중인 앱의 권한을 요청합니다.
Wear 앱이 전화에서 실행 중인 앱의 권한을 요청합니다.
전화 앱이 웨어러블 기기에서 실행 중인 앱의 권한을 요청합니다.
전화 앱이 웨어러블 기기가 연결되어 있는 동안에만 사용할 수 있는 권한을 여러 개 요청합니다.
작동하는 앱에서 이러한 시나리오를 모두 확인하려면 GitHub의 ExerciseSampleCompose 샘플을 참고하세요.
다음 섹션에서는 이러한 각 시나리오를 설명합니다. 권한 요청에 관한 자세한 내용은 권한-요청 패턴 섹션을 참고하세요.
Wear 앱이 웨어러블 권한을 요청
Wear 앱이 웨어러블 기기에서 실행 중인 앱의 권한을 요청하면 시스템에서 사용자에게 이 권한을 요청하는 대화상자를 표시합니다. 앱에서는 특정 작업을 실행하는 데 권한이 필요한 이유가 사용자에게 명확할 때만 권한을 요청합니다.
권한 원칙을 검토하여 사용자에게 최상의 환경을 제공하는지 확인합니다. 또한 shouldShowRequestPermissionRationale()을 확인하여 필요하다면 추가 정보를 제공합니다.
앱 또는 시계 화면에서 동시에 두 개 이상의 권한이 필요한 경우 권한 요청이 차례로 표시됩니다.
Wear 앱이 전화 권한을 요청
Wear 앱이 전화 권한을 요청하면(예: 웨어러블 앱이 모바일 버전의 앱에 있는 사진 또는 기타 민감한 정보에 액세스하려고 함) Wear 앱은 권한을 수락하도록 사용자를 전화로 보내야 합니다. 여기서 전화 앱은 활동을 사용하여 사용자에게 추가 정보를 제공할 수 있습니다. 활동에서 두 가지 버튼을 포함합니다. 하나는 권한을 부여하는 버튼이고 하나는 권한을 거부하는 버튼입니다.
전화 앱이 웨어러블 권한을 요청
사용자가 전화 앱을 사용 중이고 앱에 웨어러블 권한이 필요한 경우(예: 전화가 연결 해제될 경우 음악 미리 로드) 전화 앱은 권한을 수락하도록 사용자를 웨어러블 기기로 보냅니다. 웨어러블 버전 앱은 requestPermissions() 메서드를 사용하여 시스템 권한 대화상자를 트리거합니다.
전화 앱에서 한 번에 여러 권한을 요청
Android 12(API 수준 31) 이상 버전에서 실행되는 파트너 앱은 시계에 연결할 때 호환 기기 프로필을 사용할 수 있습니다. 프로필을 사용하면 기기 유형별 권한 세트 부여를 한 단계로 묶어 등록 프로세스를 간소화할 수 있습니다.
번들 권한은 기기가 연결되면 호환 앱에 부여되고 기기가 연결된 동안에만 지속됩니다. 앱을 삭제하거나 연결을 제거하면 권한이 삭제됩니다. 자세한 내용은 AssociationRequest.Builder.setDeviceProfile()을 참고하세요.
권한-요청 패턴
사용자에게 권한을 요청하기 위한 다양한 패턴이 있습니다. 우선순위에 따른 권한 요청 패턴은 다음과 같습니다.
컨텍스트에 따라 요청: 권한이 특정 기능에는 명백히 필요하지만 전체적으로 앱이 실행되는 데는 필요하지 않은 경우
컨텍스트에 따라 교육 제공: 권한을 요청하는 이유가 명확하지 않고 앱이 전체적으로 실행되는 데 권한이 필요하지 않은 경우
이러한 패턴은 다음 섹션에서 설명합니다.
컨텍스트에 따라 요청
특정 작업을 실행하는 데 권한이 필요한 이유가 사용자에게 명확할 때 권한을 요청합니다. 사용하려는 기능과 권한 사이의 관계를 사용자가 이해할 경우 권한을 부여할 가능성이 더 높습니다.
예를 들어 앱에서는 관심 있는 주변 장소를 표시하기 위해 사용자의 위치를 요구할 수 있습니다. 사용자가 탭하여 주변 장소를 검색하면 앱에서는 즉시 위치 정보 액세스 권한을 요청할 수 있습니다. 주변 장소 검색과 위치 정보 액세스 권한의 필요성 사이에는 분명한 관계가 있기 때문입니다. 이 관계가 명확하다면 앱에서 추가 교육 화면을 표시할 필요가 없습니다.
컨텍스트에 따라 교육 제공
그림 6은 컨텍스트에서 제공하는 교육의 예를 나타냅니다. 앱은 타이머를 시작하는 데 권한이 필요하지 않지만 인라인 교육 큐는 활동의 일부(위치 감지)가 잠겨 있다고 표시합니다. 사용자가 이 큐를 탭하면 권한 요청 화면이 표시되어 위치 감지를 잠금 해제할 수 있습니다.
shouldShowRequestPermissionRationale() 메서드를 사용하여 앱에서 추가 정보를 제공할지 결정하도록 지원하세요. 자세한 내용은 앱 권한 요청을 참고하세요. 또는 GitHub의 스피커 샘플 애플리케이션이 정보 표시를 처리하는 방식을 살펴볼 수 있습니다.
거부 처리
의도된 활동에 꼭 필요하지는 않은 권한 요청을 사용자가 거부하는 경우 활동을 계속하지 못하도록 차단하면 안 됩니다. 거부된 권한으로 인해 활동의 특정 부분이 사용 중지되는 경우 실행 가능한 시각적 피드백을 제공하세요.
그림 7에서는 사용자가 사용 권한을 부여하지 않아 기능이 잠겨 있음을 나타내기 위해 사용된 자물쇠 아이콘을 보여줍니다.
이전에 거부된 웨어러블 권한 대화상자가 두 번째로 표시되면 거부, 다시 표시 안함 옵션이 포함됩니다. 사용자가 이 옵션을 선택하는 경우 나중에 웨어러블의 설정 앱을 사용해야만 권한을 부여할 수 있습니다.
권한 거부 처리 방법을 자세히 알아보세요.
서비스 권한
활동만 requestPermissions() 메서드를 호출할 수 있습니다. 따라서 사용자가 서비스(예: 시계 화면)를 사용하여 앱과 상호작용하는 경우 해당 서비스는 권한을 요청하기 전에 활동을 열어야 합니다. 이 활동에서 권한이 필요한 이유에 관한 추가 교육을 제공합니다.
일반적으로 시계 화면 권한은 요청하지 마세요. 대신 정보 표시를 구현하고 사용자가 정보 표시를 통해 표시할 데이터를 선택하도록 허용합니다.
설정
사용자는 언제든지 설정에서 Wear 앱의 권한을 변경할 수 있습니다. 사용자가 권한이 필요한 어떤 작업을 하려고 하면 먼저 checkSelfPermission() 메서드를 호출하여 앱에 작업을 실행할 권한이 있는지 확인합니다.
사용자가 이전에 권한을 부여했더라도 확인 작업을 실행하세요. 나중에 권한을 취소했을 수 있기 때문입니다.
추천 서비스
- 참고: JavaScript가 사용 중지되어 있으면 링크 텍스트가 표시됩니다.
- 런타임 권한 요청
- 블루투스 권한
- 백그라운드에서 통신