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 introduce límites de memoria de la app basados en la RAM total del dispositivo para crear un entorno más estable y determinista para tus apps y los usuarios de Android. En Android 17, los límites se establecen de forma conservadora para establecer líneas de base del sistema, orientadas a fugas de memoria extremas y otros valores atípicos antes de que provoquen inestabilidad en todo el sistema, lo que genera tartamudeo de la IU, mayor consumo de batería y finalización de apps. Si bien anticipamos un impacto mínimo en la gran mayoría de las sesiones de la app, 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 la 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 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 procesos visibles y no visibles.

Privacidad

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

Protección contra OTP por SMS

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

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

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns 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

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.

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 de los dispositivos.

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.