一、前臺服務類型

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通過以下方式限制應用向內部應用組件發(fā)送隱式intent：

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

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

這些更改可防止惡意應用攔截只供給用內部組件使用的隱式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.僅接收系統(tǒng)廣播的接收器例外

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

4.更安全的動態(tài)代碼加載

如果應用以Android14為目標平臺并使用動態(tài)代碼加載(DCL)，則所有動態(tài)加載的文件都必須標記為只讀，否則，系統(tǒng)會拋出異常。

建議應用盡可能避免動態(tài)加載代碼，因為這樣做會大大增加應用因代碼注入或代碼篡改而受到危害的風險。

如果必須動態(tài)加載代碼，請使用以下方法將動態(tài)加載的文件(例如: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.處理已存在的動態(tài)加載文件

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

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

6.Zip path traversal

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

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

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

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

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

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

setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)

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

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

8.Android14將禁止修改系統(tǒng)內置根證書

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

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

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

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

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

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

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

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

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

審核編輯：湯梓紅