一、前臺服務類型

targetSdkVersion 34 的情況下，必須為應用內的每個前臺服務(foreground-services) 指定至少一種前臺服務類型。

前臺服務類型是在Android10引入的，通過android:foregroundServiceType 可以指定 的服務類型，可供選擇的前臺服務類型有：

camera
connectedDevice
dataSync
health
location
mediaPlayback
mediaProjection
microphone
phoneCall
remoteMessaging
shortService
specialUse
systemExempted

二、Android14應用安全

1.對pending/implicit intent的限制

對于面向Android14的應用，Android通過以下方式限制應用向內部應用組件發送隱式intent：

(1).隱式intent僅傳遞給導出的組件，應用必須使用明確的intent來交付給未導出的組件，或者將組件標記為已導出(exported)。

(2).如果應用創建一個mutable pending intent，但intent未指定組件或包，系統現在會拋出異常。

這些更改可防止惡意應用攔截只供給用內部組件使用的隱式intent，例如：

如果應用嘗試使用隱式intent啟動該 activity，則會拋出異常：

//Throws an exception when targeting Android 14.
context.startActivity(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)

2.運行時注冊的廣播接收器必須指定導出行為

以Android14為目標，并使用context-registered

receivers(ContextCompat.registerReceiver)應用和服務的需要指定一個標志，以指示接收器是否應導出到設備上的所有其他應用:分別為RECEIVER_EXPORTED或RECEIVER_NOT_EXPORTED。

val filter = IntentFilter(APP_SPECIFIC_BROADCAST)
val listenToBroadcastsFromOtherApps = false
val receiverFlags = if (listenToBroadcastsFromOtherApps) {
   ContextCompat.RECEIVER_EXPORTED
} else {
   ContextCompat.RECEIVER_NOT_EXPORTED
}
ContextCompat.registerReceiver(context, br, filter, receiverFlags)

3.僅接收系統廣播的接收器例外

如果應用僅通過Context#registerReceiver方法為系統廣播注冊接收器時，那么它可以不在注冊接收器時指定標志,例如 android.intent.action.AIRPLANE_MODE。

4.更安全的動態代碼加載

如果應用以Android14為目標平臺并使用動態代碼加載(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)

5.處理已存在的動態加載文件

為防止現有動態加載文件拋出異常，我們建議可以嘗試在應用中再次動態加載文件之前，刪除并重新創建這些文件。

重新創建文件時，請按照前面的指導在寫入時將文件標記為只讀，或者將現有文件重新標記為只讀，但在這種情況下，強烈建議首先驗證文件的完整性(例如，通過根據可信值檢查文件的簽名)，以幫助保護應用免受惡意操作。

6.Zip path traversal

對于針對Android14的應用，Android通過以下方式防止Zip路徑遍歷漏洞

如果zip文件條目名稱包含".."或以"/"開頭，則ZipFile(String)和ZipInputStream.getNextEntry()會拋出一個ZipException。

應用可以通過調用dalvik.system.ZipPathValidator.clearCallback()選擇退出驗證。

7.從后臺啟動活動的附加限制

針對Android14的應用，系統進一步限制了應用在后臺啟動Activity的時間

(1).當應用使用PendingIntent#send()發送PendingIntent以及類似行為時，如果應用想要授予其自己的后臺service啟動權限以啟動pending intent，則該應用現在必須選擇加入一個 ActivityOptions，具體為帶有

setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)

(2).當一個可見應用使用bindService()綁定另一個在后臺運行的應用的服務時，如果該可見應用想要將其自己的后臺activity啟動權限授予綁定服務，則它現在必須選擇加入 BIND_ALLOW_ACTIVITY_STARTS 標志。

這些更改擴展了現有的一組限制 ，通過防止惡意應用濫用 API 從后臺啟動破壞性活動來保護用戶。

8.Android14將禁止修改系統內置根證書

Android14不再允許開發者修改系統內置根證書進行調試，這意味著開發者無法通過諸如替換證書或中間人劫持的方式來檢測某些流量。

Android系統的證書存儲庫位于/system/etc/security/cacerts/，盡管從Android7.0開始開發者無法直接修改證書庫，但如果root了那么還可以修改證書庫路徑，直接注入自己需要的證書，比如自簽名的泛證書。

而在Android14中，谷歌做了一項可以快速反應的安全措施：通過Google Play更新安卓系統的證書庫。

這樣做也不是沒有原因，以前證書綁定在系統里，谷歌無法直接更新，這導致有些證書被吊銷后谷歌也無法及時操作，這也導致注入Let's Encrypt 因為需要兼容舊版安卓系統，不得不推遲證書更新，因為新證書不受舊版安卓系統的信任。

后續谷歌可以隨時通過Google Play更新證書庫，包括加載新的ROOT CA和吊銷某些ROOT CA，這讓谷歌可以快速應對CA行業的某些問題。

然而問題在于這種新的更新方法不再從/system/etc/security/cacerts/讀取證書，而是從另一個路徑/apex/com.android.conscrypt/cacerts/讀取證書。

而APEX容器背后確切的機制很難完全理解，因為存在很多細節沒有公布出來，而在測試的時候開發者也發現嘗試修改這個目錄是沒用的，系統會直接忽略修改。

因此即便注入自簽名的證書也無法被系統讀取，所以也沒法再使用中間人之類的手段進行劫持，來達到調試某些TLS流量的目的。

好消息是Android14的這項變化有助于大幅度提高Android對CA行業的響應速度，例如快速吊銷或信任證書，這將有助于提高Android設備的安全性。 ?
?
壞消息就是對開發者和安全研究人員來說這就很難受了，因為無法讓系統信任自簽名證書，這將對調試和安全分析工作產生嚴重影響。

審核編輯：湯梓紅