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
Beginning with Android 17, apps targeting Android 17 (API level 37)
or higher receive a new lock-free implementation of
android.os.MessageQueue. The new implementation improves performance and
reduces missed frames, but may break clients that reflect on MessageQueue
private fields and methods.
For more information, including mitigation strategies, see MessageQueue behavior change guidance.
Os campos finais estáticos não podem mais ser modificados
Apps running on Android 17 or higher that target
Android 17 (API level 37) or higher cannot change static final fields. If
an app attempts to change a static final field by using reflection, it will
cause an IllegalAccessException. Attempting to modify one of these fields
through JNI APIs (such as SetStaticLongField()) will cause the app to crash.
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
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
Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission
to protect users from unauthorized local network access. Because this falls
under the existing NEARBY_DEVICES permission group, users who have already
granted other NEARBY_DEVICES permissions aren't prompted again. This new
requirement prevents malicious apps from exploiting unrestricted local network
access for covert user tracking and fingerprinting. By declaring and requesting
this permission, your app can discover and connect to devices on the local area
network (LAN), such as smart home devices or casting receivers.
Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.
For more information, see the Local network permission documentation.
Ocultar senhas de dispositivos físicos
If an app targets Android 17 (API level 37) or higher and the user is using
a physical input device (for example, an external keyboard), the Android
operating system applies the new show_passwords_physical setting to all
characters in the password field. By default, that setting hides all password
characters.
The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.
If the user is using the device's touchscreen, the system applies the new
show_passwords_touch setting.
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
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 legadaMODE_BACKGROUND_ACTIVITY_START_ALLOWED. Em vez disso, adote controles granulares, comoMODE_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
If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.
All native files loaded using System.load() must be marked as read-only.
Otherwise, the system throws UnsatisfiedLinkError.
We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
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
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_ALARMaudio 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
For apps targeting Android 17 (API level 37), the
read() method of the InputStream obtained from an
RFCOMM-based BluetoothSocket now returns -1 when the
socket is closed or the connection is dropped.
This change makes RFCOMM socket behavior consistent with LE CoC sockets and
aligns with the standard InputStream.read()
documentation, which states that -1 is returned when the end of the stream is
reached.
Apps that rely solely on catching an IOException to break out of a read loop may
be impacted by this change and should update the BluetoothSocket read loops to
explicitly check for a return value of -1. This ensures the loop terminates
correctly when the remote device disconnects or the socket is closed. For an
example of the recommended implementation, see the
code snippet in the Transfer Bluetooth data
guide.