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 de memoria de la app

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 aplicaciones y 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 activen la inestabilidad en todo el sistema, lo que provoca tartamudeo de la IU, agotamiento de la 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 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.

La tarea LeakCanary en el generador de perfiles de Android Studio.

Para ayudarte a encontrar fugas de memoria, Android Studio Panda agrega la integración de LeakCanary directamente en el generador de perfiles de Android Studio como una tarea dedicada, contextualizada dentro del IDE y completamente integrada con tu código fuente.

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.

Seguridad

Android 17 incluye las siguientes mejoras en la seguridad de dispositivos y 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 las concesiones de URI implícitas

目前，如果应用启动的 intent 具有 URI，且该 URI 具有操作 ACTION_SEND、ACTION_SEND_MULTIPLE或 ACTION_IMAGE_CAPTURE，则系统会自动向目标应用授予读取和 写入 URI 权限。从 Android 18 开始，系统将 不再自动授予这些权限。因此，我们建议应用明确授予相关 URI 权限，而不是依赖系统授予这些权限。

如需检测应用中这些 intent 的使用情况，请将 StrictMode 与 detectImplicitUriPermissionGrant() 结合使用，以触发违规行为：

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

或者，您也可以监控包含消息 Please set the grant explicitly in the app 的已记录异常，该消息会在系统隐式设置授予时显示。您可以使用以下 adb 命令监控这些日志：

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

如需明确授予必要的权限，请将 FLAG_GRANT_READ_URI_PERMISSION标志添加到ACTION_SEND和 ACTION_SEND_MULTIPLEintent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

对于 ACTION_IMAGE_CAPTURE intent，请同时添加FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

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

从 Android 17 开始，当设备的配置发生变化（例如，通过旋转）且应用本身未处理此变化时，系统不会恢复之前的 IME 可见性。

如果应用经历了它无法处理的配置更改，并且应用需要在更改后显示键盘，您必须明确请求此行为。您可以通过以下方式之一提出此要求：

  • 将 android:windowSoftInputMode 属性设置为 stateAlwaysVisible。
  • 在 activity 的 onCreate() 方法中以编程方式请求显示软键盘，或添加 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

从 Android 17 开始，如果应用使用 View.requestPointerCapture() 请求捕获指针，并且用户使用触控板，系统会识别用户触摸操作产生的指针移动和滚动手势，并以与捕获的鼠标产生的指针和滚轮移动相同的方式将这些信息报告给应用。在大多数情况下，这使得支持捕获鼠标的应用无需为触控板添加特殊的处理逻辑。如需了解详情，请参阅 View.POINTER_CAPTURE_MODE_RELATIVE 的文档。

之前，系统不会尝试识别触控板的手势，而是以类似于触摸屏触摸的格式将原始的绝对手指位置传递给应用。如果应用仍需要此绝对数据，则应改为使用 View.POINTER_CAPTURE_MODE_ABSOLUTE 调用新的 View.requestPointerCapture(int) 方法。

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