Android 12 需要更新適配點并不多，本篇主要介紹最常見的兩個需要適配的點：android:exported 和 SplashScreen 。
一、android:exported
它主要是設置 Activity 是否可由其他應用的組件啟動， “true” 則表示可以，而“false”表示不可以。
若為“
false”，則Activity只能由同一應用的組件或使用同一用戶 ID 的不同應用啟動。
當然不止是 Activity， Service 和 Receiver 也會有 exported 的場景。
一般情況下如果使用了 intent-filter，則不能將 exported 設置為“false”，不然在 Activity 被調用時系統會拋出 ActivityNotFoundException 異常。
相反如果沒有
intent-filter，那就不應該把Activity的exported設置為true，這可能會在安全掃描時被定義為安全漏洞。
而在 Android 12 的平臺上，也就是使用 targetSdkVersion 31 時，那么你就需要注意：
如果 Activity 、 Service 或 Receiver 使用 intent-filter ，并且未顯式聲明 android:exported 的值，App 將會無法安裝。
這時候你可能會選擇去 AndroidManifest 一個一個手動修改，但是如果你使用的 SDK 或者第三方庫沒有支持怎么辦？或者你想要打出不同 target 平臺的包？這時候下面這段 gradle 腳本可以給你省心：
com.android.tools.build:gradle:3.4.3 以下版本
/**
* 修改 Android 12 因為 exported 的構建問題
*/
android.applicationVariants.all { variant ->
variant.outputs.all { output ->
output.processResources.doFirst { pm ->
String manifestPath = output.processResources.manifestFile
def manifestFile = new File(manifestPath)
def xml = new XmlParser(false, true).parse(manifestFile)
def exportedTag = "android:exported"
///指定 space
def androidSpace = new groovy.xml.Namespace('http://schemas.android.com/apk/res/android', 'android')
def nodes = xml.application[0].'*'.findAll {
//挑選要修改的節點，沒有指定的 exported 的才需要增加
(it.name() == 'activity' || it.name() == 'receiver' || it.name() == 'service') && it.attribute(androidSpace.exported) == null
}
///添加 exported，默認 false
nodes.each {
def isMain = false
it.each {
if (it.name() == "intent-filter") {
it.each {
if (it.name() == "action") {
if (it.attributes().get(androidSpace.name) == "android.intent.action.MAIN") {
isMain = true
println("......................MAIN FOUND......................")
}
}
}
}
}
it.attributes().put(exportedTag, "${isMain}")
}
PrintWriter pw = new PrintWriter(manifestFile)
pw.write(groovy.xml.XmlUtil.serialize(xml))
pw.close()
}
}
}
com.android.tools.build:gradle:4.1.0 以上版本
/**
* 修改 Android 12 因為 exported 的構建問題
*/
android.applicationVariants.all { variant ->
variant.outputs.each { output ->
def processManifest = output.getProcessManifestProvider().get()
processManifest.doLast { task ->
def outputDir = task.multiApkManifestOutputDirectory
File outputDirectory
if (outputDir instanceof File) {
outputDirectory = outputDir
} else {
outputDirectory = outputDir.get().asFile
}
File manifestOutFile = file("$outputDirectory/AndroidManifest.xml")
println("----------- ${manifestOutFile} ----------- ")
if (manifestOutFile.exists() && manifestOutFile.canRead() && manifestOutFile.canWrite()) {
def manifestFile = manifestOutFile
///這里第二個參數是 false ，所以 namespace 是展開的，所以下面不能用 androidSpace，而是用 nameTag
def xml = new XmlParser(false, false).parse(manifestFile)
def exportedTag = "android:exported"
def nameTag = "android:name"
///指定 space
//def androidSpace = new groovy.xml.Namespace('http://schemas.android.com/apk/res/android', 'android')
def nodes = xml.application[0].'*'.findAll {
//挑選要修改的節點，沒有指定的 exported 的才需要增加
//如果 exportedTag 拿不到可以嘗試 it.attribute(androidSpace.exported)
(it.name() == 'activity' || it.name() == 'receiver' || it.name() == 'service') && it.attribute(exportedTag) == null
}
///添加 exported，默認 false
nodes.each {
def isMain = false
it.each {
if (it.name() == "intent-filter") {
it.each {
if (it.name() == "action") {
//如果 nameTag 拿不到可以嘗試 it.attribute(androidSpace.name)
if (it.attributes().get(nameTag) == "android.intent.action.MAIN") {
isMain = true
println("......................MAIN FOUND......................")
}
}
}
}
}
it.attributes().put(exportedTag, "${isMain}")
}
PrintWriter pw = new PrintWriter(manifestFile)
pw.write(groovy.xml.XmlUtil.serialize(xml))
pw.close()
}
}
}
}
com.android.tools.build:gradle:7.0.3 以下版本
調試中，目前 AGP 有奇怪的 Bug，XmlUtil 無法正常序列化。
這段腳本你可以直接放到 app/build.gradle 下執行，也可以單獨放到一個 gradle 文件之后 apply 引入，它的作用就是：
在打包過程中檢索所有沒有設置 exported 的組件，給他們動態配置上 exported。這里有個特殊需要注意的是，因為啟動 Activity 默認就是需要被 Launcher 打開的，所以 "android.intent.action.MAIN" 需要 exported 設置為 true 。（PS：應該是用 LAUNCHER 類別，這里故意用 MAIN）
如果有需要，還可以自己增加判斷設置了
"intent-filter"的才配置exported。
二、SplashScreen
Android 12 新增加了 SplashScreen 的 API，它包括啟動時的進入應用的動作、顯示應用的圖標畫面，以及展示應用本身的過渡效果。
它大概由如下 4 個部分組成，這里需要注意：
- 1 最好是矢量的可繪制對象，當然它可以是靜態或動畫形式。
- 2 是可選的，也就是圖標的背景。
- 與自適應圖標一樣，前景的三分之一被遮蓋 (3)。
- 4 就是窗口背景。
啟動畫面動畫機制由進入動畫和退出動畫組成。
- 進入動畫由系統視圖到啟動畫面組成，這由系統控制且不可自定義。
- 退出動畫由隱藏啟動畫面的動畫運行組成。如果要對其進行自定義，可以通過
SplashScreenView自定義。
更詳細的介紹這里就不展開了，有興趣的可以自己看官方的資料： https://developer.android.com/guide/topics/ui/splash-screen ，這里主要介紹下如何適配和使用的問題。
首先不管你的 TargetSDK 什么版本，當你運行到 Android 12 的手機上時，所有的 App 都會增加 SplashScreen 的功能。
如果你什么都不做，那 App 的 Launcher 圖標會變成 SplashScreen 界面的那個圖標，而對應的原主題下 windowBackground 屬性指定的顏色，就會成為 SplashScreen 界面的背景顏色。這個啟動效果在所有應用的冷啟動和熱啟動期間會出現。
其實不適配好像也沒啥問題。
關于如何遷移和使用 SplashScreen 可以查閱官方詳細文檔： https://developer.android.com/guide/topics/ui/splash-screen/migrate
另外還可以參考 《Jetpack新成員SplashScreen：打造全新的App啟動畫面》 這篇文章，文章詳細介紹了如果使用官方的 Jetpack 庫來讓這個效果適配到更低的 Target 平臺。
而正常情況下我們可以做的就是：
- 1、升級
compileSdkVersion 31、targetSdkVersion 31&buildToolsVersion '31.0.0' - 2、 添加依賴
implementation "androidx.core:core-splashscreen:1.0.0-alpha02" - 3、增加
values-v31的目錄 - 4、添加
styles.xml對應的主題，例如：
<resources>
<style name="LaunchTheme" parent="Theme.SplashScreen">
<item name="windowSplashScreenBackground">@color/splashScreenBackground</item>
<!--<item name="windowSplashScreenAnimatedIcon">@drawable/splash</item>-->
<item name="windowSplashScreenAnimationDuration">500</item>
<item name="postSplashScreenTheme">@style/AppTheme</item>
</style>
</resources>
- 5、給你的啟動
Activity添加這個主題，不同目錄下使用不同主題來達到適配效果。
PS: 我個人是一點都不喜歡這個玩意。
三、其他
1、通知中心又又又變了
Android 12 更改了可以完全自定義通知外觀和行為，以前自定義通知能夠使用整個通知區域并提供自己的布局和樣式，現在它行為變了。
使用 TargetSDK 為 31 的 App，包含自定義內容視圖的通知將不再使用完整通知區域；而是使用系統標準模板。
此模板可確保自定義通知在所有狀態下都與其他通知長得一模一樣，例如在收起狀態下的通知圖標和展開功能，以及在展開狀態下的通知圖標、應用名稱和收起功能，與 Notification.DecoratedCustomViewStyle 的行為幾乎完全相同。
2、Android App Links 驗證
Android App Links 是一種特殊類型的 DeepLink ，用于讓 Web 直接在 Android 應用中打開相應對應 App 內容而無需用戶選擇應用。使用它需要執行以下步驟：
如何使用可查閱：https://developer.android.com/training/app-links/verify-site-associations#auto-verification
使用 TargetSDK 為 31 的 App，系統對 Android App Links 的驗證方式進行了一些調整，這些調整會提升應用鏈接的可靠性。
如果你的 App 是依靠 Android App Links 驗證在應用中打開網頁鏈接，那么在為 Android App Links 驗證添加 intent 過濾器時，請確保使用正確的格式，尤其需要注意的是確保這些
intent-filter包含 BROWSABLE 類別并支持https方案。
3、安全和隱私設置
3.1、大致位置
使用 TargetSDK 為 31 的 App，用戶可以請求應用只能訪問大致位置信息。
如果 App 請求
ACCESS_COARSE_LOCATION但未請求ACCESS_FINE_LOCATION那么不會有任何影響。
TargetSDK 為 31 的 App 請求 ACCESS_FINE_LOCATION 運行時權限，還必須請求 ACCESS_COARSE_LOCATION 權限。當 App 同時請求這兩個權限時，系統權限對話框將為用戶提供以下新選項：
3.2、SameSite Cookie
Cookie 的 SameSite 屬性決定了它是可以與任何請求一起發送，還是只能與同站點請求一起發送。
- 沒有
SameSite屬性的 Cookie 被視為SameSite=Lax。 - 帶有
SameSite=None的 Cookie 還必須指定Secure屬性，這意味著它們需要安全的上下文，需要通過 HTTPS 發送。 - 站點的 HTTP 版本和 HTTPS 版本之間的鏈接現在被視為跨站點請求，因此除非將 Cookie 正確標記為
SameSite=None; Secure，否則 Cookie 不會被發送。
在 WebView devtools 中 切換界面標志 webview-enable-modern-cookie-same-site，可以在測試設備上手動啟用 SameSite 行為。
4、應用休眠
Android 12 在 Android 11（API 級別 30）中引入的自動重置權限行為 的基礎上進行了擴展。
如果 TargetSDK 為 31 的 App 用戶幾個月不打開，則系統會自動重置授予的所有權限并將App 置于休眠狀態。
更多可以查閱：https://developer.android.com/topic/performance/app-hibernation
四、最后
大致需要注意的就是這些，基本上其實除了 exproted 和 SplashScreen 之外，其他基本都不怎么需要適配，事實上 SplashScreen 我個人覺得會很遭產品嫌棄，畢竟 Material Design 在國內的待遇確實有點慘，沒辦法去掉 SplashScreen 這點估計需要和產品扯皮一段時間，不過產品和設計一般沒有 Android 手機，何況 Android 12，所以日后再說吧～
