谷歌的Android Q到底有哪些新特性及變動？

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 行爲變動

最令咱們關心的，仍是咱們的適配工做。下面，分兩部分講：

1、針對全部運行在 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設備的性能特別有害。

2、針對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，系統將忽略全屏意圖。

閱讀更多

程序員接私活經驗總結

（Android）面試題級答案（精選版）

還在期待安卓9.0嗎？Android 10.0要來了

阿里內部的那個牛逼帶閃電的Java診斷工具終於開源了

錘子科技"臨死前"被"接盤"，內部人士爆料已改簽今日頭條母公司

若是對技術比較感興趣，歡迎關注公衆號：終端研發部，id：codeGoogler ，一塊兒交流和學習~