Como nas versões anteriores, o Android 17 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam exclusivamente a apps destinados ao Android 17 ou versões mais recentes. Se o app for direcionado ao Android 17 ou a versões mais recentes, faça modificações para oferecer suporte a esses comportamentos, quando aplicável.
Consulte também a lista de mudanças de comportamento que afetam todos os apps
executados no Android 17, independente da targetSdkVersion do seu app.
Principal recurso
O Android 17 inclui as seguintes mudanças que modificam ou ampliam vários recursos principais do sistema Android.
Nova implementação sem bloqueio de MessageQueue
从 Android 17 开始,以 Android 17(API 级别 37)
或更高版本为目标平台的应用会收到
android.os.MessageQueue 的新无锁实现。新实现可提升性能并减少丢帧,但可能会破坏反映 MessageQueue 私有字段和方法的客户端。
如需了解详情(包括缓解措施),请参阅 MessageQueue 行为变更指南。
Os campos finais estáticos não podem mais ser modificados
Os apps executados no Android 17 ou mais recente que segmentam o
Android 17 (nível 37 da API) ou mais recente não podem mudar os campos static final. Se
um app tentar mudar um campo static final usando reflexão, isso vai
causar um IllegalAccessException. Tentar modificar um desses campos
usando APIs JNI (como SetStaticLongField()) vai causar falha no app.
Acessibilidade
O Android 17 faz as seguintes mudanças para melhorar a acessibilidade.
Suporte de acessibilidade para digitação complexa no teclado físico do IME
Esse recurso apresenta novas AccessibilityEvent e TextAttribute
APIs para melhorar o feedback falado do leitor de tela para entrada de idiomas CJKV. Os apps de IME CJKV agora podem sinalizar se um candidato de conversão de texto foi selecionado durante a composição de texto. Os apps com campos de edição podem especificar tipos de mudança de texto ao enviar eventos de acessibilidade de texto alterado.
Por exemplo, os apps podem especificar que uma mudança de texto ocorreu durante a composição do texto ou que uma mudança de texto resultou de um commit.
Isso permite que os serviços de acessibilidade, como leitores de tela, ofereçam feedback mais preciso com base na natureza da modificação de texto.
Adoção de apps
Apps de IME:ao definir a composição de texto em campos de edição, os IMEs podem usar
TextAttribute.Builder.setTextSuggestionSelected()para indicar se um candidato de conversão específico foi selecionado.Apps com campos de edição:os apps que mantêm um
InputConnectionpersonalizado podem recuperar dados de seleção de candidatos chamandoTextAttribute.isTextSuggestionSelected(). Esses apps precisam chamarAccessibilityEvent.setTextChangeTypes()ao enviar eventosTYPE_VIEW_TEXT_CHANGED. Os apps destinados ao Android 17 (nível 37 da API) que usam oTextViewpadrão terão esse recurso ativado por padrão. Ou seja, oTextViewvai processar a recuperação de dados do IME e definir tipos de mudança de texto ao enviar eventos para serviços de acessibilidade.Serviços de acessibilidade:os serviços de acessibilidade que processam eventos
TYPE_VIEW_TEXT_CHANGEDpodem chamarAccessibilityEvent.getTextChangeTypes()para identificar a natureza da modificação e ajustar as estratégias de feedback de acordo.
Privacidade
O Android 17 inclui as seguintes mudanças para melhorar a privacidade do usuário.
ECH (Encrypted Client Hello) ativado
O Android 17 apresenta suporte da plataforma para o Encrypted Client Hello (ECH), uma extensão do TLS que aumenta a privacidade do usuário criptografando a indicação de nome do servidor (SNI) no handshake de TLS. Essa criptografia ajuda a impedir que observadores da rede identifiquem facilmente o domínio específico a que seu app está se conectando.
Para apps direcionados ao Android 17 (nível 37 da API) ou mais recentes, o ECH é usado para conexões TLS. O ECH só fica ativo se a biblioteca de rede usada pelo app (por exemplo, HttpEngine, WebView ou OkHttp) tiver suporte integrado para ECH e o servidor remoto também for compatível com o protocolo ECH. Se não for possível negociar o ECH, o cliente enviará uma extensão com conteúdo aleatório (um mecanismo chamado ECH GREASE). Consulte a RFC 9849 para mais detalhes sobre como o ECH GREASE funciona.
Para permitir que os apps personalizem esse comportamento, o Android 17 adiciona um novo
elemento <domainEncryption> ao arquivo de configuração de segurança de rede.
Os desenvolvedores podem usar <domainEncryption> nas tags <base-config> ou <domain-config> para selecionar um modo de ECH (por exemplo, "enabled" ou "disabled") de forma global ou por domínio.
Para mais informações, consulte a documentação do Encrypted Client Hello (em inglês).
Permissão de rede local necessária para apps destinados ao Android 17
Android 17 引入了 ACCESS_LOCAL_NETWORK 运行时权限,以保护用户免遭未经授权的本地网络访问。由于此权限属于现有的 NEARBY_DEVICES 权限组,因此系统不会再次提示已授予其他 NEARBY_DEVICES 权限的用户。这项新要求可防止恶意应用利用不受限制的本地网络访问权限进行隐秘的用户跟踪和指纹识别。通过声明和请求此权限,您的应用可以发现并连接到局域网 (LAN) 中的设备,例如智能家居设备或投屏接收器。
以 Android 17(API 级别 37)或更高版本为目标平台的应用现在可以通过两种方式与 LAN 设备保持通信:采用系统介导的、可保护隐私的设备选择器来跳过权限提示,或者在运行时明确请求此新权限以保持本地网络通信。
如需了解详情,请参阅本地网络权限文档。
Ocultar senhas de dispositivos físicos
Se um app for direcionado ao Android 17 (nível 37 da API) ou versões mais recentes e o usuário estiver usando
um dispositivo de entrada físico (por exemplo, um teclado externo), o sistema
operacional Android vai aplicar a nova configuração show_passwords_physical a todos os
caracteres no campo de senha. Por padrão, essa configuração oculta todos os caracteres
da senha.
O sistema Android mostra o último caractere digitado para ajudar o usuário a verificar se ele digitou a senha errada. No entanto, isso é muito menos necessário com teclados externos maiores. Além disso, dispositivos com teclados externos geralmente têm telas maiores, o que aumenta o risco de alguém ver a senha digitada.
Se o usuário estiver usando a tela sensível ao toque do dispositivo, o sistema vai aplicar a nova configuração de
show_passwords_touch.
Proteção de OTP para mensagens SMS padrão
从 Android 17 开始,Android 将扩展其短信验证码保护功能,以适用于标准短信(包含验证码但不使用 WebOTP 或 SMS Retriever 格式的短信)。对于以 Android 17(API 级别 37)或更高版本为目标平台的应用,这些短信在收到后三小时内不会提供。此延迟旨在帮助防止动态密码劫持。在这三小时的延迟期间,系统会保留
SMS_RECEIVED_ACTION广播,并过滤
短信提供商数据库查询。延迟结束后,这些应用即可使用短信。
某些应用(例如默认短信助理应用、已连接的设备配套应用等)不受此延迟限制。所有依赖于读取短信 来提取动态密码的应用都应改用 SMS Retriever 或 SMS User Consent API,以确保功能持续可用。
Segurança
O Android 17 faz as seguintes melhorias na segurança de dispositivos e apps.
Segurança de atividade
In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.
Key impacts for developers include:
- BAL hardening & improved opt-in: We are refining Background Activity
Launch (BAL) restrictions by extending protections to
IntentSender. Developers must migrate away from the legacyMODE_BACKGROUND_ACTIVITY_START_ALLOWEDconstant. Instead, you should adopt granular controls likeMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface. - Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.
Ativar a CT por padrão
如果应用以 Android 17(API 级别 37)或更高版本为目标平台,则默认启用证书透明度 (CT)。(在 Android 16 上,CT 可用,但应用必须选择启用。)
DCL nativa mais segura: C
如果您的应用以 Android 17(API 级别 37)或更高版本为目标平台,则 Android 14 中针对 DEX 和 JAR 文件引入的更安全的动态代码加载 (DCL) 保护功能现在也适用于原生库。
使用 System.load() 加载的所有原生文件都必须标记为只读。否则,系统会抛出 UnsatisfiedLinkError。
我们建议应用尽可能避免动态加载代码,因为这样做会大大增加应用因代码注入或代码篡改而遭到入侵的风险。
Restringir campos de PII na visualização de dados do CP2
Para apps destinados ao Android 17 (nível 37 da API) e versões mais recentes, o provedor de contatos 2 (CP2) restringe determinadas colunas que contêm informações de identificação pessoal (PII) da visualização de dados. Quando essa mudança é ativada, essas colunas são removidas da visualização de dados para melhorar a privacidade do usuário. As colunas restritas incluem:
Os apps que usam essas colunas de ContactsContract.Data
podem extraí-las de ContactsContract.RawContacts
em vez disso, fazendo a junção com RAW_CONTACT_ID.
Aplicar verificações rigorosas de SQL no CP2
For apps targeting Android 17 (API level Android 17 (API level 37)) and
higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when
the ContactsContract.Data table is accessed without
READ_CONTACTS permission.
With this change, if an app doesn't have READ_CONTACTS
permission, StrictColumns and
StrictGrammar options are set when querying
the ContactsContract.Data table. If a query
uses a pattern that isn't compatible with these, it will be
rejected and cause an exception to be thrown.
Mídia
O Android 17 inclui as seguintes mudanças no comportamento de mídia.
Reforço da proteção de áudio em segundo plano
从 Android 17 开始,音频框架对后台音频互动(包括音频播放、音频焦点请求和音量更改 API)强制执行限制,以确保这些更改是由用户有意启动的。
部分音频限制适用于所有应用。不过,如果应用以 Android 17(API 级别 37)为目标平台,则限制会更加严格。如果这些应用在后台运行时与音频互动,则必须有前台服务正在运行。此外,应用还必须满足以下一项或两项要求:
- 前台服务必须具有仅在使用时授予的权限 (WIU)。
- 应用必须具有精确闹钟权限,并且正在与
USAGE_ALARM音频流互动。
如需了解详情(包括缓解措施),请参阅后台音频安全加固。
Formatos de dispositivos
O Android 17 inclui as seguintes mudanças para melhorar a experiência do usuário em vários tamanhos de dispositivos e formatos.
Mudanças na API Platform para ignorar restrições de orientação, redimensionamento e proporção em telas grandes (sw>=600 dp)
Introduzimos mudanças na API Platform no Android 16 para ignorar restrições de orientação, proporção e redimensionamento em telas grandes (sw >= 600 dp) para apps destinados ao nível 36 da API ou mais recente. Os desenvolvedores têm a opção de desativar essas mudanças com o SDK 36, mas essa opção não estará mais disponível para apps destinados ao Android 17 (nível da API 37) ou mais recente.
Para mais informações, consulte Restrições de orientação e redimensionamento são ignoradas.
Conectividade
O Android 17 introduz a seguinte mudança para melhorar a consistência e
alinhar com o comportamento padrão do Java InputStream para soquetes RFCOMM Bluetooth.
Comportamento consistente de BluetoothSocket read() para RFCOMM
Para apps direcionados ao Android 17 (nível da API 37), o
read() método do InputStream recebido de um
BluetoothSocket baseado em RFCOMM agora retorna -1 quando o
soquete é fechado ou a conexão é interrompida.
Essa mudança torna o comportamento do soquete RFCOMM consistente com os soquetes LE CoC e
está alinhada com a documentação padrão InputStream.read(), que afirma que -1 é retornado quando o fim do fluxo é
atingido.
Os apps que dependem apenas da captura de uma IOException para sair de uma repetição de leitura podem ser afetados por essa mudança e precisam atualizar as repetições de leitura do BluetoothSocket para verificar explicitamente um valor de retorno de -1. Isso garante que o loop seja encerrado corretamente quando o dispositivo remoto se desconectar ou o soquete for fechado. Para um
exemplo da implementação recomendada, consulte o
snippet de código no guia Transferir dados Bluetooth.