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 también de revisar la lista de cambios de comportamiento que afectan a todas las apps que se ejecutan en Android 14, independientemente de la targetSdkVersion de la app.

Funcionalidad principal

Los tipos de servicio en primer plano son obligatorios

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

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

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

Aplicación del permiso BLUETOOTH_CONNECT en BluetoothAdapter

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

Este método ya requería el permiso BLUETOOTH_CONNECT, pero no se aplicó. Asegúrate de que la app declare BLUETOOTH_CONNECT en su 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 la devolución de llamada y el comportamiento de red

Desde su lanzamiento, JobScheduler espera que tu app regrese de onStartJob o onStopJob en pocos segundos. Antes de Android 14, si un trabajo se ejecuta durante demasiado tiempo, se detiene y falla de forma silenciosa. Si tu app se orienta a Android 14 (nivel de API 34) o versiones posteriores, y excede 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 hay respuesta a onStopJob". Considera migrar a WorkManager, que proporciona compatibilidad con el procesamiento asíncrono o migrar cualquier trabajo pesado a un subproceso en segundo plano.

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

API de lanzamiento de tarjetas

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

Privacidad

Acceso parcial a fotos y videos

En Android 14, se introduce 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.

Este cambio solo se habilita si tu app se orienta a Android 14 (nivel de API 34) o versiones posteriores. Si aún no usas el selector de fotos, te recomendamos que lo implementes en tu app para proporcionar una experiencia coherente para seleccionar 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 mediante permisos de almacenamiento y necesitas mantener el control total sobre tu 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 la ejecuta en un modo de compatibilidad.

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) o versiones posteriores, las apps que tienen permitido usar este permiso se limitan a aquellas que proporcionan llamadas y alarmas únicamente. Google Play Store revoca los permisos USE_FULL_SCREEN_INTENT predeterminados para las apps que no se ajustan a este perfil. La fecha límite para estos cambios de 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 componentes internos de 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 se puede declarar 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:

Kotlin

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

Java

// Throws an 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 en su lugar:

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

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

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

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

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

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

Restricciones adicionales sobre el inicio de actividades en segundo plano

En el caso de las apps que se orientan a Android 14 (nivel de API 34) o 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, debe habilitar la opción 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(), la app visible ahora debe aceptar si desea otorgar sus propios privilegios de inicio de la actividad en segundo plano al 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 文件条目名称包含“..”或以“/”开头，则 ZipInputStream.getNextEntry() 会抛出 ZipException。ZipFile(String)

应用可以通过调用 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。

如需详细了解此 Android 版本中的变更，请参阅 Android 14 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息，请参阅对非 SDK 接口的限制。