Cambios en el comportamiento: apps orientadas a Android 17 o versiones posteriores

Al igual que las versiones anteriores, Android 17 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 17 o versiones posteriores. Si tu app está orientada a Android 17 o versiones posteriores, debes modificarla para que admita estos comportamientos, cuando corresponda.

Asegúrate de revisar también la lista de cambios en el comportamiento que afectan a todas las apps que se ejecutan en Android 17, independientemente de targetSdkVersion de la app.

Funcionalidad principal

Android 17 incluye los siguientes cambios que modifican o expanden varias capacidades principales del sistema Android.

Nueva implementación sin bloqueo de MessageQueue

A partir de Android 17, las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores reciben una nueva implementación sin bloqueo de android.os.MessageQueue. La nueva implementación mejora el rendimiento y reduce los fotogramas perdidos, pero puede interrumpir los clientes que reflejan los campos y métodos privados de MessageQueue.

Para obtener más información, incluidas las estrategias de mitigación, consulta la guía sobre el cambio de comportamiento de MessageQueue.

Los campos finales estáticos ahora no se pueden modificar

Las apps que se ejecutan en Android 17 o versiones posteriores y que se segmentan para Android 17 (nivel de API 37) o versiones posteriores no pueden cambiar los campos de static final. Si una app intenta cambiar un campo static final con la reflexión, se producirá un IllegalAccessException. Si intentas modificar uno de estos campos a través de las APIs de JNI (como SetStaticLongField()), la app fallará.

Accesibilidad

Android 17 realiza los siguientes cambios para mejorar la accesibilidad.

Compatibilidad de accesibilidad para la escritura compleja del teclado físico del IME

Esta función presenta nuevas APIs de AccessibilityEvent y TextAttribute para mejorar los comentarios por voz del lector de pantalla para la entrada de idiomas CJKV. Las apps de IME de CJKV ahora pueden indicar si se seleccionó un candidato de conversión de texto durante la composición de texto. Las apps con campos de edición pueden especificar tipos de cambios de texto cuando envían eventos de accesibilidad de texto cambiado. Por ejemplo, las apps pueden especificar que se produjo un cambio de texto durante la composición de texto o que un cambio de texto se produjo a partir de una confirmación. Esto permite que los servicios de accesibilidad, como los lectores de pantalla, proporcionen comentarios más precisos según la naturaleza de la modificación del texto.

Adopción de apps

  • Apps de IME: Cuando se configura la composición de texto en campos de edición, los IME pueden usar TextAttribute.Builder.setTextSuggestionSelected() para indicar si se seleccionó un candidato de conversión específico.

  • Apps con campos de edición: Las apps que mantienen un InputConnection personalizado pueden recuperar datos de selección de candidatos llamando a TextAttribute.isTextSuggestionSelected(). Luego, estas apps deben llamar a AccessibilityEvent.setTextChangeTypes() cuando envíen eventos TYPE_VIEW_TEXT_CHANGED. Las apps que se segmentan para Android 17 (nivel de API 37) y que usan el TextView estándar tendrán esta función habilitada de forma predeterminada. (Es decir, TextView controlará la recuperación de datos del IME y establecerá tipos de cambio de texto cuando envíe eventos a los servicios de accesibilidad).

  • Servicios de accesibilidad: Los servicios de accesibilidad que procesan eventos de TYPE_VIEW_TEXT_CHANGED pueden llamar a AccessibilityEvent.getTextChangeTypes() para identificar la naturaleza de la modificación y ajustar sus estrategias de comentarios en consecuencia.

Privacidad

Android 17 incluye los siguientes cambios para mejorar la privacidad del usuario.

ECH (Encrypted Client Hello) habilitado

Android 17 introduce compatibilidad con la plataforma para Encrypted Client Hello (ECH), una extensión de TLS que mejora la privacidad del usuario encriptando la indicación del nombre del servidor (SNI) en el protocolo de enlace TLS. Este encriptado ayuda a evitar que los observadores de la red identifiquen fácilmente el dominio específico al que se conecta tu app.

En el caso de las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores, se usa ECH para las conexiones TLS. El ECH solo está activo si la biblioteca de redes que usa la app (por ejemplo, HttpEngine, WebView o OkHttp) tiene compatibilidad integrada con el ECH y el servidor remoto también admite el protocolo ECH. Si no se puede negociar ECH, el cliente envía una extensión de ECH con contenido aleatorio (un mecanismo llamado ECH GREASE). Consulta RFC 9849 para obtener más detalles sobre cómo funciona ECH GREASE.

Para permitir que las apps personalicen este comportamiento, Android 17 agrega un nuevo elemento <domainEncryption> al archivo de configuración de seguridad de red. Los desarrolladores pueden usar <domainEncryption> dentro de las etiquetas <base-config> o <domain-config> para seleccionar un modo de ECH (por ejemplo, "enabled" o "disabled") de forma global o por dominio.

Para obtener más información, consulta la documentación de Encrypted Client Hello.

Se requiere permiso de red local para las apps orientadas a 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 contraseñas de dispositivos físicos

Si una app se orienta a Android 17 (nivel de API 37) o versiones posteriores, y el usuario usa un dispositivo de entrada físico (por ejemplo, un teclado externo), el sistema operativo Android aplica el nuevo parámetro de configuración show_passwords_physical a todos los caracteres del campo de contraseña. De forma predeterminada, ese parámetro de configuración oculta todos los caracteres de la contraseña.

El sistema Android muestra el último carácter de contraseña escrito para ayudar al usuario a ver si escribió mal la contraseña. Sin embargo, esto es mucho menos necesario con teclados externos más grandes. Además, los dispositivos con teclados externos suelen tener pantallas más grandes, lo que aumenta el peligro de que alguien vea la contraseña escrita.

Si el usuario usa la pantalla táctil del dispositivo, el sistema aplica el nuevo parámetro de configuración show_passwords_touch.

Protección de OTP para mensajes SMS estándar

A partir de Android 17, Android extiende su protección de OTP por SMS para aplicarla a los mensajes SMS estándar (mensajes SMS que contienen una OTP que no usa los formatos WebOTP o SMS Retriever). En el caso de la mayoría de las apps orientadas a Android 17 (nivel de API 37) o versiones posteriores, estos mensajes SMS no están disponibles hasta tres horas después de recibirlos. El objetivo de esta demora es evitar el secuestro de OTP. Durante esta demora de tres horas, se retiene la transmisión SMS_RECEIVED_ACTION y se filtran las consultas de la base de datos del proveedor de SMS. El mensaje SMS está disponible para estas apps después de la demora.

Ciertas apps, como la app de asistente de SMS predeterminada, las apps complementarias de dispositivos conectados, etc., están exentas de esta demora. Todas las apps que dependen de la lectura de mensajes SMS para la extracción de OTP deben hacer la transición al uso de las APIs de SMS Retriever o SMS User Consent para garantizar la continuidad de la funcionalidad.

Seguridad

Android 17 realiza las siguientes mejoras en la seguridad de los dispositivos y las apps.

Seguridad de la actividad

在 Android 17 中，平台继续向“默认安全”架构转变，引入了一系列旨在缓解网络钓鱼、互动劫持和混淆代理攻击等高严重性漏洞的增强功能。此更新要求开发者明确选择启用新的安全标准，以保持应用兼容性和用户保护。

对开发者的主要影响包括：

  • BAL 安全加固和改进的选择启用： 我们正在优化后台活动启动 (BAL) 限制，方法是将保护范围扩展到 IntentSender。开发者必须从旧版 MODE_BACKGROUND_ACTIVITY_START_ALLOWED 常量迁移。相反，您应 采用精细控制，例如 MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE，它将 活动启动限制为调用应用可见的场景，从而显著 缩小攻击面。
  • 采用工具： 开发者应利用严格模式和更新后的 lint 检查来识别旧版模式，并确保为未来的目标 SDK 要求做好准备。

Habilitar CT de forma predeterminada

Si una app se orienta a Android 17 (nivel de API 37) o versiones posteriores, la transparencia de certificados (CT) está habilitada de forma predeterminada. (En Android 16, la CT está disponible, pero las apps debían habilitarla).

DCL-C nativo más seguro

Si tu app está orientada a Android 17 (nivel de API 37) o versiones posteriores, la protección de carga dinámica de códigos (DCL) más segura que se introdujo en Android 14 para archivos DEX y JAR ahora se extiende a las bibliotecas nativas.

Todos los archivos nativos cargados con System.load() se deben marcar como de solo lectura. De lo contrario, el sistema arrojará UnsatisfiedLinkError.

Recomendamos que las apps eviten la carga dinámica de códigos siempre que sea posible, ya que de esta manera aumenta, en gran medida, el riesgo de que una app pueda verse comprometida por la inserción o la manipulación de código.

Restringir los campos de PII en la vista de datos de 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 verificaciones estrictas de SQL en 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.

Medios

Android 17 incluye los siguientes cambios en el comportamiento de los medios.

Protección de audio en segundo plano

A partir de Android 17, el framework de audio aplica restricciones en las interacciones de audio en segundo plano, como la reproducción de audio, las solicitudes de enfoque de audio y las APIs de cambio de volumen, para garantizar que el usuario inicie estos cambios de forma intencional.

Se aplican algunas restricciones de audio a todas las apps. Sin embargo, las restricciones son más estrictas si una app se segmenta para Android 17 (nivel de API 37). Si una de estas apps interactúa con el audio mientras está en segundo plano, debe tener un servicio en primer plano en ejecución. Además, la app debe cumplir con uno o ambos de los siguientes requisitos:

  • El servicio en primer plano debe tener capacidades de permiso durante el uso (WIU).
  • La app debe tener el permiso de alarma exacta y estar interactuando con transmisiones de audio de USAGE_ALARM.

Para obtener más información, incluidas las estrategias de mitigación, consulta Protección de audio en segundo plano.

Factores de forma del dispositivo

Android 17 incluye los siguientes cambios para mejorar la experiencia del usuario en una variedad de tamaños y factores de forma de dispositivos.

Cambios en la API de la plataforma para ignorar las restricciones de orientación, cambio de tamaño y relación de aspecto en pantallas grandes (sw>=600dp)

我们在 Android 16 中引入了平台 API 变更，以 忽略屏幕方向、 宽高比和尺寸调整能力限制（针对大型屏幕，sw >= 600dp），适用于面向 API 级别 36 或更高级别的应用。开发者可以选择使用 SDK 36 退出这些变更，但对于面向 Android 17（API 级别 37）或更高级别的应用，此退出选项将不再可用。

如需了解详情，请参阅忽略屏幕方向和尺寸调整能力限制。

Conectividad

Android 17 introduce el siguiente cambio para mejorar la coherencia y alinearse con el comportamiento estándar de InputStream de Java para los sockets RFCOMM de Bluetooth.

Comportamiento coherente 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.