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.

Funcionalidad principal

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

Límites a la memoria de las apps

Android 17 incluye límites a la memoria de las apps según la RAM total del dispositivo para crear un entorno más estable y determinista para tus apps y los usuarios de Android. Estos límites se centran en las pérdidas de memoria y otros valores atípicos antes de que provoquen inestabilidad en todo el sistema, lo que genera tartamudeo en la IU, un mayor consumo de batería y la finalización de las apps. Si bien anticipamos un impacto mínimo en la gran mayoría de las sesiones de apps, recomendamos las siguientes prácticas recomendadas de memoria, incluido el establecimiento de una línea de base para la memoria.

Puedes determinar si tu sesión de app se vio afectada llamando a getDescription en ApplicationExitInfo. Si tu app se vio afectada, el motivo de salida será REASON_OTHER y la descripción contendrá la cadena "MemoryLimiter:AnonSwap" junto con otra información. También puedes usar la generación de perfiles basada en activadores con TRIGGER_TYPE_ANOMALY para obtener volcados de montón que se recopilan cuando se alcanza el límite de memoria.

En la documentación Cómo administrar la memoria de tu app, se proporciona información para ayudarte a diagnosticar los problemas de memoria de tu app y optimizar su consumo de recursos.

Prueba el comportamiento de tu app en las restricciones de memoria

Puedes usar Android Debug Bridge (adb) para ajustar o inhabilitar los límites de memoria en cualquier dispositivo que los imponga. El comando de shell am proporciona tres subcomandos para ajustar los límites de memoria. (Estos comandos no tienen ningún efecto en un dispositivo que no impone límites de memoria).

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Indica al limitador de memoria que ignore algunos o todos los procesos. Si pasas un UID (ID de usuario de Android), se le indica al limitador de memoria que ignore la aplicación en todos los procesos asociados con ese UID. También puedes pasar all (ignorar todas las apps) o none (no ignorar ninguna app). Si pasas none, se anularán todas las llamadas anteriores a am memory-limiter ignore.

Si le indicas al limitador de memoria que ignore un UID, puedes aplicar un límite de memoria manual a un proceso dentro de la app llamando a am memory-limiter manual.

manual

Indica al sistema que imponga una restricción de memoria en el proceso con el PID especificado (ID del proceso). La restricción de memoria se especifica como un número entero de MB. Por ejemplo, si pasas 30, se especifica que el proceso está limitado a 30 MB de memoria. Si pasas max, se quitan todos los límites de memoria de ese proceso. Si pasas none, se quitan todos los límites manuales establecidos en el proceso y se restablece el límite predeterminado del sistema (si corresponde).

status

Informa el estado actual del limitador de memoria. El estado incluye los límites de memoria impuestos en los procesos visibles y no visibles.

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 hacer la transición al uso de las APIs de SMS Retriever o SMS User Consent para garantizar la funcionalidad continua.

Seguridad

Android 17 incluye las siguientes mejoras en la seguridad de los dispositivos y las 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

Actualmente, si una app inicia un intent con un URI que tiene la acción ACTION_SEND, ACTION_SEND_MULTIPLE o ACTION_IMAGE_CAPTURE, el sistema otorga automáticamente los permisos de lectura y escritura del URI a la app de destino. A partir de Android 18, el sistema ya no otorgará automáticamente estos permisos. Por este motivo, recomendamos que las apps otorguen explícitamente los permisos de URI pertinentes en lugar de depender de que el sistema los otorgue.

Para detectar el uso de estos intents en tu app, usa StrictMode con detectImplicitUriPermissionGrant() para activar un incumplimiento:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Como alternativa, puedes supervisar las excepciones registradas que contengan el mensaje Please set the grant explicitly in the app, que aparece cuando el sistema establece el otorgamiento de forma implícita. Puedes supervisar estos registros con el siguiente comando de adb:

adb logcat | grep "Please set the grant explicitly in the app"

Para otorgar explícitamente los permisos necesarios, agrega la marca FLAG_GRANT_READ_URI_PERMISSION a las intenciones ACTION_SEND y ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Incluye las marcas FLAG_GRANT_READ_URI_PERMISSION y FLAG_GRANT_WRITE_URI_PERMISSION para los intents ACTION_IMAGE_CAPTURE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

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 la 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

从 Android 17 开始，音频框架会对后台音频互动（包括音频播放、音频焦点请求和音量更改 API）强制执行限制，以确保这些更改是由用户有意发起的。

如果应用尝试在应用未处于有效生命周期时调用音频 API，则音频播放和音量更改 API 会以静默方式失败，而不会抛出异常或提供失败消息。音频焦点 API 会失败，并返回结果代码 AUDIOFOCUS_REQUEST_FAILED。

如需了解详情（包括缓解措施），请参阅后台音频安全加固。

Conectividad

Android 17 incluye los siguientes cambios para mejorar la conectividad de los dispositivos.

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

Android 17 引入了自主重新配对功能，这是一项系统级增强功能，旨在自动解决蓝牙配对信息丢失问题。

以前，如果配对信息丢失，用户必须手动前往“设置”取消配对，然后重新配对外围设备。此功能以 Android 16 的安全改进为基础，允许系统在后台重新建立配对信息，而无需用户手动前往“设置”取消配对并重新配对外围设备。

虽然大多数应用不需要更改代码，但开发者应注意蓝牙堆栈中的以下行为变更：

  • 新的配对上下文： ACTION_PAIRING_REQUEST 现在包含 EXTRA_PAIRING_CONTEXT extra，允许应用区分 标准配对请求和自主系统发起的重新配对尝试。
  • 有条件的密钥更新：只有在重新配对成功且新连接达到或超过之前配对信息的安全级别时，才会替换现有安全密钥。
  • 修改后的 intent 时间：现在，只有在自主重新配对尝试失败时，才会广播 ACTION_KEY_MISSING intent。如果系统在后台成功恢复配对信息，则可以减少应用中不必要的错误处理。
  • 用户通知：系统通过新的界面通知和对话框管理重新配对。系统会提示用户确认重新配对尝试，以确保用户了解重新连接。

外围设备制造商和配套应用开发者应验证硬件和应用是否能妥善处理配对信息转换。如需测试此行为，请使用以下任一方法模拟远程配对信息丢失：

  • 从外围设备中手动移除配对信息
  • 在“设置”>“已连接的设备”中手动取消配对设备