1妨蛹、背景
最近對我的應用做了一些小的改動，準備上架 Google Play. 本以為小事一樁秸歧，沒想到要做非常多的改動灾锯。其中一個改動是谷歌要求 billing 庫升級到 4.0 及以上版本。此外贞铣，另一個比較大的改動是要求升級目標版本到 31.
我之前從 29 升級到 30 那次改動已經非常大了闹啦。這次應該不會太多改動，沒想到總歸還是 too young too simple, sometimes naive. 升級目標版本到 31 也不是那么簡單辕坝。下面是谷歌官方提供的兩個文章窍奋，分別詳細列舉了升級到版本的變更以及升級到 Android 12 的詳細的變更：
谷歌官方已經給了詳細的說明，這里我分享我在適配過程中遇到的問題和解決思路酱畅。
2琳袄、exported 屬性
本次適配需要做的最明顯的一個變更是修改 exported 屬性。這個屬性是之前就存在纺酸。我之前只在個別幾個 Service 屬性中使用了它窖逗。在 31 上開始要求開發(fā)者明確指定組件的 exported 屬性。
對于沒有聲明 exported 屬性的應用餐蔬，在啟動的過程中就會拋出如下異常碎紊，
[圖片上傳失敗...(image-6feea4-1670856933201)]
對于 exported 屬性佑附，你可以查看谷歌官方文檔的詳細解釋：android:exported
適配這個屬性并不難，只需要在 manifest 中明確指定每個組件的 exported 屬性即可仗考。一般來說音同，遵循如下原則：如果組件中使用了 intent-filter 等屬性，那么它大概率是需要對外暴露的秃嗜，此時需要將 exported 屬性直為 true权均，其他情況下置為 false 即可。锅锨。
對于引用的三方類庫中的 xml 屬性也可以通過覆寫聲明方式增加 exported 以兼容處理叽赊，
<activity android:name="com.squareup.leakcanary.internal.DisplayLeakActivity"
android:exported="false"/>
3、PendingIntent 的變動
這是一個隱藏的變動必搞，非潮刂福坑又不像 exported 屬性那樣容易被察覺。這邊變動主要是要求開發(fā)者指定在創(chuàng)建 PendingIntent 的時候傳入的 flags 參數(shù)的可變性恕洲。
這可以通過在之前的 flags 基礎上增加 FLAG_MUTABLE 和 FLAG_IMMUTABLE 兩個屬性來完成取劫。比如，之前我的 flags 是研侣，PendingIntent.FLAG_CANCEL_CURRENT谱邪，當我想將其修改為不可變的時候，就可以使用如下方式進行修改：
val flags = PendingIntent.FLAG_CANCEL_CURRENT or PendingIntent.FLAG_IMMUTABLE
它可能是需要改動最多的一個變動庶诡，根據(jù)我在項目中修改的情況來看惦银，以下幾個場景需要排查：
- 桌面小控件 Appwidget
- 通知 Notification
- 桌面快捷方式 Shortcut
同時從幾個方向來檢索項目中需要改動的地方：
- 直接檢索 PendingIntent 的 flags 的調用，比如
FLAG_ONE_SHOT, FLAG_NO_CREATE, FLAG_CANCEL_CURRENT和FLAG_UPDATE_CURRENT等末誓，建議查看源碼之后進行檢索 - PendingIntent 的靜態(tài)方法工廠扯俱，比如
PendingIntent.getBroadcast()、PendingIntent.getActivity()等喇澡。因為迅栅，獲取 PendingIntent 的時候需要指定 flags 參數(shù)。
那么晴玖，另一個問題來了读存，究竟什么時候該選擇 FLAG_MUTABLE，什么時候該選擇 FLAG_IMMUTABLE 呢呕屎？
它的注釋是這么說的让簿，
Flag indicating that the created PendingIntent should be immutable. This means that the additional intent argument passed to the send methods to fill in unpopulated properties of this intent will be ignored.
FLAG_IMMUTABLE only limits the ability to alter the semantics of the intent that is sent by send by the invoker of send. The creator of the PendingIntent can always update the PendingIntent itself via FLAG_UPDATE_CURRENT.
也就是說，FLAG_IMMUTABLE 的“不可變”指的是秀睛，當 PendingIntent 設置了 flags 為“不可變”之后尔当，調用它的 send 方法時傳入的 Intent 將會被忽略。
這里舉一個具體的場景蹂安，比如在列表類的 Appwidget 里椭迎，我們會使用 PendingIntent 設置列表的某一項的點擊事件锐帜。考慮到列表量比較大畜号，為每一個列表條目都聲明一個 PendingIntent 顯然開銷太大抹估。所以，Android 的處理機制是弄兜，
val views = RemoteViews(context.packageName, R.layout.layout_appwidget_note_list)
val i = Intent(context, MainActivity::class.java)
i.action = ACTION_APPWIDGET_NOTE_CLICK
val pi = PendingIntent.getActivity(context, 0, i, FLAG_CANCEL_CURRENT_MUTABLE)
views.setPendingIntentTemplate(R.id.lv, pi)
如上所示，首先定一個一個 PendingIntent瓷式，并調用 RemoteViews 的 setPendingIntentTemplate 方法傳入替饿，作為一個模版。然后在 RemoteViewsFactory 的 getViewAt 方法中為每個列表項設置點擊時的 Intent贸典，
val row = RemoteViews(context.packageName, R.layout.item_appwidget_note)
val i = Intent().putExtras(extras)
row.setOnClickFillInIntent(R.id.root, i)
當用戶觸發(fā)了點擊事件的時候视卢，系統(tǒng)會在調用 PendingIntent 的 send 方法時將 Intent 傳入并喚起組件。此時廊驼，如果我們將 PendingIntent 的 flags 設置為 FLAG_IMMUTABLE据过，那么這里發(fā)送時傳入的 Intent 參數(shù)將被忽略，因此可能導致雖然喚起了其他組件妒挎，但是參數(shù)丟失的情況绳锅。而對于那種，聲明 PendingIntent 時就傳入了 Intent 的時候酝掩，一般來說不需要設置為 FLAG_MUTABLE 的鳞芙。
以上是 PendingIntent 的改動，剛好在我的項目里兩種情況都有遇到期虾，所以詳細分析了一下原朝。
4、構建項目 JDK 需要升級
當將項目的 targetSdkVersion 升級到了 31 之后镶苞，構建項目的時候可能會遇到如下異常喳坠，
當然你也可能不會遇到這個問題。那主要的原因是茂蚓，你的 Android Studio 里 Gradle 構建時用到的版本已經是 Java 11 的了壕鹉。可以通過 Preference->Build->Gradle 查看當前 Android Studio 中使用的 JDK 版本聋涨，
在 Gradle JDK 處修改構建時用的 JDK 版本即可御板。
以上是針對 Android Studio 構建時的情況。但當我們使用腳本或者命令行構建項目的時候需要用到的就不是 Android Studio 的 JDK 版本了牛郑。此時怠肋，可以通過 java --version 查看環(huán)境變量中配置的 JDK 版本。
我們不能直接修改環(huán)境變量中的 JDK 版本解決上述編譯問題淹朋。因為畢竟除了開發(fā)笙各，我們可能還有很多其他應用在使用 JDK 環(huán)境钉答。此時，我們可以通過 Gradle 構建時的命令來指定構建時使用的 JDK杈抢。
gradlew -Dorg.gradle.java.home=你的 JDK 路徑
對于打包腳本的修改我也更新到了項目 autopackage 中数尿。
總結
以上是個人升級項目的目標版本到 31 過程中遇到的一些典型的問題。此外惶楼，在適配的過程中可能還有許多其他細節(jié)需要修改右蹦，對此，參考文首的幾個鏈接了解即可歼捐。升級 31 雖然沒有升級到 30 改動多何陆，但是對大型的項目來說，需要改動的點應該還是挺多的豹储。
如有疑問贷盲，歡迎交流！??
