Android 17 restringe uso da API de acessibilidade por aplicativos que não são assistivos

Mudança no Android Advanced Protection Mode revoga permissões de acessibilidade para apps não classificados como ferramentas assistivas e reduz um vetor comum de abuso por malware móvel.

Componente	Android Advanced Protection Mode no Android 17 Beta 2, com restrição sobre a API de serviços de acessibilidade do sistema operacional.
Vetor	Aplicativos que não são ferramentas de acessibilidade tentam obter ou manter permissão para usar AccessibilityService, um recurso legítimo frequentemente abusado por malware Android.
Impacto	Quando o modo de proteção avançada está ativo, permissões já concedidas a apps não assistivos são revogadas e novas concessões ficam bloqueadas até o usuário desativar a configuração.
Prioridade	Avaliar dependências corporativas que usam acessibilidade fora do escopo assistivo, testar compatibilidade no Android 17 e orientar usuários de alto risco a ativar o modo quando disponível.
Versões	A restrição aparece no Android 17 Beta 2; o Android Advanced Protection Mode foi introduzido no Android 16.
Exceções	Ferramentas verificadas como assistivas, marcadas com isAccessibilityTool=true, ficam fora do bloqueio.

Resumo técnico

O Android 17 Beta 2 incorpora uma nova restrição ao Android Advanced Protection Mode, um modo opcional de endurecimento do sistema voltado a usuários expostos a ataques sofisticados. A mudança impede que determinadas categorias de aplicativos usem a API de serviços de acessibilidade quando elas não são classificadas como ferramentas assistivas. O alvo defensivo é um vetor recorrente em malware móvel: o abuso de permissões de acessibilidade para observar telas, interagir com interfaces, automatizar ações e acessar dados sensíveis em um dispositivo já comprometido.

O Android Advanced Protection Mode foi introduzido no Android 16 e reúne configurações de segurança que reduzem a superfície de ataque em troca de perda de conveniência. Entre os controles já associados ao modo estão bloqueio de instalação de aplicativos a partir de fontes desconhecidas, restrição de sinalização de dados via USB e exigência de varredura pelo Google Play Protect. No Android 17, esse pacote passa a atuar também sobre a autorização de acessibilidade, removendo privilégios de apps que não se enquadram na definição de tecnologia assistiva.

A exceção declarada é limitada a aplicativos reconhecidos como ferramentas de acessibilidade, identificados pelo sinalizador isAccessibilityTool=true. Nessa categoria entram leitores de tela, sistemas de entrada por chaves, ferramentas de entrada por voz e programas de acesso baseados em Braille. Antivírus, ferramentas de automação, assistentes, aplicativos de monitoramento, limpadores, gerenciadores de senhas e launchers não são tratados como ferramentas assistivas para essa regra, mesmo que alguns deles tenham casos de uso legítimos envolvendo observação ou automação de interface.

Fluxo técnico

O fluxo de proteção depende da ativação do Android Advanced Protection Mode pelo usuário. Quando o modo está ativo, um aplicativo que não seja classificado como ferramenta assistiva não consegue receber permissão para usar a API de serviços de acessibilidade. Se esse aplicativo já possuía a permissão antes da ativação, o privilégio é revogado automaticamente. Isso reduz a janela em que um software instalado com permissão excessiva pode continuar operando sobre a interface do sistema após a mudança para um estado de segurança mais rígido.

A API AccessibilityService existe para permitir que pessoas com deficiência interajam com dispositivos e aplicativos Android. O mesmo nível de integração com a interface, entretanto, torna a API atraente para abuso. Em campanhas de malware móvel, a permissão de acessibilidade pode ser explorada para acompanhar conteúdo exibido na tela, auxiliar automação de cliques, interferir em fluxos de autenticação e coletar informação sensível. A nova política não remove a API do sistema, mas restringe seu uso no perfil de proteção avançada a aplicativos que pertencem ao conjunto assistivo definido pelo Android.

Para desenvolvedores, o Android 17 também expõe integração por meio da API AdvancedProtectionManager, permitindo que aplicativos detectem o estado do modo de proteção avançada e ajustem seu comportamento. O uso defensivo esperado é reduzir funções de maior risco quando o usuário opta pelo modo endurecido. Isso cria uma dependência prática para softwares corporativos: aplicações que usavam acessibilidade para automação, monitoramento ou conveniência podem perder essa capacidade sob AAPM e precisam tratar esse cenário sem induzir o usuário a enfraquecer a proteção.

Superfície afetada

A superfície principal é composta por aplicativos Android instalados em dispositivos que venham a executar Android 17 com o Android Advanced Protection Mode habilitado. O bloqueio não é descrito como uma regra global para todos os usuários do sistema, mas como parte do modo de proteção avançada. Portanto, o impacto operacional depende da adoção desse modo por pessoas de maior risco, ambientes gerenciados ou usuários que desejam priorizar segurança sobre funcionalidade.

A mudança afeta de forma mais direta softwares que dependem de acessibilidade sem serem ferramentas assistivas. Isso inclui categorias citadas como antivírus, automação, assistentes, monitoramento, limpadores, gerenciadores de senhas e launchers. A presença de um caso de uso legítimo não altera a classificação informada: para a nova regra, essas categorias não entram automaticamente no conjunto de tecnologias assistivas. A consequência técnica é que a autorização pode deixar de existir quando o modo estiver ativo, exigindo desenho alternativo de funcionalidade ou degradação controlada.

O Android 17 também adiciona um seletor de contatos mais granular, permitindo que desenvolvedores solicitem campos específicos da agenda, como telefones ou endereços de e-mail, ou que usuários compartilhem contatos selecionados com um aplicativo de terceiros. Embora esse recurso seja separado da restrição de acessibilidade, ele aponta para a mesma direção de desenho: limitar acesso por escopo e reduzir permissões amplas quando a funcionalidade pode ser atendida por seleção explícita de dados.

• Dispositivos Android 17 Beta 2 com Android Advanced Protection Mode ativo aplicam a nova restrição sobre serviços de acessibilidade.
• Apps não assistivos perdem permissões já concedidas para AccessibilityService quando o modo está ativo.
• Novas concessões de acessibilidade a apps fora da categoria assistiva ficam bloqueadas enquanto a configuração permanece ligada.
• Ferramentas assistivas verificadas, como leitores de tela e entrada por Braille, são tratadas como exceção declarada pela regra.

Hunting e telemetria

Para defesa móvel, a mudança desloca parte da análise para inventário de permissões e comportamento de aplicativos. Equipes que administram dispositivos Android devem identificar quais apps dependem de serviços de acessibilidade e separar ferramentas assistivas reais de softwares que usam a API para automação, monitoramento ou conveniência. Essa distinção é necessária porque a política do Android 17 pode interromper funcionalidades previamente aceitas pelo usuário, mas também pode revelar dependências perigosas que merecem revisão de risco.

Em investigações de malware Android, a permissão de acessibilidade continua sendo um sinal de alta relevância quando aparece em aplicativos que não precisam oferecer suporte assistivo. A telemetria deve priorizar alterações de permissão, tentativas de solicitação de acessibilidade por apps recém-instalados, comportamento de sobreposição de interface e eventos que indiquem interação automatizada com telas sensíveis. A nova restrição não substitui análise de instalação, reputação, Play Protect e controle de origem de aplicativos; ela adiciona uma barreira específica para um abuso conhecido.

Ambientes com gerenciamento corporativo devem correlacionar falhas funcionais após ativação do modo com apps que dependem de acessibilidade. Um aplicativo legítimo que deixa de executar uma rotina pode estar apenas incompatível com o modo, enquanto um aplicativo suspeito que solicita acessibilidade fora de um propósito assistivo deve ser tratado como risco. O ponto operacional é evitar exceções amplas: liberar o modo ou orientar sua desativação para manter uma função secundária pode reabrir o vetor que a mudança pretende reduzir.

• Inventário de apps com permissão de acessibilidade, com classificação entre ferramenta assistiva e uso não assistivo.
• Eventos de revogação de permissão após ativação do Android Advanced Protection Mode.
• Tentativas recorrentes de solicitar acesso a AccessibilityService por apps de automação, limpeza, monitoramento ou origem não confiável.
• Relatos de perda de funcionalidade em gerenciadores de senhas, launchers, assistentes ou ferramentas de segurança que dependiam da API fora do escopo assistivo.

Mitigação

A primeira ação defensiva é preparar inventário e teste de compatibilidade antes da adoção ampla do Android 17 em grupos sensíveis. Organizações que recomendam ou gerenciam Android Advanced Protection Mode devem validar quais aplicativos críticos dependem de acessibilidade e quais possuem alternativa funcional sem essa permissão. O objetivo não é contornar a proteção, mas reduzir dependências de uma API que oferece capacidade ampla de interação com a interface do usuário.

Para usuários de alto risco, a ativação do Android Advanced Protection Mode aumenta a resistência do dispositivo contra classes de ataque que dependem de instalação fora de canais confiáveis, conexão USB com dados habilitados, falta de varredura por Play Protect e abuso de acessibilidade por apps não assistivos. A decisão envolve perda de usabilidade, mas a nova regra deixa claro que a plataforma passa a tratar a permissão de acessibilidade como um recurso sensível demais para permanecer disponível a categorias amplas de aplicativos quando o dispositivo está em estado endurecido.

Desenvolvedores devem consultar o estado do modo por meio de AdvancedProtectionManager e desenhar respostas previsíveis quando recursos de maior risco forem bloqueados. Aplicativos que hoje dependem de acessibilidade para finalidades não assistivas devem revisar arquitetura, reduzir permissões e usar APIs mais específicas quando existirem. No caso de acesso a contatos, o seletor granular do Android 17 oferece um caminho menos invasivo para obter apenas campos ou contatos selecionados, evitando solicitação ampla de leitura da agenda.

• Testar Android 17 Beta 2 com AAPM ativo em um conjunto controlado de dispositivos antes de orientar adoção em massa.
• Remover dependências desnecessárias de AccessibilityService em aplicativos internos ou aprovados pela organização.
• Manter bloqueio de instalação por fontes desconhecidas, restrição de dados via USB e varredura do Play Protect alinhados ao modo de proteção avançada.
• Revisar políticas de suporte para que falhas de conveniência não resultem em orientação genérica para desativar o Android Advanced Protection Mode.
• Preferir seletores e permissões granulares, como o novo seletor de contatos, quando o aplicativo só precisa de campos ou registros específicos.