和先前版本一樣,Android 14 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 14 (API 級別 34) 以上版本的應用程式。如果您的應用程式指定 Android 14 以上版本,建議您視情況修改應用程式,以支援這些行為。
此外,無論應用程式的 targetSdkVersion
為何,請務必查看對所有 Android 14 應用程式有影響的行為變更清單。
核心功能
必須提供前景服務類型
如果您的應用程式以 Android 14 (API 級別 34) 以上版本為目標,則必須為應用程式中的每個前景服務指定至少一個前景服務類型。您應選擇代表應用程式用途的前景服務類型。系統會預期具有特定類型的前景服務,以滿足特定用途。
如果應用程式的用途與上述任一類型無關,強烈建議您遷移邏輯,以便使用 WorkManager 或使用者啟動的資料移轉作業。
在 BluetoothAdapter 中強制執行 BLUETOOTH_CONNECT 權限
針對指定 Android 14 (API 級別 34) 以上版本的應用程式呼叫 BluetoothAdapter
getProfileConnectionState()
方法,Android 14 會強制執行 BLUETOOTH_CONNECT
權限。
這個方法已要求 BLUETOOTH_CONNECT
權限,但未強制執行。請務必在應用程式的 AndroidManifest.xml
檔案中宣告 BLUETOOTH_CONNECT
,如以下程式碼片段所示,並在呼叫 getProfileConnectionState
之前檢查使用者是否已授予權限。
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
OpenJDK 17 更新
Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.
A few of these changes can affect app compatibility:
- Changes to regular expressions: Invalid group references are now
disallowed to more closely follow the semantics of OpenJDK. You might see
new cases where an
IllegalArgumentException
is thrown by thejava.util.regex.Matcher
class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle theDISALLOW_INVALID_GROUP_REFERENCE
flag using the compatibility framework tools. - UUID handling: The
java.util.UUID.fromString()
method now does more strict checks when validating the input argument, so you might see anIllegalArgumentException
during deserialization. To enable or disable this change while testing, toggle theENABLE_STRICT_VALIDATION
flag using the compatibility framework tools. - ProGuard issues: In some cases, the addition of the
java.lang.ClassValue
class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whetherClass.forName("java.lang.ClassValue")
returns a class or not. If your app was developed against an older version of the runtime without thejava.lang.ClassValue
class available, then these optimizations might remove thecomputeValue
method from classes derived fromjava.lang.ClassValue
.
JobScheduler 會強化回呼和網路行為
Since its introduction, JobScheduler expects your app to return from
onStartJob
or onStopJob
within a few seconds. Prior to Android 14,
if a job runs too long, the job is stopped and fails silently.
If your app targets Android 14 (API level 34) or higher and
exceeds the granted time on the main thread, the app triggers an ANR
with the error message "No response to onStartJob
" or
"No response to onStopJob
".
This ANR may be a result of 2 scenarios:
1. There is work blocking the main thread, preventing the callbacks onStartJob
or onStopJob
from executing and completing within the expected time limit.
2. The developer is running blocking work within the JobScheduler
callback onStartJob
or onStopJob
, preventing the callback from
completing within the expected time limit.
To address #1, you will need to further debug what is blocking the main thread
when the ANR occurs, you can do this using
ApplicationExitInfo#getTraceInputStream()
to get the tombstone
trace when the ANR occurs. If you're able to manually reproduce the ANR,
you can record a system trace and inspect the trace using either
Android Studio or Perfetto to better understand what is running on
the main thread when the ANR occurs.
Note that this can happen when using JobScheduler API directly
or using the androidx library WorkManager.
To address #2, consider migrating to WorkManager, which provides
support for wrapping any processing in onStartJob
or onStopJob
in an asynchronous thread.
JobScheduler
also introduces a requirement to declare the
ACCESS_NETWORK_STATE
permission if using setRequiredNetworkType
or
setRequiredNetwork
constraint. If your app does not declare the
ACCESS_NETWORK_STATE
permission when scheduling the job and is targeting
Android 14 or higher, it will result in a SecurityException
.
啟動圖塊 API
For apps targeting 14 and higher,
TileService#startActivityAndCollapse(Intent)
is deprecated and now throws
an exception when called. If your app launches activities from tiles, use
TileService#startActivityAndCollapse(PendingIntent)
instead.
隱私權
相片和影片的部分存取權
Android 14 推出「Selected Photos Access」功能,讓使用者可授予應用程式存取媒體庫中特定圖片和影片的權限,而非授予特定類型的所有媒體存取權。
只有在應用程式指定 Android 14 (API 級別 34) 以上版本為目標版本時,才能啟用這項異動。如果您尚未使用相片挑選工具,建議您在應用程式中導入這項工具,以便提供一致的圖片和影片選取體驗,同時提升使用者隱私權,且無須要求任何儲存空間權限。
如果您使用儲存空間權限維護自己的相片庫挑選器,且需要完全掌控實作方式,請調整實作方式,以便使用新的 READ_MEDIA_VISUAL_USER_SELECTED
權限。如果應用程式未使用新權限,系統會以相容模式執行應用程式。
使用者體驗
安全的全螢幕意圖通知
With Android 11 (API level 30), it was possible for any app to use
Notification.Builder.setFullScreenIntent
to send full-screen
intents while the phone is locked. You could auto-grant this on app install by
declaring USE_FULL_SCREEN_INTENT
permission in the
AndroidManifest.
Full-screen intent notifications are designed for extremely high-priority
notifications demanding the user's immediate attention, such as an incoming
phone call or alarm clock settings configured by the user. For apps targeting
Android 14 (API level 34) or higher, apps that are allowed to use this
permission are limited to those that provide calling and alarms only. The Google
Play Store revokes default USE_FULL_SCREEN_INTENT
permissions for any apps
that don't fit this profile. The deadline for these policy changes is May 31,
2024.
This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.
You can use the new API
NotificationManager.canUseFullScreenIntent
to check if your app
has the permission; if not, your app can use the new intent
ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT
to launch the settings
page where users can grant the permission.
安全性
隱含和待處理意圖的限制
針對以 Android 14 (API 級別 34) 以上版本為目標的應用程式,Android 會透過以下方式,限制應用程式傳送隱含意圖至內部應用程式元件:
- 隱含意圖只會傳送至匯出的元件。應用程式必須使用明確意圖傳送至未匯出的元件,或將元件標示為已匯出。
- 如果應用程式建立可變動的待處理意圖,且意圖未指定元件或套件,系統會擲回例外狀況。
這些異動可防止惡意應用程式攔截由應用程式內部元件使用的隱含意圖。
例如,以下是可在應用程式資訊清單檔案中宣告的意圖篩選器:
<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>
如果您的應用程式嘗試以隱含意圖啟動這個活動,系統會擲回 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"));
若要啟動非匯出活動,應用程式應改用明確意圖:
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);
已註冊執行階段的廣播接收器必須指定匯出行為
應用程式和服務若以 Android 14 (API 級別 34) 以上版本為目標版本,並使用已註冊使用情境的接收器,必須利用 RECEIVER_EXPORTED
或 RECEIVER_NOT_EXPORTED
標記,指定應否將接收器匯出至裝置上其他所有應用程式。透過 Android 13 針對這些接收器引進的功能,上述要求有助於避免應用程式出現安全漏洞。
僅接收系統廣播訊息的接收器除外
如果應用程式僅透過 Context#registerReceiver
方法 (例如 Context#registerReceiver()
),為系統廣播訊息註冊接收器,則註冊接收器時不應指定標記。
更安全的動態程式碼載入
如果您的應用程式指定 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);
處理已存在的動態載入檔案
為避免現有的動態載入檔案擲回例外狀況,建議您先刪除並重新建立檔案,然後再嘗試在應用程式中動態載入這些檔案。重新建立檔案時,請按照上述指示,在寫入時將檔案標記為唯讀。此外,也可以 將現有檔案重新標示為唯讀 建議您先驗證檔案的完整性 (例如,使用 檢查檔案簽名是否符合信任的值),協助您保護應用程式 不受惡意動作的影響
從背景啟動活動的額外限制
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,系统会进一步限制允许应用在后台启动 activity 的时间:
- 现在,当应用使用
PendingIntent#send()
或类似方法发送PendingIntent
时,如果它想要授予自己的后台 activity 启动待处理 intent 的启动特权,则必须选择启用。如需选择启用,应用应通过setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
传递ActivityOptions
软件包。 - 当可见应用使用
bindService()
方法绑定其他在后台应用的服务时,如果可见应用想要授予自己的后台 activity 对绑定服务的启动特权,则必须选择启用。如需选择启用,应用应在调用bindService()
方法时包含BIND_ALLOW_ACTIVITY_STARTS
标志。
这些更改扩大了一组现有限制条件的范围,目的是防止恶意应用滥用 API 以在后台启动干扰性活动,从而保护用户。
Zip Path Traversal
For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip
Path Traversal Vulnerability in the following way:
ZipFile(String)
and
ZipInputStream.getNextEntry()
throws a
ZipException
if zip file entry names contain ".." or start
with "/".
Apps can opt-out from this validation by calling
dalvik.system.ZipPathValidator.clearCallback()
.
每次 MediaProjection 擷取工作階段都必須取得使用者同意
For apps targeting Android 14 (API level 34) or higher, a SecurityException
is
thrown by MediaProjection#createVirtualDisplay
in either of the following
scenarios:
- Your app caches the
Intent
that is returned fromMediaProjectionManager#createScreenCaptureIntent
, and passes it multiple times toMediaProjectionManager#getMediaProjection
. - Your app invokes
MediaProjection#createVirtualDisplay
multiple times on the sameMediaProjection
instance.
Your app must ask the user to give consent before each capture session. A single
capture session is a single invocation on
MediaProjection#createVirtualDisplay
, and each MediaProjection
instance must
be used only once.
Handle configuration changes
If your app needs to invoke MediaProjection#createVirtualDisplay
to handle
configuration changes (such as the screen orientation or screen size changing),
you can follow these steps to update the VirtualDisplay
for the existing
MediaProjection
instance:
- Invoke
VirtualDisplay#resize
with the new width and height. - Provide a new
Surface
with the new width and height toVirtualDisplay#setSurface
.
Register a callback
Your app should register a callback to handle cases where the user doesn't grant
consent to continue a capture session. To do this, implement
Callback#onStop
and have your app release any related resources (such as
the VirtualDisplay
and Surface
).
If your app doesn't register this callback,
MediaProjection#createVirtualDisplay
throws an IllegalStateException
when your app invokes it.
更新非 SDK 限制
Android 14 包含更新后的受限非 SDK 接口列表(基于与 Android 开发者之间的协作以及最新的内部测试)。在限制使用非 SDK 接口之前,我们会尽可能确保有可用的公开替代方案。
如果您的应用并非以 Android 14 为目标平台,其中一些变更可能不会立即对您产生影响。然而,虽然您目前仍可以使用一些非 SDK 接口(具体取决于应用的目标 API 级别),但只要您使用任何非 SDK 方法或字段,终归存在导致应用出问题的显著风险。
如果您不确定自己的应用是否使用了非 SDK 接口,则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口,您应该开始计划迁移到 SDK 替代方案。然而,我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案,应请求新的公共 API。
如要進一步瞭解此 Android 版本中的變更,請參閱「Android 14 的非 SDK 介面限制更新內容」。如要進一步瞭解非 SDK 介面的一般資訊,請參閱「非 SDK 介面的限制」。