Cambios de comportamiento: todas las apps

La plataforma de Android 15 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios 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

Históricamente, Android solo admitió tamaños de página de memoria de 4 KB, lo que optimizó el rendimiento de la memoria del sistema para la cantidad promedio de memoria total que suelen tener los dispositivos Android. A partir de Android 15, el AOSP admite dispositivos configurados para usar un tamaño de página de 16 KB (dispositivos de 16 KB). Si tu app usa alguna biblioteca del NDK, ya sea directamente o a través de un SDK, deberás volver a compilarla para que funcione en estos dispositivos de 16 KB.

A medida que los fabricantes de dispositivos sigan creando dispositivos con mayores cantidades de memoria física (RAM), muchos de estos dispositivos adoptarán tamaños de página de 16 KB (y, con el tiempo, incluso mayores) para optimizar el rendimiento del dispositivo. Agregar compatibilidad con dispositivos con tamaño de página de 16 KB permite que tu app se ejecute en estos dispositivos y se beneficie de las mejoras de rendimiento asociadas. Sin recompilación, las apps no funcionarán en dispositivos de 16 KB en futuras versiones de Android.

Para ayudarte a agregar compatibilidad con tu app, te proporcionamos orientación sobre cómo comprobar si tu app se ve afectada, cómo volver a compilar tu app (si corresponde) y cómo probar tu app en un entorno de 16 KB con emuladores (incluidas las imágenes del sistema de Android 15 para Android Emulator).

Benefits and performance gains

Los dispositivos configurados con tamaños de página de 16 KB usan un poco más de memoria en promedio, pero también obtienen varias mejoras de rendimiento para el sistema y las apps:

• Tiempos de inicio de la app más bajos mientras el sistema está bajo presión de memoria: un 3.16% más bajo en promedio, con mejoras más significativas (hasta un 30%) para algunas apps que probamos
• Menor consumo de energía durante el lanzamiento de la app: Reducción promedio del 4.56%
• Inicio más rápido de la cámara: Inicios en caliente un 4.48% más rápidos en promedio y, en promedio, un 6.60% más rápidos en frío
• Mejor tiempo de inicio del sistema: se mejoró en un 8% (aproximadamente 950 milisegundos) en promedio.

Estas mejoras se basan en nuestras pruebas iniciales, y es probable que los resultados en los dispositivos reales difieran. Proporcionaremos análisis adicionales de posibles ganancias para las apps a medida que continuemos con las pruebas.

Check if your app is impacted

Si tu app usa código nativo, debes recompilarla para que sea compatible con dispositivos de 16 KB. Si no sabes con seguridad si tu app usa código nativo, puedes usar el Analizador de APK para identificar si hay código nativo presente y, luego, verificar la alineación de los segmentos ELF de las bibliotecas compartidas que encuentres. Android Studio también proporciona funciones que te ayudan a detectar automáticamente problemas de alineación.

Si tu app solo usa código escrito en el lenguaje de programación Java o en Kotlin, incluidas todas las bibliotecas o SDKs, ya es compatible con dispositivos de 16 KB. Sin embargo, te recomendamos que pruebes tu app en un entorno de 16 KB para verificar que no haya regresiones inesperadas en el comportamiento de la app.

Cambios necesarios 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 de destino de 23 a 24

Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.

Malware often targets lower API levels in order to bypass security and privacy protections that have been introduced in higher Android versions. For example, some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API level 23). This Android 15 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level results in an installation failure, with a message like the following one appearing in Logcat:

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

On devices upgrading to Android 15, any apps with a targetSdkVersion lower than 24 remain installed.

If you need to test an app targeting an older API level, use the following ADB command:

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

Seguridad y privacidad

Android 15 introduces robust measures to combat one-time passcode (OTP) fraud and to protect the user's sensitive content, focusing on hardening the Notification Listener Service and screenshare protections. Key enhancements include redacting OTPs from notifications accessible to untrusted apps, hiding notifications during screenshare, and securing app activities when OTPs are posted. These changes aim to keep the user's sensitive content safe from unauthorized actors.

Developers need to be aware of the following to ensure their apps are compatible with the changes in Android 15:

OTP Redaction

Android will stop untrusted apps that implement a NotificationListenerService from reading unredacted content from notifications where an OTP has been detected. Trusted apps such as companion device manager associations are exempt from these restrictions.

Screenshare Protection

• Notification content is hidden during screen sharing sessions to preserve the user's privacy. If the app implements setPublicVersion(), Android shows the public version of the notification which serves as a replacement notification in insecure contexts. Otherwise, the notification content is redacted without any further context.
• Sensitive content like password input is hidden from remote viewers to prevent revealing the user's sensitive information.
• Activities from apps that post notifications during screenshare where an OTP has been detected will be hidden. App content is hidden from the remote viewer when launched.
• Beyond Android's automatic identification of sensitive fields, developers can manually mark parts of their app as sensitive using setContentSensitivity, which is hidden from remote viewers during screenshare.
• Developers can choose to toggle the Disable screen share protections option under Developer Options to be exempted from the screenshare protections for demo or testing purposes. The default system screen recorder is exempted from these changes, since the recordings remain on-device.

Cámara y contenido multimedia

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

La reproducción de audio directa y la descarga invalidan las pistas de audio directas o descargadas que se abrieron anteriormente cuando se alcanzan los límites de recursos.

Antes de Android 15, si una app solicitaba la reproducción de audio directa o descargada mientras otra app estaba reproduciendo audio y se alcanzaban los límites de recursos, la app no podía abrir un nuevo AudioTrack.

A partir de Android 15, cuando una app solicita la reproducción directa o de descarga y se alcanzan los límites de recursos, el sistema invalida los objetos AudioTrack abiertos que impiden entregar la solicitud de pista nueva.

(Por lo general, se abren pistas de audio directas y de descarga para la reproducción de formatos de audio comprimidos. Entre los casos de uso comunes para reproducir audio directo, se incluye la transmisión de audio codificado a través de HDMI a una TV. Por lo general, se usan para reproducir audio comprimido en un dispositivo móvil con aceleración de DSP de hardware.

Experiencia del usuario y la IU del sistema

Android 15 incluye algunos cambios que tienen como objetivo crear una experiencia del usuario más coherente e intuitiva.

Se habilitaron las animaciones de retroceso predictivo para las apps que habilitaron la función.

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.

Se inhabilitan los widgets cuando el usuario fuerza la detención de una app

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 proyección de medios alerta a los usuarios sobre el uso compartido, la transmisión y la grabación de la 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.

Verifica si tu app se verá afectada

De forma predeterminada, tu app incluye el chip de la barra de estado y suspende automáticamente la proyección de pantalla cuando se activa la pantalla de bloqueo.

Para obtener más información sobre cómo probar tu app para estos casos de uso, consulta Chip de la barra de estado y detención automática.

Restricciones de acceso a la red en segundo plano

En Android 15, las apps que inician una solicitud de red fuera de un ciclo de vida del proceso válido reciben una excepción. Por lo general, un UnknownHostException o algún otro IOException relacionado con el zócalo. Por lo general, las solicitudes de red que se producen fuera de un ciclo de vida válido se deben a que las apps continúan una solicitud de red sin saberlo, incluso después de que la app ya no está activa.

Para mitigar esta excepción, asegúrate de que tus solicitudes de red sean conscientes del ciclo de vida y se cancelen cuando salgan de un ciclo de vida de proceso válido con componentes conscientes del ciclo de vida. Si es importante que la solicitud de red se realice incluso cuando el usuario salga de la aplicación, considera programar la solicitud de red con WorkManager o continuar una tarea visible para el usuario con el servicio en primer plano.

Bajas

Con cada actualización, es posible que las APIs específicas de Android queden obsoletas o deban refactorizarse a fin de 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 destacadas en esta versión de Android, consulta la página de bajas.