Cambios en el comportamiento: apps orientadas a Android 14 o versiones posteriores

Al igual que las versiones anteriores, Android 14 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 14 (nivel de API 34) o versiones posteriores. Si tu app está orientada a Android 14 o versiones posteriores, debes modificarla para que admita estos comportamientos correctamente, cuando corresponda.

Asegúrate de revisar también la lista de cambios de comportamiento que afectan a todas las apps que se ejecutan en Android 14, independientemente de targetSdkVersion de la app.

Funcionalidad principal

Los tipos de servicio en primer plano son obligatorios

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，则必须为应用中的每个前台服务至少指定一项前台服务类型。您应选择一个能代表应用用例的前台服务类型。系统需要特定类型的前台服务满足特定用例。

如果应用中的用例与这些类型均不相关，强烈建议您迁移逻辑以使用 WorkManager 或用户发起的数据传输作业。

Aplicación del permiso BLUETOOTH_CONNECT en BluetoothAdapter

Android 14 aplica el permiso BLUETOOTH_CONNECT cuando se llama al método BluetoothAdapter getProfileConnectionState() para apps orientadas a Android 14 (nivel de API 34) o versiones posteriores.

Este método ya requería el permiso BLUETOOTH_CONNECT, pero no se aplicaba. Asegúrate de que tu app declare BLUETOOTH_CONNECT en el archivo AndroidManifest.xml, como se muestra en el siguiente fragmento, y verifica que un usuario haya otorgado el permiso antes de llamar a getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

Actualizaciones de OpenJDK 17

Android 14 continúa la tarea de actualizar las bibliotecas principales de Android para alinearlas con las funciones de las versiones más recientes de LTS de OpenJDK, lo que incluye las actualizaciones de bibliotecas y la compatibilidad con el lenguaje Java 17 para desarrolladores de apps y plataformas.

Algunos de estos cambios pueden afectar la compatibilidad de la app:

• Cambios en las expresiones regulares: Ahora no se permite que las referencias de grupo no válidas sigan la semántica de OpenJDK. Es posible que veas casos nuevos en los que la clase java.util.regex.Matcher arroje IllegalArgumentException, así que asegúrate de probar tu app para detectar áreas que usen expresiones regulares. Para habilitar o inhabilitar este cambio durante las pruebas, activa o desactiva la marca DISALLOW_INVALID_GROUP_REFERENCE con las herramientas del marco de compatibilidad.
• Manejo de UUID: El método java.util.UUID.fromString() ahora realiza verificaciones más estrictas cuando se valida el argumento de entrada, por lo que es posible que veas una IllegalArgumentException durante deserialización. Para habilitar o inhabilitar este cambio durante las pruebas, activa o desactiva la marca ENABLE_STRICT_VALIDATION con las herramientas del marco de compatibilidad.
• Problemas de ProGuard: En algunos casos, la adición de la clase java.lang.ClassValue genera un problema si intentas reducir, ofuscar y optimizar la app con ProGuard. El problema se origina en una biblioteca de Kotlin que cambia el comportamiento del tiempo de ejecución en función de si Class.forName("java.lang.ClassValue") muestra una clase o no. Si tu app se desarrolló en una versión anterior del tiempo de ejecución sin la clase java.lang.ClassValue disponible, estas optimizaciones podrían quitar el método computeValue de las clases derivadas de java.lang.ClassValue.

JobScheduler refuerza el comportamiento de devolución de llamada y de red

Desde su introducción, JobScheduler espera que tu app regrese de onStartJob o onStopJob en unos segundos. Antes de Android 14, Si una tarea se ejecuta por demasiado tiempo, se detiene y falla de manera silenciosa. Si tu app se orienta a Android 14 (nivel de API 34) o versiones posteriores y supera el tiempo otorgado en el subproceso principal, la app activa un error de ANR con el mensaje de error "No response to onStartJob" o "No response to onStopJob".

Este error de ANR puede deberse a 2 situaciones: 1) Hay trabajo que bloquea el subproceso principal, lo que impide que las devoluciones de llamadas onStartJob o onStopJob se ejecuten y completen dentro del límite de tiempo esperado. 2. El desarrollador ejecuta un trabajo de bloqueo dentro de la devolución de llamada de JobScheduler onStartJob o onStopJob, lo que impide que la devolución de llamada se complete dentro del límite de tiempo esperado.

Para abordar el punto 1, deberás depurar mejor lo que bloquea el subproceso principal cuando se produce el error de ANR. Puedes hacerlo con ApplicationExitInfo#getTraceInputStream() para obtener el seguimiento de la lápida cuando se produce el error de ANR. Si puedes reproducir el error de ANR de forma manual, puedes capturar un registro del sistema e inspeccionarlo usando cualquiera de las dos opciones: Android Studio o Perfetto para comprender mejor lo que se ejecuta el subproceso principal cuando se produce el error de ANR. Ten en cuenta que esto puede ocurrir cuando se usa la API de JobScheduler directamente o la biblioteca de androidx WorkManager.

Para solucionar el problema 2, considera migrar a WorkManager, que proporciona compatibilidad para unir cualquier procesamiento en onStartJob o onStopJob en un subproceso asíncrono.

JobScheduler también incluye un requisito para declarar la el permiso ACCESS_NETWORK_STATE si usas setRequiredNetworkType setRequiredNetwork. Si tu app no declara el permiso ACCESS_NETWORK_STATE cuando programa la tarea y se orienta a Android 14 o versiones posteriores, se generará una SecurityException.

API de lanzamiento de tarjetas

对于以 Android 14 及更高版本为目标平台的应用， TileService#startActivityAndCollapse(Intent) 已弃用，现在会抛出 调用时抛出异常。如果您的应用从功能块启动 activity，请使用 TileService#startActivityAndCollapse(PendingIntent)。

Privacidad

Acceso parcial a fotos y videos

Android 14 引入了“已选照片访问权限”，让用户可以向应用授予对其媒体库中特定图片和视频的访问权限，而不是授予对给定类型的所有媒体的访问权限。

只有当您的应用以 Android 14（API 级别 34）或更高版本为目标平台时，此更改才会启用。如果您尚未使用照片选择器，我们建议您在应用中实现照片选择器，以提供一致的图片和视频选择体验，同时增强用户隐私保护，而无需请求任何存储权限。

如果您使用存储权限维护自己的图库选择器，并且需要对实现保持完全控制，请调整实现以使用新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。如果您的应用不使用新权限，系统会以兼容模式运行您的应用。

Experiencia del usuario

Notificaciones de intent de pantalla completa seguras

Con Android 11 (nivel de API 30), cualquier app podía usar Notification.Builder.setFullScreenIntent para enviar intents de pantalla completa mientras el teléfono estaba bloqueado. Para otorgarlo de forma automática durante la instalación de la app, declara el permiso USE_FULL_SCREEN_INTENT en AndroidManifest.

Las notificaciones de los intents de pantalla completa están diseñadas para las notificaciones de prioridad extremadamente alta que requieren la atención inmediata del usuario, como una llamada entrante o la configuración de la alarma que establece el usuario. En el caso de las apps orientadas a Android 14 (nivel de API 34) y versiones posteriores, las apps que pueden usar este permiso se limitan a aquellas que solo proporcionan llamadas y alarmas. Google Play Store revoca los permisos USE_FULL_SCREEN_INTENT predeterminados para las apps que no se ajustan a este perfil. El plazo para estos cambios en las políticas es el 31 de mayo de 2024.

Este permiso permanece habilitado para las apps que se instalan en el teléfono antes de que el usuario actualice a Android 14. Los usuarios pueden activar o desactivar este permiso.

Puedes usar la nueva API de NotificationManager.canUseFullScreenIntent para verificar si tu app tiene el permiso. De lo contrario, la app puede usar el nuevo intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT para iniciar la página de configuración en la que los usuarios pueden otorgar el permiso.

Seguridad

Restricciones a intents implícitos y pendientes

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 会通过以下方式限制应用向内部应用组件发送隐式 intent：

• 隐式 intent 只能传送到导出的组件。应用必须使用显式 intent 传送到未导出的组件，或将该组件标记为已导出。
• 如果应用通过未指定组件或软件包的 intent 创建可变待处理 intent，系统会抛出异常。

这些变更可防止恶意应用拦截意在供应用内部组件使用的隐式 intent。

例如，下面是可以在应用的清单文件中声明的 intent 过滤器：

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

如果应用尝试使用隐式 intent 启动此 activity，则系统会抛出 ActivityNotFoundException 异常：

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

如需启动非导出的 activity，应用应改用显式 intent：

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

Los receptores de transmisiones registradas en el tiempo de ejecución deben especificar el comportamiento de exportación

Las apps y los servicios que se orientan a Android 14 (nivel de API 34) o versiones posteriores y usan receptores registrados en el contexto deben especificar una marca para indicar si el receptor se debe exportar a todas las otras apps en el dispositivo: RECEIVER_EXPORTED o RECEIVER_NOT_EXPORTED, respectivamente. Este requisito ayuda a proteger las apps de las vulnerabilidades de seguridad aprovechando las funciones de estos receptores que se introdujeron en Android 13.

Excepción para receptores que solo reciben transmisiones del sistema

Si tu app registra un receptor solo para las transmisiones del sistema a través de métodos Context#registerReceiver, como Context#registerReceiver(), no debería especificar una marca cuando registra el receptor.

Carga más segura del código dinámico

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，并且使用动态代码加载 (DCL) 功能，则必须将所有动态加载的文件标记为只读。否则，系统会抛出异常。我们建议应用尽可能避免动态加载代码，因为这样做会大大增加应用因代码注入或代码篡改而遭到入侵的风险。

如果必须动态加载代码，请使用以下方法，在动态文件（例如 DEX、JAR 或 APK 文件）打开并写入任何内容之前立即将其设为只读：

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

处理已存在的动态加载文件

为防止系统对现有动态加载的文件抛出异常，我们建议您先删除并重新创建文件，然后再尝试在应用中重新动态加载这些文件。重新创建文件时，请按照上述指南在写入时将文件标记为只读。或者，您可以将现有文件重新标记为只读，但在这种情况下，我们强烈建议您先验证文件的完整性（例如，对照可信值检查文件的签名）以保护应用免遭恶意操作的影响。

Restricciones adicionales sobre el inicio de actividades en segundo plano

En el caso de las apps orientadas a Android 14 (nivel de API 34) y versiones posteriores, el sistema restringe aún más el momento en que las apps pueden iniciar actividades en segundo plano:

• Cuando una app envía un objeto PendingIntent con PendingIntent#send() o métodos similares, esta ahora debe aceptar si desea otorgar sus propios privilegios de inicio de la actividad en segundo plano para iniciar el intent pendiente. Para hacerlo, la app debe pasar un paquete ActivityOptions con setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
• Cuando una app visible vincula un servicio de otra app que está en segundo plano con el método bindService(), esta ahora debe aceptar si desea otorgar sus propios privilegios de inicio de la actividad en segundo plano para el servicio vinculado. Para hacerlo, la app debe incluir la marca BIND_ALLOW_ACTIVITY_STARTS cuando llame al método bindService().

Estos cambios expanden el conjunto existente de restricciones para proteger a los usuarios, ya que evitan que las apps maliciosas abusen de las APIs para iniciar actividades disruptivas en segundo plano.

Salto de directorio del archivo ZIP

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 会通过以下方式防止 Zip 路径遍历漏洞：如果 Zip 文件条目名称包含“..”或以“/”开头，ZipFile(String) 和 ZipInputStream.getNextEntry() 会抛出 ZipException。

应用可以通过调用 dalvik.system.ZipPathValidator.clearCallback() 选择停用此验证。

Se requiere el consentimiento del usuario para cada sesión de captura de MediaProjection.

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，在以下任一情况下，MediaProjection#createVirtualDisplay 都会抛出 SecurityException：

• 您的应用会缓存从 MediaProjectionManager#createScreenCaptureIntent 返回的 Intent，并多次将其传递给 MediaProjectionManager#getMediaProjection。
• 您的应用在同一 MediaProjection 实例上多次调用 MediaProjection#createVirtualDisplay。

您的应用必须在每次捕获会话之前征求用户同意。单次捕获会话是对 MediaProjection#createVirtualDisplay 的单次调用，并且每个 MediaProjection 实例只能使用一次。

处理配置变更

如果您的应用需要调用 MediaProjection#createVirtualDisplay 来处理配置更改（例如屏幕方向或屏幕大小更改），您可以按照以下步骤更新现有 MediaProjection 实例的 VirtualDisplay：

1. 使用新的宽度和高度调用 VirtualDisplay#resize。
2. 向 VirtualDisplay#setSurface 提供新的 Surface，并为其指定新的宽度和高度。

注册回调

您的应用应注册回调，以处理用户不同意继续拍摄会话的情况。为此，请实现 Callback#onStop，并让应用释放所有相关资源（例如 VirtualDisplay 和 Surface）。

如果您的应用未注册此回调，当您的应用调用它时，MediaProjection#createVirtualDisplay 会抛出 IllegalStateException。

Actualización de restricciones que no pertenecen al SDK

Android 14 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 14 为目标平台，其中一些变更可能不会立即对您产生影响。然而，虽然您目前仍可以使用一些非 SDK 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。然而，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，应请求新的公共 API。

Para obtener más información sobre los cambios implementados en esta versión de Android, consulta Actualizaciones a las restricciones de interfaces que no pertenecen al SDK en Android 14. Para obtener más información sobre interfaces que no pertenecen al SDK en general, consulta Restricciones en interfaces que no pertenecen al SDK.