Wear OS에서 권한 요청

Android 6.0(API 레벨 23)에는 새로운 권한 모델이 도입되었습니다. 이로 인해 Wear OS by Google에 일부 변경사항이 적용되고, 모든 Android 제공 기기에 기타 변경사항이 적용됩니다.

다음의 관련 리소스를 참조하세요.

사용자는 호환 전화 앱이 있는 경우에도 Wear 앱에 권한을 부여해야 합니다. Android 6.0(API 레벨 23)부터 Wear 앱은 전화 앱에 부여된 권한을 받을 수 없습니다. 예를 들어 사용자가 위치 데이터 사용 권한을 전화 앱에 부여하더라도 이후 Wear 앱에 동일한 권한을 부여해야 합니다.

참고: 이 페이지는 전화 앱과 호환되는 시계 앱을 만들 수 있는 개발자를 대상으로 합니다. 하지만 전화 앱을 만들 필요는 없으며 시계 앱은 독립형 앱이 될 수 있습니다.

Wear 앱과 전화 앱 모두 Android 6.0(API 레벨 23) 권한 모델에서 앱에 필요할 수도 있는 모든 권한을 사용자가 미리 부여해야 한다는 요구사항을 제거하여 앱 설치와 업그레이드를 간소화합니다. 대신 실제로 필요할 때까지 앱에서 권한을 요청하지 않습니다.

참고: 앱에서 새로운 권한 모델을 사용하려면 uses-sdk-elementcompileSdkVersion 모두에 23 값을 지정해야 합니다.

이 문서의 나머지 부분에서는 Wear OS 앱을 개발할 때 Android 6.0(API 레벨 23) 권한 모델을 사용하는 방법을 설명합니다.

권한 시나리오

대체로 Wear OS에서 위험한 권한을 요청할 때 발생할 수 있는 네 가지 시나리오는 다음과 같습니다.

  • Wear 앱웨어러블 기기에서 실행 중인 앱의 권한을 요청
  • Wear 앱핸드셋에서 실행 중인 앱의 권한을 요청
  • 전화 앱웨어러블 기기에서 실행 중인 앱의 권한을 요청
  • 웨어러블 앱이 전화 앱과 다른 권한 모델을 사용

이 섹션의 나머지 부분에서는 이 시나리오에 대해 각각 설명합니다. 권한 요청에 관한 자세한 내용은 권한-요청 패턴을 참조하세요.

Wear 앱이 웨어러블 기기에서 실행 중인 앱의 권한을 요청

Wear 앱이 웨어러블 기기에서 실행 중인 앱의 권한을 요청하면 시스템에서 사용자에게 이 권한을 요청하는 대화상자를 표시합니다. 앱이나 서비스는 활동에서만 requestPermissions() 메서드를 호출할 수 있습니다. 사용자가 시계 모드 같은 서비스를 통해 앱과 상호작용하는 경우 서비스는 권한을 요청하기 전에 활동을 열어야 합니다.

앱에서는 특정 작업을 시행하는 데 권한이 필요한 이유가 명확한 경우 컨텍스트에 따라 권한을 요청합니다. 앱에 특정 권한이 필요한 이유가 명확하면 시작 화면에서 앱이 해당 권한을 요청할 수 있습니다. 필요성이 명확하지 않은 경우 권한을 요청하기 전에 추가 교육을 제공하도록 선택할 수 있습니다.

앱 또는 시계 모드에서 동시에 두 개 이상의 권한이 필요한 경우 권한 요청이 차례로 표시됩니다.

차례로 나타나는 여러 권한 요청 화면

그림 1. 연속적으로 표시되는 권한 요청 화면

참고: Android 6.0(API 레벨 23)부터는 Wear OS에서 캘린더, 연락처, 위치 데이터를 Wear 기기에 자동으로 동기화합니다. 결과적으로 이 시나리오는 Wear에서 이 데이터를 요청할 때 적용됩니다.

Wear 앱이 전화 권한을 요청

Wear 앱에서 전화 권한을 요청하는 경우 Wear 앱은 사용자를 전화로 보내 권한을 수락하도록 해야 합니다. 여기서 전화 앱은 활동을 통해 사용자에게 추가 교육을 제공할 수 있습니다. 활동에는 권한 부여 버튼과 권한 거부 버튼의 두 가지 버튼이 포함되어야 합니다.

권한을 부여하도록 Wear 앱이 사용자를 전화 앱으로 보냅니다.

그림 2. 권한을 부여하도록 사용자를 전화로 보냄

전화 앱이 웨어러블 권한을 요청

사용자가 전화 앱에 있고 이 앱에 웨어러블 권한이 필요한 경우 전화 앱은 사용자를 웨어러블로 보내 권한을 수락하도록 해야 합니다. 전화 앱은 웨어러블에서 requestPermissions() 메서드를 사용해 시스템 권한 대화상자를 트리거합니다.

권한을 부여하도록 전화 앱이 사용자를 웨어러블로 보냅니다.

그림 3. 권한을 부여하도록 사용자를 웨어러블로 보냄

웨어러블 및 전화 앱 간에 권한 모델 불일치

전화 앱이 Android 6.0(API 레벨 23) 모델을 사용하여 시작되지만 웨어러블 앱은 다른 모델을 사용하는 경우, 시스템에서는 Wear 앱을 다운로드하지만 설치하지는 않습니다. 사용자가 앱을 처음 시작할 때 시스템은 모든 대기 중인 권한을 부여하도록 사용자에게 요청합니다. 사용자가 권한을 부여하면 시스템이 앱을 설치합니다. 앱(예: 시계 모드)에 런처가 없는 경우 시스템에서 사용자에게 앱에 필요한 권한을 부여하도록 요청하는 스트림 알림을 표시합니다.

권한-요청 패턴

사용자에게 권한을 요청하기 위한 다양한 패턴이 있습니다. 우선순위에 따른 권한 요청 패턴은 다음과 같습니다.

  • 컨텍스트에 따라 요청: 특정 기능에 대한 권한의 필요성이 명확하지만 앱을 실행하는 데 필요한 권한은 아닌 경우
  • 컨텍스트에 따라 교육 제공: 권한을 요청하는 이유가 명확하지 않고 앱을 실행하는 데 필요한 권한은 아닌 경우
  • 미리 권한 요청: 권한의 필요성이 명확하고 앱이 실행하는 데 필요한 권한인 경우
  • 미리 교육 제공: 권한의 필요성이 명확하지 않고 앱을 실행하는 데 필요한 권한은 아닌 경우

컨텍스트에 따라 요청

특정 작업을 시행하는 데 권한이 필요한 이유가 명확한 경우 앱에서 권한을 요청해야 합니다. 사용자가 자신이 사용하려는 기능과 권한 사이의 관계를 이해할 경우 권한을 부여할 가능성이 더 높습니다.

예를 들어 앱에서 주변 관심 장소를 표시하기 위해 사용자 위치가 필요할 수 있습니다. 사용자가 주변 장소를 탭하여 검색하는 경우 주변 장소 검색과 위치 권한의 필요성 간의 관계가 명확하므로 앱에서 즉시 위치 정보 액세스 권한을 요청할 수 있습니다. 이 관계가 명확하다면 앱에서 추가 교육 화면을 표시할 필요가 없습니다.

필요성이 명확한 경우에 앱이 권한을 요청합니다.

그림 4. 컨텍스트에 따라 요청

컨텍스트에 따라 교육 제공

필요할 경우 권한을 요청하기 전에 추가 교육을 제공하도록 선택할 수도 있습니다. 다시 강조하자면, 특정 작업을 완료하기 위해 앱이 요청된 권한에 액세스해야 하는 이유가 명확하지 않은 경우 그 작업의 컨텍스트에 따라 교육을 제공해야 합니다.

그림 5는 컨텍스트에서 제공하는 교육의 예를 나타냅니다. 앱에서 타이머를 시작하는 데 권한이 필요하지 않지만 인라인 교육 큐는 활동(위치 감지) 일부가 잠겨 있다고 표시합니다. 사용자가 이 큐를 탭하면 위치 감지를 잠금 해제할 수 있도록 권한-요청 화면이 나타납니다.

shouldShowRequestPermissionRationale() 메서드를 사용하면 앱에서 정보를 더 제공할지 결정하는 데 도움이 됩니다. 자세한 내용은 런타임 시 권한 요청을 참조하세요.

권한에 대한 필요성이 제기되면 앱에서 권한이 필요한 이유를 설명합니다.

그림 5. 컨텍스트에 따라 교육 제공

미리 권한 요청

앱이 작동하는 데 명확하게 권한이 필요한 경우, 사용자가 앱을 실행할 때 권한을 요청할 수 있습니다. 예를 들어 지도 앱에서 기대되는 활동을 실행하려면 기기의 위치에 액세스할 권한이 명확히 필요합니다. 이 권한에는 추가 교육이 필요하지 않습니다.

앱을 실행하는 데 권한이 명확히 필요한 경우 실행 즉시 이 권한을 요청할 수 있습니다.

그림 6. 미리 권한 요청

미리 교육 제공

앱에 기본 기능을 위한 권한이 필요하지만 그 권한의 필요성이 명확하지 않은 경우도 있습니다. 이 경우 사용자가 처음으로 앱을 시작하거나 시계 모드를 설정할 때 앱 또는 시계 모드에서 사용자를 교육하도록 선택하고 권한을 요청할 수도 있습니다.

시작 시 권한을 요청할 때 앱에서 권한이 필요한 이유를 설명할 수 있습니다.

그림 7. 미리 교육 제공

거부 처리

의도된 활동에 꼭 필요하지는 않은 권한 요청을 사용자가 거부하는 경우 활동을 계속하지 못하도록 차단하면 안 됩니다. 거부된 권한으로 인해 활동의 특정 부분이 사용 중지되는 경우 실행 가능한 시각적 의견을 제공하세요. 그림 8에서는 사용자가 사용 권한을 부여하지 않아 해당 기능이 잠겼음을 나타내는 자물쇠 아이콘이 사용되었음을 보여줍니다.

사용자가 권한을 거부하면 연결된 기능과 함께 자물쇠 아이콘이 표시됩니다.

그림 8. 권한이 거부되어 기능이 잠겼음을 보여주는 자물쇠 아이콘

이전에 거부된 웨어러블 권한 대화상자가 두 번째로 표시되면 거부, 다시 표시 안함 옵션이 포함됩니다. 사용자가 이 옵션을 선택하는 경우 나중에 웨어러블의 설정 앱을 사용해야만 권한을 허용할 수 있습니다.

시스템에서 권한 요청 중지 옵션을 제공합니다.

그림 9. 권한-요청 화면을 더 이상 표시하지 않도록 제안

서비스 권한

위에서 언급한 것처럼 활동만 requestPermissions() 메서드를 호출할 수 있으므로, 사용자가 특정 서비스(예: 시계 모드)를 통해 앱과 상호작용하는 경우 이 서비스는 권한을 요청하기 전에 백그라운드 활동을 열어야 합니다. 이 활동은 추가 교육을 제공할 수도 있고, 시스템 대화상자를 표시하는 보이지 않는 활동에 불과할 수도 있습니다.

웨어러블 앱에서 시계 모드가 아닌 서비스를 실행하는데, 사용자가 권한을 요청해야 할 수도 있는 앱을 실행하지 않는 경우 웨어러블에 교육 알림을 게시할 수 있습니다. 알림은 시스템 권한 대화상자를 트리거하는 활동을 여는 작업을 제공합니다.

참고: 이는 권한 요청을 위해 스트림 알림을 사용할 수 있는 유일한 경우입니다.

서비스를 통해 간접적으로 앱과 상호작용하는 경우 사용자가 권한을 부여해야 할 수도 있습니다.

그림 10. 서비스 권한 요청

설정

전화에서와 마찬가지로 사용자가 설정에서 Wear 앱의 권한을 언제든지 변경할 수 있습니다. 따라서 사용자가 권한이 필요한 어떤 작업을 하려고 하면 항상 앱에서 먼저 checkSelfPermission() 메서드를 호출하여 앱에서 현재 이 작업을 시행하기 위해 필요한 권한이 있는지 확인해야 합니다. 사용자가 나중에 권한을 취소했을 수도 있으므로 이전에 이 권한을 부여했음을 알고 있더라도 앱에서는 이 확인 과정을 거쳐야 합니다.

사용자가 설정 앱을 통해 권한을 변경할 수 있습니다.

그림 11. 설정 앱을 통한 설정 변경