Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

Solicitar permissões no Wear OS

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

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

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

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

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

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

Cenários de permissões

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

  • O app Wear solicita permissões para um app executado no dispositivo wearable.
  • O app Wear solicita permissões para um app executado no smartphone.
  • O app para smartphone solicita permissões para um app executado no dispositivo wearable.
  • O app para wearable usa um modelo de permissões diferente do seu complemento para smartphone.

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

App Wear solicita permissão para um app executado no dispositivo wearable

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

Seu app solicita permissões no contexto quando está claro o motivo pelo qual as permissões são necessárias para realizar determinada operação. Se seu app 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 app 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 (API de nível 23), o Wear OS sincroniza automaticamente 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.

App Wear solicita permissão ao smartphone

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

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

Figura 2. Direcionamento do usuário ao smartphone para que ele conceda a permissão.

App para smartphone solicita permissão do wearable

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

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

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

Modelos de permissão diferentes entre os apps para wearable e para smartphone

Se seu app para smartphone começa usando o modelo do Android 6.0 (API de nível 23), mas seu app para wearable usa outra versão, o sistema fará o download do app Wear, mas não o instalará. Quando o usuário inicia o app pela primeira vez, o sistema solicita que ele conceda todas as permissões pendentes. Quando isso for feito, ele instalará o app. Se seu app, por exemplo, um mostrador de 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 app 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 app 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 app em si.
  • Solicitar imediatamente quando a necessidade da permissão é óbvia e ela é obrigatória para a execução do app.
  • Informar imediatamente quando a necessidade da permissão não é óbvia, mas é obrigatória para a execução do app.

Solicitar em contexto

O app precisa solicitar permissões quando a necessidade é clara para executar determinada operação. Os usuários têm mais probabilidade de conceder uma permissão quando entendem a relação dela com o recurso que desejam usar.

Por exemplo, um app pode precisar da localização de um usuário para mostrar locais de interesse nas proximidades. Quando o usuário toca na pesquisa de lugares próximos, o app pode solicitar imediatamente a permissão de localização, porque 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 app mostrar mais telas informativas.

O app 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, seu app precisa fazer isso no contexto de uma ação específica, caso não seja óbvio o motivo pelo qual o app 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 app 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 app a decidir se precisa fornecer mais informações. Para mais detalhes, consulte Solicitar permissões no tempo de execução.

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

Figura 5. Informar em contexto.

Solicitar imediatamente

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

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

Figura 6. Solicitar imediatamente.

Informar imediatamente

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

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

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 algumas 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 bloqueio mostrando que um recurso está bloqueado devido a uma permissão negada.

Quando a caixa de diálogo de uma permissão de wearable anteriormente negada aparecer uma segunda vez, 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 app Settings do wearable.

O sistema oferece parar de solicitar a permissão.

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

Permissões para serviços

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

Se seu app para wearable executar um serviço que não seja um mostrador do relógio e o usuário não iniciar um app 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 conceder uma permissão ao interagir indiretamente com um app por meio de um serviço.

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

Configurações

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

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

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