Cambios de comportamiento: todas las apps

La plataforma de Android 14 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 14, 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 14.

Funcionalidad principal

El permiso para programar alarmas exactas se rechaza de forma predeterminada

Las alarmas exactas están diseñadas para notificaciones destinadas a usuarios o para acciones que deben realizarse en un momento preciso. A partir de Android 14, el permiso SCHEDULE_EXACT_ALARM ya no se otorga, de forma previa, a la mayoría de las apps instaladas más recientemente que se orienten a Android 13 y versiones posteriores; el permiso se rechaza de forma predeterminada.

Obtén más información sobre los cambios en el permiso para programar alarmas exactas.

Las transmisiones registradas en el contexto se ponen en cola mientras las apps se almacenan en caché

On Android 14, the system can place context-registered broadcasts in a queue while the app is in the cached state. This is similar to the queuing behavior that Android 12 (API level 31) introduced for async binder transactions. Manifest-declared broadcasts aren't queued, and apps are removed from the cached state for broadcast delivery.

When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast. Depending on other factors, such as system health, apps might be removed from the cached state, and any previously queued broadcasts are delivered.

Las apps solo pueden finalizar sus propios procesos en segundo plano

A partir de Android 14, cuando tu app llame a killBackgroundProcesses(), la API solo puede finalizar los procesos en segundo plano de tu propia app.

Si pasas el nombre del paquete de otra app, este método no tiene efecto en los procesos en segundo plano de esa app, y aparece el siguiente mensaje en Logcat:

Invalid packageName: com.example.anotherapp

Tu app no debe usar la API de killBackgroundProcesses() ni intentar influir, de otra manera, en el ciclo de vida del proceso de otras apps, incluso en versiones anteriores del SO. Android se diseñó para mantener las apps almacenadas en caché en segundo plano y eliminarlas automáticamente cuando el sistema necesite memoria. Si tu app finaliza, de forma innecesaria, otras apps, puede reducir el rendimiento del sistema y aumentar el consumo de batería, ya que se requieren reinicios completos de esas apps más adelante, lo que exige muchos más recursos que reanudar una app existente almacenada en caché.

La MTU se establece en 517 para el primer cliente GATT que solicita una MTU.

A partir de Android 14, la pila Bluetooth de Android cumple de manera más estricta con la versión 5.2 de la especificación Bluetooth Core y solicita que la MTU de BLE ATT sea de 517 bytes cuando el primer cliente GATT solicita una MTU usando la API de BluetoothGatt#requestMtu(int) e ignora todas las solicitudes de MTU posteriores en esa conexión de LCA.

Para abordar este cambio y hacer que tu app sea más sólida, considera las siguientes opciones:

  • Tu dispositivo periférico debe responder a la solicitud de MTU del dispositivo Android con un valor razonable que el periférico pueda admitir. El valor final negociado será un valor mínimo del valor solicitado por Android y el valor proporcionado de forma remota (por ejemplo, min(517, remoteMtu))
    • Implementar esta solución podría requerir una actualización del firmware del dispositivo periférico.
  • Como alternativa, limita las operaciones de escritura de características GATT según el mínimo entre el valor compatible conocido de tu periférico y el cambio de MTU recibido.
    • Un recordatorio de que debes reducir 5 bytes del tamaño admitido para los encabezados
    • Por ejemplo: arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

Nuevo motivo por el que una app puede ubicarse en el intervalo de espera restringido

Android 14 presenta un nuevo motivo por el que una app se puede colocar en el intervalo en espera restringido. Los trabajos de la app activan errores de ANR varias veces debido a los tiempos de espera de los métodos onStartJob, onStopJob o onBind. (Consulta JobScheduler refuerza la devolución de llamada y el comportamiento de la red para los cambios en onStartJob y onStopJob).

Para realizar un seguimiento de si la app ingresó o no en el intervalo en espera restringido, te recomendamos que realices el registro con la API UsageStatsManager.getAppStandbyBucket() cuando se ejecute el trabajo o con UsageStatsManager.queryEventsForSelf() cuando se inicie la app.

mlock limitado a 64 KB

En Android 14 (nivel de API 34) y versiones posteriores, la plataforma reduce la memoria máxima que se puede bloquear con mlock() a 64 KB por proceso. En versiones anteriores, el límite era de 64 MB por proceso. Esta restricción promueve una mejor administración de la memoria en las apps y el sistema. Para proporcionar más coherencia en todos los dispositivos, Android 14 agrega una nueva prueba del CTS para el nuevo límite de mlock() en los dispositivos compatibles.

El sistema aplica de manera forzosa el uso de recursos de apps en caché

By design, an app's process is in a cached state when it's moved to the background and no other app process components are running. Such an app process is subject to being killed due to system memory pressure. Any work that Activity instances perform after the onStop() method has been called and returned, while in this state, is unreliable and strongly discouraged.

Android 14 introduces consistency and enforcement to this design. Shortly after an app process enters a cached state, background work is disallowed, until a process component re-enters an active state of the lifecycle.

Apps that use typical framework-supported lifecycle APIs – such as services, JobScheduler, and Jetpack WorkManager – shouldn't be impacted by these changes.

Experiencia del usuario

Opción de otorgar acceso parcial a fotos y videos

Android 14 presenta el Acceso a fotos seleccionadas, que permite a los usuarios otorgar a las apps acceso a imágenes y videos específicos de su biblioteca, en lugar de dar acceso a todo el contenido multimedia de un tipo determinado.

Si aún no usas el selector de fotos, te recomendamos que lo implementes en tu app para proporcionar una experiencia coherente de selección de imágenes y videos que también mejore la privacidad del usuario sin tener que solicitar ningún permiso de almacenamiento.

Si mantienes tu propio selector de galería con permisos de almacenamiento y necesitas mantener el control total sobre la implementación, adapta tu implementación para usar el nuevo permiso READ_MEDIA_VISUAL_USER_SELECTED. Si tu app no usa el permiso nuevo, el sistema ejecutará tu app en un modo de compatibilidad.

Cambios en la experiencia de los usuarios con notificaciones que no se pueden descartar

Si tu app les muestra a los usuarios notificaciones que no se pueden descartar en primer plano, Android 14 cambió el comportamiento para permitir que los usuarios puedan hacerlo.

Este cambio se aplica a las apps que evitan que los usuarios descarten las notificaciones en primer plano estableciendo Notification.FLAG_ONGOING_EVENT mediante Notification.Builder#setOngoing(true) o NotificationCompat.Builder#setOngoing(true). Se modificó el comportamiento de FLAG_ONGOING_EVENT para que el usuario pueda descartar realmente estas notificaciones.

Estos tipos de notificaciones aún no se pueden descartar en las siguientes situaciones:

  • Si el teléfono está bloqueado.
  • Si el usuario selecciona una acción de notificación Borrar todo (lo que ayuda cuando se descartan por accidente).

Además, este nuevo comportamiento no se aplica a las notificaciones en los siguientes casos de uso:

  • CallStyle notificaciones
  • Controlador de políticas del dispositivo (DPC) y paquetes de asistencia para empresas

La información de seguridad de los datos es más visible

To enhance user privacy, Android 14 increases the number of places where the system shows the information you have declared in the Play Console form. Currently, users can view this information in the Data safety section on your app's listing in Google Play.

We encourage you to review your app's location data sharing policies and take a moment to make any applicable updates to your app's Google Play Data safety section.

Learn more in the guide about how data safety information is more visible on Android 14.

Accesibilidad

Escalamiento de fuente no lineal al 200%

A partir de Android 14, el sistema admite el escalamiento de la fuente hasta el 200%, lo que les brinda a los usuarios con visión reducida opciones de accesibilidad adicionales que se alinean con las Pautas de Accesibilidad al Contenido Web (WCAG).

Si ya usas unidades de píxeles ajustados (sp) para definir el tamaño del texto, es probable que estos cambios no produzcan un gran impacto en tu app. Sin embargo, debes realizar pruebas de IU con el tamaño de fuente máximo habilitado (200%) para asegurarte de que tu app pueda admitir tamaños de fuente más grandes sin afectar la usabilidad.

Seguridad

Nivel mínimo de API objetivo instalable

A partir de Android 14, no se pueden instalar apps con un targetSdkVersion inferior a 23. Exigir a las apps que cumplan con estos requisitos mínimos del nivel de API objetivo mejora la seguridad y la privacidad de los usuarios.

Con frecuencia, el software malicioso se orienta a niveles de APIs más antiguos para evitar las protecciones de seguridad y privacidad que se introdujeron en las versiones más recientes 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 14 dificulta que el software malicioso evite las mejoras de seguridad y privacidad. Si intentas instalar una app que se oriente a un nivel de API inferior, se producirá un error de instalación y se mostrará el siguiente mensaje en Logcat:

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

En los dispositivos que se actualizan a Android 14, las apps que tengan un targetSdkVersion inferior a 23 permanecerán 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

Los nombres de los paquetes de los propietarios del contenido multimedia podrían estar ocultos

La tienda de contenido multimedia admite consultas para la columna OWNER_PACKAGE_NAME, que indica la app que almacenó un archivo multimedia en particular. A partir de Android 14, este valor se oculta, a menos que se cumpla mínimo una de las siguientes condiciones:

  • La app que almacenó el archivo multimedia tiene un nombre de paquete que siempre está visible para otras apps.
  • La app que consulta la tienda de contenido multimedia solicita el permiso QUERY_ALL_PACKAGES.

Descubre cómo Android filtra la visibilidad de paquetes por motivos de privacidad.