Cambios de comportamiento: todas las apps

La plataforma de Android 15 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 15, independientemente de targetSdkVersion. Debes probar tu app y, luego, modificarla según corresponda para admitir estos cambios.

Asegúrate también de revisar la lista de cambios de comportamiento que solo afectan a las apps orientadas a Android 15.

Funcionalidad principal

Android 15 modifica o expande varias capacidades principales del sistema Android.

Cambios en el estado detenido del paquete

La intención del estado FLAG_STOPPED del paquete (que los usuarios pueden activar en compilaciones de AOSP si mantienen presionado el ícono de una app y seleccionan "Forzar detención") siempre fue mantener las apps en este estado hasta que el usuario las quite de este estado de forma explícita, ya sea iniciándolas directamente o interactuando con ellas de forma indirecta (a través de la hoja compartida o un widget, seleccionando la app como fondo de pantalla en vivo, etcétera). En Android 15, actualizamos el comportamiento del sistema para que se alinee con este comportamiento previsto. Las apps solo deben quitarse del estado detenido a través de una acción directa o indirecta del usuario.

Para admitir el comportamiento deseado, además de las restricciones existentes, el sistema también cancela todos los intents pendientes cuando la app entra en el estado detenido en un dispositivo que ejecuta Android 15. Cuando las acciones del usuario quitan la app del estado detenido, la transmisión ACTION_BOOT_COMPLETED se entrega a la app, lo que brinda la oportunidad de volver a registrar cualquier intent pendiente.

Puedes llamar al nuevo método ApplicationStartInfo.wasForceStopped() para confirmar si la app se puso en el estado de detención.

Compatibilidad con tamaños de página de 16 KB

Historically, Android has only supported 4 KB memory page sizes, which has optimized system memory performance for the average amount of total memory that Android devices have typically had. Beginning with Android 15, AOSP supports devices that are configured to use a page size of 16 KB (16 KB devices). If your app uses any NDK libraries, either directly or indirectly through an SDK, then you will need to rebuild your app for it to work on these 16 KB devices.

As device manufacturers continue to build devices with larger amounts of physical memory (RAM), many of these devices will adopt 16 KB (and eventually greater) page sizes to optimize the device's performance. Adding support for 16 KB page size devices enables your app to run on these devices and helps your app benefit from the associated performance improvements. Without recompiling, apps won't work on 16 KB devices in future Android releases.

To help you add support for your app, we've provided guidance on how to check if your app is impacted, how to rebuild your app (if applicable), and how to test your app in a 16 KB environment using emulators (including Android 15 system images for the Android Emulator).

Benefits and performance gains

Devices configured with 16 KB page sizes use slightly more memory on average, but also gain various performance improvements for both the system and apps:

• Lower app launch times while the system is under memory pressure: 3.16% lower on average, with more significant improvements (up to 30%) for some apps that we tested
• Reduced power draw during app launch: 4.56% reduction on average
• Faster camera launch: 4.48% faster hot starts on average, and 6.60% faster cold starts on average
• Improved system boot time: improved by 8% (approximately 950 milliseconds) on average

These improvements are based on our initial testing, and results on actual devices will likely differ. We'll provide additional analysis of potential gains for apps as we continue our testing.

Check if your app is impacted

If your app uses any native code, then you should rebuild your app with support for 16 KB devices. If you are unsure if your app uses native code, you can use the APK Analyzer to identify whether any native code is present and then check the alignment of ELF segments for any shared libraries that you find. Android Studio also provides features that help you to automatically detect alignment issues.

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices. Nevertheless, we recommend that you test your app in a 16 KB environment to verify that there are no unexpected regressions in app behavior.

Cambios obligatorios para que algunas apps admitan el espacio privado

El espacio privado es una nueva función de Android 15 que permite a los usuarios crear un espacio independiente en su dispositivo en el que pueden mantener las apps sensibles lejos de miradas indiscretas, con una capa adicional de autenticación. Debido a que las apps del espacio privado tienen visibilidad restringida, algunos tipos de apps deben seguir pasos adicionales para poder ver e interactuar con las apps del espacio privado de un usuario.

Todas las apps

Debido a que las apps del espacio privado se mantienen en un perfil de usuario independiente, similar a los perfiles de trabajo, las apps no deben suponer que las copias instaladas de su app que no están en el perfil principal están en el perfil de trabajo. Si tu app tiene lógica relacionada con apps de perfil de trabajo que hacen esta suposición, deberás ajustarla.

Apps médicas

Cuando un usuario bloquea el espacio privado, se detienen todas las apps que se encuentran en él, y estas no pueden realizar actividades en primer o segundo plano, incluida la visualización de notificaciones. Este comportamiento podría afectar de manera significativa el uso y la función de las apps médicas instaladas en el espacio privado.

La experiencia de configuración del espacio privado advierte a los usuarios que el espacio privado no es adecuado para apps que necesitan realizar actividades críticas en primer o segundo plano, como mostrar notificaciones de apps médicas. Sin embargo, las apps no pueden determinar si se están usando o no en el espacio privado, por lo que no pueden mostrar una advertencia al usuario en este caso.

Por estos motivos, si desarrollas una app médica, revisa cómo esta función podría afectarla y toma las medidas adecuadas, como informar a los usuarios que no la instalen en el espacio privado, para evitar interrumpir sus funciones fundamentales.

Apps de lanzamiento

Si desarrollas una app de selector, debes hacer lo siguiente para que las apps del espacio privado sean visibles:

1. Tu app debe asignarse como la app de selector predeterminado del dispositivo, es decir, debe tener el rol ROLE_HOME.
2. Tu app debe declarar el permiso normal ACCESS_HIDDEN_PROFILES en el archivo de manifiesto de la app.

Las apps de selector que declaran el permiso ACCESS_HIDDEN_PROFILES deben controlar los siguientes casos de uso de espacio privado:

1. Tu app debe tener un contenedor de selector independiente para las apps instaladas en el espacio privado. Usa el método getLauncherUserInfo() para determinar qué tipo de perfil de usuario se está controlando.
2. El usuario debe poder ocultar y mostrar el contenedor de espacio privado.
3. El usuario debe poder bloquear y desbloquear el contenedor de espacio privado. Usa el método requestQuietModeEnabled() para bloquear (pasando true) o desbloquear (pasando false) el espacio privado.

4. Cuando está bloqueado, ninguna app del contenedor de espacio privado debe ser visible ni detectable a través de mecanismos como la búsqueda. Tu app debe registrar un receptor para las transmisiones de ACTION_PROFILE_AVAILABLE y ACTION_PROFILE_UNAVAILABLE, y actualizar la IU en tu app cuando cambie el estado de bloqueo o desbloqueo del contenedor de espacio privado. Ambas transmisiones incluyen EXTRA_USER, que tu app puede usar para hacer referencia al usuario del perfil privado.

   También puedes usar el método isQuietModeEnabled() para verificar si el perfil de espacio privado está bloqueado o no.

Apps de tiendas de aplicaciones

El espacio privado incluye un botón "Instalar apps" que inicia un intent implícito para instalar apps en el espacio privado del usuario. Para que tu app reciba este intent implícito, declara un <intent-filter> en el archivo de manifiesto de tu app con un <category> de CATEGORY_APP_MARKET.

Se quitó la fuente de emojis basada en PNG

Se quitó el archivo de fuente de emojis heredado basado en PNG (NotoColorEmojiLegacy.ttf) y solo se dejó el archivo basado en vectores. A partir de Android 13 (nivel de API 33), el archivo de fuente de emojis que usa el renderizador de emojis del sistema cambió de un archivo basado en PNG a uno basado en vectores. El sistema retuvo el archivo de fuente heredado en Android 13 y 14 por motivos de compatibilidad, de modo que las apps con sus propios renderizadores de fuentes pudieran seguir usándolo hasta que pudieran actualizarse.

Para verificar si tu app se ve afectada, busca referencias al archivo NotoColorEmojiLegacy.ttf en el código de la app.

Puedes adaptar tu app de varias maneras:

• Usa las APIs de la plataforma para la renderización de texto. Puedes renderizar texto en un Canvas con copia de seguridad de mapa de bits y usarlo para obtener una imagen sin procesar si es necesario.
• Agrega compatibilidad con fuentes COLRv1 a tu app. La biblioteca de código abierto FreeType es compatible con COLRv1 en la versión 2.13.0 y versiones posteriores.
• Como último recurso, puedes agrupar el archivo de fuente de emojis heredado (NotoColorEmoji.ttf) en tu APK, aunque, en ese caso, a tu app le faltarán las actualizaciones de emojis más recientes. Para obtener más información, consulta la página del proyecto de GitHub de Noto Emoji.

Se aumentó la versión mínima del SDK objetivo de 23 a 24

Android 15 se basa en los cambios que se realizaron en Android 14 y extiende aún más esta seguridad. En Android 15, no se pueden instalar apps con un targetSdkVersion inferior a 24. Exigir a las apps que cumplan con los niveles de API modernos ayuda a garantizar una mejor seguridad y privacidad.

El software malicioso a menudo apunta a niveles de API más bajos para evadir la seguridad y la privacidad protecciones que se introdujeron en versiones posteriores de Android. Por ejemplo, algunas apps de software malicioso usan targetSdkVersion de 22 para evitar que estén sujetas al modelo de permisos de tiempo de ejecución que, en 2015, introdujo Android 6.0 Marshmallow (nivel de API 23). Este cambio en Android 15 dificulta que el software malicioso evite la seguridad y mejoras en la privacidad. Intentar instalar una app segmentada para una API inferior generará un error de instalación, con un mensaje como el siguiente en Logcat:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 7

En los dispositivos que se actualizan a Android 15, todas las apps con un targetSdkVersion inferior de 24 permanecen instaladas.

Si necesitas probar una app que se oriente a un nivel de API anterior, usa el siguiente comando de adb:

adb install --bypass-low-target-sdk-block FILENAME.apk

Seguridad y privacidad

Android 15 presenta medidas sólidas para combatir el fraude de contraseña de un solo uso (OTP) y proteger el contenido sensible del usuario, enfocándose en endurecer el servicio de objeto de escucha de notificaciones y las protecciones de uso compartido de pantalla. Entre las mejoras clave, se incluyen la ocultación de las OTP de las notificaciones a las que pueden acceder apps no confiables, la ocultación de las notificaciones durante la función de compartir pantalla y la protección de las actividades de la app cuando se publican OTP. El objetivo de estos cambios es proteger el contenido sensible del usuario de personas no autorizadas.

Los desarrolladores deben tener en cuenta lo siguiente para asegurarse de que sus apps sean compatibles con los cambios en Android 15:

Ocultación de OTP

Android impedirá que las apps no confiables que implementen un NotificationListenerService lean contenido sin censura de las notificaciones en las que se detectó una OTP. Las apps de confianza, como las asociaciones de administradores de dispositivos complementarios, están exentas de estas restricciones.

Protección de Compartir pantalla

• El contenido de las notificaciones se oculta durante las sesiones de uso compartido de pantalla para preservar la privacidad del usuario. Si la app implementa setPublicVersion(), Android muestra la versión pública de la notificación, que sirve como notificación de reemplazo en contextos no seguros. De lo contrario, el contenido de la notificación se oculta sin ningún otro contexto.
• El contenido sensible, como la entrada de contraseñas, se oculta a los usuarios remotos para evitar que se revele la información sensible del usuario.
• Se ocultarán las actividades de las apps que publiquen notificaciones durante la función de Compartir pantalla en la que se haya detectado una OTP. El contenido de la app se oculta al visor remoto cuando se inicia.
• Además de la identificación automática de campos sensibles de Android, los desarrolladores pueden marcar manualmente partes de su app como sensibles con setContentSensitivity, que se oculta a los usuarios remotos durante la función de compartir pantalla.
• Los desarrolladores pueden activar o desactivar la opción Inhabilitar protecciones cuando compartes pantalla en Opciones para desarrolladores para quedar exentos de las protecciones de uso compartido de pantalla con fines de demostración o pruebas. La grabadora de pantalla predeterminada del sistema está exenta de estos cambios, ya que las grabaciones permanecen en el dispositivo.

Cámara y contenido multimedia

Android 15 realiza los siguientes cambios en el comportamiento de la cámara y el contenido multimedia para todas las apps.

La reproducción de audio directa y descargada invalida las pistas de audio directas o descargadas abiertas anteriormente cuando se alcanzan los límites de recursos

Before Android 15, if an app requested direct or offload audio playback while another app was playing audio and the resource limits were reached, the app would fail to open a new AudioTrack.

Beginning with Android 15, when an app requests direct or offload playback and the resource limits are reached, the system invalidates any currently open AudioTrack objects which prevent fulfilling the new track request.

(Direct and offload audio tracks are typically opened for playback of compressed audio formats. Common use-cases for playing direct audio include streaming encoded audio over HDMI to a TV. Offload tracks are typically used to play compressed audio on a mobile device with hardware DSP acceleration.)

Experiencia del usuario y la IU del sistema

Android 15 incluye algunos cambios destinados a crear una experiencia del usuario más coherente e intuitiva.

Animaciones del gesto atrás predictivo habilitadas para las apps que aceptaron participar

A partir de Android 15, se quitó la opción para desarrolladores de animaciones de atrás predictivo. Las animaciones del sistema, como volver a la página principal, cambiar de tarea y cambiar de actividad, ahora aparecen en las apps que habilitaron el gesto atrás predictivo por completo o a nivel de la actividad. Si tu app se ve afectada, realiza las siguientes acciones:

• Asegúrate de que tu app se haya migrado correctamente para usar el gesto atrás predictivo.
• Asegúrate de que las transiciones de fragmentos funcionen con la navegación con atrás predictivo.
• Migra de las animaciones y las transiciones de framework, y usa transiciones de animador y androidx.
• Migra de las pilas de actividades que FragmentManager no conoce. En su lugar, usa pilas de actividades administradas por FragmentManager o por el componente Navigation.

Widgets inhabilitados cuando el usuario detiene una app de forma forzada

Si un usuario detiene de forma forzosa una app en un dispositivo que ejecuta Android 15, el sistema inhabilita temporalmente todos los widgets de la app. Los widgets están inhabilitados, y el usuario no puede interactuar con ellos. Esto se debe a que, a partir de Android 15, el sistema cancela todos los intents pendientes de una app cuando se detiene de forma forzosa.

El sistema vuelve a habilitar esos widgets la próxima vez que el usuario inicia la app.

Para obtener más información, consulta Cambios en el estado de detención del paquete.

El chip de la barra de estado de la proyección de contenido multimedia alerta a los usuarios sobre el uso compartido, la transmisión y la grabación de pantalla

Los exploits de proyección de pantalla exponen datos privados del usuario, como información financiera, porque los usuarios no se dan cuenta de que se está compartiendo la pantalla de su dispositivo.

En el caso de las apps que se ejecutan en dispositivos con Android 15 QPR1 o versiones posteriores, un chip de la barra de estado grande y destacado alerta a los usuarios sobre cualquier proyección de pantalla en curso. Los usuarios pueden presionar el chip para evitar que se comparta, transmita o grabe su pantalla. Además, la proyección de pantalla se detiene automáticamente cuando se bloquea la pantalla del dispositivo.

Check if your app is impacted

By default, your app includes the status bar chip and automatically suspends screen projection when the lock screen activates.

To learn more about how to test your app for these use cases, see Status bar chip and auto stop.

Restricciones de acceso a la red en segundo plano

In Android 15, apps that start a network request outside of a valid process lifecycle receive an exception. Typically, an UnknownHostException or other socket-related IOException. Network requests that happen outside of a valid lifecycle are usually due to apps unknowingly continuing a network request even after the app is no longer active.

To mitigate this exception, ensure your network requests are lifecycle aware and cancelled upon leaving a valid process lifecycle by using lifecycle aware components. If it is important that the network request should happen even when the user leaves the application, consider scheduling the network request using WorkManager or continue a user visible task using Foreground Service.

Bajas

Con cada actualización, es posible que las APIs específicas de Android queden obsoletas o deban refactorizarse para ofrecerles una mejor experiencia a los desarrolladores o admitir nuevas funciones de la plataforma. En estos casos, damos de baja oficialmente las APIs obsoletas y les indicamos a los desarrolladores las APIs alternativas que pueden usar en su lugar.

Baja significa que finalizamos la asistencia oficial para las APIs, pero estas seguirán disponibles para los desarrolladores. Para obtener más información sobre las bajas notables de esta versión de Android, consulta la página de bajas.