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) 권한 모델은 또한 앱 설치와 업그레이드를 간소화하였으며, 앱에 필요할 수도 있는 모든 권한을 사용자가 미리 부여해야 한다는 요구사항을 없앴습니다. 그 대신, 실제로 필요할 때까지는 앱이 권한을 요청하지 않습니다.

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

이 문서의 나머지 부분에서는 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. 권한 거부로 인해 기능이 잠겼음을 나타내는 잠금 아이콘.

이전에 거부된 웨어러블 권한 대화상자가 두 번째로 나타나는 경우에는 Deny, don't show again 옵션이 포함됩니다. 사용자가 이 옵션을 선택한 경우, 나중에 이 권한을 허용할 수 있는 유일한 방법은 웨어러블의 Settings 앱을 사용하는 것입니다.

권한 요청을 중지하는 시스템 오퍼.

그림 9. 권한-요청 화면을 더 이상 표시하지 않는 오퍼.

서비스 권한

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

시계 모드가 아닌 서비스가 웨어러블 앱에서 실행되는데, 사용자가 권한 요청이 필요할 수도 있는 앱을 시작하지 않는다면, 웨어러블에 교육 알림을 게시할 수 있습니다. 알림은 시스템 권한 대화상자를 트리거하는 액티비티를 열기 위한 액션을 제공할 수 있습니다.

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

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

그림 10. 서비스 요청 권한.

Settings

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

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

그림 11. Settings 앱을 통해 설정 변경.