安卓11來了，快！扶我起來

前言

安卓更新換代很是快，5.0以前版本更新的時間線有點看不懂，但5.0以後更新仍是比較穩定的，大概一年更新一次，谷歌工程師對安卓每一個版本的命名也有點意思，好比棒棒糖、棉花糖、奧利奧、餡餅啊啥的（命名的應該也是個吃貨），還有，從1.5開始，以後的版本都按照英文字母順序排列，從C開始，到如今的11排到了R。

2019年5月8日，谷歌在Google I/O 2019開發者大會上，正式公佈了安卓10系統。通過數月的Beta版測試，谷歌又於2019年9月4日，推送了安卓10正式版。

從谷歌推出安卓10到如今也快一年的時間了，好多應用尚未適配，但如今安卓11的開發者預覽版已經出來了，原本應該在今年的I/O大會上發佈正式版安卓11的，可是因爲疫情影響，3月21日發佈消息，受新冠肺炎疫情影響，谷歌週五宣佈完全取消一年一度的I/O開發者大會，此前該公司在3月3日宣佈，因爲受到新冠病毒疫情的影響，將把I/O大會改成僅在線上舉行，但如今線上大會也被取消了。

雖然今年I/O大會不開了，可是安卓11確定要發佈的，因此開發人員也別想跑，也須要適配啊！

準備工做

「大哥，你這說了半天安卓11的適配在哪呢？」

「彆着急啊，下面不是就要說了嘛！」

「快說，再白活會就取關了！」

「這就來這就來，哎！若是你有Pixel，那麼恭喜你能夠直接經過刷OTA的方式來體驗和提早適配安卓11。「

」沒有？跟我同樣來使用模擬器吧！「

「什麼？不知道怎麼配置？真的是，給你說下吧，記好了。」

1. 在 Android Studio 中，依次點擊 Tools > SDK Manager。

2. 在 SDK Platforms 標籤頁下，選擇窗口底部的 Show Package Details。

3. 在 Android 11 Developer Preview 下，選擇系統映像（例如 Google APIs Intel x86 Atom System Image）。

4. 在 SDK Tools 標籤頁中，選擇最新版 Android 模擬器，點擊 OK 開始安裝。

5. 安裝完成後，依次選擇 Tools > AVD Manager，而後按照說明建立新的 AVD。

   請務必選擇 Pixel 設備，並對系統映像選擇 R。

6. 返回 AVD 管理器的虛擬設備列表，雙擊新虛擬設備便可啓動該設備。

「萬事俱備，只欠適配了！」

這裏就不寫刷OTA的具體步驟了，須要的能夠自行下載和刷寫。

正文

「來了來了，開始了，別說話了，安靜！！！」

分區存儲

還記得在適配安卓10的時候設置requestLegacyExternalStorage爲true來修改外部存儲空間視圖模型（true爲 Legacy View，false 爲 Filtered View）嗎？這是重點：當您將應用更新爲以 Android 11 爲目標平臺後，將沒法使用 requestLegacyExternalStorage 來停用分區存儲。

"大哥，這都停用了那我該怎麼適配呢？"

「這孩子，猴急猴急的，這不就要說了嘛！」

數據遷移到使用分區存儲時可見的目錄：

在以 Android 11 爲目標平臺以前，應將數據遷移到與分區存儲兼容的目錄。在大多數狀況下，能夠將數據遷移到應用的應用專用目錄。

若是有要遷移的數據，當用戶升級到以 Android 11 爲目標平臺的新版應用時，能夠保留舊版存儲模型。這樣，用戶就能夠保留對應用以前用來保存數據的目錄中存儲的應用數據的訪問權限。要啓用舊版存儲模型以進行升級，請在應用的清單中將 preserveLegacyExternalStorage 屬性設爲 true。

這裏須要注意如下兩點：

• 大多數應用都不須要使用 preserveLegacyExternalStorage。此標記僅適用於這樣一種狀況：你將應用數據遷移到了與分區存儲兼容的位置，而且但願用戶在更新你應用時保留對數據的訪問權限。使用此標記會致使更難以測試分區存儲對應用的用戶有何影響，由於當用戶更新應用時，它會繼續使用舊版存儲模型。
• 若是使用 preserveLegacyExternalStorage，則舊版存儲模型只在用戶卸載應用以前保持有效。若是用戶在搭載 Android 11 的設備上安裝或從新安裝應用，則不管 preserveLegacyExternalStorage 的值是什麼，應用都沒法停用分區存儲模型。

測試分區存儲

若是要在應用中啓用分區存儲，而不考慮應用的目標 SDK 版本和清單標記值，請啓用如下應用兼容性標記：

• DEFAULT_SCOPED_STORAGE（默認狀況下，對全部應用處於啓用狀態）
• FORCE_ENABLE_SCOPED_STORAGE（默認狀況下，對全部應用處於停用狀態）

要停用分區存儲而改用舊版存儲模型，請取消設置這兩個標記。

管理設備存儲空間

若是你的應用是文件管理器應用而且在 Android 11 上運行，它就不能再刪除其餘應用的緩存文件，即便您的應用具備全部文件訪問權限也是如此（清理文件的應用尤爲須要注意，好比某某管家、衛士啥的）。相反，你應執行如下操做：

1. 經過調用 ACTION_MANAGE_STORAGE intent 操做來檢查可用空間。
2. 若是設備上的可用空間不足，請提示用戶贊成讓您的應用清除全部緩存。爲此，請調用 ACTION_CLEAR_APP_CACHE intent 操做。

這裏須要注意：ACTION_CLEAR_APP_CACHE intent 操做會嚴重影響設備的電池續航時間，而且可能會從設備上移除大量的文件。

媒體文件訪問權限

這個很贊，Android 11 增長了如下訪問媒體功能。

執行批量操做

爲實現各類設備之間的一致性並增長用戶便利性，Android 11 向 MediaStore API 中添加了多種方法。對於但願簡化特定媒體文件更改流程（例如在原位置編輯照片）的應用而言，這些方法尤其有用。

添加的方法以下：

• [createWriteRequest()](developer.android.google.cn/reference/a…(android.content.ContentResolver, java.util.Collection))

  用戶嚮應用授予對指定媒體文件組的寫入訪問權限的請求。

• [createFavoriteRequest()](developer.android.google.cn/reference/a…(android.content.ContentResolver, java.util.Collection, boolean))

  用戶將設備上指定的媒體文件標記爲「收藏」的請求。對該文件具備讀取訪問權限的任何應用均可以看到用戶已將該文件標記爲「收藏」。

• [createTrashRequest()](developer.android.google.cn/reference/a…(android.content.ContentResolver, java.util.Collection, boolean))

  用戶將指定的媒體文件放入設備垃圾箱的請求。垃圾箱中的內容在特定時間段（默認爲 7 天）後會永久刪除。

• [createDeleteRequest()](developer.android.google.cn/reference/a…(android.content.ContentResolver, java.util.Collection))

  用戶當即永久刪除指定的媒體文件（而不是先將其放入垃圾箱）的請求。

系統在調用以上任何一個方法後，會構建一個 PendingIntent 對象。應用調用此 intent 後，用戶會看到一個對話框，請求用戶贊成應用更新或刪除指定的媒體文件。

使用原始路徑訪問文件

從 Android 11 開始，具備 READ_EXTERNAL_STORAGE 權限的應用可使用直接文件路徑和原生庫來讀取設備的媒體文件。經過這項新功能，應用能夠更順暢地使用第三方媒體庫。

文件和目錄訪問限制

如下與存儲訪問框架 (SAF) 相關的變動只有在應用以 Android 11 爲目標平臺時纔會生效。

訪問目錄

沒法再使用 ACTION_OPEN_DOCUMENT_TREE intent 操做來請求訪問如下目錄：

• Downloads 根目錄。
• 設備製造商認爲可靠的各個 SD 卡卷的根目錄，不管該卡是模擬卡仍是可移除的卡。

訪問文件

沒法再使用 ACTION_OPEN_DOCUMENT_TREE 或 ACTION_OPEN_DOCUMENT intent 操做來請求用戶從如下目錄中選擇單獨的文件：

• Android/data/ 目錄及其全部子目錄。
• Android/obb/ 目錄及其全部子目錄。

權限

無論應用的目標 SDK 版本是什麼，如下變動均會在 Android 11 中生效：

• 存儲運行時權限已重命名爲文件和媒體。
• 若是應用未停用分區存儲而且請求 READ_EXTERNAL_STORAGE 權限，則用戶會看到不一樣於 Android 10 的對話框。該對話框會指示應用正在請求訪問照片、視頻、音頻剪輯和文件。
• 用戶能夠在系統設置中查看哪些應用具備 READ_EXTERNAL_STORAGE 權限。在設置 > 隱私 > 權限管理器 > 文件和媒體頁面上，具備該權限的每一個應用都列在容許存儲全部文件下。

這裏要注意：若是應用以 Android 11 爲目標平臺，切記，對「全部文件」的這種訪問權限是隻讀訪問權限。要使用此應用讀取和寫入共享的存儲空間中的全部文件，須要具備全部文件訪問權限。

全部文件訪問權限

某些應用的核心用例須要訪問大量的文件，如文件管理操做或備份和恢復操做。這些應用可經過執行如下操做來獲取「全部文件訪問權限」：

1. 聲明 MANAGE_EXTERNAL_STORAGE 權限。
2. 使用 ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION intent 操做將用戶引導至一個系統設置頁面，在該頁面上，用戶能夠爲應用啓用如下選項：授予全部文件的管理權限。

「全部文件訪問權限」可授予如下權限：

• 對共享的存儲空間內全部文件的讀寫訪問權限。
• 對 MediaStore.Files 表的內容的訪問權限。

應用可使用 MediaStore API 或原始文件路徑來訪問這些文件。若是應用使用存儲訪問框架，不能使用它來訪問「全部文件訪問權限」提供的其餘文件和目錄。得到此權限的應用仍然沒法訪問屬於其餘應用的應用專用目錄。這些目錄在存儲捲上顯示爲 Android/data/ 的子目錄。

自定義消息框視圖被屏蔽

出於安全方面的考慮，同時也爲了保持良好的用戶體驗，若是包含自定義視圖的消息框是以 Android 11 爲目標平臺的應用從後臺發送的，則系統會屏蔽這些消息框。請注意，仍容許使用文本消息框；此類消息框是使用 Toast.makeText() 建立的，並不調用 setView()。

若是您的應用仍嘗試從後臺發佈包含自定義視圖的消息框，則系統不會向用戶顯示相應的消息，而會執行如下操做：

1. 顯示如下消息框消息：

   Background custom toast blocked for package package-name. See g.co/dev/toast.

2. 在 logcat 中記錄如下消息：

   W/NotificationService: Blocking custom toast from package due to package not in the foreground

若是但願在消息框（文本消息框或自定義消息框）出現或消失時收到通知，請使用新的 addCallback() 方法。

這裏須要注意，因爲平臺行爲發生了變動，以 Android 11 爲目標平臺的應用會發現文本消息框受到如下負面影響：

• getView() 方法返回 null。
• 如下方法的返回值並不反映實際值，所以儘可能別使用：
  • getHorizontalMargin()
  • getVerticalMargin()
  • getGravity()
  • getXOffset()
  • getYOffset()
• 如下方法是空操做，所以應用不該使用：
  • [setMargin()](developer.android.google.cn/reference/a…(float, float))
  • [setGravity()](developer.android.google.cn/reference/a…(int, int, int))

前臺服務類型

從 Android 9 開始，應用僅限於在前臺訪問攝像頭和麥克風。爲了進一步保護用戶，Android 11 更改了前臺服務訪問攝像頭和麥克風相關數據的方式。若是應用以 Android 11 爲目標平臺而且在某項前臺服務中訪問這些類型的數據，則須要在該前臺服務的聲明的 foregroundServiceType 屬性中添加新的 camera 和 microphone 類型。

來舉個例子吧，若是應用中的某項前臺服務須要訪問與設備的位置信息和攝像頭相關的數據，請按如下代碼段所示聲明該服務：

<manifest>
        ...
        <service ... android:foregroundServiceType="location|camera" />
    </manifest>
複製代碼

MAC 地址

在以 Android 10（API 級別 29）及更低版本爲目標平臺的應用中，MAC 地址的隨機分配是基於每一個 SSID 進行的，由於 Passpoint 能夠鏈接到同一資料的不一樣 SSID。而在以 Android 11（API 級別「R」）及更高版本爲目標平臺的應用中，Passpoint 網絡的 MAC 地址隨機分配將更改成針對每一個徹底限定域名 (FQDN) 進行分配。

對於以 API 級別「R」及更高級別爲目標平臺的應用，非特權應用將沒法訪問設備的 MAC 地址；只有具備 IPv4 地址的網絡接口可見。會影響 getifaddrs() 和 NetworkInterface.getHardwareAddress() 方法，以及 RTM_GETLINK netlink 消息的發送。

下面列出了此變動會以哪些方式來影響應用：

• NetworkInterface.getHardwareAddress() 會針對每一個接口返回 null。
• 應用沒法對 NETLINK_ROUTE 套接字使用 bind() 函數。
• IP 命令不會返回有關接口的信息。

這些變動強制執行不要使用 MAC 地址中提供的指導。

請注意，大多數開發者應使用級別較高的 ConnectivityManager API 而不是級別較低的 NetworkInterface/getifaddrs() API。

每一個進程的網絡訪問控制

從 Android 11 開始，處理敏感用戶數據的應用能夠向每一個進程授予網絡訪問權限。經過明確指定容許哪些進程訪問網絡，您能夠隔離不須要上傳數據的全部代碼。

雖然不能保證防止應用意外上傳數據，但該功能可以讓下降應用中的錯誤致使數據泄露的概率。

下面顯示了使用這項新功能的清單文件的示例：

<processes>
        <process />
        <deny-permission android:name="android.permission.INTERNET" />
        <process android:process=":withoutnet1" />
        <process android:process="com.android.cts.useprocess.withnet1">
            <allow-permission android:name="android.permission.INTERNET" />
        </process>
        <allow-permission android:name="android.permission.INTERNET" />
        <process android:process=":withoutnet2">
            <deny-permission android:name="android.permission.INTERNET" />
        </process>
        <process android:process="com.android.cts.useprocess.withnet2" />
    </processes>
複製代碼

一次性權限

在 Android 11 中，每當應用請求與位置信息、麥克風或攝像頭相關的權限時，應用都會得到臨時的一次性權限。這個其實在蘋果中也有相似的權限申請。

Android 11 不建議重複請求特定權限組中的權限。在您的應用安裝到設備上後，若是用戶在使用過程當中兩次針對某項特定的權限點按拒絕，此操做表示其但願之後請求相應權限組中的該權限時「再也不詢問」。

系統還對與點按拒絕選項相仿的操做的響應行爲作出了定義：

• 若是用戶按返回按鈕關閉權限對話框，此操做不算「拒絕」操做。
• 若是用戶使用 [requestPermissions()](developer.android.google.cn/reference/a…(android.app.Activity, java.lang.String[], int)) 從您的應用轉到系統設置，而後按返回按鈕，此操做就算是「拒絕」操做。

懸浮窗口 intent 始終會將用戶轉至系統權限屏幕

從 Android 11 開始，ACTION_MANAGE_OVERLAY_PERMISSION intent 始終會將用戶轉至頂級設置屏幕，用戶可在其中授予或撤消應用的 SYSTEM_ALERT_WINDOW 權限。intent 中的任何 package: 數據都會被忽略。

在更低版本的 Android 中，ACTION_MANAGE_OVERLAY_PERMISSION intent 能夠指定一個文件包，它會將用戶轉至應用專用屏幕來管理權限。Android 11 再也不支持此功能，而是必須由用戶先選擇要對其授予或撤消權限的應用。此變動可讓權限的授予更有目的性，從而達到保護用戶的目的。

限制非 SDK 接口

若是應用並不是以 Android 11 爲目標平臺，那麼其中一些變動可能不會當即產生影響。雖然目前仍然可使用灰名單中的一些非 SDK 接口（取決於應用的目標 API 級別），但若是使用任何非 SDK 方法或字段，則應用沒法運行的風險終歸較高。

若是不肯定本身的應用是否使用了非 SDK 接口，則能夠測試該應用，進行確認。若是應用依賴於非 SDK 接口，則應該開始計劃遷移到 SDK 替代方案。若是沒法爲應用中的某項功能找到使用非 SDK 接口的替代方案，則應該請求新的公共 API。

Open Mobile API 變動

從 Android 11 開始，Open Mobile API (OMAPI) 有了額外的功能：

• 解析運營商權限的規則。
• 使用如下一項或多項來自定義嵌入式安全元件 (eSE) 訪問權限或配置 eSE：
  • 系統特許權限
  • 可配置的訪問規則應用主數據 (ARA-M) 應用標識符 (AID)
  • 用於重置 OMAPI 讀取器的系統 API
• 爲讀取器提供清晰的指示符，以便應用過濾設備功能。

支持併發使用多個攝像頭

Android 11 添加了 API 來查詢對同時使用多個攝像頭（包括前置攝像頭和後置攝像頭）的支持。

要在運行應用的設備上檢查支持狀況，請使用如下方法：

• getConcurrentStreamingCameraIds() 可返回攝像頭 ID 組合 Set，這些組合可與有保證的數據流組合併發進行流式傳輸（若是它們是由同一應用進程配置的）。
• isConcurrentSessionConfigurationSupported() 可查詢攝像頭設備是否能夠併發支持相應的會話配置。

總結

到這裏本篇文章也到了尾聲了，本文基本寫完了安卓11更新的主要內容，你們能夠根據應用實際狀況進行準備，如今還不着急適配，真正須要適配的話應該還得好幾個月。最後再放一下官網地址：developer.android.google.cn/preview。 若是本文對你有幫助的話記得點贊關注啊，感激涕零！！！