Cambios de comportamiento: todas las apps

La plataforma de Android 17 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios de comportamiento se aplican a todas las apps cuando se ejecutan en Android 17, independientemente de targetSdkVersion. Debes probar tu app y, luego, modificarla según corresponda para admitir estos cambios.

Asegúrate también de consultar la lista de cambios de comportamiento que solo afectan a las apps orientadas a Android 17.

Nota: En esta página, se enumeran algunos de los cambios más importantes. Para obtener información más detallada, consulta las notas de la versión de Android 17.

Funcionalidad principal

Android 17 (nivel de API 37) incluye los siguientes cambios que modifican o expanden varias capacidades principales del sistema Android.

Límites de memoria de la app

Android 17 引入了基于设备总 RAM 的应用内存限制，旨在为您的应用和 Android 用户打造更稳定、更具确定性的环境。在 Android 17 中，限制设置得较为保守，目的是建立系统基准，在极端内存泄漏和其他异常情况触发系统范围的不稳定性（导致界面卡顿、耗电过快和应用被终止）之前，先针对这些情况。虽然我们预计对绝大多数 应用会话的影响很小，但我们建议遵循以下内存最佳实践， 包括建立内存基准。

您可以通过在 ApplicationExitInfo 中调用 getDescription 来确定应用会话是否受到影响；如果您的应用受到 影响，退出原因将为 REASON_OTHER 并且 说明将包含字符串 "MemoryLimiter:AnonSwap" 以及 其他信息。您还可以使用 基于触发器的分析（使用 TRIGGER_TYPE_ANOMALY）来获取在达到 内存限制时收集的堆转储。

Android Studio 性能分析器中的 LeakCanary 任务。

为了帮助您查找内存泄漏，Android Studio Panda 直接在 Android Studio 性能分析器中添加了 LeakCanary 集成，作为 IDE 中特定任务，并与您的源代码完全集成。

Privacidad

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

Protección contra OTP por SMS

A partir de Android 17, Android amplía su protección para los mensajes SMS que contienen contraseñas de un solo uso (OTP).

En versiones anteriores de Android, esta protección se centraba principalmente en el formato de SMS Retriever. La entrega de mensajes que contenían un hash de SMS Retriever se retrasó durante tres horas para la mayoría de las apps. Sin embargo, ciertas apps (como el controlador de SMS predeterminado) estaban exentas del retraso, y la app que poseía el hash también estaba exenta.

A partir de Android 17, la protección también se aplica a los mensajes de formato WebOTP. Si una app tiene permiso para leer mensajes SMS, pero no es el destinatario previsto de un mensaje WebOTP (según lo determinado por la verificación de dominio), la app no podrá acceder al mensaje hasta tres horas después de que lo reciba. El objetivo de este cambio es mejorar la seguridad del usuario, ya que garantiza que solo las apps asociadas con el dominio mencionado en el mensaje puedan leer el código de verificación de forma programática.

Durante este retraso 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 del retraso. Este cambio se aplica a todas las apps, independientemente de su nivel de API objetivo.

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

Nota: Si tu app se orienta a Android 17 (nivel de API 37) o versiones posteriores, esta protección también se extiende a los mensajes SMS estándar. Para obtener más información, consulta Protección de OTP para mensajes SMS estándar en la documentación de Cambios en el comportamiento: apps orientadas a Android 17.

Seguridad

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

Plan de baja de usesClearTraffic

En una versión futura, planeamos dar de baja el elemento usesCleartextTraffic. Las apps que necesitan realizar conexiones sin encriptar (HTTP) deben migrar al uso de un archivo de configuración de seguridad de redes, que te permite especificar a qué dominios tu app necesita realizar conexiones de texto simple.

Ten en cuenta que los archivos de configuración de seguridad de redes solo se admiten en los niveles de API 24 y posteriores. Si tu app tiene un nivel de API mínimo inferior a 24, debes hacer ambas de las siguientes acciones:

• Establece el atributo usesCleartextTraffic en true.
• Usa un archivo de configuración de red.

Si el nivel mínimo de API de tu app es 24 o superior, puedes usar un archivo de configuración de red y no necesitas establecer usesCleartextTraffic.

Restringe las concesiones de URI implícitas

目前，如果应用使用具有操作 ACTION_SEND、 SEND_MULTIPLE、 或 ACTION_IMAGE_CAPTURE的 URI 启动 intent，系统会自动向目标应用授予读取和 写入 URI 权限。我们计划在 Android 18 中更改此行为。因此，我们建议应用显式授予相关 URI 权限，而不是依赖系统来授予这些权限。

Límites de keystore por app

Las apps deben evitar crear una cantidad excesiva de claves en Android Keystore, ya que es un recurso compartido para todas las apps del dispositivo. A partir de Android 17, el sistema aplica un límite en la cantidad de claves que puede tener una app. El límite es de 50,000 claves para apps que no son del sistema orientadas a Android 17 (nivel de API 37) o versiones posteriores, y de 200,000 claves para todas las demás apps. Las apps del sistema tienen un límite de 200,000 claves, independientemente del nivel de API al que se orienten.

Si una app intenta crear claves más allá del límite, la creación falla con una KeyStoreException. La cadena de mensajes de la excepción contiene información sobre el límite de claves. Si la app llama a getNumericErrorCode() en la excepción, el valor que se muestra depende del nivel de API al que se oriente la app:

• Apps orientadas a Android 17 (nivel de API 37) o versiones posteriores: getNumericErrorCode() muestra el nuevo valor ERROR_TOO_MANY_KEYS.
• Todas las otras apps: getNumericErrorCode() muestra ERROR_INCORRECT_USAGE.

Bloquea el tráfico de bucle invertido entre perfiles sincronizados

A partir de Android 17, el tráfico de bucle invertido entre perfiles ya no se permite de forma predeterminada. El tráfico de bucle invertido dentro del mismo perfil no se ve afectado. Este cambio se aplica a todas las apps que se ejecutan en Android 17 o versiones posteriores, independientemente del nivel de API al que se oriente la app.

Experiencia del usuario y IU del sistema

Android 17 incluye los siguientes cambios destinados a crear una experiencia del usuario más coherente e intuitiva.

Restablece la visibilidad predeterminada del IME después de la rotación

A partir de Android 17, cuando cambia la configuración del dispositivo (por ejemplo, a través de la rotación) y la app no lo controla, no se restablece la visibilidad anterior del IME.

Si tu app experimenta un cambio de configuración que no controla y necesita que el teclado esté visible después del cambio, debes solicitarlo de forma explícita. Puedes realizar esta solicitud de una de las siguientes maneras:

• Establece el atributo android:windowSoftInputMode en stateAlwaysVisible.
• Solicita el teclado en pantalla de forma programática en el método onCreate() de tu actividad o agrega el método onConfigurationChanged().

Intervención humana

Android 17 incluye los siguientes cambios que afectan la forma en que las apps interactúan con dispositivos de entrada humana, como teclados y paneles táctiles.

Los paneles táctiles entregan eventos relativos de forma predeterminada durante la captura del puntero

A partir de Android 17, si una app solicita la captura del puntero con View.requestPointerCapture() y el usuario usa un panel táctil, el sistema reconoce el movimiento del puntero y los gestos de desplazamiento de los toques del usuario y los informa a la app de la misma manera que los movimientos del puntero y la rueda de desplazamiento de un mouse capturado. En la mayoría de los casos, esto elimina la necesidad de que las apps que admiten mouse capturados agreguen una lógica de control especial para los paneles táctiles. Para obtener más detalles, consulta la documentación de View.POINTER_CAPTURE_MODE_RELATIVE.

Anteriormente, el sistema no intentaba reconocer los gestos del panel táctil y, en cambio, entregaba las ubicaciones absolutas y sin procesar de los dedos a la app en un formato similar a los toques de la pantalla táctil. Si una app aún requiere estos datos absolutos, debe llamar al nuevo View.requestPointerCapture(int) método con View.POINTER_CAPTURE_MODE_ABSOLUTE en su lugar.

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, incluidas 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.

Si la app intenta llamar a las APIs de audio mientras no se encuentra en un ciclo de vida válido, las APIs de reproducción de audio y de cambio de volumen fallan de forma silenciosa sin generar una excepción ni proporcionar un mensaje de falla. La API de enfoque de audio falla con el código de resultado AUDIOFOCUS_REQUEST_FAILED.

Nota: Las restricciones son más estrictas si una app se orienta a Android 17 (nivel de API 37). En el caso de estas apps, el servicio en primer plano debe tener capacidades de uso mientras está en uso (WIU), a menos que la app tenga el permiso de alarma exacto y esté interactuando con transmisiones de audio USAGE_ALARM.

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

Conectividad

Android 17 incluye los siguientes cambios para mejorar la conectividad del dispositivo.

Revinculación autónoma para pérdidas de vinculación de Bluetooth

Android 17 introduce el nuevo emparejamiento autónomo, una mejora a nivel del sistema diseñada para resolver automáticamente la pérdida de vinculación de Bluetooth.

Anteriormente, si se perdía la vinculación, los usuarios debían navegar manualmente a Configuración para desvincular y, luego, volver a vincular el periférico. Esta función se basa en la mejora de seguridad de Android 16, ya que permite que el sistema restablezca las vinculaciones en segundo plano sin requerir que los usuarios naveguen manualmente a Configuración para desvincular y volver a vincular los periféricos.

Si bien la mayoría de las apps no requerirán cambios de código, los desarrolladores deben tener en cuenta los siguientes cambios de comportamiento en la pila de Bluetooth:

• Nuevo contexto de vinculación: El objeto ACTION_PAIRING_REQUEST ahora incluye el objeto EXTRA_PAIRING_CONTEXT adicional, que permite que las apps distingan entre una solicitud de vinculación estándar y un intento de revinculación autónomo iniciado por el sistema.
• Actualizaciones condicionales de claves: Las llaves de seguridad existentes solo se reemplazarán si la nueva vinculación se realiza correctamente y la nueva conexión cumple o supera el nivel de seguridad de la vinculación anterior.
• Sincronización de intención modificada: La intención ACTION_KEY_MISSING ahora se transmite solo si falla el intento de volver a vincular de forma autónoma. Esto reduce el manejo de errores innecesarios en la app si el sistema recupera correctamente la vinculación en segundo plano.
• Notificación del usuario: El sistema administra el nuevo vínculo a través de nuevas notificaciones y diálogos de la IU. Se les pedirá a los usuarios que confirmen el intento de volver a vincular los dispositivos para asegurarse de que sepan que se restableció la conexión.

Los fabricantes de dispositivos periféricos y los desarrolladores de apps complementarias deben verificar que el hardware y la app controlen las transiciones de vinculación sin inconvenientes. Para probar este comportamiento, simula una pérdida de vinculación remota con cualquiera de los siguientes métodos:

• Cómo quitar manualmente la información de vinculación del dispositivo periférico
• Desvincula manualmente el dispositivo en Configuración > Dispositivos conectados.