Mudanças de comportamento: apps destinados ao Android 17 ou versões mais recentes

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

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

  • IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

  • Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

  • Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

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

如果应用以 Android 17(API 级别 37)或更高版本为目标平台,并且用户使用的是实体输入设备(例如外接键盘),Android 操作系统会对密码字段中的所有字符应用新的 show_passwords_physical 设置。默认情况下,该设置会隐藏所有密码字符。

Android 系统会显示用户最后输入的密码字符,以帮助用户查看是否输错了密码。不过,对于较大的外接键盘,此功能就没那么必要了。此外,配备外接键盘的设备通常具有较大的显示屏,这会增加他人看到输入密码的风险。

如果用户使用的是设备触摸屏,系统会应用新的 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 RetrieverSMS User Consent API,以确保功能持续可用。

Segurança

O Android 17 faz as seguintes melhorias na segurança de dispositivos e apps.

Segurança de atividade

No Android 17, a plataforma continua a transição para uma arquitetura "segura por padrão", introduzindo um conjunto de melhorias projetadas para mitigar exploits de alta gravidade, como phishing, sequestro de interação e ataques de vice-delegado. Essa atualização exige que os desenvolvedores ativem explicitamente os novos padrões de segurança para manter a compatibilidade do app e a proteção do usuário.

Os principais impactos para os desenvolvedores incluem:

  • Reforço da proteção do BAL e ativação aprimorada: estamos aprimorando as restrições de inicialização de atividades em segundo plano (BAL, na sigla em inglês) estendendo as proteções ao IntentSender. Os desenvolvedores precisam migrar da constante legada MODE_BACKGROUND_ACTIVITY_START_ALLOWED. Em vez disso, adote controles granulares, como MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, que restringe os inícios de atividades a cenários em que o app de chamada está visível, reduzindo significativamente a superfície de ataque.
  • Ferramentas de adoção:os desenvolvedores precisam usar o modo estrito e as verificações de lint atualizadas para identificar padrões legados e garantir a preparação para os requisitos futuros do SDK de destino.

Ativar a CT por padrão

Se um app for destinado ao Android 17 (nível 37 da API) ou mais recente, a transparência de certificados (CT, na sigla em inglês) será ativada por padrão. No Android 16, a CT está disponível, mas os apps precisam ativar o recurso.

DCL nativa mais segura: C

Se o app for direcionado ao Android 17 (nível 37 da API) ou versões mais recentes, a proteção de carregamento dinâmico de código (DCL) mais seguro introduzida no Android 14 para arquivos DEX e JAR agora será estendida a bibliotecas nativas.

Todos os arquivos nativos carregados usando System.load() precisam ser marcados como somente leitura. Caso contrário, o sistema vai gerar UnsatisfiedLinkError.

Recomendamos que os apps evitem carregar código dinamicamente sempre que possível, porque isso aumenta muito o risco de comprometimento do app por injeção ou adulteração de código.

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

Em apps destinados ao Android 17 (nível 37 da API) e versões mais recentes, o provedor de contatos 2 (CP2) aplica uma validação rigorosa de consultas SQL quando a tabela ContactsContract.Data é acessada sem a permissão READ_CONTACTS.

Com essa mudança, se um app não tiver a permissão READ_CONTACTS, as opções StrictColumns e StrictGrammar serão definidas ao consultar a tabela ContactsContract.Data. Se uma consulta usar um padrão incompatível com esses, ela será rejeitada e vai gerar uma exceção.

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.