Android Q 新特性及變更記錄

xiasem發表於2019-04-03
Android

Android Q 隱私更改相關介紹

儲存範圍變更

Android Q 改變了應用程式訪問裝置外部儲存上檔案的方式。 通過使用更細粒度的媒體特定許可權替換以前的 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE許可權。

外存中私有目錄許可權變更

Android Q 為每個應用程式提供了一個獨立的在外部儲存裝置的儲存沙箱，沒有其他應用可以直接訪問您應用的沙盒檔案。由於檔案是私有的，因此訪問這些檔案不再需要任何許可權。
並且 Android Q 推薦了獲取外部儲存私有檔案的最佳位置：即Context.getExternalFilesDir（）返回的位置，因為此位置在所有Android版本中表現一致。使用此方法時，請傳入與要建立或開啟的檔案型別對應的媒體環境。例如，要訪問或儲存app-private影象，請呼叫Context.getExternalFilesDir（Environment.DIRECTORY_PICTURES）。

公共媒體集合特性

  1. 定義公共媒體集合：Photos & Videos、Music、 Downloads。

  2. APP 無需請求任何許可權即可在這些共享集合中建立和修改自己的檔案。

  3. 如果你的APP想建立和修改其他應用已建立的檔案，則必須首先請求相應的許可權：

訪問Photos & Videos目錄的其他應用程式檔案 需要請求 READ_MEDIA_IMAGES 或 READ_MEDIA_VIDEO 許可權，具體取決於您的應用程式需要訪問的檔案型別。

訪問 Music 共享集合中的其他應用程式檔案需要 READ_MEDIA_AUDIO 許可權。

沒有訪問Downloads共享集合的許可權，您的應用可以訪問此集合中自己的檔案。但是，要訪問此集合中的其他應用程式檔案，您必須允許使用者使用系統的檔案選擇器應用程式選擇檔案。

訪問共享集合

訪問共享集合通過 MediaStore API ，如 MediaStore.Images、MediaStore.Video、MediaStore.Audio、MediaStore.Downloads。

需要注意的是：對於 Android Q 上新安裝的應用，對 getExternalStoragePublicDirectory（）的呼叫僅提供對應用已儲存在其隔離儲存沙箱中的檔案的訪問許可權。要保持對其他應用程式檔案的訪問許可權，請更新應用程式的邏輯以使用MediaStore。

新增 ACCESS_MEDIA_LOCATION 許可權

一些照片在其資料中會包含位置資訊，允許使用者檢視拍攝照片的位置。由於此位置資訊是敏感的，因此我們想獲取位置資訊需要以下幾步：

  1. 將新的 ACCESS_MEDIA_LOCATION 許可權新增到AndroidManifest。

  2. 獲取位置資訊

photoUri = MediaStore.setRequireOriginal(photoUri);
InputStream stream = getContentResolver().openInputStream(photoUri);
//從流中讀取位置資訊
複製程式碼
儲存新特性相容

target API 級別等於 Android Q 的應用，或者在執行Android Q 的裝置上新安裝的應用預設都會採取新的許可權策略
如果你的APP同時滿足以下兩個條件，則會相容以前的許可權策略：

  1. targetSdkVersion <= Android 9
  2. 你的應用安裝在從 Android 9 升級到 Android Q 的裝置上
識別特定的外部儲存裝置

Android Q 為每個外部儲存裝置提供唯一的卷名。

 //獲取卷名方式
Set<String> volumeNames = MediaStore.getAllVolumeNames(context);
複製程式碼

Activity後臺活動限制

Android Q 對應用未經通知使用者就啟動進行了極大地限制，在Android Q上執行的應用只有在滿足以下一個或多個條件時才能啟動活動：

  1. 該APP具有可見視窗，例如有前臺Activity
  2. 位於前臺的另一個 APP 傳送屬於該應用程式的 PendingIntent。
  3. 系統傳送屬於該 APP 的PendingIntent，例如點選通知。
  4. 系統嚮應用程式傳送廣播，例如SECRET_CODE_ACTION。只有應用程式預期啟動UI的特定廣播才免除。
活動限制的相容性

此行為更改適用於在 Android Q 上執行的所有應用，甚至是針對Android 9（API級別28）或更低階別的應用。但是，只要您的應用以使用者互動的直接結果開始活動，您的應用很可能不會受到此更改的影響。實際上，大多數應用程式都不受此更改的影響。

此外，Android Q 建議我們 後臺應用程式都應建立通知，以便向使用者提供資訊，而不是直接啟動活動。

一些特殊情況如：來電或者警報，需要立刻啟動 Activity，則可以通過建立高優先順序的通知，並提供 fullscreen itent。如何建立高優先順序通知？

裝置位置許可權的訪問控制

使用者可以更好地控制應用何時可以訪問裝置位置。當在Android Q上執行的應用程式請求位置訪問時，會通過對話方塊的形式給使用者進行授權提示。此對話方塊允許使用者授予對兩個不同範圍的位置訪問許可權：在使用中（僅限前臺）或始終（前臺和後臺）。

新增許可權 ACCESS_BACKGROUND_LOCATION

如果你的應用針對 Android Q 並且需要在後臺執行時訪問使用者的位置，則必須在應用的清單檔案中宣告新許可權

<manifest>
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>
複製程式碼
位置限制的相容性

如果您的應用在 Android Q 上執行但針對的是 Android 9（API級別28）或更低版本，則會出現以下行為：

  1. 如果你的應用為 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION 宣告 標記，則系統會在安裝期間自動為ACCESS_BACKGROUND_LOCATION 新增 標記。
  2. 如果你的應用請求 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION，系統會自動將 ACCESS_BACKGROUND_LOCATION新增到請求中。
  3. 雖然你的應用可以請求並接收 ACCESS_BACKGROUND_LOCATION，但使用者可以通過選擇您的應用僅應在前臺訪問位置資訊來撤消此許可權。

對資料和識別符號的更改

影響在Android Q 上執行的所有應用的更改：

聯絡人親緣關係

從Android Q開始，該平臺不再跟蹤聯絡人親緣關係資訊。因此，如果您的應用對使用者的聯絡人進行搜尋，則結果不再按互動頻率排序。 “聯絡人提供程式”指南包含一個通知，說明自Android Q起所有裝置上已廢棄的特定欄位和方法。

MAC地址隨機化

在Android Q 執行的裝置預設傳輸隨機的MAC 地址，獲取隨機MAC地址API：WifiConfiguration.getRandomizedMacAddress()
獲取實際硬體MAC地址：WifiInfo.getFactoryMacAddress()。

唯一識別符號

應用必須具有 READ_PRIVILEGED_PHONE_STATE 特權許可權才能訪問裝置的不可重置識別符號，包括IMEI和序列號。原則上 Android Q 建議避免使用更容易關聯到個人的硬體識別符號，而是使用例項ID。例項ID的做法推薦

訪問剪貼簿資料

除非您的應用程式是預設輸入法編輯器或當前具有焦點的應用程式，否則您的應用程式無法訪問剪貼簿資料。

影響針對 Android Q API 級別執行的應用的更改：

訪問USB序列需要使用者許可

如果您的應用針對Android Q，則您的應用只能在使用者授予您訪問USB裝置或配件的應用許可權後才能讀取序列號。

相機和連線相關更改

影響在Android Q 上執行的所有應用的更改：

訪問相機資訊需要獲得許可

Android Q更改了預設情況下getCameraCharacteristics（）方法返回的資訊的廣度。特別是，您的應用必須具有CAMERA許可權才能訪問此方法的返回值中包含的潛在裝置特定後設資料。

啟用和禁用Wi-Fi的限制

在Android Q上執行的應用無法啟用或停用Wi-Fi。 WifiManager.setWifiEnabled（）方法始終返回false。 如果需要，請使用設定皮膚提示使用者啟用和禁用Wi-Fi。

影響針對 Android Q API 級別執行的應用的更改：

電話，Wi-Fi，藍芽API所需的精確位置許可

除非您的應用具有ACCESS_FINE_LOCATION許可權，否則在Android Q上執行時，您的應用無法在Wi-Fi，Wi-Fi Aware或藍芽API中使用多種方法。要檢視受影響方法的列表，請參閱隱私附錄。

Wi-Fi網路配置限制

將Wi-Fi網路列表的手動配置限制在系統應用程式中。如果您的應用針對Android Q，則以下方法不再返回有用資料,下面方法將不會返回有效資訊：

  • getConfiguredNetworks（）方法始終返回空List
  • addNetwork（）和updateNetwork（） - 始終返回-1
  • 返回布林值的每個網路操作 - removeNetwork（），reassociate（），enableNetwork（），disableNetwork（），reconnect（）和disconnect（） - 始終返回false

物理活動識別

針對 Android Q API 級別執行的應用，Android Q為需要檢測使用者移動的應用程式（例如步行，騎自行車或車輛）引入了新的ACTIVITY_RECOGNITION執行時許可權。這旨在讓使用者瞭解設定中如何使用裝置感測器資料。

Android Q 行為變更

最令我們關心的，還是我們的適配工作。下面，分兩部分講：

一、針對所有執行在 Android Q 上的app的行為變更

非SDK介面限制更新（Non-SDK interface restrictions）：

為了確保應用穩定性和相容性，Google 在 Android O 中開始限制使用哪些非SDK介面（API級別28）。 Android Q 更新了非SDK介面的限制列表，並且修改了限制規則。

1.灰名單修改：在Android 9（API級別28）中，灰名單分為以下兩個列表：

（1）lightgrey列表: targetSdkVersion<28 情況下可以使用的非SDK介面

（2）darkgrey list：targetSdkVersion>=28 情況下無法使用的非SDK介面

在 Android Q 中，我們現在將這兩個列表統稱為 greylist（灰名單），但是受目標API級別限制：
如在 Android P 中被限制的黑灰色名單：darkgrey list 現在叫做 greylist-max-o， 在 Android Q 中被限制的非SDK介面應該稱為 greylist-max-p

2.程式碼註釋修改：引入以下註解來區別哪些非SDK介面在哪個API做了限制 @UnsupportedAppUsge 無限制的灰名單
@UnsupportedAppUsage(maxTargetSdk = 0) 黑名單，哪個API都不能呼叫
@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.O) API <= Android O 可以呼叫
@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.P) API <= Android P 可以呼叫
Android Q 非SDK介面限制列表過長，這裡直接附上查詢地址

WIFI P2P 廣播（Wi-Fi Direct broadcasts）：

在 Android Q 上，與 Wi-Fi Direct 功能相關的廣播不再具有粘性。如果你的 APP 依賴於在註冊時接收這些廣播，可以在初始化時使用適當的get（）方法來獲取資訊，具體可參考 WifiP2pManager 類相關方法。

SYSTEM_ALERT_WINDOW 許可權在 Android Go 裝置變更

在Android Q（Go版）裝置上執行的應用無法接收SYSTEM_ALERT_WINDOW許可權。這是因為繪製疊加視窗使用過多的記憶體，這對低記憶體Android裝置的效能特別有害。

二、針對API級別為 Android Q 的行為變更

如果你的應用將targetSdkVersion設定為“android-Q”或更高版本，則下面的你需要注意了。

灰名單變更

灰名單變更參考“針對所有執行在 Android Q 上的app的行為變更”的策略，意味著@UnsupportedAppUsage(maxTargetSdk < Build.VERSION_CODES.Q) 的非API方法你都需要注意了！！！

共享記憶體

針對Q的應用不能再直接使用ashmem（/ dev / ashmem），而必須通過NDK的ASharedMemory類訪問共享記憶體。此外，應用程式無法直接對現有的ashmem檔案描述符進行IOCTL，而必須使用NDK的ASharedMemory類或Android Java API來建立共享記憶體區域。在使用共享記憶體時，此更改可提高安全性和穩健性，從而提高Android整體的效能和安全性。

Android runtime only accepts system-generated OAT files

Android執行時（ART）不再從應用程式程式呼叫dex2oat。此更改意味著ART將僅接受系統生成的OAT檔案。

Permissions changes for fullscreen intents

使用全屏Intent通知的應用必須在其應用的 Manifest 檔案中請求 USE_FULL_SCREEN_INTENT 許可權，這是正常許可權，因此係統會自動授予。 如果針對Android Q或更高版本的應用嘗試在不請求USE_FULL_SCREEN_INTENT許可權的情況下建立具有全屏的Intent，系統將忽略全屏意圖。

相關文章