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.

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

Actualmente, si una app inicia un intent con un URI que tiene la acción Send, SendMultiple o ImageCapture, el sistema otorga automáticamente los permisos de URI de lectura y escritura a la app de destino. Planeamos cambiar este comportamiento en Android 18. 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.

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 las apps que no son del sistema y que se segmentan para 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 un KeyStoreException. La cadena de mensaje 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 de devolución depende del nivel de API al que se orienta la app:

  • Apps segmentadas para Android 17 (nivel de API 37) o versiones posteriores: getNumericErrorCode() devuelve el nuevo valor de ERROR_TOO_MANY_KEYS.
  • Todas las demás apps: getNumericErrorCode() devuelve ERROR_INCORRECT_USAGE.

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 controla este cambio, 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 virtual 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 los movimientos 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 ratones capturados agreguen lógica de control especial para los trackpads. 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, proporcionaba las ubicaciones absolutas sin procesar de los dedos a la app en un formato similar al de los toques en 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.

Contenido multimedia

Android 17 incluye los siguientes cambios en el comportamiento de contenido multimedia.

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, como 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 fallarán de forma silenciosa sin arrojar una excepción ni proporcionar un mensaje de error. 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.

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 introduces autonomous re-pairing, a system-level enhancement designed to automatically resolve Bluetooth bond loss.

Previously, if a bond was lost, users had to manually navigate to Settings to unpair and then re-pair the peripheral. This feature builds upon the security improvement of Android 16 by allowing the system to re-establish bonds in the background without requiring users to manually navigate to Settings to unpair and re-pair peripherals.

While most apps will not require code changes, developers should be aware of the following behavior changes in Bluetooth stack:

  • New pairing context: The ACTION_PAIRING_REQUEST now includes the EXTRA_PAIRING_CONTEXT extra which allows apps to distinguish between a standard pairing request and an autonomous system-initiated re-pairing attempt.
  • Conditional key updates: Existing security keys will only be replaced if the re-pairing is successful and new connection meets or exceeds the security level of the previous bond.
  • Modified intent timing: The ACTION_KEY_MISSING intent is now broadcast only if the autonomous re-pairing attempt fails. This reduces unnecessary error handling in the app if the system successfully recovers the bond in the background.
  • User notification: The system manages re-pairing via new UI notifications and dialogs. Users will be prompted to confirm the re-pairing attempt to ensure they are aware of the reconnection.

Peripheral device manufacturers and companion app developers should verify that hardware and app gracefully handle bond transitions. To test this behavior, simulate a remote bond loss using either of the following methods:

  • Manually remove the bond information from the peripheral device
  • Manually unpair the device in: Settings > Connected devices