從 2018 年 3 月初我們釋出 Android P 開發者預覽版以來，很多開發者都對當前常見應用在 Android P 上做了一些相容性測試，我們在這裡總結了一些常見的問題，以及它們發生的原因和建議的修改措施。

問題 1: 假設 android.os.Build.VERSION.RELEASE 為數值型別

原因：

對於即將推出的 Android 新版本的預覽版，這些值可能是字母數字 (如 “PPR” 或 “P”)，因此在嘗試將 “P” 解析為整數時會導致崩潰。

建議：

應用把 RELEASE 的值作為字串型別來處理。

問題 2: 使用的第三方 SDK 版本過低，不相容 Android P

原因：

在中國的 Android 生態中，應用經常依賴的第三方 SDK (特別是加固和熱修復框架) 會和系統底層緊密整合 (如使用非公開的介面)，而導致應用在 Android 版本升級時無法正常執行。我們也開始與一些常見的 SDK 提供商合作 (並計劃覆蓋更多)，在 Android 新的預覽版本中儘早解決相容性問題。

建議：

經常檢查第三方 SDK 的升級公告，及時升級至其最新版本。

如果您使用的第三方 SDK 尚不支援 Android 新版本，請報告給其提供商，幫助推動它解決相容性問題。

問題 3: 開啟應用時顯示 "Detected problems with API compatibility"，或呼叫非 SDK 介面時遭遇 NoSuchFieldException 或 NoSuchMethodException

原因：

非 SDK 介面指的是 Android 系統內部使用、並未提供在 SDK 中的介面，開發者可能通過 Java 反射、JNI 等技術來呼叫這些介面。但是，這麼做是很危險的：非 SDK 介面沒有任何公開文件，必須檢視原始碼才能理解其行為邏輯。

非 SDK 介面的函式簽名 (包括引數列表和返回值)、行為邏輯都有可能在下個 Android 版本中被大幅修改，甚至 API 本身也可能被刪除。這會導致使用非 SDK 介面的應用在新的 Android 版本中無法執行，或執行時產生不符合預期的行為，開發者必須投入相當的研發資源保持其在未來每個 Android 新版本中的適配。

直接使用底層的非 SDK 介面有可能會繞過一些 Android 對使用者的安全性和隱私性方面的保護，不但影響使用者體驗、妨害使用者隱私，也很可能會被 Google Play Protect 判定為惡意軟體而提示使用者解除安裝應用。

建議：

只使用 Android SDK 中的公開介面進行應用開發。公開 SDK 介面有詳細的技術文件和支援渠道，未來的 Android 新版本也會保證公開 SDK 介面的相容性 (即使有改動，也會在文件中詳細闡明)。

請儘早在 Android P 預覽版中測試您的應用，您可以執行並操作應用，然後在 adb logcat 中查詢類似下方的內容，其中包含了應用呼叫的非 SDK 介面名，所屬黑/灰名單和呼叫的方式: 
Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)

Accessing hidden method Landroid/app/ActivityThread;->currentActivityThread()Landroid/app/ActivityThread; (dark greylist, reflection)

如果您有合理的理由，必須使用某個非 SDK 介面，請在文章下方留言給我們，我們非常期待聆聽和與您進行討論，並會在充分評估必要性和可行性後，提供可能的方案來滿足合理的功能需求。

問題 4: 直接呼叫 dex2oat，或者使用不支援 / 不正確的方式編譯 dex 檔案

原因：

從一開始，dex2oat 就被設計為系統內部使用的編譯部署工具，Android 從來都未支援過開發者直接呼叫 dex2oat 的場景。我們會持續而不定期地對這個工具進行優化，而很多時候其行為變更 (如: 生成的檔案及其格式) 都是與之前不相容的。在大多數情況下，標準的類載入器 (BaseDexClassLoader / DexClassLoader / PathClassLoader) 無法找到或使用由直接呼叫 dex2oat 生成的檔案。

此外請注意，從 Android O 開始，BaseDexClassLoader 和 DexClassLoader 建構函式中的 “optimizedDirectory” 引數已廢棄，並在載入 dex 檔案時不起作用。

建議：

如果您需要從記憶體中載入 dex 檔案，而不願在儲存中留下痕跡，請使用 Android O 中新增的載入器 InMemoryDexClassLoader。

問題 5: 注入或篡改 Android Studio 生成的 dex 和 so 檔案

原因：

Android Studio 生成的 dex 檔案雖然有公開的佈局格式，但具體內容還是會在執行時被系統在後臺進行編譯優化。如果您在 dex 檔案中寫入自定義的內容，很可能這些自定義的寫入操作與系統優化發生衝突，以致自定義的內容被擦除或覆蓋，甚至導致優化後的 dex 在執行時直接崩潰。

Android Studio 生成的 so 檔案包含一些元資料 (如 ELF headers 和 section headers)，以備動態連結器進行完整性檢查。篡改 so 檔案並不會帶來安全性的提升 (很多工具可以重新生成元資料)，反而可能導致應用無法在未來的 Android 版本中啟動 (由於動態連結器可能執行更嚴格的檢查)。更多關於 so 檔案的要求，您可在公眾號平臺傳送資訊 “so檔案” 獲取相關連結。

建議：

不要修改 Android Studio 生成的 dex 和 so 檔案。

問題 6: 應用在 Android P 上啟動時顯示 “This app was built for an older version of Android and may not work properly...”

原因:

應用的 targetSdkVersion 太舊 ( <17 )

建議：

升級您應用的 targetSdkVersion 至最新版本，您可在公眾號平臺傳送資訊 “targetsdkversion” 獲取相關文件連結。

問題 7: 應用在特長螢幕上未能正確顯示，部分內容超出螢幕

原因：

Android O 開始支援特長螢幕，而且已經有很多廠商開始釋出特長螢幕的手機。應用對螢幕的顯示比例做出錯誤的假設，而未能支援 16:9 以上的縱橫比，進而影響使用者體驗。

建議：

修改您的應用，使他能夠適應不同的螢幕尺寸 (包括 16:9 以上的縱橫比)。

如果自適應式 UI 不適合您的場景，可以考慮在 manifest 中的 <activity> 內設定 resizableActivity = false，並加上 android:MaxAspectRatio 來宣告最大支援縱橫比。這會在特長螢幕的裝置上啟用相容模式，把應用邊緣的顯示空間以黑色填充。

問題 8: 應用在特長螢幕上未能正確顯示，上下出現黑邊

原因：

Android O 開始支援特長螢幕，而且已經有很多廠商開始釋出特長螢幕的手機。應用對未能支援 16:9 以上的縱橫比會在特長螢幕的裝置上啟用相容模式，把應用邊緣的顯示空間以黑色填充。

建議：

升級您應用的 targetSdkVersion 至最新版本，您可在公眾號平臺傳送資訊 “targetsdkversion” 獲取相關文件連結。

請參考下列 Android P 相關文件，使您的應用盡早相容 Android P：

- 設定 SDK 和模擬器

https://developer.android.google.cn/preview/setup-sdk.html

- 遷移指南

https://developer.android.google.cn/preview/migration.html

- 行為變更

https://developer.android.google.cn/preview/behavior-changes.html

- 新功能及 API

https://developer.android.google.cn/preview/features.html

如果您在 Android P 的相容性工作中有什麼經驗和體會，歡迎在文章下方留言與我們分享。謝謝！

推薦閱讀