Skip to content

Most visited

Recently visited

navigation

Práticas recomendadas para permissões de aplicativos

Solicitações de permissão protegem informações confidenciais disponíveis em um dispositivo e só devem ser usadas quando o acesso às informações é necessário para o funcionamento do aplicativo. Este documento fornece dicas sobre como obter os mesmos recursos (ou melhores) sem exigir o acesso a essas informações. Não se trata de uma discussão completa sobre o funcionamento das permissões no sistema operacional Android.

Para obter uma perspectiva mais geral sobre as permissões do Android, consulte Permissões e dados do usuário. Para obter detalhes sobre como trabalhar com permissões no seu código, consulte Trabalho com permissões do sistema. Para obter práticas recomendadas sobre como trabalhar com identificadores exclusivos, consulte Práticas recomendadas para identificadores exclusivos.

Princípios de como trabalhar com as permissões do Android

Recomendamos seguir os seguintes princípios ao trabalhar com permissões do Android:

#1: Use somente as permissões necessárias para o funcionamento do seu aplicativo. Dependendo de como você use as permissões, pode haver outra maneira de fazer o que precisa (intents do sistema, identificações, obtenção de informações para chamadas telefônicas) sem precisar de acesso a informações confidenciais.

#2: Preste atenção às permissões das quais as bibliotecas precisam. Ao incluir uma biblioteca, você também herda seus requisitos de permissões. Você deve estar ciente do que está incluindo, as permissões necessárias e para que essas permissões são usadas.

#3: Seja transparente. Ao fazer uma solicitação de permissão, seja claro sobre o que está acessando e por que, para que os usuários possam tomar decisões informadas. Disponibilize essas informações juntamente com a solicitação de permissão, incluindo caixas de diálogo de permissões de instalação, tempo de execução ou atualização.

#4: Torne explícito o acesso ao sistema. Ao fornecer indicações contínuas ao acessar recursos importantes (como a câmera ou o microfone), você deixa claro para os usuários quando está coletando dados e evita a percepção de que essa coleta está sendo feita clandestinamente.

As demais seções deste guia detalham essas regras no contexto do desenvolvimento de aplicativos Android.

Permissões no Android 6.0 e em versões posteriores

O Android 6.0 Marshmallow introduziu um novo modelo de permissões que permite que os aplicativos solicitem permissões do usuário no tempo de execução, em vez de antes da instalação. Os aplicativos compatíveis com o novo modelo solicitam permissões quando de fato precisam dos serviços ou dos dados protegidos pelos serviços. Embora isso não (necessariamente) mude o comportamento geral do dispositivo, foram feitas algumas mudanças relevantes sobre a forma com a qual os dados confidenciais do usuário são manipulados:

Aumento no contexto situacional: Os usuários recebem uma solicitação no tempo de execução, no contexto do seu aplicativo, para concederem permissão de acessar o recurso incluído nesses grupos de permissões. Os usuários estão mais atentos ao contexto no qual a permissão é solicitada e, em caso de incompatibilidade entre sua solicitação e o propósito do seu aplicativo, é ainda mais importante fornecer explicações detalhadas sobre o motivo da solicitação de permissão; sempre que possível, forneça uma explicação sobre sua solicitação no momento da solicitação e em uma caixa de diálogo de acompanhamento se o usuário a negar.

Mais flexibilidade para a concessão de permissões: Os usuários podem negar acesso a permissões individuais no momento em que são solicitadas e nas configurações, mas eles ainda assim podem se surpreender se um recurso for inutilizado como resultado. É recomendável monitorar quantos usuários estão negando permissões (por exemplo, usando o Google Analytics) para que você possa adaptar seu aplicativo dependendo da permissão ou fornecer uma explicação melhor sobre o motivo pelo qual você precisa da permissão para o funcionamento adequado do aplicativo. Certifique-se também de que seu aplicativo lide com as exceções criadas quando os usuários negam solicitações de permissão ou desativam as permissões nas configurações.

Aumento na carga de transações: Os usuários serão solicitados a conceder acesso para grupos de permissões individualmente, não como um conjunto. Dessa forma, é extremamente importante minimizar o número de permissões solicitadas, pois isso aumenta o esforço do usuário para conceder permissões e aumenta a probabilidade de pelo menos uma delas ser negada.

Evite solicitar permissões desnecessárias

Esta seção fornece alternativas para casos de uso comuns que ajudarão a limitar o número de solicitações de permissões que você realiza. Como o número e o tipo de permissões exibidas ao usuário afetam os downloads em comparação a outros aplicativos que solicitam menos permissões, é recomendável evitar a solicitação de permissões para recursos desnecessários.

Acesso à câmera/aos contatos com solicitações de usuários em tempo real

Neste caso, você precisa de acesso ocasional à câmera ou às informações de contato do dispositivo e não se importa em solicitar ao usuário sempre que precisar de acesso.

Se a sua necessidade de acesso aos dados do usuário for infrequente — em outras palavras, se não for inaceitavelmente disruptivo para o usuário receber uma caixa de diálogo de tempo de execução sempre que você precisar acessar os dados — você pode usar uma solicitação baseada em intent. O Android fornece algumas intents de sistema que os aplicativos podem usar sem solicitar permissões, pois o usuário escolhe o que, se for o caso, deseja compartilhar com o aplicativo no momento que a solicitação baseada em intent é emitida.

Por exemplo, um tipo de ação de intent de MediaStore.ACTION_IMAGE_CAPTURE ou MediaStore.ACTION_VIDEO_CAPTURE pode ser usado para capturar imagens ou vídeos sem usar o objeto Camera diretamente (ou solicitar a permissão). Nesse caso, a intent do sistema solicitará a permissão do usuário em seu nome sempre que uma imagem for capturada.

Execução em segundo plano após a perda do foco de áudio

Neste caso, seu aplicativo precisa ser executado em segundo plano quando o usuário recebe uma chamada e voltar ao foco somente quando a chamada for finalizada.

A abordagem comum nesses casos - por exemplo, um reprodutor de mídia entrando em mudo ou sendo pausado durante uma chamada - é ouvir as mudanças no estado da chamada usando PhoneStateListener ou ouvir a transmissão de android.intent.action.PHONE_STATE. O problema com essa solução é que ela exige a permissão READ_PHONE_STATE, que força o usuário a conceder acesso a uma grande seção de dados importantes, como os códigos do hardware do dispositivo e do chip e o número de telefone da chamada recebida.

Você pode evitar isso solicitando AudioFocus para seu aplicativo, o que não exige permissões explícitas (pois ele não acessa informações confidenciais). Basta inserir o código necessário para colocar seu áudio em segundo plano no gerenciador de eventos onAudioFocusChange() e ele será executado automaticamente quando o SO alterar o foco do áudio. Informações mais detalhadas sobre como fazer isso podem ser encontradas aqui.

Determine o dispositivo no qual sua instância está sendo executada

Neste caso, você precisa de um identificador exclusivo para determinar o dispositivo no qual a instância do seu aplicativo está sendo executada.

Os aplicativos podem ter preferências ou mensagens específicas ao dispositivo (por exemplo, salvar uma lista de reprodução específica ao dispositivo para um usuário na nuvem para que ele possa ter uma lista de reprodução diferente para o carro e em casa). Uma solução comum é utilizar identificadores de dispositivo como Device IMEI, mas isso exige o grupo de permissões Device ID and call information (PHONE no M+). Ele também usa um identificador que não pode ser redefinido e que é compartilhado em todos os aplicativos.

Existem duas alternativas para o uso desses tipos de identificadores:

  1. Usar a InstanceID API do com.google.android.gms.iid. O getInstance(Context context).getID() retornará um identificador exclusivo do dispositivo para a instância do seu aplicativo. O resultado é um identificador com escopo da instância do aplicativo que pode ser usado como chave ao armazenar informações sobre o aplicativo e que é redefinido se o usuário reinstalar o aplicativo.
  2. Crie seu próprio identificador com escopo do armazenamento do seu aplicativo usando funções básicas como randomUUID().

Crie um identificador exclusivo para análises de publicidade ou usuários

Neste caso, você precisa de um identificador exclusivo para criar um perfil para usuários que não se conectaram ao seu aplicativo (por exemplo, para direcionar anúncios ou medir as conversões).

Criar um perfil para análise de publicidade e usuários às vezes exige um identificador compartilhado por outros aplicativos. Soluções comuns para isso envolvem o uso de identificadores de dispositivo como Device IMEI, que exige o grupo de permissões Device ID and call information (PHONE no nível de API 23 e superiores) e que não pode ser redefinido pelo usuário. Em qualquer um desses casos, além de usar um identificador que não pode ser redefinido e solicitar uma permissão que pode parecer estranha aos usuários, você também estará violando as Políticas do Programa do Desenvolvedor do Google Play.

Infelizmente, nesses casos, o uso da InstanceID API do com.google.android.gms.iid ou de funções do sistema para criar um código com escopo de aplicativo não é uma solução apropriada, pois o código pode precisar ser compartilhado em outros aplicativos. Uma solução alternativa é usar o Advertising Identifier disponibilizado pela classe AdvertisingIdClient.Info com o método getId(). Você pode criar um objeto AdvertisingIdClient.Info usando o método getAdvertisingIdInfo(Context) e chamar o método getId() para usar o identificador. Observe que esse método é bloqueador, portanto, você não deve chamá-lo pelo encadeamento principal; uma explicação detalhada sobre esse método pode ser encontrada aqui.

Conheça as bibliotecas com as quais você está trabalhando

Às vezes, as bibliotecas que você usa no seu aplicativo exigem permissões. Por exemplo, bibliotecas de anúncios ou de análise podem exigir acesso aos grupos de permissões Location ou Identity para implementar os recursos necessários. No entanto, no ponto de vista do usuário, a solicitação de permissão é emitida pelo seu aplicativo, não pela biblioteca.

Assim como os usuários selecionam aplicativos que usam menos permissões para proporcionar os mesmos recursos, os desenvolvedores devem analisar suas bibliotecas e selecionar SDKs de terceiros que não usem permissões desnecessárias. Por exemplo, procure evitar bibliotecas que exijam o grupo de permissões Identity a não ser que exista uma razão clara para o aplicativo precisar dessas permissões que o usuário possa visualizar. Especificamente, para bibliotecas que fornecem o recurso de localização, certifique-se de que não seja necessário solicitar a permissão FINE_LOCATION a não ser que você esteja usando recursos de direcionamento baseados na localização.

Seja transparente

Informe os usuários sobre o que você está acessando e por quê. Pesquisas mostram que os usuários se sentem muito mais à vontade com solicitações de permissões se souberem por que o aplicativo precisa delas. Um estudo de usuários revelou que:

...a disposição de um usuário de conceder determinada permissão a um determinado aplicativo para dispositivos móveis é fortemente influenciada pelo propósito associado a tal permissão. Por exemplo, a disposição de um usuário de conceder acesso à sua localização variará dependendo de a solicitação ser necessária para oferecer suporte a um recurso essencial do aplicativo ou de ela ser usada para compartilhar essa informação com uma rede de publicidade ou empresa de análise.1

Com base na pesquisa de seu grupo, o Professor Jason Hong da CMU concluiu que, de forma geral:

... quando as pessoas sabem por que um aplicativo está utilizando uma informação tão importante quanto sua localização — por exemplo, para anúncios direcionados — eles ficam mais à vontade do que ficariam ao serem simplesmente informados de que um aplicativo está usando sua localização.1

Consequentemente, se você só estiver usando uma fração das chamadas de API que se encaixem em um grupo de permissões, é pertinente listar explicitamente quais permissões você está usando e por quê. Por exemplo:

Em certas condições, também é pertinente informar os usuários sobre acessos a dados confidenciais em tempo real. Por exemplo, se você estiver acessando a câmera ou o microfone, geralmente é recomendável informar o usuário com um ícone de notificação em algum lugar do aplicativo ou na bandeja de notificações (se o aplicativo estiver sendo executado em segundo plano) para que não pareça que os dados estão sendo coletados clandestinamente.

Finalmente, se precisar solicitar uma permissão para que um recurso do seu aplicativo seja executado, mas o motivo não estiver claro para o usuário, encontre uma maneira de informar por que você precisa das permissões mais confidenciais.

Referências

[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, por J. Lin B. Liu, N. Sadeh e J. Hong. Nos procedimentos do SOUPS 2014.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Siga o Google Developers no WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)