Android vai barrar WRITE_CONTACTS: apps terão de usar intents padrão para editar contatos

A mudança mira um problema antigo: WRITE_CONTACTS dá ao app poder amplo sobre a agenda inteira, inclusive em segundo plano e sem interação do usuário. Só que a maioria dos apps salva um contato ou outro. Para esses casos, o Google empurra os intents ACTION_INSERT, ACTION_EDIT e ACTION_INSERT_OR_EDIT, que não exigem permissão nenhuma. Quem mira a próxima versão do Android e tentar gravar direto leva SecurityException.

O motivo de os apps pedirem a permissão até hoje é prático: os intents se comportavam diferente em cada aparelho. Alguns editores jogavam fora a foto enviada, o botão voltar salvava o contato sem querer e a opção de criar contato era difícil de achar. O Google diz que vai exigir um padrão único dos fabricantes. Para o dev, o checklist é direto: buscar WRITE_CONTACTS, RawContacts.CONTENT_URI, Data.CONTENT_URI e applyBatch, trocar cada gravação guiada pelo usuário por intent e tirar a permissão do manifest. Atenção a dois detalhes: tipos MIME customizados em Insert.DATA são ignorados em silêncio pelo editor, e SHOW_OR_CREATE_CONTACT não é tratado pelo editor do sistema.

Em 22 de abril de 2026, o CEVIU noticiou que o Android 17 encerrava o acesso "tudo ou nada" aos contatos, com o novo Contact Picker para leitura seletiva. Agora o outro lado da moeda chega: a escrita também sai do modelo de permissão ampla. Leitura passa pelo Contact Picker, edição pelos intents, e o acesso amplo fica restrito ao MANAGE_CONTACTS, que chega no Android 17 QPR2 (quarto trimestre de 2026) e exige declaração no Play Console.

Para quem tem app com agenda, CRM mobile ou mensageiro, isso mexe em fluxo de produto e em revisão na Play Store. Customizar a tela de edição de contatos só por design não qualifica para MANAGE_CONTACTS. Quem depender de acesso amplo precisa justificar por que os intents não bastam. Planejar a migração antes de subir o target SDK evita crash e rejeição.