Android 11適配方案變更及適配攻略

總算開始了Android 11的適配作業(yè)。記載一下，供需求的人參看。

1. 預(yù)備工作

老規(guī)矩，首要將咱們項(xiàng)目中的 targetSdkVersion 改為 30。或許運(yùn)用兼容性調(diào)試東西，后邊我會(huì)提到。

2. 存儲(chǔ)機(jī)制更新

Scoped Storage（分區(qū)存儲(chǔ)）

詳細(xì)適配辦法和上一年的Android 10 適配攻略中的沒有太大差異。

不過需求留神的是，運(yùn)用targetSdkVersion >= 30，強(qiáng)制實(shí)施分區(qū)存儲(chǔ)機(jī)制。之前在AndroidManifest.xml中增加 android:requestLegacyExternalStorage="true"的適配辦法已不起效果。

還有一個(gè)改變：Android 11 容許運(yùn)用除 MediaStore API 之外的 API 經(jīng)過文件途徑直接拜訪同享存儲(chǔ)空間中的媒體文件。其間包括：

  • File API。
  • 原生庫，例如 fopen()。

假定你之前沒有適配Android 10，這一點(diǎn)對(duì)你來說是個(gè)好音訊。Android 10在AndroidManifest.xml中增加 android:requestLegacyExternalStorage="true"來適配，Android 11上直接運(yùn)用File API拜訪媒體文件。不得不說，等等黨的成功？

不過，運(yùn)用原始文件途徑直接拜訪同享存儲(chǔ)空間中的媒體文件會(huì)重定向到 MediaStore API，這次重定向會(huì)構(gòu)成功用影響（隨機(jī)讀寫慢一倍左右）。而且直接運(yùn)用原始文件途徑，并不會(huì)比運(yùn)用 MediaStore API 有更多優(yōu)勢(shì)，因而官方強(qiáng)烈主張直接運(yùn)用 MediaStore API。

MANAGE_EXTERNAL_STORAGE

當(dāng)然還有一種簡(jiǎn)略粗暴的適配辦法，獲取外部存儲(chǔ)辦理權(quán)限。假定你的運(yùn)用是手機(jī)管家、文件辦理器這類需求拜訪大量文件的app，能夠央求MANAGE_EXTERNAL_STORAGE權(quán)限，將用戶引導(dǎo)至體系設(shè)置頁面翻開。代碼如下：

<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE"
tools:ignore="ScopedStorage" />


public static void checkStorageManagerPermission(Context context) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R &&
!Environment.isExternalStorageManager()) {
Intent intent = new Intent(Settings.ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
}
}

需求留神的是即便你有了MANAGE_EXTERNAL_STORAGE權(quán)限，也無法拜訪Android/data/目錄下的文件。

關(guān)于MANAGE_EXTERNAL_STORAGE權(quán)限，國(guó)內(nèi)運(yùn)用應(yīng)該沒有什么影響?？墒窃贕oogle Play上需求說明為什么已有的SAF或MediaStore不滿足你的運(yùn)用需求，審核經(jīng)過才容許上架運(yùn)用。所以一般狀況下，我個(gè)人不推薦你為了適配簡(jiǎn)略，直接央求運(yùn)用MANAGE_EXTERNAL_STORAGE權(quán)限。

其他細(xì)節(jié)改動(dòng)見文檔：Android 11 中的存儲(chǔ)機(jī)制更新。

相關(guān)api改動(dòng)及運(yùn)用推薦郭霖大神的這篇：Android 11新特性，Scoped Storage又有了新花樣。

存儲(chǔ)拜訪結(jié)構(gòu) (SAF)改動(dòng)

Android 11對(duì)SAF增加以下束縛：

  • 運(yùn)用 ACTION_OPEN_DOCUMENT_TREE 或 ACTION_OPEN_DOCUMENT，無法閱讀到Android/data/ 和 Android/obb/目錄及其悉數(shù)子目錄。
  • 運(yùn)用 ACTION_OPEN_DOCUMENT_TREE無法授權(quán)拜訪存儲(chǔ)根目錄、Download文件夾。

REQUEST_INSTALL_PACKAGES

在8.0的適配中，咱們?cè)O(shè)備apk包之前需求央求“設(shè)備不知道來歷運(yùn)用”的權(quán)限。一般來說初次是跳轉(zhuǎn)到授權(quán)頁面讓用戶手動(dòng)翻開，然后回來app進(jìn)行設(shè)備。

在Android 11中當(dāng)用戶打開“設(shè)備不知道來歷運(yùn)用”的權(quán)限，app就會(huì)被殺死。該行為與強(qiáng)制分區(qū)存儲(chǔ)有關(guān)，由于持有 REQUEST_INSTALL_PACKAGES 權(quán)限的運(yùn)用能夠拜訪其他運(yùn)用的Android/obb 目錄。

好在用戶公布權(quán)限之后，盡管app會(huì)被殺死，可是設(shè)備頁面仍然會(huì)彈出。

現(xiàn)在關(guān)于這一改動(dòng)我沒有發(fā)現(xiàn)能夠適配處理的辦法，詳細(xì)介紹見：Android 11特性調(diào)整：設(shè)備外部來歷運(yùn)用需求重啟APP

3.權(quán)限改變

單次權(quán)限授權(quán)

從 Android 11 開始，每當(dāng)運(yùn)用央求與方位信息、麥克風(fēng)或攝像頭相關(guān)的權(quán)限時(shí)，面向用戶的權(quán)限對(duì)話框會(huì)包括僅限這一次選項(xiàng)。假定用戶在對(duì)話框中挑選此選項(xiàng)，體系會(huì)向運(yùn)用公布暫時(shí)的單次授權(quán)。

單次權(quán)限授權(quán)的運(yùn)用能夠在一段時(shí)間內(nèi)拜訪相關(guān)數(shù)據(jù)，詳細(xì)時(shí)間取決于運(yùn)用的行為和用戶的操作：

  • 當(dāng)運(yùn)用的 Activity 可見時(shí)，運(yùn)用能夠拜訪相關(guān)數(shù)據(jù)。
  • 假定用戶將運(yùn)用轉(zhuǎn)為后臺(tái)作業(yè)，運(yùn)用能夠在短時(shí)間內(nèi)繼續(xù)拜訪相關(guān)數(shù)據(jù)。
  • 假定您在 Activity 可見時(shí)主張了一項(xiàng)前臺(tái)服務(wù)，而且用戶隨后將您的運(yùn)用轉(zhuǎn)到后臺(tái)，那么您的運(yùn)用能夠繼續(xù)拜訪相關(guān)數(shù)據(jù)，直到該前臺(tái)服務(wù)中止。
  • 假定用戶撤消單次授權(quán)（例如在體系設(shè)置中撤消），不管您是否主張了前臺(tái)服務(wù)，運(yùn)用都無法拜訪相關(guān)數(shù)據(jù)。與任何權(quán)限相同，假定用戶撤消了運(yùn)用的單次授權(quán)，運(yùn)用進(jìn)程就會(huì)中止。

當(dāng)用戶下次翻開運(yùn)用而且運(yùn)用中的某項(xiàng)功用央求拜訪方位信息、麥克風(fēng)或攝像頭時(shí)，體系會(huì)再次提示用戶公布權(quán)限。

假定你之前就是運(yùn)用權(quán)限時(shí)才央求相關(guān)權(quán)限，那么這一改動(dòng)關(guān)于你的運(yùn)用沒有影響。

央求方位權(quán)限

這部分在Android 10的適配有過調(diào)整，其時(shí)規(guī)則如下：

央求ACCESS_FINE_LOCATION或 ACCESS_COARSE_LOCATION權(quán)限標(biāo)明在前臺(tái)時(shí)具有拜訪設(shè)備方位信息的權(quán)限。在央求彈框中，挑選“一向容許”標(biāo)明前后臺(tái)都能夠獲取方位信息，挑選“僅在運(yùn)用運(yùn)用進(jìn)程中容許”只標(biāo)明具有前臺(tái)的權(quán)限。

在Android 11中，央求彈框中取消了“一向容許”這一選項(xiàng)。也就是說默許不會(huì)公布你后臺(tái)拜訪設(shè)備方位信息的權(quán)限。假定檢驗(yàn)央求ACCESS_BACKGROUND_LOCATION權(quán)限的一同央求任何其他權(quán)限，體系會(huì)拋出失常，不會(huì)向運(yùn)用公布其間的任一權(quán)限。

官方給出的適配主張及原因如下：

主張運(yùn)用對(duì)方位權(quán)限實(shí)施遞加央求，先央求前臺(tái)方位信息拜訪權(quán)限，再央求后臺(tái)方位信息拜訪權(quán)限。實(shí)施遞加央求能夠?yàn)橛脩艄┙o更大的控制權(quán)和透明度，由于他們能夠更好地了解運(yùn)用中的哪些功用需求后臺(tái)方位信息拜訪權(quán)限。

總結(jié)一下得出兩點(diǎn)：

  • 先央求前臺(tái)方位信息拜訪權(quán)限，再央求后臺(tái)方位信息拜訪權(quán)限。
  • 單獨(dú)央求后臺(tái)方位信息拜訪權(quán)限，不要與其他權(quán)限一同央求。

這兒還需求留神不同方針途徑運(yùn)用在Android 11上的表現(xiàn)：

  • Android 10 為方針途徑的運(yùn)用
    容許一同拜訪前后臺(tái)的方位信息權(quán)限，但相同不會(huì)有“一向容許”這一選項(xiàng)。
  1. 沒有前后臺(tái)的方位信息權(quán)限時(shí)：

  1. 有前臺(tái)的方位信息權(quán)限時(shí)：

  • Android 11 為方針途徑的運(yùn)用
  1. 沒有前后臺(tái)的方位信息權(quán)限時(shí)，只能先央求前臺(tái)的方位信息權(quán)限：

  1. 有前臺(tái)的方位信息權(quán)限，央求后臺(tái)的方位信息時(shí)體系會(huì)跳轉(zhuǎn)到下面的設(shè)置頁面。


挑選“一向容許”標(biāo)明具有前后臺(tái)方位信息拜訪權(quán)限，假定用戶回絕兩次運(yùn)用定位拜訪央求（直接回來等），后邊央求相同權(quán)限都會(huì)被直接提示央求失利。（這兒就需求咱們給用戶以引導(dǎo)了）

這兒解釋一下“回絕兩次”，這是Android 11 上增加的權(quán)限對(duì)話框的可見性，從前咱們點(diǎn)擊了“不再問詢”標(biāo)明回絕授權(quán)?，F(xiàn)在還包括相似上面這種轉(zhuǎn)到體系設(shè)置，然后點(diǎn)回來按鈕，也算是回絕授權(quán)。當(dāng)然，用戶按回來按鈕封閉權(quán)限對(duì)話框，此操作不算。

總結(jié)一下，與Android 10的差異就是將后臺(tái)權(quán)限的央求分離了出來，增加了用戶“回絕”的條件，避免了運(yùn)用重復(fù)央求用戶已回絕的權(quán)限。

軟件包可見性

軟件包可見性是Android 11上提高體系隱私安全性的一個(gè)新特性。它的效果是束縛app隨意獲取其他app的信息和設(shè)備狀況。避免病毒軟件、間諜軟件利用，引發(fā)網(wǎng)絡(luò)垂釣、用戶設(shè)備信息走漏等安全事情。

獲取主動(dòng)可見運(yùn)用的列表，能夠?qū)嵤┲噶?code>adb shell dumpsys package queries，找到 forceQueryable 部分。下面是在vivo iqoo手機(jī)的實(shí)施效果。

Queries:
system apps queryable: false
forceQueryable:
[com.android.BBKCrontab,com.vivo.fingerprint,com.vivo.epm,com.vivo.abe,com.vivo.fingerprintengineer,com.vivo.contentcatcher,com.vivo.floatingball,com.vivo.agent,com.vivo.nightpearl,android,com.wapi.wapicertmanage,com.vivo.vms,co
m.android.providers.settings,com.vivo.upslide,com.vivo.assistant,com.vivo.vivokaraoke,com.vivo.fingerprintui,com.android.wallpaperbackup,com.bbk.facewake,com.vivo.faceunlock,com.vivo.doubleinstance,com.vivo.audiofx,com.iqoo.powersav
ing,com.bbk.SuperPowerSave,com.vivo.vibrator4d,com.vivo.smartunlock,com.vivo.globalanimation,com.vivo.appfilter,com.vivo.voicewakeup,com.vivo.minscreen,com.android.bbklog,com.mobile.cos.iroaming,com.vivo.networkstate,com.vivo.daemon
Service,com.vivo.smartshot,com.vivo.vtouch,com.android.networkstack.tethering.inprocess,com.android.localtransport,com.vivo.pem,com.vivo.wifiengineermode,com.android.server.telecom,com.vivo.gamecube,com.vivo.aiengine,com.vivo.multin
lp,com.vivo.smartmultiwindow,com.vivo.permissionmanager,com.qti.diagservices,com.vivo.bsptest,com.qti.snapdragon.qdcm_ff,com.vivo.dr,com.vivo.sps,com.android.dynsystem,com.vivo.setupwizard,com.vivo.gamewatch,com.android.keychain,com
.vivo.faceui,com.android.networkstack.inprocess,com.android.location.fused,com.android.inputdevices,com.android.settings,com.iqoo.engineermode,com.vivo.fuelsummary]
[com.qualcomm.uimremoteserver,com.vivo.devicereg,com.qti.qualcomm.deviceinfo,com.volte.config,com.android.mms.service,com.android.ons,com.qualcomm.qcrilmsgtunnel,com.vivo.sim.contacts,com.qualcomm.qti.uimGbaApp,com.qualcomm.qti.
modemtestmode,com.android.stk,com.android.vendors.bridge.softsim,com.qualcomm.uimremoteclient,com.qti.qualcomm.datastatusnotification,com.qualcomm.qti.uim,com.android.phone,com.qualcomm.qti.dynamicddsservice,com.qualcomm.qti.telepho
nyservice,com.android.cellbroadcastservice,com.android.providers.telephony,com.qti.dpmserviceapp,com.android.incallui]
[com.android.vivo.tws.vivotws,com.android.bluetooth]
com.android.nfc
com.android.se
com.android.networkstack.permissionconfig
com.android.shell
com.android.providers.media.module
com.android.wifi.resources.overlay.common
com.android.theme.icon_pack.filled.themepicker
com.android.theme.icon_pack.circular.themepicker
com.android.server.telecom.overlay.common
......

能夠看到都是體系運(yùn)用包名，所以咱們的三方運(yùn)用默許是不行見的。此項(xiàng)改動(dòng)影響比較多的是共享支付一類需求與其他運(yùn)用交互的功用。下面舉一個(gè)簡(jiǎn)略的比如：


private static boolean hasActivity(Context context, Intent intent) {
PackageManager packageManager = context.getPackageManager();
return packageManager.queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY).size() > 0;
}
public void test() {
Intent intent = new Intent();
intent.setClassName("com.tencent.mm", "com.tencent.mm.ui.tools.ShareImgUI");
Log.d("hasActivity:", hasActivity(this, intent) + "");
}

hasActivity辦法中經(jīng)過queryIntentActivities來判別此頁面是否存在。可是在targetSdkVersion >= 30中，這些三方默許都是不行見的。所以都會(huì)回來false。相似辦法getInstalledPackages、getPackageInfo也遭到相應(yīng)的束縛。

解決辦法很簡(jiǎn)略，在AndroidManifest.xml 中增加queries元素，里面增加需求可見的運(yùn)用包名。

<manifest package="com.example.app">
<queries>
<package android:name="com.tencent.mm" /&gt; <- 指定微信包名
</queries>
...
</manifest>

我在適配中用到的還有下面的包名，咱們能夠按需增加：

<queries>
<!-- 微博 -->
<package android:name="com.sina.weibo" />
<!-- QQ -->
<package android:name="com.tencent.mobileqq" />
<!-- 支付寶 --&gt;
<package android:name="com.eg.android.AlipayGphone" />
<!-- AlipayHK -->
<package android:name="hk.alipay.wallet" />
</queries>

除了直接增加包名的辦法外，咱們能夠按intent和provider來增加：

<manifest package="com.example.app">
&lt;queries>
<intent>
<action android:name="android.intent.action.SEND" />
<data android:mimeType="image/jpeg" />
</intent&gt;
<provider android:authorities="com.example.settings.files" />
</queries>
...
</manifest>

詳細(xì)的規(guī)則拜見：辦理軟件包可見性

當(dāng)然，還有一種簡(jiǎn)略粗暴的辦法，能夠直接央求權(quán)限QUERY_ALL_PACKAGES。假定你的運(yùn)用需求上架Google Play，那么或許要留神相關(guān)方針。為了尊重用戶隱私，主張?jiān)蹅兊倪\(yùn)用按正常作業(yè)所需的最小軟件包可見性來適配。

有一點(diǎn)需求說明一下，咱們?nèi)粘＿\(yùn)用的startActivity 辦法不受體系軟件包可見性行為的影響，即便hasActivity為false，相同能夠跳轉(zhuǎn)。假定咱們?cè)谧鎏D(zhuǎn)前，進(jìn)行相似hasActivity的判別，那么會(huì)受影響。

最終需求留神的是，運(yùn)用queries元素需求Android Gradle 插件版別是 4.1及以上，由于舊版其他插件并不兼容此元素，出現(xiàn)合并 manifest 的過錯(cuò)。

前臺(tái)服務(wù)類型

Android 10中，在前臺(tái)服務(wù)拜訪方位信息，需求在對(duì)應(yīng)的service中增加 location 服務(wù)類型。

相同的，Android 11中，在前臺(tái)服務(wù)拜訪攝像頭或麥克風(fēng)，需求在對(duì)應(yīng)的service中增加camera或microphone 服務(wù)類型。

<manifest>
...
<service
android:name="MyService"
android:foregroundServiceType="microphone|camera" /&gt;
</manifest>

這一束縛的改動(dòng)，使得程序無法在后臺(tái)主張服務(wù)拜訪攝像頭和麥克風(fēng)。如需運(yùn)用，只能是前臺(tái)翻開前臺(tái)服務(wù)。除非有如下狀況：

  • 服務(wù)由體系組件主張。
  • 服務(wù)是經(jīng)過運(yùn)用小部件主張。
  • 服務(wù)是經(jīng)過與告知交互主張的。
  • 服務(wù)是PendingIntent主張的，它是從另一個(gè)可見的運(yùn)用程序發(fā)送過來的。
  • 服務(wù)由一個(gè)運(yùn)用程序主張，該運(yùn)用是一個(gè)DPC，且在設(shè)備悉數(shù)者形式下作業(yè)。
  • 服務(wù)由一個(gè)供給VoiceInteractionService的運(yùn)用主張。
  • 服務(wù)由一個(gè)具有START_ACTIVITIES_FROM_BACKGROUND權(quán)限的運(yùn)用主張。

權(quán)限主動(dòng)重置

假定運(yùn)用以 Android 11 或更高版別為方針途徑而且數(shù)月未運(yùn)用，體系會(huì)經(jīng)過主動(dòng)重置用戶已公布運(yùn)用的作業(yè)時(shí)活絡(luò)權(quán)限來保護(hù)用戶數(shù)據(jù)。如下圖所示：

留神上圖中有一個(gè)主張主動(dòng)重置的開關(guān)。假定咱們的運(yùn)用有特別需求，能夠引導(dǎo)用戶封閉它。示例代碼如下：

public void checkAutoRevokePermission(Context context) {
// 判別是否翻開
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R &&
!context.getPackageManager().isAutoRevokeWhitelisted()) {
// 跳轉(zhuǎn)設(shè)置頁    
Intent intent = new Intent(Intent.ACTION_AUTO_REVOKE_PERMISSIONS);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setData(Uri.fromParts("package", context.getPackageName(), null));
context.startActivity(intent);
}
}

SYSTEM_ALERT_WINDOW權(quán)限

這部分我在適配中沒有用到，直接照搬文檔：

在 Android 11 中，體系會(huì)依據(jù)央求主意向某些類型的運(yùn)用公布 SYSTEM_ALERT_WINDOW 權(quán)限：

  • 體系會(huì)主意向具有 ROLE_CALL_SCREENING 且央求 SYSTEM_ALERT_WINDOW 的悉數(shù)運(yùn)用公布該權(quán)限。假定運(yùn)用失掉 ROLE_CALL_SCREENING，就會(huì)失掉該權(quán)限。

  • 體系會(huì)主意向經(jīng)過 MediaProjection 截取屏幕且央求 SYSTEM_ALERT_WINDOW的悉數(shù)運(yùn)用公布該權(quán)限，除非用戶已清楚回絕向運(yùn)用公布該權(quán)限。當(dāng)運(yùn)用中止截取屏幕時(shí)，就會(huì)失掉該權(quán)限。此用例首要用于游戲直播運(yùn)用。

這些運(yùn)用無需發(fā)送 ACTION_MANAGE_OVERLAY_PERMISSION 以獲取 SYSTEM_ALERT_WINDOW 權(quán)限，它們只需直接央求 SYSTEM_ALERT_WINDOW 即可。

MANAGE_OVERLAY_PERMISSION intent 一向會(huì)將用戶轉(zhuǎn)至體系權(quán)限屏幕

從 Android 11 開始，ACTION_MANAGE_OVERLAY_PERMISSION intent 一向會(huì)將用戶轉(zhuǎn)至頂級(jí)設(shè)置屏幕，用戶可在其間公布或撤消運(yùn)用的 SYSTEM_ALERT_WINDOW 權(quán)限。intent 中的任何 package: 數(shù)據(jù)都會(huì)被疏忽。

在更低版其他 Android 中，ACTION_MANAGE_OVERLAY_PERMISSION intent 能夠指定一個(gè)軟件包，它會(huì)將用戶轉(zhuǎn)至運(yùn)用專用屏幕以辦理權(quán)限。從 Android 11 開始將不再支撐此功用，而是有必要由用戶先挑選要公布或撤消哪些運(yùn)用的權(quán)限。此改動(dòng)能夠讓權(quán)限的公布更有目的性，然后達(dá)到保護(hù)用戶的目的。

讀取手機(jī)號(hào)

假定你是經(jīng)過TelecomManager的getLine1Number辦法，或TelephonyManager的getMsisdn方法獲取電話號(hào)碼。那么在Android 11中需求增加READ_PHONE_NUMBERS權(quán)限。運(yùn)用其他辦法不受限。

<manifest>
<!-- 假定運(yùn)用僅在 Android 10及更低版別中運(yùn)用該權(quán)限，能夠增加 maxSdkVersion="29" -->
<uses-permission android:name="android.permission.READ_PHONE_STATE"
android:maxSdkVersion="29" />
<uses-permission android:name="android.permission.READ_PHONE_NUMBERS" /&gt;
</manifest>

4.其他行為改動(dòng)

自定義view的Toast

Android 11 為方針途徑的運(yùn)用，從后臺(tái)發(fā)送自定義view的Toast音訊體系會(huì)進(jìn)行屏蔽。前臺(tái)運(yùn)用不受影響。Toast相應(yīng)的setView 和 getView也現(xiàn)已扔掉不主張運(yùn)用。

假定要在后臺(tái)運(yùn)用，推薦運(yùn)用默許的toast或Snackbar替代。

APK簽名

Android 11 為政策途徑的運(yùn)用，僅經(jīng)過v1 簽名的運(yùn)用無法在Android 11的設(shè)備上設(shè)備或更新。有必要運(yùn)用v2或更高版別進(jìn)行簽名。

一同Android 11 增加了對(duì) APK 簽名方案 v4 的支撐。

AsyncTask

AsyncTask在Android 11現(xiàn)已不主張運(yùn)用，主張遷移至kotlin的協(xié)程。

此外Handler未指定Looper的結(jié)構(gòu)辦法也已不主張運(yùn)用。

主張清楚指定Looper：

private Handler handler = new Handler(Looper.myLooper());
// 或
private Handler handler = new Handler(Looper.getMainLooper());

5.新增東西

兼容性調(diào)試東西

以往咱們做適配的時(shí)分，需求先將咱們項(xiàng)目中的 targetSdkVersion 修改為對(duì)應(yīng)版別。這就導(dǎo)致你適配進(jìn)程中有或許遭到其他改動(dòng)的影響，而這個(gè)新增的兼容性調(diào)試東西能夠讓你在不晉級(jí)targetSdkVersion的狀況下，針對(duì)每項(xiàng)改動(dòng)逐一翻開適配。

運(yùn)用辦法：

  • 開發(fā)者選項(xiàng)中找到運(yùn)用兼容性改動(dòng)選項(xiàng)。
  • 點(diǎn)擊進(jìn)入找到你需求調(diào)試的運(yùn)用
  • 在改動(dòng)列表中，找到想要翻開或封閉的改動(dòng)，然后點(diǎn)擊相應(yīng)的開關(guān)。


上面榜首行DEFAULT_SCOPED_STORAGE就是啟用分區(qū)儲(chǔ)存，這些常量詳細(xì)的意義見：Android 11 改動(dòng)列表。

關(guān)于兼容性調(diào)試東西詳細(xì)的運(yùn)用辦法見：兼容性結(jié)構(gòu)東西，這兒限于篇幅就不打開說了。

無線調(diào)試

Android 11的開發(fā)者選項(xiàng)中增加了一個(gè)無線調(diào)試的功用。相似于聯(lián)接藍(lán)牙耳機(jī)功用，可以無需USB聯(lián)接線進(jìn)行日常開發(fā)調(diào)試作業(yè)。（差異于從前的Android WIFI ADB，這個(gè)是真無線，哈哈）

運(yùn)用辦法：

  • 開發(fā)者選項(xiàng)中找到無線調(diào)試并翻開。
  • 初次配對(duì)需點(diǎn)擊“運(yùn)用配對(duì)碼配對(duì)設(shè)備”
  • 作業(yè) adb pair ipaddr:port后輸入配對(duì)碼進(jìn)行聯(lián)接。

留神事項(xiàng)：

  • 堅(jiān)持電腦和手機(jī)在一個(gè)網(wǎng)絡(luò)。
  • Platform Tools 版別需大于30.0?？蛇\(yùn)用adb --version檢查。

不過我自己領(lǐng)會(huì)下來，感覺聯(lián)接不是很安穩(wěn)，不知是AS的問題仍是手機(jī)問題。一同鎖屏后也會(huì)斷開聯(lián)接，領(lǐng)會(huì)不是很好。。。等候后續(xù)的優(yōu)化吧。

本篇內(nèi)容有點(diǎn)多。總結(jié)一下，Android 11在權(quán)限上的改動(dòng)比較多，但假定你一向恪守央求權(quán)限相關(guān)的最佳做法，那么根本上不需求額定的適配作業(yè)。

最終側(cè)重一下，關(guān)于單次授權(quán)，權(quán)限對(duì)話框的可見性，SYSTEM_ALERT_WINDOW 權(quán)限，設(shè)備apk這些改動(dòng)只要在Android 11上就會(huì)收效，不管你是否適配Android 11。關(guān)于其他改動(dòng)和API（相機(jī)、5G、瀑布屏、鍵盤等），由于我暫時(shí)沒有遇到，也就沒有列出，有需求的能夠點(diǎn)擊文末的官方文檔鏈接檢查。

截止發(fā)這篇博客時(shí)，我手機(jī)上只發(fā)現(xiàn)嗶哩嗶哩現(xiàn)已適配了Android 11。大多數(shù)停留在28、29，更有甚者還在26（Android 8.0 國(guó)內(nèi)上架的最低適配標(biāo)準(zhǔn)）。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容