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 que tienen como objetivo 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.

Experiencia del usuario y la IU del sistema

Android 17 incluye los siguientes cambios que tienen como objetivo crear una experiencia del usuario más coherente e intuitiva.

Widget de límite de memoria

A partir de Android 17, para las apps que se orientan a Android 17 (nivel de API 37) o versiones posteriores, el sistema aplica un límite de memoria estricto (1.5 * ancho de pantalla * alto de pantalla * 4) en comparación con el uso de memoria combinado de los mapas de bits y los íconos presentes en el paquete de RemoteViews. Si se superan estos límites, se arroja un error IllegalArgumentException fatal y se detiene el proceso de la app.

Para obtener más información, consulta UpdateAppWidget.

Funcionalidad principal

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

Nueva implementación sin bloqueos de MessageQueue

A partir de Android 17, las apps orientadas a Android 17 (nivel de API 37) o versiones posteriores reciben una nueva implementación sin bloqueos 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 de 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 orientan a Android 17 (nivel de API 37) o versiones posteriores no pueden cambiar los campos static final. Si una app intenta cambiar un campo static final con la reflexión, se producirá una IllegalAccessException. Si intentas modificar uno de estos campos a través de las APIs de JNI (como SetStaticLongField()), la app fallará.

Accesibilidad

Android 17 incluye los siguientes cambios para mejorar la accesibilidad.

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

Esta función presenta las nuevas APIs de AccessibilityEvent y TextAttribute para mejorar las descripciones 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 modificado. 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 el texto de redacción en los 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(). Estas apps deben llamar a AccessibilityEvent.setTextChangeTypes() cuando se envían eventos TYPE_VIEW_TEXT_CHANGED. Las apps orientadas a Android 17 (nivel de API 37) que usen el TextView estándar tendrán esta función habilitada de forma predeterminada. (Es decir, TextView se encargará de recuperar datos del IME y establecer tipos de cambios de texto cuando se envíen eventos a los servicios de accesibilidad).

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

Privacidad

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

ECH (Encrypted Client Hello) habilitado

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

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

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 el permiso de red local para las apps que se orientan a Android 17

Android 17 presenta el permiso de tiempo de ejecución ACCESS_LOCAL_NETWORK para proteger a los usuarios del acceso no autorizado a la red local. Como esto se incluye en el grupo de permisos NEARBY_DEVICES existente, no se vuelve a solicitar a los usuarios que ya otorgaron otros permisos de NEARBY_DEVICES. Este nuevo requisito evita que las apps maliciosas aprovechen el acceso sin restricciones a la red local para realizar un seguimiento encubierto de los usuarios y crear huellas digitales. Si declaras y solicitas este permiso, tu app podrá descubrir dispositivos en la red de área local (LAN) y conectarse a ellos, como dispositivos inteligentes para la casa o receptores de transmisión.

Las apps que se orientan a Android 17 (nivel de API 37) o versiones posteriores ahora tienen dos formas de mantener la comunicación con los dispositivos de LAN: adoptar selectores de dispositivos que preserven la privacidad y estén mediados por el sistema para omitir el mensaje de permiso, o solicitar explícitamente este nuevo permiso durante el tiempo de ejecución para mantener la comunicación con la red local.

Para obtener más información, consulta la documentación sobre el permiso de red local.

Ocultar contraseñas de dispositivos físicos

Si una app se orienta a Android 17 (nivel de API 37) o una versión posterior, y el usuario utiliza 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 la contraseña que se escribió para ayudar al usuario a ver si la escribió de forma incorrecta. 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 que se escribe.

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 que se aplique a los mensajes SMS estándar (mensajes SMS que contienen una OTP que no usan los formatos de WebOTP o SMS Retriever). En la mayoría de las apps que se orientan a Android 17 (nivel de API 37) o versiones posteriores, estos mensajes SMS no estarán disponibles hasta tres horas después de su recepción. Esta demora tiene como objetivo ayudar a evitar el robo de OTP. Durante este retraso de tres horas, se retiene la transmisión de SMS_RECEIVED_ACTION y se filtran las consultas de la base de datos del proveedor de SMS. El mensaje SMS estará disponible para estas apps después de la demora.

Algunas apps, como la app de asistencia de SMS predeterminada, las apps complementarias de dispositivos conectados, etcétera, están exentas de esta demora. Todas las apps que dependen de la lectura de mensajes SMS para la extracción de OTP deben pasar a usar las APIs de SMS Retriever o SMS User Consent para garantizar la continuidad de la funcionalidad.

Seguridad

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

Seguridad de la actividad

En Android 17, la plataforma continúa su cambio hacia una arquitectura "segura de forma predeterminada", con la introducción de un conjunto de mejoras diseñadas para mitigar los exploits de gravedad alta, como el phishing, el secuestro de interacciones y los ataques de diputado confundido. Esta actualización requiere que los desarrolladores habiliten de forma explícita los nuevos estándares de seguridad para mantener la compatibilidad de las apps y la protección de los usuarios.

Entre los impactos clave para los desarrolladores, se incluyen los siguientes:

• Refuerzo de BAL y habilitación mejorada: Estamos perfeccionando las restricciones de inicio de actividades en segundo plano (BAL) extendiendo las protecciones a IntentSender. Los desarrolladores deben migrar de la constante heredada MODE_BACKGROUND_ACTIVITY_START_ALLOWED. En su lugar, debes adoptar controles detallados, como MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, que restringe los inicios de actividades a situaciones en las que la app de llamadas es visible, lo que reduce significativamente la superficie de ataque.
• Herramientas de adopción: Los desarrolladores deben usar el modo estricto y las verificaciones de lint actualizadas para identificar patrones heredados y garantizar la preparación para los requisitos futuros del SDK de destino.

Habilitar la CT de forma predeterminada

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

DCL nativo más seguro: C

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

Todos los archivos nativos cargados con System.load() deben marcarse como de solo lectura. De lo contrario, el sistema arroja 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.

Restringe los campos de PII en la vista de datos de CP2

En el caso de las apps que se orientan a Android 17 (nivel de API 37) y versiones posteriores, el proveedor de contactos 2 (CP2) restringe ciertas columnas que contienen información de identificación personal (PII) de la vista de datos. Cuando se habilita este cambio, estas columnas se quitan de la vista de datos para mejorar la privacidad del usuario. Las columnas restringidas incluyen las siguientes:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

Las apps que usan estas columnas de ContactsContract.Data pueden extraerlas de ContactsContract.RawContacts en su lugar, uniéndolas con RAW_CONTACT_ID.

Aplica verificaciones estrictas de SQL en CP2

En el caso de las apps que se orientan a Android 17 (nivel de API 37) y versiones posteriores, el Proveedor de contactos 2 (CP2) aplica una validación estricta de consultas en SQL cuando se accede a la tabla ContactsContract.Data sin el permiso READ_CONTACTS.

Con este cambio, si una app no tiene el permiso READ_CONTACTS, se configuran las opciones StrictColumns y StrictGrammar cuando se consulta la tabla ContactsContract.Data. Si una consulta usa un patrón que no es compatible con estos, se rechazará y se generará una excepción.

Inteligencia

Android 17 incluye los siguientes cambios en la inteligencia del sistema.

Baja de setContentCaptureEnabled

La captura de contenido está habilitada de forma predeterminada en ciertos dispositivos para permitir que las funciones de IA integradas en el dispositivo analicen el contenido de la pantalla y ofrezcan experiencias inteligentes.

A partir de Android 17, el método de la API de ContentCaptureManager.setContentCaptureEnabled(boolean) dejará de estar disponible. En el caso de las apps que se orientan a Android 17 (nivel de API 37) o versiones posteriores, llamar a setContentCaptureEnabled(false) ya no inhabilita la captura de contenido.

Si tu app necesita seguir inhabilitando la captura de contenido o restringir la captura del contenido de la pantalla por parte del sistema, debes realizar la transición para usar el parámetro de diseño de ventana FLAG_SECURE.

Para inhabilitar la captura de contenido, establece la marca FLAG_SECURE en tu ventana, como se muestra en el siguiente ejemplo:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

Para obtener más detalles, consulta la documentación de referencia de WindowManager.LayoutParams.FLAG_SECURE.

Medios

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

Refuerzo del audio en segundo plano

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

Algunas restricciones de audio se aplican a todas las apps. Sin embargo, las restricciones son más estrictas si una app se orienta a 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 estos requisitos:

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

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

Factores de forma de los dispositivos

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>=600 dp)

Introdujimos cambios en la API de la plataforma en Android 16 para ignorar las restricciones de orientación, cambio de tamaño y relación de aspecto en pantallas grandes (sw >= 600 dp) para las apps que se orientan al nivel de API 36 o versiones posteriores. Los desarrolladores tienen la opción de inhabilitar estos cambios con el SDK 36, pero esta inhabilitación ya no estará disponible para las apps que se orienten a Android 17 (nivel de API 37) o versiones posteriores.

Para obtener más información, consulta Se ignoran las restricciones de orientación y cambio de tamaño.

Conectividad

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

Comportamiento coherente de read() de BluetoothSocket para RFCOMM

En el caso de las apps orientadas a Android 17 (nivel de API 37), el método read() de InputStream obtenido de un BluetoothSocket basado en RFCOMM ahora devuelve -1 cuando se cierra el socket o se interrumpe la conexión.

Este cambio hace que el comportamiento del socket de RFCOMM sea coherente con los sockets de LE CoC y se alinee con la documentación estándar de InputStream.read(), que indica que se devuelve -1 cuando se alcanza el final de la transmisión.

Es posible que este cambio afecte a las apps que dependen únicamente de detectar una IOException para salir de un bucle de lectura, por lo que deben actualizar los bucles de lectura de BluetoothSocket para verificar de forma explícita si se devuelve un valor de -1. Esto garantiza que el bucle finalice correctamente cuando el dispositivo remoto se desconecte o se cierre el socket. Para ver un ejemplo de la implementación recomendada, consulta el fragmento de código en la guía Transferencia de datos por Bluetooth.