v
Save the date! Android Dev Summit is coming to Sunnyvale, CA on Oct 23-24, 2019.

Request permissions on Wear OS

O Android 6.0 (nível de API 23) introduziu um novo modelo de permissões, trazendo algumas mudanças específicas ao Wear OS by Google e outras mudanças que se aplicam a todos os dispositivos Android.

Um usuário deve conceder permissões para um aplicativo Wear mesmo que haja um aplicativo para celular complementar. No Android 6.0 (nível de API 23), um aplicativo Wear não pode receber permissões concedidas em um aplicativo para celular. Por exemplo, se um usuário conceder a um aplicativo para celular a permissão para usar dados de localização, o usuário do aplicativo Wear deverá, subsequentemente, conceder a mesma permissão.

Observação: Esta página pressupõe a possibilidade de você estar criando um aplicativo para celular como complemento do seu aplicativo para relógio. Entretanto, não é obrigatório que você crie um aplicativo para celular. Seu aplicativo para relógio pode ser autônomo.

Para aplicativos para celular e Wear, o modelo de permissões do Android 6.0 (nível de API 23) também otimiza a instalação e a atualização do aplicativo ao eliminar a necessidade de o usuário conceder imediatamente todas as permissões que um aplicativo possa precisar. Em vez disso, o aplicativo não solicita permissões até o momento em que precisar delas.

Observação: Para que um aplicativo use o novo modelo de permissões, ele deve especificar um valor de 23 para uses-sdk-element e compileSdkVersion.

O restante do documento discute como usar o modelo de permissões do Android 6.0 (nível de API 23) ao desenvolver aplicativos para o Wear OS.

Cenários de permissões

De forma geral, há quatro cenários que você pode encontrar ao solicitar permissões perigosas no Wear OS:

  • O aplicativo Wear solicita permissões para um aplicativo executado no dispositivo wearable.
  • O aplicativo Wear solicita permissões para um aplicativo executado no telefone.
  • O aplicativo para celular solicita permissões para um aplicativo executado no dispositivo wearable.
  • O aplicativo para wearable usa um modelo de permissões diferente de seu complemento para celular.

O restante desta selão explica cada um desses cenários. Para obter informações mais detalhadas sobre como solicitar permissões, consulte Padrões de solicitação de permissões.

O aplicativo Wear solicita permissões para um aplicativo executado no dispositivo wearable.

Quando o aplicativo Wear solicita uma permissão para um aplicativo executado em um dispositivo wearable, o sistema exibe uma caixa de diálogo para solicitar essa permissão do usuário. Um aplicativo ou serviço só pode chamar o método requestPermissions() de uma atividade. Se o usuário interagir com seu aplicativo por meio de um serviço, como o mostrador do relógio, o serviço deve abrir uma atividade antes de solicitar a permissão.

Se aplicativo solicita permissões no contexto quando está claro o motivo pelo qual as permissões são necessários para realizar determinada operação. Se seu aplicativo obviamente exigir certas permissões, ele poderá solicitá-las quando for iniciado. Se a necessidade não for tão óbvia, você pode optar por fornecer mais informações antes de solicitar uma permissão.

Se um aplicativo ou mostrador do relógio exigir mais de uma permissão por vez, as solicitações de permissão serão exibidas consecutivamente.

Várias telas de permissão consecutivas.

Figura 1. Telas de permissão aparecendo consecutivamente.

Observação: A partir do Android 6.0 (nível de API 23), o Wear OS automaticamente sincroniza os dados de Agenda, Contatos e Localização com o dispositivo Wear. Consequentemente, este cenário é o aplicável quando o Wear solicita esses dados.

Aplicativo Wear solicita permissão ao celular

Ao solicitar uma permissão ao celular, o aplicativo Wear deve direcionar o usuário ao celular para que ele aceite a permissão. Lá, o aplicativo para celular pode fornecer informações adicionais ao usuário por meio de uma atividade. A atividade deve incluir dois botões: um para aceitar e outro para negar a permissão.

O aplicativo Wear direciona o usuário ao celular para que ele conceda a permissão.

Figura 2. Direcione o usuário ao celular para que ele conceda a permissão.

Aplicativo para celular solicita permissão do wearable

Quando o usuário está usando um aplicativo para celular e o aplicativo solicita permissão do wearable, ele deve direcionar o usuário ao wearable para aceitar a permissão. O aplicativo para celular usa o método requestPermissions() no wearable para acionar a caixa de diálogo de permissões do sistema.

O aplicativo para celular direciona o usuário ao wearable para que ele conceda a permissão.

Figura 3. Direcione o usuário ao wearable para que ele conceda a permissão.

Modelos de permissão diferentes entre os aplicativos para wearable e para celular

Se seu aplicativo para celular começa usando o modelo do Android 6.0 (nível de API 23), mas seu aplicativo para wearable usa outra versão, o sistema baixará o aplicativo Wear, mas não o instalará. Quando o usuário inicia o aplicativo pela primeira vez, o sistema solicita que ele conceda todas as permissões pendentes. Quando isso for feito, ele instalará o aplicativo. Se seu aplicativo, por exemplo, um mostrador do relógio, não tiver um inicializador, o sistema exibirá uma notificação de stream solicitando que o usuário conceda as permissões de que o aplicativo precisa.

Padrões de solicitação de permissão

Há diferentes padrões para solicitar permissões dos usuários. Aqui estão eles, em ordem de prioridade:

  • Solicitar em contexto quando a permissão é obviamente necessária para um recurso específico, mas não para a execução do aplicativo em si.
  • Informar em contexto quando o motivo para solicitar a permissão não é óbvio e a permissão não é necessária para a execução do aplicativo em si.
  • Solicitar imediatamente quando a necessidade da permissão é óbvia e ela é obrigatória para a execução do aplicativo.
  • Informar imediatamente quando a necessidade da permissão não é óbvia, mas ela é obrigatória para a execução do aplicativo.

Solicitar em contexto

Seu aplicativo deve solicitar permissões quando sua necessidade é clara para executar determinada operação. Os usuários têm mais probabilidade de conceder uma permissão quando entendem sua relação com o recurso que desejam usar.

Por exemplo, um aplicativo pode precisar da localização de um usuário para mostrar locais de interesse nas proximidades. Quando o usuário toca na pesquisa de locais próximos, o aplicativo pode imediatamente solicitar a permissão de localização, pois há uma relação clara entre procurar locais próximos e a necessidade da permissão de localização. A obviedade dessa relação elimina a necessidade de o aplicativo mostrar telas informativas adicionais.

O aplicativo solicita a permissão quando ela é obviamente necessária.

Figura 4. Solicitar em contexto.

Informar em contexto

Se necessário, você pode optar por fornecer mais informações antes de solicitar uma permissão. Novamente, o aplicativo deve fazer isso no contexto de uma ação específica, caso não óbvio o motivo pelo qual seu aplicativo precisa da permissão solicitada para executar a ação em questão.

A figura 5 mostra um exemplo de informações em contexto. O aplicativo não precisa de permissões para iniciar o timer, mas uma dica informativa interna mostra que parte da atividade (detecção de localização) está bloqueada. Quando o usuário toca na dica, é exibida uma tela de solicitação de permissão, permitindo que o usuário desbloqueie a detecção de localização.

Você pode usar o método shouldShowRequestPermissionRationale() para ajudar seu aplicativo a decidir se deve fornecer mais informações. Para obter mais detalhes, consulte Solicitar permissões no tempo de execução.

Quando a necessidade da permissão surgir, o aplicativo explicará porque ela é necessária.

Figura 5. Informar em contexto.

Solicitar imediatamente

Se seu aplicativo claramente precisar de uma permissão para funcionar, você pode solicitá-la quando o usuário iniciar o aplicativo. Por exemplo, um aplicativo de mapas claramente precisa de acesso à localização do dispositivo para executar suas atividades. Não é necessário fornecer mais informações para essa permissão.

Se um aplicativo obviamente precisar de uma permissão para ser executado, ele pode solicitá-la imediatamente após sua inicialização.

Figura 6. Solicitar imediatamente.

Informar imediatamente

Em alguns casos, o aplicativo precisa de uma permissão para suas funções básicas, mas o motivo disso não é óbvio. Nesses casos, quando o usuário inicia o aplicativo pela primeira vez ou define um mostrador de relógio, o aplicativo ou mostrador do relógio podem optar por informar o usuário e solicitar a permissão.

Ao solicitar uma permissão após a inicialização, o aplicativo pode explicar por que precisa dessa permissão.

Figura 7. Informar imediatamente.

Processar rejeições

Se um usuário negar uma permissão solicitada que não seja essencial para a atividade pretendida, não o impeça de continuar a atividade. Se certas partes da atividade forem desativadas pela permissão negada, forneça um feedback visual e acionável. A figura 8 mostra o uso de um ícone de cadeado para indicar que um recurso está bloqueado porque o usuário não concedeu permissão para usá-lo.

Quando o usuário negar a permissão, um ícone de cadeado será mostrado ao lado do recurso associado.

Figura 8. Ícone de cadeado mostrando que um recurso foi bloqueado por causa de uma permissão negada.

Quando a caixa de diálogo de uma permissão de wearable anteriormente negada aparecer uma segunda fez, ela incluirá a opção Deny, don't show again. Se o usuário selecionar essa opção, a única maneira de concedê-la no futuro será pelo aplicativo Settings do wearable.

O sistema oferece parar de solicitar a permissão.

Figura 9. A oferta de não mostrar mais a tela de solicitação de permissão.

Permissões para serviços

Como foi mencionado acima, somente uma atividade pode chamar o método requestPermissions(), portanto, se o usuário interagir com o aplicativo por meio de um serviço, por exemplo, um mostrador do relógio, o serviço deverá abrir uma atividade em segundo plano antes de solicitar a permissão. Essa atividade pode fornecer informações adicionais ou simplesmente ser uma atividade invisível que exibe a caixa de diálogo do sistema.

Se seu aplicativo para wearable executar um serviço que não seja um mostrador do relógio e o usuário não iniciar um aplicativo para o qual faça sentido solicitar a permissão, você pode exibir uma notificação informativa no wearable. A notificação pode fornecer uma ação para abrir uma atividade que, então, aciona a caixa de diálogo de permissões do sistema.

Observação: Esse é o único uso aceitável de uma notificação de stream para solicitações de permissão.

O usuário pode precisar solicitar uma permissão ao interagir indiretamente com um aplicativo por meio de um serviço.

Figura 10. Um serviço solicitando permissão.

Configurações

Assim como com o celular, o usuário pode alterar as permissões de um aplicativo Wear em Settings a qualquer momento. Portanto, quando o usuário tenta fazer algo que requer uma permissão, o aplicativo sempre deve chamar o método checkSelfPermission() para verificar se ele tem a permissão para realizar essa operação. O aplicativo deve realizar essa verificação mesmo que saiba que o usuário já concedeu essa permissão anteriormente, pois ele pode ter revogado a permissão depois.

O usuário pode alterar permissões pelo aplicativo Settings.

Figura 11. Alterar configurações pelo aplicativo Settings.