Cambios de comportamiento: todas las apps

La plataforma de Android 17 incluye cambios de comportamiento que podrían afectar a tu app. Los siguientes cambios 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 funciones 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 determinístico para tus apps y los usuarios de Android. Estos límites se enfocan en las fugas de memoria y otros valores atípicos antes de que activen la inestabilidad en todo el sistema, lo que genera interrupciones en la IU, un mayor agotamiento de la batería y el cierre de apps. Si bien anticipamos un impacto mínimo en la gran mayoría de las sesiones de la app, te recomendamos que sigas las prácticas recomendadas para la memoria, incluido el establecimiento de un modelo de referencia para la memoria.

Puedes determinar si la sesión de tu 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 creació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 de Administra 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 con 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 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. Pasar un UID (ID de usuario de Android) indica al limitador de memoria que ignore la aplicación de medidas en todos los procesos asociados con ese UID. También puedes pasar all (ignorar todas las apps) o none (no ignorar ninguna app). Pasar none anula cualquier llamada anterior 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 (ID de proceso) especificado. La restricción de memoria se especifica como un número entero de MB. Por ejemplo, si se pasa 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 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 a los procesos visibles y no visibles.

Privacidad

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

Protección de OTP por SMS

A partir de Android 17, Android ampliará su protección para los mensajes SMS que contengan 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 contienen un hash de recuperación de SMS se retrasó tres horas para la mayoría de las apps. Sin embargo, algunas apps (como el controlador de SMS predeterminado) estaban exentas de la demora, y la app propietaria del hash también estaba exenta.

A partir de Android 17, la protección también se aplica a los mensajes con formato de WebOTP. Si una app tiene permiso para leer mensajes SMS, pero no es el destinatario previsto de un mensaje de WebOTP (según lo determine la verificación de dominio), la app no podrá acceder al mensaje hasta tres horas después de que se 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 manera programática.

Durante esta demora 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 está disponible para estas apps después de la demora. Este cambio se aplica a todas las apps, independientemente de su nivel de API objetivo.

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.

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 los dispositivos y las apps.

Plan de baja de usesClearTraffic

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

• Set the usesCleartextTraffic attribute to true
• Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set usesCleartextTraffic.

Restringe los otorgamientos de URI implícitos

Currently, if an app launches an intent with a URI that has the action ACTION_SEND, ACTION_SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. Starting in Android 18, the system will no longer automatically grant these permissions. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

To detect the usage of these intents in your app, use StrictMode with detectImplicitUriPermissionGrant() to trigger a violation:

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);

Alternatively, you can monitor for logged exceptions containing the message Please set the grant explicitly in the app that appears when system implicitly sets the grant. You can monitor for these logs using the following adb command:

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

To explicitly grant the necessary permissions, add the FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and ACTION_SEND_MULTIPLE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags for ACTION_IMAGE_CAPTURE intents:

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 del almacén de claves 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, ya no se permite el tráfico de bucle invertido entre perfiles 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 orienten.

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.

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

Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.

If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:

• Set the android:windowSoftInputMode attribute to stateAlwaysVisible.
• Programmatically request the soft keyboard in your activity's onCreate() method, or add the onConfigurationChanged() method.

Intervención humana

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

Los paneles táctiles envían 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 del mouse de un mouse capturado. En la mayoría de los casos, esto elimina la necesidad de que las apps que admiten ratones capturados agreguen lógica de manejo 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 su lugar, entregaba las ubicaciones absolutas y sin procesar de los dedos a la app en un formato similar al de los toques de la pantalla táctil. Si una app aún requiere estos datos absolutos, debe llamar al nuevo método View.requestPointerCapture(int) con View.POINTER_CAPTURE_MODE_ABSOLUTE en su lugar.

Medios

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

Refuerzo del audio en segundo plano

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

Note: The restrictions are more stringent if an app targets Android 17 (API level 37). For these apps, the foreground service must have while-in-use (WIU) capabilities, unless the app has the exact alarm permission and is interacting with USAGE_ALARM audio streams.

For more information, including mitigation strategies, see Background audio hardening.

Conectividad

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

Vinculación autónoma para pérdidas de conexión Bluetooth

Android 17 presenta la vinculación autónoma, 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 un vínculo, 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 los vínculos en segundo plano sin que los usuarios tengan que navegar 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 ACTION_PAIRING_REQUEST ahora incluye el elemento adicional EXTRA_PAIRING_CONTEXT, que permite que las apps distingan entre una solicitud de vinculación estándar y un intento de volver a vincularse iniciado por el sistema autónomo.
• Actualizaciones de claves condicionales: Las claves 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.
• Se modificó el tiempo del intent: El intent 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 innecesario en la app si el sistema recupera correctamente la vinculación en segundo plano.
• Notificación al usuario: El sistema administra la revinculación 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 para asegurarse de que estén al tanto de la reconexión.

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

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