升級 Android 目標版本到 31(S) 居然這麼多坑
1、背景
最近對我的應用做了一些小的改動，準備上架 Google Play. 本以為小事一樁，沒想到要做非常多的改動。其中一個改動是谷歌要求 billing 庫升級到 4.0 及以上版本。此外，另一個比較大的改動是要求升級目標版本到 31.
我之前從 29 升級到 30 那次改動已經非常大了。這次應該不會太多改動，沒想到總歸還是 too young too simple, sometimes naive. 升級目標版本到 31 也不是那麼簡單。下面是谷歌官方提供的兩個文章，分別詳細列舉了升級到版本的變更以及升級到 Android 12 的詳細的變更：
谷歌官方已經給了詳細的說明，這裡我分享我在適配過程中遇到的問題和解決思路。
2、exported 屬性
本次適配需要做的最明顯的一個變更是修改 exported 屬性。這個屬性是之前就存在。我之前只在個別幾個 Service 屬性中使用了它。在 31 上開始要求開發者明確指定元件的 exported 屬性。
對於沒有宣告 exported 屬性的應用，在啟動的過程中就會丟擲如下異常，
對於 exported 屬性，你可以檢視谷歌官方文件的詳細解釋：android:exported
適配這個屬性並不難，只需要在 manifest 中明確指定每個元件的 exported 屬性即可。一般來說，遵循如下原則：如果元件中使用了 intent-filter 等屬性，那麼它大概率是需要對外暴露的，此時需要將 exported 屬性直為 true，其他情況下置為 false 即可。。
對於引用的三方類庫中的 xml 屬性也可以通過覆寫宣告方式增加 exported 以相容處理，
xml
<activity android:name="com.squareup.leakcanary.internal.DisplayLeakActivity"
android:exported="false"/>
3、PendingIntent 的變動
這是一個隱藏的變動，非常坑又不像 exported 屬性那樣容易被察覺。這邊變動主要是要求開發者指定在建立 PendingIntent 的時候傳入的 flags 引數的可變性。
這可以通過在之前的 flags 基礎上增加 FLAG_MUTABLE 和 FLAG_IMMUTABLE 兩個屬性來完成。比如，之前我的 flags 是，PendingIntent.FLAG_CANCEL_CURRENT，當我想將其修改為不可變的時候，就可以使用如下方式進行修改：
kotlin
val flags = PendingIntent.FLAG_CANCEL_CURRENT or PendingIntent.FLAG_IMMUTABLE
它可能是需要改動最多的一個變動，根據我在專案中修改的情況來看，以下幾個場景需要排查：
- 桌面小控制元件 Appwidget
- 通知 Notification
- 桌面快捷方式 Shortcut
同時從幾個方向來檢索專案中需要改動的地方：
- 直接檢索 PendingIntent 的 flags 的呼叫，比如
FLAG_ONE_SHOT, FLAG_NO_CREATE, FLAG_CANCEL_CURRENT和FLAG_UPDATE_CURRENT等，建議檢視原始碼之後進行檢索 - PendingIntent 的靜態方法工廠，比如
PendingIntent.getBroadcast()、PendingIntent.getActivity()等。因為，獲取 PendingIntent 的時候需要指定 flags 引數。
那麼，另一個問題來了，究竟什麼時候該選擇 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 的處理機制是，
kotlin
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，
kotlin
val row = RemoteViews(context.packageName, R.layout.item_appwidget_note)
val i = Intent().putExtras(extras)
row.setOnClickFillInIntent(R.id.root, i)
當用戶觸發了點選事件的時候，系統會在呼叫 PendingIntent 的 send 方法時將 Intent 傳入並喚起元件。此時，如果我們將 PendingIntent 的 flags 設定為 FLAG_IMMUTABLE，那麼這裡傳送時傳入的 Intent 引數將被忽略，因此可能導致雖然喚起了其他元件，但是引數丟失的情況。而對於那種，宣告 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 檢視環境變數中配置的 JDK 版本。
我們不能直接修改環境變數中的 JDK 版本解決上述編譯問題。因為畢竟除了開發，我們可能還有很多其他應用在使用 JDK 環境。此時，我們可以通過 Gradle 構建時的命令來指定構建時使用的 JDK。
gradlew -Dorg.gradle.java.home=你的 JDK 路徑
對於打包指令碼的修改我也更新到了專案 autopackage 中。
總結
以上是個人升級專案的目標版本到 31 過程中遇到的一些典型的問題。此外，在適配的過程中可能還有許多其他細節需要修改，對此，參考文首的幾個連結瞭解即可。升級 31 雖然沒有升級到 30 改動多，但是對大型的專案來說，需要改動的點應該還是挺多的。
如有疑問，歡迎交流！👏