Android Target 31 升級全攻略 —— 記阿里首個超級 App 的坎坷升級之路

阿里巴巴移動技術發表於2022-06-28
Android阿里APP

作者：楊夕凱、張炅軒

簡述

Android Target 版本作為應用和系統版本間的“協議”與“橋樑”，在廠商預裝合作、應用商店曝光、開放能力方面都是一個重要衡量標準，近年來谷歌和手機廠商對於 Target 升級的推動速度和力度明顯加大。Target 版本越高，對系統和使用者的安全性相應越好，但其對應用的改動、約束和不明確的坑也隨之增多，尤其是對使用系統API範圍廣、業務複雜、穩定性要求高的超級應用挑戰很大。

高德地圖此次一鼓作氣從 Target 28 升級到 最新的 Target31，成為業界首個升級到最新版本的頭部應用，滿足了應用市場、廠商預裝合規的要求，為後續市場先發、預裝合作等贏得了時間視窗。第一個“吃螃蟹”，踩了不少坑，因此我們總結了升級過程中遇到的問題、原理、解決方案及操作方式，希望能幫大家在升級 Target 中事半功倍。

1.1 釋義：何為 Target 版本

Target 版本，用白話意思是「告知系統我已滿足指定系統版本的合規要求，並願意受約束」。具體指:

  • 從約束上，和一般的強制約束（例如使用者升級到 Android 12 就必須滿足某個條件）不同，Target 版本為我們提供了一種“柔和、緩衝適配”的途徑，允許使用者在升級 Android 12 時，先臨時不受新系統約束（Target 為老版本），而是等自己“準備就緒後”在升級 Target 版本以滿足約束，更具靈活性；
  • 從強度上，Target 版本越高，受到的約束越多，且約束力越強，這裡的版本為“系統 API 版本號”，和 Android 版本一一對應，如 28 對應的是 Android 9，29 為 Android 10，以此類推。

1.2 挑戰：變化快、成本高的原因

為什麼近期 Target 升級推動快、成本高呢？從行業發展和技術的角度來看：

從行業發展看趨勢：

  • 廠商跟進快： 近年來對於 Target 升級的要求表現了“趨緊”和“趨嚴”，通過此手段，可從系統層面約束各 App 滿足隱私合規、統一使用者體驗等要求；其中：

a、針對預裝應用，作為 CTS（Compatibility Test Suite，谷歌的相容性測試套件）整合的必要一環，若不能及時響應 Target 升級訴求，則很有可能導致預裝下架，進而對廠商合作、應用帶量等造成嚴重影響；

b、針對市場應用，通過TAF 《移動應用軟體高API等級預置與分發自律公約》等公約，從經驗看會在 1-2年內將條件擴充套件到應用商店，即便不涉及預裝應用，則仍要未雨綢繆

  • 隱私力度強：無論政府監管部門，還是廠商、Google，其滿足“隱私合規”的要求越加頻繁，曾經“粗放”的App 許可權已成過去，從長遠看，此種限制對使用者是有顯著收益的，但對於應用開發者而言，需要及時響應、明確趨勢，充分理解和執行；
  • 碎片裝置多：谷歌和各廠商/ROM 對於隱私、API 調整等的理解不同，其不同版本、不同裝置的實施效果有較大差異，且“碎片化”愈演愈烈。如“大致位置”、“啟動圖”等，各廠商會根據自己的需求來做二次開發，導致在谷歌原生的適配方法，到其它 ROM 中則存在問題

從技術看問題：

  • 變化頻繁：以 Android 12 為例，Release 釋出後至少有 5 次文件變動（包括啟動圖、模糊定位、檔案儲存等），並下發過 Release Patch 至廠商，廠商再根據自己的需求、節奏來看是否“實施”Patch，導致適配成本成倍增加；加之各 ROM 的碎片化，過程中需要持續調整對焦
  • 材料不全：當時業內無較好的分析文件，主流 App 也未適配到 31，很多需要自己探索，如新增許可權判斷、外接儲存使用、啟動圖等，官方要麼未提及，要麼只說大概，需要自己分析原始碼 + 不斷的實踐才能明確。
  • 適配困難：每一個許可權調整，其涉及 API 眾多、使用者影響高，且適配量很大，以我們為例，相比過去 Target 21 → 26 的 20+ 系統 API，本次涉及 300+ 系統 API，上千處呼叫，涵蓋多個技術棧，改造成本高、影響範圍廣，為我們的適配帶來了不小挑戰

作為高速發展的超級 App，高德需要做到既保持內部“持續的業務增長”，又能消化外部“要求高、變化快、難度大”。經過大家的不懈努力，最終圓滿完成了 Target 28 → 31 的升級。

1.3 收益

  1. 為滿足應用市場、廠商預裝合規要求，政府、廠商、電信終端產業協會公約 打好提前量，為後續市場先發、預裝合作贏得的時間視窗，避免卡脖子；
  2. 在專項過程中沉澱了升級、合規相關經驗，設計並落地系統隔離層，降低後續改動對業務的影響，提升後續對新系統、華米 OV ROM、鴻蒙等的應對效率；
  3. 通過原始碼分析+自研指令碼，成功識別 13 個谷歌未提及的改動，減少了 119 個潛在崩潰、不可用風險。

隱私許可權

2.1 外接儲存、分割槽儲存與限制【29,30】

背景

為了更好保護使用者資料並限制裝置冗餘檔案增加，若應用升級到 Target 29，在預設情況下被賦予了對外部儲存裝置的分割槽訪問許可權（即分割槽儲存），應用只能看到本應用專有的沙箱目錄以及特定型別的媒體（通過MediaStore）。

現狀（SDK=28為目標平臺的應用）

當使用者授予“儲存”許可權，允許讀寫外接非沙盒目錄的內容，並在解除安裝重灌後不會被清除；此外，一些使用者相簿、敏感資訊，在授予許可權後也可以讀取到。

Target 升級後不同訪問方式表現

前提：

  • 設定requestLegacyExternalStorage=true 和 PreserveLegacyExternalStorage=true
  • APK targetSDK升級到31
  • 新裝/解除安裝後重灌 APK

目錄：

  • 共享目錄：儲存其他應用可訪問檔案， 包含媒體檔案、文件檔案以及其他檔案，對應裝置DCIM、Pictures、Alarms, Music, Notifications,Podcasts, Ringtones、Movies、Download等目錄;

  • 沙箱內目錄：

    • /sdcard/Android/data/{packagename}
    • /data/data/{packagename}
    • /sdcard/Android/media/{packagename}
  • 其他目錄：系統或其他應用在外接SD卡建立的目錄；

坑點&避坑建議（已在小米、ov等主流機型驗證）：

  • 坑點：在Android 11+、Target 為 30+ 且使用者新裝/解除安裝重灌時，即便沒有儲存許可權，寫入超過sdcard兩級子目錄（比如：/sdcard/xxx/yyy）系統返回“可讀寫”仍為 true，不符合預期；直到對檔案內容做讀寫時，系統才丟擲寫入異常，導致失敗。
  • 避坑建議：由於單一依靠系統返回結果已不可信，因此對系統返回結果做雙重校驗。如：Android 11 及以上且“可讀寫”返回 true 後，寫入臨時檔案，若寫入失敗則仍放入沙箱。

總結&適配建議

  • 覆蓋安裝不會自動開啟分割槽儲存，原有儲存訪問許可權不受影響；
  • 應用可通過requestLegacyExternalStorage和PreserveLegacyExternalStorage兩個屬性禁掉分割槽儲存機制來完成資料遷移，但這兩個屬性只對升級有效，在android 11後的機器新裝/重灌會強制開啟分割槽儲存機制；
  • 分割槽儲存開啟後無需申請儲存許可權即可正常訪問沙箱內目錄；
  • 分割槽儲存開啟後非沙箱內目錄訪問會受限，具體表現見上表格；
  • 分割槽儲存開啟後仍然需要申請儲存許可權，否則訪問共享目錄會受限。

2.2 藍芽許可權及不同策略【29,30,31】

涉及許可權的藍芽API

大致可以分為下面三類：

藍芽許可權在不同版本的要求

  • Target ≤ 28 時： 具備BLUETOOTH和BLUETOOT_ADMIN許可權就能使用連線類API和廣播類API，掃描類API需要具備大致定位許可權（ACCESS_COARSE_LOCATION）
  • Target 為 29 和 30 時：連線類API和廣播類API許可權無變化，掃描類API需要另外具備精確定位許可權(ACCESS_FINE_LOCATION)。

  • Target ≥ 31 時： 新增了細分的藍芽許可權來替代BLUETOOTH和BLUETOOTH_ADIMIN，為應用提供更靈活的許可權申請方式。具體包括：

    • BLUETOOTH_SCAN：允許掃描和發現裝置，掃描類API需要同時具備該許可權和精確定位許可權(ACCESS_FINE_LOCATION)。
    • BLUETOOTH_CONNECT：允許連線和訪問已配對的裝置，連線類API需要具備該許可權。
    • BLUETOOTH_ADVERTISE：允許向附近的藍芽裝置進行廣播，廣播類API需要具備該許可權。

對於新增的這三個許可權的彈窗表現，我們也實際測試了一下，現象如下：

不同版本中藍芽API與許可權的對應關係，最終總結起來如下：

適配方案

  • 在不同的Android版本中，藍芽API的使用方式並未發生變化，所以只需要對許可權進行相應的適配，避免因未授權而導致的崩潰即可；
  • 如果同時使用了藍芽的掃描、連線和廣播類API，對應的許可權都需要進行申請。考慮到藍芽的這三類操作往往是緊密相連的，比如掃描發現後，就會進行連線，如果一次性申請掃描、連線和廣播所需的所有藍芽許可權能更好的滿足使用場景，同時也能避免重複彈出許可權彈窗，使互動更加簡潔。因此我們最終採取了組合申請的方式；
  • 組合申請藍芽許可權時，在Vivo IQOO 5上的系統許可權彈窗如圖：

以下是Target SDK從28升級到31需要做的適配：

  1. 為不同Android版本申明不同的許可權
  • 為了繼續相容SDK 29-30，需要保留在Manifest中申明的BLUETOOTH和BLUETOOTH_ADMIN許可權，同時還應宣告maxSdkVersion為30，ACCESS_COARSE_LOCATION也需要保留，如：
  <!-- Request legacy Bluetooth permissions on older devices. -->
    <uses-permission android:name="android.permission.BLUETOOTH"
                     android:maxSdkVersion="30" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"
                     android:maxSdkVersion="30" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
  • 新增BLUETOOTH_SCAN，BLUETOOTH_CONNECT 和BLUETOOTH_ADVERTISE許可權的申明。如
    <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
  • 新增ACCESS_FINE_LOCATION許可權申明（如果確定應用不會推導使用者位置，可跳過此申明和下面的動態申請。但需在BLUETOOTH_SCAN許可權申明時，新增android:usesPermissionFlags="neverForLocation"申明）

2、動態申請執行時許可權

  • SDK 29-30，需要動態申請獲得ACCESS_FINE_LOCATION
  • SDK ≥ 31，先動態申請獲得ACCESS_COARSE_LOCATION+ACCESS_FINE_LOCATION（模糊定位引入的新要求，詳見下文)，然後再組合BLUETOOTH_SCAN、BLUETOOTH_CONNECT和BLUETOOTH_ADVERTISE一起申請獲得藍芽許可權。如果在未獲得ACCESS_FINE_LOCATION的情況下，直接申請藍芽許可權，可能導致請求被忽略的異常結果。

3、使用API前做許可權校驗

使用涉及許可權的藍芽API前，需做許可權校驗。確定已具備相應許可權，再繼續呼叫；否則應停止呼叫，否則可能導致應用直接崩潰。

  • SDK 29-30，判斷是否具備ACCESS_FINE_LOCATION許可權即可
  • SDK ≥ 31，因為採用了組合申請方式，我們可以直接判斷是否同時具備ACCESS_FINE_LOCATION和BLUETOOTH_SCAN即可

2.3 大致位置【31】

（廠商稱“模糊定位”，以下做統一）

背景

升級到Target 31後，在Android 12系統的定位許可權設定頁和授權彈窗中，明確區分了精確定位和模糊定位，並允許使用者選擇僅使用模糊定位，即當開啟“模糊定位”時，其“精準定位”許可權被關閉。此前，小米/Vivo的部分Android 11機型已經採用了這種方式為使用者提供更靈活的定位選擇，Android target 31升級算是借鑑了相同的思路。可以理解為，在原先僅小米/Vivo 支援“模糊定位”（關閉精確定位）的基礎上，Target 升級後，將其擴充套件到了 Oppo/華為/三星等其他廠商的所有 Android 12 系統。

不同廠商/版本策略

圖 定位許可權設定頁

圖 定位授權彈窗

以下是Target 31升級前後關於模糊定位的對比情況：

可以看到，如果應用僅使用模糊定位，那麼不會受到任何影響。但對於高度依賴精確定位的應用，則需要進行相應的適配，確保獲得精確定位許可權。

適配方案

  1. 判斷應用是否具備精確定位許可權
  • Target ≤ 30且支援模糊定位的機型（小米/Vivo），需使用廠商提供的API進行判斷，具體可參見各廠商適配相關文件（官網或內部發布文件）
  • Target ≥ 31的機型，可直接使用系統API，即Context.checkSelfPermission()判斷是否具備ACCESS_FINE_LOCATION即可。

2、引導使用者開啟精確定位： 可以在彈出授權彈窗前，或者去到應用許可權設定頁面前，向使用者展示引導性的彈窗或文案，提示其開啟精確定位。

2.4 在後臺訪問位置資訊的許可權【29,30】

背景

為了讓使用者更好地控制應用對位置資訊的訪問許可權，從Android10開始加強了後臺定位許可權申請的管控。在介紹變更之前需先了解後臺定位的場景，除非符合以下條件之一，否則應用將被視為在後臺訪問位置資訊：

  • 屬於該應用的 Activity 可見；
  • 該應用執行的某個前臺裝置已宣告前臺服務型別為 location。

升級後的變化

  • Target = 29 時： 開始引入了 ACCESS_BACKGROUND_LOCATION 許可權，應用需在AndroidManifest宣告ACCESS_BACKGROUND_LOCATION 許可權，然後動態申請該許可權且使用者選擇“始終允許”才能獲取到後臺定位能力；

  • Target ≥ 30 時：應用需在AndroidManifest宣告ACCESS_BACKGROUND_LOCATION 許可權，然後使用者在系統設定頁面上選擇“始終允許”後才能獲取到後臺定位能力。

注意：通過requestPermission去動態申請ACCESS_BACKGROUND_LOCATION 許可權，系統將忽略該請求不會彈窗。如果您同時請求在前臺訪問位置資訊的許可權和在後臺訪問位置資訊的許可權， 系統會忽略該請求，且不會向您的應用授予其中的任一許可權。

適配建議

  • 由於不同target後臺定位許可權獲取方式不一致，如果需要後臺訪問位置許可權，建議從產品側引導使用者去系統設定新增
  • 不要同時申請前臺和後臺訪問位置許可權，否則無法顯示授權彈窗

2.5 精準的鬧鐘許可權【31】

背景

為了鼓勵應用節省系統資源，Android 12 要求為以 Android 12 為目標平臺且設定精確的鬧鐘的應用配置“鬧鐘和提醒”特殊應用訪問許可權。如需獲取這種特殊應用訪問許可權，請在清單中請求 SCHEDULE_EXACT_ALARM 許可權。精確的鬧鐘只能用於面向使用者的功能，且使用者和系統均可撤消“鬧鐘和提醒”特殊應用訪問許可權，因此需要時加許可權判斷，否則會丟擲Exception。

適配建議

需要精確的鬧鐘的得申請SCHEDULE_EXACT_ALARM許可權，且使用時做許可權判斷。

2.6 一些電話 API、藍芽 API 和 WLAN API 需要精確位置許可權【29】

背景

如果應用以 Android 10 或更高版本為目標平臺， 則它必須具有 ACCESS_FINE_LOCATION 許可權才能使用 Telephony、WLAN、WLAN 感知和藍芽（藍芽上面章節已介紹）API中的一些方法。涉及影響的類主要有：

1）電話：TelephonyManager、TelephonyScanManager、TelephonyScanManager.NetworkScanCallback、PhoneStateListener

2）WLAN：WifiManager、WifiAwareManager、WifiP2pManager、WifiRttManager

適配建議

涉及通過無線進行“定位”的API需授予ACCESS_FINE_LOCATION許可權後方可呼叫。

安全合規

3.1 軟體包可見性【30】

背景

Android 11 更改了應用查詢使用者已在裝置上安裝的其他應用以及與之互動的方式。使用 <queries> 元素，應用可以定義一組自身可訪問的其他軟體包。通過告知系統應向您的應用顯示哪些其他軟體包，此元素有助於鼓勵最小許可權原則。此外，此元素還可幫助 Google Play 等應用商店評估應用為使用者提供的隱私權和安全性。

現狀&影響

通過識別發現主要受影響的系統API包括但不限於：queryIntentActivities、getPackageInfo、getInstalledApplications、getInstalledPackages 等。我們以 getInstalledPackages 和 getInstalledApplications 的API為例：

  • 在Target升級前，可直接通過 getInstalledPackages 和 getInstalledApplications 來獲取安裝的應用

  • 當Target升級後，如果未命中白名單的，將無法獲取包名。這裡提到的白名單主要包括：

    1. 您自己的應用，即自身應用
    2. 實現 Android 核心功能的某些系統軟體包，如媒體提供程式。
    3. 通過 startActivityForResult（注意 startActivity 無效）開啟自身應用時的應用（僅當次有效）
    4. 安裝了您應用的應用（如當時安裝自身應用時的應用市場）
    5. 通過 bindService/startService/Provider 開啟自身應用時的應用（僅當次有效）
    6. 自己在 Manifest 中宣告的包名/簽名/IntentFilter/ProviderAuthorities 清單（見“建議”）
  • 另外，通過宣告 QUERY_ALL_PACKAGES 許可權可臨時忽略上述限制，但 Google Play 已要求在 22年4月，除安全、瀏覽器、檔案等必要應用（無導航應用）外，其餘應下線此許可權，否則會面臨下架風險，因此僅可作為兜底方案。

建議

  1. 如果有需要查詢或者互動的非當前App應用元件，需要在 AndroidManifest 中新增 queries 元素。以下有幾種建議，大家可根據自己的實際使用場景來選擇，最好遵守最小使用原則。可考慮新增包名、Provider 宣告的 android:authorities、通用的 Intent-Filter 等來實現；
  2. 【不建議】在 Manifest 中新增 QUERY_ALL_PACKAGES 做兜底，避免崩潰，但應考慮 Google Play 及海外市場的限制。

補充

關於軟體包可見性，除了Google的要求外，國內各大廠商正在要求App新增廠商自定義許可權：com.android.permission.GET_INSTALLED_APPS，該許可權需要使用者授權，也就是說未來某App想要獲取應用軟體列表資訊是需要使用者授權通過才可以正常獲取。

3.2 對已配置的 WLAN 網路限制【29】

背景

為了保護使用者隱私，只有系統應用和裝置政策控制器 (DPC) 支援手動配置 WiFi 網路列表（包括增刪改/連線 WiFi 等）。如果應用升級 Target 到 29 且應用不是系統應用或 DPC，則有些方法不會返回有用資料，具體表現見下節。

升級後的變化

Target升級到29+後獲取/操作WIFI列表的行為如下：

  • 獲取 WiFi 列表；
  • 掃描WiFi 列表（startScan），在授予“精確定位”（FINE_LOCATION）許可權後可正常獲取，該行為跟升級前一致；
  • 若使用者僅授予“模糊定位”（COARSE_LOCATION），則無法獲取，返回空；
  • 使用者已儲存的網路（getConfiguredNetworks）則始終無法獲取，返回空；
  • 新增 WiFi（儲存網路）。

需更換新 API（addNetworkSuggestions），當新增新 WiFi 時系統會彈窗等待使用者確認（如下圖），使用者可拒絕新增；其它行為和升級前一致。

  • 移除/修改儲存的 WiFi：需更換 為新API removeNetworkSuggestions；
  • 主動連線 WiFi：已禁止（enableNetwork），只能交由系統策略處理或者使用者去系統設定連線。

適配建議

  • 獲取 WiFi 列表：適配當使用者只授予“模糊定位”返回 Null 時的情況；去掉對已儲存網路（getConfiguredNetworks）介面的依賴；
  • 新增/移除/修改儲存的WiFi：更換新 API。考慮到有系統彈窗，如需要的話可引導使用者完成。

3.3 更安全的元件匯出【31】

背景

如果您的應用以 Android 12 或更高版本為目標平臺，且包含使用 intent 過濾器的 activity、服務或廣播接收器，您必須為這些應用元件顯式宣告 android:exported 屬性。

警告：如果 activity、服務或廣播接收器使用 intent 過濾器，並且未顯式宣告 android:exported 的值，您的應用將無法在搭載 Android 12 或更高版本的裝置上進行安裝。

影響

需要check一下activity、服務或廣播中包含intent過濾器的場景。

思考&建議

官方考慮對於強制宣告android:exported 屬性，主要是考慮到安全性，自然也建議我們將exported 屬性非必需true的都改成false，理想的角度，推薦大家逐一check一下所有的場景。

當然如果大家想更快捷的去解決，推薦在編譯期間，解析AndroidManifest，對於沒有主動設定exported屬性的統一設定，這樣也可以一併解決 SDK 相關問題。

這裡有個細節需要注意一下，當Activity包含intent 過濾器時，如果沒有設定exported屬性，系統在執行的時候會將exported解析成true使用，這在系統的原始碼中也是有體現的；這樣我們就需要考慮歷史業務場景中：可能會存在沒有給exported設定屬性，卻將exported設為true來使用。

3.4 前臺服務啟動限制【31】

背景

以 Android 12 或更高版本為目標平臺的應用無法在後臺執行時啟動前臺服務，少數特殊情況除外。如果應用嘗試在後臺執行時啟動前臺服務，則會引發異常。

影響

使用到啟動前臺服務（API如下）的業務場景，需要check是否有從後臺啟動的情況，如果有看是否滿足特殊情況。主要涉及：startForegroundService 和 startForeground 方法。

建議：

儘量避免，甚至杜絕（隨著系統不斷升級，對於從後臺啟動前臺服務越來越嚴）從後臺啟動前臺服務。建議從靜態分析角度查詢所有涉及前臺呼叫的 API，梳理和 Check。

3.5 前臺服務訪問攝像頭、麥克風需宣告【30】

背景：

  1. 在前臺服務中訪問攝像頭或麥克風，則必須新增前臺服務型別 camera 和 microphone；
  2. 如果應用在後臺執行時啟動了某項前臺服務， 則該前臺服務無法訪問麥克風或攝像頭，如果想訪問位置，需要有後臺訪問位置資訊的許可權。

影響

前臺服務中使用攝像頭、麥克風或位置。

建議

  1. 如果在前臺服務中需要使用camera和microphone，需要在AndroidManifest.xml宣告對應型別。如下：<service ... android:foregroundServiceType="camera|microphone" />
  2. 不建議應用在後臺時啟動前臺服務，因為如果Target升級到31的時候，除非特殊情況，否則無法從後臺啟動前臺服務。

3.6 待處理 intent 可變性【31】

背景

如果您的應用以 Android 12 為目標平臺，則需對 Pending Intent 強制設定“可變性”（即 FLAG_IMMUTABLE/FLAG_MUTABLE），這項額外的要求可提高應用的安全性。

影響

使用到PendingIntent的業務場景。

建議

根據需要為PendingIntent填寫 PendingIntent.FLAG_MUTABLE 或 PendingIntent.FLAG_IMMUTABLE 標誌；此外，最好提供一個適配的聚合類，其他類都直接呼叫適配類的方法，這樣可以減少適配成本。

3.7 更新後的非 SDK 限制【29,30,31】

背景

從 Android 9（API 級別 28）開始，Android 平臺對應用能使用的非 SDK 介面實施了限制。只要應用引用非 SDK 介面或嘗試使用反射或 JNI 來獲取其控制程式碼，這些限制就適用。這些限制旨在幫助提升使用者體驗和開發者體驗，為使用者降低應用發生崩潰的風險，同時為開發者降低緊急釋出的風險。

  • 區分 SDK 介面和非 SDK 介面： 一般而言，公共 SDK 介面是在 Android 框架軟體包索引中記錄的那些介面。非 SDK 介面的處理是 API 抽象出來的實現細節，因此這些介面可能會在不另行通知的情況下隨時發生更改。為了避免發生崩潰和意外行為，應用應僅使用 SDK 中經過正式記錄的類。這也意味著當您的應用通過反射等機制與類互動時，不應訪問 SDK 中未列出的方法或欄位；
  • 非 SDK API 名單： 隨著每個 Android 版本的釋出，會有更多非 SDK 介面受到限制。為最大程度地降低非 SDK 使用限制對開發工作流的影響，將非 SDK 介面分成了幾個名單，這些名單界定了非 SDK 介面使用限制的嚴格程度（取決於應用的目標 API 級別）。

影響

使用google官方提供的工具和Android 12 非 SDK 介面及其對應的名單，就可以對需要的APP掃描出結果，根據結果可知道影響範圍。

建議

理想情況下，我們應該只使用SDK(whitelist)；但是一些App為了獲得一些能力，使用了非sdk介面。因此：

  • 對於greylist，我們暫且可以使用；
  • 對於greylist-max-x，我們需要根據工程中target版本來看是否可以暫且使用，greylist-max-p等價於max-target-p；
  • 對於blacklist，則無法使用。另外所有的非sdk介面一定要加try catch保護。

寫在結束前

以上是我們在 Target 升級中的思考和解法，由於篇幅所限，上述僅介紹了一些隱私安全相關的“關鍵要點”，具體的技術實現細節，大家若有興趣，歡迎隨時在評論區留言討論。

Target 升級的關鍵之處，除了外部（廠商、政府政策）的推動，公司內部對於擁抱隱私合規，對使用者負責的積極態度外，還有多方團隊的合作，自上而下的重視，以及自內而外的決心，三者缺一不可。Target 升級絕非“一錘子買賣”，它需要長期、持之以恆的耕耘，才能不斷結出果實。希望我們的經歷，能為大家帶來啟發，少走彎路，輕裝上陣。

關注【阿里巴巴移動技術】，阿里前沿移動乾貨&實踐給你思考！

相關文章