Práticas recomendadas de privacidade

O foco do Android é ajudar os usuários a aproveitar as inovações mais recentes, garantindo que a segurança e a privacidade sejam as maiores prioridades.

Algumas das práticas recomendadas descritas nesta página também aparecem na folha de referência.

Atenção às permissões

Crie uma relação de confiança com seus usuários sendo transparente e dando a eles controle sobre o uso do app.

Solicite as permissões mínimas necessárias para seu recurso. Sempre que você apresentar grandes alterações no app, revise as permissões solicitadas para confirmar que os recursos ainda precisam delas.
- As versões mais recentes do Android geralmente têm maneiras de acessar os dados mantendo a privacidade, sem exigir permissões. Para mais informações, consulte Avaliar se o app precisa declarar permissões.
- Se o app for distribuído no Google Play, o Android vitals vai informar a porcentagem de usuários que negam permissões no app. Use esses dados para reavaliar o design dos recursos cujas permissões necessárias são negadas com mais frequência.
Siga o fluxo recomendado para explicar por que um recurso no seu app precisa de uma permissão. Faça o pedido dela apenas quando necessário, não na inicialização do app. Assim, a necessidade da permissão fica clara para os usuários.
Os usuários ou o sistema podem negar a permissão várias vezes. O Android respeita essa escolha ignorando pedidos de permissão do mesmo app.
Faça uma degradação suave quando os usuários negarem ou revogarem uma permissão. Por exemplo, você pode desativar o recurso de entrada de texto por voz do app caso o usuário não permita o acesso ao microfone.
Ao atualizar o app, remova o acesso dele às permissões de execução que não são mais necessárias.
Se você usa um SDK ou uma biblioteca que acessa dados protegidos por permissões perigosas, os usuários geralmente atribuem isso ao app. Entenda as permissões exigidas pelos seus SDKs e por que elas são necessárias.
- Caso você teste o app no Android 11 (API de nível 30), use a auditoria de acesso a dados para descobrir lugares no seu código e no da biblioteca de terceiros em que os dados particulares estão sendo acessados.

Minimizar o uso da localização

Se o app tiver suporte a casos de uso sem necessidade de dados de local, não peça permissões de localização. Caso ele peça permissão para acessar a localização, ajude os usuários a decidir de forma consciente.

Se o app precisar coletar informações de local, explique aos usuários como ele usa essas informações para oferecer benefícios específicos.
Se o app precisar parear o dispositivo do usuário com outro próximo por Bluetooth ou Wi-Fi, use o gerenciador de dispositivos complementar, que não solicita permissões de localização.
Analise o nível de granularidade da localização de que o app precisa. O acesso à localização aproximada é suficiente para atender à maioria dos casos de uso.
Acesse os dados de localização enquanto o app estiver visível para o usuário. Assim, ele entende melhor por que o app está pedindo essas informações.
Se o app exigir a localização em segundo plano, como ao implementar a fronteira geográfica virtual, verifique se isso é essencial para o recurso principal e é feito de maneira óbvia para os usuários. Saiba mais sobre as considerações para usar a localização em segundo plano.
No Android 10 (API de nível 29) e versões mais recentes, os usuários podem limitar o acesso do app à localização enquanto ele está em uso. Projete o app para que ele faça uma degradação suave quando não tiver acesso integral à localização.
Se o app precisar reter o acesso à localização para uma tarefa iniciada pelo usuário depois que ele sair da IU, inicie um serviço em primeiro plano antes de o app entrar em segundo plano. Você pode fazer isso em um dos callbacks de ciclo de vida do Android, como onPause().
Não inicie serviços em primeiro plano a partir do segundo plano. Em vez disso, considere iniciar o app usando uma notificação e, em seguida, executar o código de localização quando a IU estiver visível.

Processar dados com segurança

Observação: você pode ler mais sobre o que é considerado como dados confidenciais na página do artigo Dados do usuário na Central de políticas para desenvolvedores do Google Play.

Mantenha a transparência e a segurança na maneira como processa dados confidenciais.

Informe os usuários quando e por que seu app coleta, usa ou compartilha dados confidenciais.
Use o modelo de armazenamento com escopo, se possível. Saiba como migrar para o armazenamento com escopo com base nos casos de uso do app.
Sempre use conexões de rede seguras. Para os dados em repouso do app, use a criptografia de credencial integrada do Android. Para dados em trânsito, use o TLS, que substitui o SSL, para todas as transmissões de dados, seja qual for a confidencialidade.
Coloque arquivos que contenham dados sensíveis no diretório particular do seu app dentro do armazenamento interno.
No Android 10 (API de nível 29), armazene arquivos relevantes apenas para seu app no diretório específico do app no armazenamento externo. Saiba mais sobre o armazenamento com escopo.
Se precisar transmitir dados confidenciais para outro app, use uma intent explícita. Conceda acesso único aos dados para restringir o acesso do outro app.
Mesmo quando o app estiver em primeiro plano, mostre uma indicação em tempo real para avisar que você está usando o microfone ou a câmera. O Android 9 (API de nível 28) e versões mais recentes não permite o acesso ao microfone ou à câmera quando o app está em segundo plano.
Não inclua dados sensíveis em mensagens do Logcat ou nos arquivos de registro do app. Saiba mais sobre como gerenciar dados do usuário.

O Jetpack oferece várias bibliotecas para deixar os dados do app mais seguros. Saiba mais nos guias de como usar a biblioteca Security e a biblioteca Preference do Jetpack.

Usar identificadores reconfiguráveis

Respeite a privacidade dos usuários e use identificadores reconfiguráveis. Consulte Práticas recomendadas para identificadores exclusivos e veja mais informações.

Não acesse o IMEI ou o número de série do dispositivo, que são identificadores persistentes. Se você tentar acessar esses identificadores em um app direcionado ao Android 10 (API de nível 29) ou versões mais recentes, vai haver uma SecurityException.
Use um ID de publicidade apenas se for criar perfis de usuários ou em casos de uso de anúncios. Esse é um requisito para a publicação de apps no Google Play. Sempre respeite as preferências do usuário sobre monitoramento de publicidade para personalização.
Para a grande maioria dos casos de uso que não são anúncios, use um ID globalmente exclusivo (GUID, na sigla em inglês) armazenado de forma privada, que tem escopo no app.
Use o ID de configurações de segurança do Android (SSAID, na sigla em inglês) para compartilhar o estado entre seus apps sem exigir que o usuário faça login em uma conta. Saiba mais sobre como rastrear as preferências de usuários desconectados entre apps.