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

A partir do Android 17, os apps destinados ao Android 17 (nível 37 da API) ou mais recente recebem uma nova implementação sem bloqueio de android.os.MessageQueue. A nova implementação melhora o desempenho e reduz os frames perdidos, mas pode causar falhas em clientes que refletem em campos e métodos particulares de MessageQueue.

Para mais informações, incluindo estratégias de mitigação, consulte Orientação sobre a mudança de comportamento do 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

Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.

For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.

To allow apps to customize this behavior, Android 17 adds a new <domainEncryption> element to the Network Security Configuration file. Developers can use <domainEncryption> within <base-config> or <domain-config> tags to select an ECH mode (for example, "enabled" or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

Permissão de rede local necessária para apps destinados ao Android 17

O Android 17 apresenta a ACCESS_LOCAL_NETWORK permissão de execução para proteger os usuários contra acesso não autorizado à rede local. Como ela se enquadra no grupo de permissões NEARBY_DEVICES, os usuários que já concederam outras permissões NEARBY_DEVICES não recebem a solicitação novamente. Esse novo requisito impede que apps mal-intencionados explorem o acesso irrestrito à rede local para rastreamento de usuários e técnicas de impressão digital. Ao declarar e solicitar essa permissão, seu app pode descobrir e se conectar a dispositivos na rede local (LAN), como dispositivos de casa inteligente ou receptores de transmissão.

Os apps direcionados ao Android 17 (nível 37 da API) ou mais recente agora têm dois caminhos para manter a comunicação com dispositivos LAN: adotar seletores de dispositivos mediados pelo sistema e que preservam a privacidade para ignorar a solicitação de permissão ou solicitar explicitamente essa nova permissão no tempo de execução para manter a comunicação da rede local.

Para mais informações, consulte a documentação da permissão de rede local.

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

A partir do Android 17, o Android vai estender a proteção de OTP por SMS para mensagens SMS padrão (mensagens SMS que contêm um OTP e não usam os formatos WebOTP ou SMS Retriever). Para a maioria dos apps destinados ao Android 17 (nível 37 da API) ou versões mais recentes, essas mensagens SMS não ficam disponíveis até três horas após o recebimento. Esse atraso ajuda a evitar o sequestro de OTPs. Durante esse atraso de três horas, a transmissão SMS_RECEIVED_ACTION é retida e as consultas de banco de dados do provedor de SMS são filtradas. A mensagem SMS fica disponível para esses apps após o atraso.

Alguns apps, como o assistente de SMS padrão, apps complementares de dispositivos conectados etc., são isentos desse atraso. Todos os apps que dependem da leitura de mensagens SMS para extração de senhas únicas precisam migrar para o uso das APIs SMS Retriever ou Consentimento do usuário de SMS para garantir a continuidade da funcionalidade.

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 legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_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

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

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:

Apps that are using these columns from ContactsContract.Data can extract them from ContactsContract.RawContacts instead, by joining with 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

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:

  • The foreground service must have while-in-use (WIU) capabilities.
  • The app must have the exact alarm permission and be interacting with USAGE_ALARM audio streams.

For more information, including mitigation strategies, see Background audio hardening.

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.