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）或更高版本为目标平台，则必须为应用中的每个前台服务至少指定一项前台服务类型。您应选择一个能代表应用用例的前台服务类型。系统需要特定类型的前台服务满足特定用例。

注意：Android 14 针对运行状况和远程消息传递用例引入了前台服务类型。系统还为简短服务、特殊用例和系统豁免保留新的类型。

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

Aplicación forzosa del permiso BLUETOOTH_CONNECT en BluetoothAdapter

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 14 会在调用 BluetoothAdapter getProfileConnectionState() 方法时强制执行 BLUETOOTH_CONNECT 权限。

此方法已要求 BLUETOOTH_CONNECT 权限，但未强制执行。确保您的应用在应用的 AndroidManifest.xml 文件中声明 BLUETOOTH_CONNECT，如以下代码段所示，并在调用 getProfileConnectionState 之前检查用户是否已授予相应权限。

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

Actualizaciones de OpenJDK 17

Android 14 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致，包括适合应用和平台开发者的库更新和 Java 17 语言支持。

以下变更可能会影响应用兼容性：

• 对正则表达式的更改：现在，为了更严格地遵循 OpenJDK 的语义，不允许无效的组引用。您可能会看到 java.util.regex.Matcher 类抛出 IllegalArgumentException 的新情况，因此请务必测试应用中使用正则表达式的情形。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换 DISALLOW_INVALID_GROUP_REFERENCE 标志。
• UUID 处理：现在，验证输入参数时，java.util.UUID.fromString() 方法会执行更严格的检查，因此您可能会在反序列化期间看到 IllegalArgumentException。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换 ENABLE_STRICT_VALIDATION 标志。
• ProGuard 问题：有时，在您尝试使用 ProGuard 缩减、混淆和优化应用时，添加 java.lang.ClassValue 类会导致问题。问题源自 Kotlin 库，该库会根据 Class.forName("java.lang.ClassValue") 是否会返回类更改运行时行为。如果您的应用是根据没有 java.lang.ClassValue 类的旧版运行时开发的，则这些优化可能会将 computeValue 方法从派生自 java.lang.ClassValue 的类中移除。

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

自从引入后，JobScheduler 期望您的应用从 onStartJob 或 onStopJob。在 Android 14 之前，如果作业运行时间过长，系统会停止作业并静默失败。如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台， 超过在主线程上授予的时间，应用会触发 ANR 显示“没有响应 onStartJob”错误消息或 “onStopJob没有回复”。

此 ANR 可能是由以下 2 种情况造成的： 1.有工作阻塞主线程，阻止回调 onStartJob 或者onStopJob在预期时间内执行并完成。 2. 开发者在 JobScheduler 中运行阻塞工作 回调 onStartJob 或 onStopJob，阻止从 在预期的时限内完成

要解决第 1 个问题，您需要进一步调试阻塞主线程的因素 您可以使用以下代码 ApplicationExitInfo#getTraceInputStream()，用于获取 Tombstone ANR 发生时的跟踪信息如果您能够手动重现 ANR 问题 您可以录制系统轨迹，并使用 Android Studio 或 Perfetto，以便更好地了解应用上运行的 在发生 ANR 时调用主线程 请注意，直接使用 JobScheduler API 或使用 androidx 库 WorkManager 时可能会发生这种情况。

如需解决问题 2，请考虑迁移到 WorkManager，它支持将 onStartJob 或 onStopJob 中的任何处理封装在异步线程中。

JobScheduler 还引入了一项要求，即如果使用 setRequiredNetworkType 或 setRequiredNetwork 约束条件，则必须声明 ACCESS_NETWORK_STATE 权限。如果您的应用未声明 ACCESS_NETWORK_STATE 权限 Android 14 或更高版本，则会导致 SecurityException。

API de lanzamiento de tarjetas

En el caso de las apps orientadas a 14 y versiones posteriores, TileService#startActivityAndCollapse(Intent) dejó de estar disponible y ahora arroja una excepción cuando se la llama. Si tu app inicia actividades desde tarjetas, usa TileService#startActivityAndCollapse(PendingIntent) en su lugar.

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

En el caso de las apps que se orientan a Android 14 (nivel de API 34) o versiones posteriores, Android restringe el envío de intents implícitos a los componentes internos de las apps de las siguientes maneras:

• Los intents implícitos solo se entregan a los componentes exportados. Las apps deben usar un intent explícito para entregar componentes no exportados o marcar el componente como exportado.
• Si una app crea un intent pendiente mutable con un intent que no especifica ningún componente ni paquete, el sistema arroja una excepción.

Estos cambios evitan que las apps maliciosas intercepten intents implícitos destinados a que los usen los componentes internos de una app.

Por ejemplo, el siguiente es un filtro de intents que podría declararse en el archivo de manifiesto de tu app:

<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>

Si tu app intenta iniciar esta actividad con un intent implícito, se arrojará una excepción ActivityNotFoundException:

Kotlin

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

Java

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

Para iniciar la actividad no exportada, tu app debe usar un intent explícito:

Kotlin

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

Java

// 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

以 Android 14（API 级别 34）或更高版本为目标平台并使用上下文注册的接收器的应用和服务必须指定以下标志，以指明接收器是否应导出到设备上的所有其他应用：RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED。此要求有助于利用 Android 13 中引入的这些接收器的功能，来保护应用免受安全漏洞的影响。

仅接收系统广播的接收器的例外情况

如果您的应用仅通过 Context#registerReceiver 方法（例如 Context#registerReceiver()）针对系统广播注册接收器，那么它在注册接收器时不应指定标志。

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

Si tu app está orientada a Android 14 (nivel de API 34) o versiones posteriores y usa la carga dinámica de códigos (DCL), todos los archivos que se carguen de esta forma se deben marcar como de solo lectura. De lo contrario, el sistema arrojará una excepción. Recomendamos que las apps eviten la carga dinámica de códigos siempre que sea posible, ya que de esta manera aumenta, en gran medida, el riesgo de que una app pueda verse comprometida por la inserción o la manipulación de código.

Si debes cargar un código de forma dinámica, usa el siguiente enfoque para establecer como de solo lectura el archivo que se cargará de esta forma (como un archivo DEX, JAR o APK) en cuanto este se abra y antes de que se escriba cualquier contenido:

Kotlin

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)

Java

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);

Cómo controlar archivos cargados de forma dinámica que ya existen

Para evitar que se arrojen excepciones para los archivos cargados de forma dinámica que ya existen, te recomendamos que borres los archivos y vuelvas a crearlos antes de intentar volver a cargarlos de forma dinámica en tu app. Cuando vuelvas a crearlos, sigue las instrucciones anteriores para marcar los archivos como de solo lectura en el momento de la escritura. Como alternativa, puedes volver a etiquetar los archivos existentes como de solo lectura, pero, en este caso, te recomendamos que primero verifiques la integridad de los archivos (por ejemplo, verifica la firma del archivo en comparación con un valor confiable) para proteger tu app de acciones maliciosas.

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

En el caso de las apps orientadas a Android 14 (nivel de API 34) o versiones posteriores, MediaProjection#createVirtualDisplay arroja una SecurityException en cualquiera de las siguientes situaciones:

• Tu app almacena en caché el Intent que se muestra desde MediaProjectionManager#createScreenCaptureIntent y lo pasa varias veces a MediaProjectionManager#getMediaProjection.
• Tu app invoca MediaProjection#createVirtualDisplay varias veces en la misma instancia de MediaProjection.

Tu app debe solicitarle al usuario que dé su consentimiento antes de cada sesión de captura. Una sola sesión de captura es una sola invocación en MediaProjection#createVirtualDisplay, y cada instancia de MediaProjection se debe usar solo una vez.

Cómo administrar los cambios en la configuración

Si tu app necesita invocar MediaProjection#createVirtualDisplay para controlar los cambios de configuración (como el cambio de orientación o tamaño de la pantalla), puedes seguir estos pasos para actualizar el VirtualDisplay de la instancia MediaProjection existente:

1. Invoca VirtualDisplay#resize con el nuevo ancho y la nueva altura.
2. Proporciona un nuevo Surface con el nuevo ancho y la nueva altura a VirtualDisplay#setSurface.

Cómo registrar una devolución de llamada

Tu app debe registrar una devolución de llamada para controlar los casos en los que el usuario no otorga su consentimiento para continuar con una sesión de captura. Para ello, implementa Callback#onStop y haz que tu app libere los recursos relacionados (como VirtualDisplay y Surface).

Si tu app no registra esta devolución de llamada, MediaProjection#createVirtualDisplay arroja una IllegalStateException cuando la invoca.

Actualización de restricciones que no pertenecen al SDK

Android 14 incluye listas actualizadas de este tipo de interfaces que están basadas en la colaboración con desarrolladores de Android y las pruebas internas más recientes. Siempre que sea posible, nos aseguramos de que las alternativas públicas estén disponibles antes de restringir las interfaces que no pertenecen al SDK.

Si tu app no está orientada a Android 14, es posible que algunos de estos cambios no te afecten de inmediato. Sin embargo, aunque actualmente puedes usar algunas interfaces que no pertenecen al SDK (según el nivel de API objetivo al que esté orientada la app), utilizar cualquier método o campo que no pertenezca al SDK siempre implica un gran riesgo de error para la app.

En caso de no saber con certeza si tu app usa este tipo de interfaces, puedes probarla para verificarlo. Si tu app depende de interfaces que no pertenezcan al SDK, deberías planificar una migración hacia otras alternativas que sí lo hagan. Sin embargo, sabemos que algunas apps tienen casos prácticos válidos para usarlas. Si no encuentras una alternativa al uso de una interfaz que no pertenece al SDK para una función de tu app, deberías solicitar una nueva API pública.

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.