Desde a entrada em vigor da Lei Geral de Proteção de Dados (Lei nº 13.709/2018), todo app publicado no Brasil que coleta dados de usuários precisa cumprir regras claras sobre finalidade, consentimento, transparência e segurança. Para quem desenvolve em Kotlin no Android, isso não é apenas uma obrigação jurídica — é também uma forma de construir confiança com o usuário e evitar sanções da Autoridade Nacional de Proteção de Dados (ANPD).

Este guia prático mostra como traduzir os princípios da LGPD em decisões concretas de código: onde armazenar dados sensíveis, como pedir consentimento, como autenticar o usuário com biometria e como se preparar para mudanças que já estão em curso no ecossistema Android em 2026, como o Privacy Sandbox.

Se você ainda está montando a base técnica, vale revisar antes nosso artigo sobre segurança de dados locais no Android com Kotlin, o guia de permissões no Android com Kotlin e a comparação Room vs SQLDelight, porque a LGPD começa exatamente na decisão de onde e como guardar cada dado.

O que a LGPD pede para o desenvolvedor

A lei se baseia em dez princípios (Art. 6º), mas, na prática do dia a dia do desenvolvimento mobile, quatro exigem atenção direta no código:

  • Finalidade: colete apenas o dado que o app realmente usa. Nada de “guardar para ver se serve depois”.
  • Transparência: o usuário precisa entender o que é coletado e por quê, em linguagem clara.
  • Segurança: dados pessoais exigem proteção técnica contra acessos indevidos.
  • Não discriminação: não use dados para finalidades que discriminem o usuário.

O titular dos dados (seu usuário) tem direitos específicos: acesso, correção, anonimização e portabilidade. O seu app precisa conseguir apagar dados quando solicitado, e isso afeta diretamente como você modela persistência local e sincronização com backend.

Para a maioria dos apps, o consentimento é a base legal mais simples. Em Kotlin, isso significa implementar um fluxo claro que (1) explica o que será coletado, (2) registra se o usuário aceitou e (3) permite revogar a decisão depois.

Um padrão seguro é armazenar o consentimento com versão e timestamp:

data class Consentimento(
    val versaoDoTermo: String,
    val aceito: Boolean,
    val timestamp: Long,
    val finalidades: List<String>
)

class ConsentimentoRepository(private val dataStore: DataStore<Preferences>) {
    private val CONSENTIMENTO = booleanPreferencesKey("consentimento_aceito")
    private val VERSAO = stringPreferencesKey("consentimento_versao")

    suspend fun registrar(decisao: Consentimento) {
        dataStore.edit { prefs ->
            prefs[CONSENTIMENTO] = decisao.aceito
            prefs[VERSAO] = decisao.versaoDoTermo
        }
    }

    val estado: Flow<Boolean> = dataStore.data.map { it[CONSENTIMENTO] ?: false }
}

Importante: o consentimento precisa ser livre, informado e inequívoco. Não basta um checkbox pré-marcado. Sempre que você mudar as finalidades de coleta, bump da versão do termo e peça consentimento de novo.

Armazenamento seguro com EncryptedSharedPreferences e DataStore

A ANPD tem cobrado cada vez mais proteção técnica, não só política. Dados pessoais no dispositivo devem ficar criptografados, especialmente em dispositivos com root ou em casos de roubo.

Para preferências pequenas (tokens, flags sensíveis), use EncryptedSharedPreferences:

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val prefs = EncryptedSharedPreferences.create(
    context,
    "dados_pessoais",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

Para volumes maiores de dados estruturados, a recomendação moderna é combinar Room com a extensão de criptografia via SQLCipher ou usar Jetpack Security. Revisitamos essas opções em detalhe no artigo sobre segurança de dados locais.

Evite guardar dados pessoais em SharedPreferences comum, arquivos texto ou logs. Logs em produção, inclusive, são um dos vetores mais comuns de vazamento detectado em pentests de apps brasileiros.

Autenticação biométrica com Biometric

Quando o app lida com dados sensíveis (financeiros, de saúde, documentos), a LGPD e o bom senso pedem autenticação forte antes de exibi-los. A biblioteca AndroidX Biometric resolve isso com poucas linhas:

val promptInfo = BiometricPrompt.PromptInfo.Builder()
    .setTitle("Desbloquear dados pessoais")
    .setSubtitle("Use biometria para acessar")
    .setNegativeButtonText("Cancelar")
    .build()

val prompt = BiometricPrompt(activity, executor,
    object : BiometricPrompt.AuthenticationCallback() {
        override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
            carregarDadosSensiveis()
        }
    })

prompt.authenticate(promptInfo)

Para quem já usa passkeys e Credential Manager — abordagem que detalhamos em passkeys no Android com Kotlin — vale combinar as duas camadas: biometria libera o cofre local e passkeys autenticam no backend.

Direito ao esquecimento e portabilidade

Dois direitos do titular viram requisitos funcionais: apagar dados e exportar dados. Modele isso desde o início:

interface DadosPessoaisService {
    suspend fun exportar(userId: String): DadosExportados
    suspend fun anonimizar(userId: String)
    suspend fun apagar(userId: String)
}

A diferença entre anonimizar e apagar importa: registros completamente anônimos podem ser mantidos para estatística, mas dados que permitam reidentificação precisam sumir de verdade, inclusive em backups com prazo definido.

Privacy Sandbox e a transição dos identificadores

Em 2026, o Android continua avançando o Privacy Sandbox, que substitui o AD_ID por APIs que limitam rastreamento cross-app. Para apps que dependem de publicidade, isso muda a forma de coletar métricas. O ponto de atenção para a LGPD: menos rastreamento não significa dispensa de consentimento — qualquer dado pessoal, mesmo pseudonimizado, ainda se enquadra na lei.

Checklist prático para auditoria de conformidade

Antes de publicar uma nova versão, confira:

  1. Toda coleta nova tem finalidade documentada e consentimento versionado.
  2. Dados pessoais locais estão criptografados (EncryptedSharedPreferences ou Room + SQLCipher).
  3. Existe fluxo de exclusão de conta funcional, testado de ponta a ponta.
  4. Logs de produção não expõem CPF, e-mail, localização ou tokens.
  5. Permissões do Android pedem apenas o necessário no momento de uso (revise nosso guia de permissões).
  6. A política de privacidade reflete exatamente o que o código faz — não mais, não menos.

Conclusão

Cumprir a LGPD em um app Android escrito em Kotlin é, sobretudo, uma questão de arquitetura: preferir armazenamento criptografado, modelar consentimento como dado de primeira classe e tratar exclusão e portabilidade como recursos, não como correções tardias. As APIs do ecossistema Jetpack — Biometric, Security, DataStore, Credential Manager — já cobrem a maior parte do caminho técnico.

Para aprofundar o lado de backend, vale cruzar este guia com nosso artigo sobre segurança de dados locais no Android e, se você mantém infra multiplataforma, com a comparação de Kotlin Multiplatform vs Flutter, onde discutimos também como compartilhar a camada de segurança entre Android e iOS. Em projetos maiores, isso conversa diretamente com a modularização no Android com Compose, separando o módulo de privacidade do resto do app.

Para um panorama mais amplo do ecossistema Kotlin neste ano, confira também as tendências Kotlin em 2026 no nosso portal. Quem trabalha com carteiras digitais pode achar útil ainda a leitura sobre cartão de crédito do nosso portfolio, que cobre como o mercado brasileiro trata consentimento financeiro — uma referência útil quando o seu app lida com pagamentos.