Android 11 开发者常见问题 | FAQ・第一期

存储

01

Q: Android 11 的分区存储是强制的吗？如果 targetSdkVersion 低于 Android 10，运行在 Android 11 的手机上，分区存储特性还生效吗？

当应用的 targetSdkVersion 升级到 Android 11 时，分区存储特性会强制生效。但如果应用 targetSdkVersion 未升级到 Android 11，运行在 Android 11 系统上时，分区存储不会强制生效。但根据 Google Play 的政策，在每一个 Android 大版本发布之后的次年 8 月，所有新发布的应用 targetSdkVersion 都需要升级至该版本或更高版本，且在版本发布的次年 11 月，所有应用 targetSdkVersion 都需要升级至该版本或更高版本。

02

Q: 清理工具类应用如何帮助用户清理应用专属目录中的数据？

MANAGE_EXTERNAL_STORAGE 权限一般适用于清理、文件管理、备份或恢复类型的应用，并且该权限会由 Google Play 来控制保护权限不会被滥用。清理类应用可以访问所有的外部存储，但同样也无法访问其他应用的专属目录。在分区存储中，应用的专属目录可以理解为和内部存储是等同的，在 Android 11 中也是不可以去访问的。如果清理类应用可以访问其他应用的专属目录，那么为了保护自己的数据，应用还是会选择将数据存放至内部存储中，这就和分区存储的出发点有异议了，所以也可以认为应用的专属目录就相当于是 "内部存储"。

03

Q: Android 11 以后，文件管理器或清理大师之类的第三方应用是不是就没有机会访问其它应用专属区域产生的文件了？

是的，如果第三方的文件管理应用还有机会去访问其他应用产生的专属目录里的文件，那么这些应用就可以进一步选择将应用文件放在内部存储中，这样对于外部存储来说并不是一个很好的应用规范。

权限

01

Q: 对于厂商自定义权限，没有采用 Google 的权限设计方式，导致应用开发各种兼容问题，是否考虑让厂商统一？比如浮窗权限 (甚至影响 Toast 的使用)，应用列表获取权限，各种 Google 没有定义的 sensor 权限。

如果各位开发者在开发过程中，发现应用在不同的手机上面的表现不一致，特别是如果认为某个手机的行为逻辑与 CDD 相悖，可以向我们反馈。通常 Android SDK 在所有 Android 手机上的表现应该都是一致的，但我们也知道某些厂商会增加一些新的功能，比如某些手机有一个电量优化的功能，对手机通知功能有影响，可能一定程度上影响用户体验及应用功能。

如果有一些功能只在部分手机厂商上存在，因为 Android 是开源的，厂商可以自行增加新的功能。对于这部分也希望各位开发者向我们反馈，让我们了解到一些功能对开发者和用户比较友好，希望可以增加到 AOSP 中。我们也可以和厂商反馈，连同厂商、开发者和用户一起把整个 Android 做的更好。

CDD

https://source.android.google.cn/compatibility/cdd

02

Q: shouldShowRequestPermissionRationale 什么时候是 true？依据是什么？被 denied 过一次吗？

因为这个是系统级 API，所以只需要去调用并且按照返回值来做合适的操作就可以了。原则上来说，如果用户拒绝过一次，且拒绝时未选择 "don't ask me again" 选项，那么下一次返回值应该就是 true。如果想要了解更详细的实现细节，可查看 AOSP 中对应的源代码。对于应用开发者来说主要还是根据其返回值来判断即可。

相关文档

https://developer.android.google.cn/training/permissions/requesting

03

Q: 对于单独进程 (单独开了个服务，指定进程名，为后台进程)，Android 11 对定位是否有影响？

如果进程是后台进程，应用需要有后台定位权限才可获取位置信息。针对一些特殊情况会有针对处理，比如应用在后台但开启前台服务，通过一个持续性的通知让用户感知其在后台运行，在这种情况下我们会认为该应用是前台应用，那么应用有前台定位权限就可获取位置信息。

04

Q:访问后的回调是否会精确到具体是哪个接口涉及到某项敏感信息？比如 requestLocationUpdate 涉及位置信息。

设置数据访问操作回调 API 还处于 Developer Perview 阶段，后续会根据实际需求不断改进。类似的适用场景比如有些时候我们需要去了解用户的行为可能和某些权限有关，并且涉及权限和应用代码要求是否是一致的。如果已经知道具体的操作是通过哪些代码实现的，那就不需要使用这个 API。如果您不知道是通过哪些代码实现，或者是否是第三方库运行结果，那通过这个 API 会有很大帮助。具体还是要参考实际用例。

05

Q: Android 11 会禁用应用修改系统的位置吗？或者检测应用是否使用虚拟定位？

如果修改系统位置可能需要 Root 权限，这样就不是我们常规考量的用户体验了。关于检测是否使用虚拟位置，一些开发者的做法是通过检测当前设备上有没有装一些专门用于修改位置的应用来实现的，如果在 Android 11 中需要实现，需要考虑应用可见性，在 mainfest 文件中列明需要检测的应用包名即可。

06

Q: 一次性权限是要一直申请么？有没有白名单机制，比如我是相机应用，如果一直申请相机权限，可能会有一些体验问题。

一次性权限是由用户来授予的，应用是不能显式申请一次性权限的。应用执行的是告知用户要申请权限，然后用户选择给予的是一次性权限还是长期的权限，这对于应用来说是透明的。对于应用开发者，我们建议按照实践指南来开发，在每次需要使用权限时，应该检查是否获得相应权限，如果没有的话按照实践指南去申请对应权限。当用户授予对应权限后就可以继续运行；当用户没有授予相应权限，也可以提示用户解释为什么需要权限，让用户了解到权限申请的必要性。

一次性权限文档: https://developer.android.google.cn/preview/privacy/permissions

CameraX

01

Q: CameraX 是否会和更多的厂商合作，提供定制化的功能？

去年 I/O 大会上我们推出了一个 Jetpack 支持库 CameraX，旨在简化相机应用的开发工作。目前我们针对 CameraX 有合作的厂商包括三星、OPPO、小米、LG 等，还有一些其他厂商自己也在跟进。更多的还是取决于厂商自己对于手机功能开发的意愿，并且由于 CameraX 是一个开源的项目，我们不需要直接跟厂商去合作。

新的屏幕类型

01

Q: Android 11 对于折叠屏的支持有改进吗？

在 Android 11 中新增了一些针对折叠屏设备状态的 API，比如在第 2 个开发者预览版中新增了 API 来检测设备铰链的开合角度，这样应用就可以根据铰链的开合角度和位置显示不同内容。

隐私/安全

01

Q: Android 系统关于防破解如何从底层提供更好的支持？

国外开发者只需将应用上传至 Google Play 应用商店即可通过 Google Play 的安全防护机制有效的保护游戏和玩家利益、减少游戏被篡改和盗版的问题。如果有应用被破解或上传至 Play 应用商店，原开发者可以要求 Play 查明后进行下架处理。

而国内生态目前是比较碎片化，有很多发布渠道，所以防破解是个比较重要的需求。在了解到这个情况之后，我们也和很多的加固厂商建立了密切的联系。从 Android O 开始我们就一直在支持一些厂商的合理需求，比如 Android 10 中新增了一个新的公开接口， AppComponentFactory.instantiateClassLoader()，在应用被加载运行其他代码之前就创建并设置一个自定义的 ClassLoader，满足加固和热修复方案的需求。在 Android 11 中，我们又增加了 ResourcesLoader API，能够让加固和热修复方案通过系统支持的接口来做自定义的资源加载。我们也会持续和加固厂商合作提升加固，尽量少的使用私有 API，以全面的获得系统级别的支持。对于应用开发者来说，在选择了这些加固方案之后，也可以更好的保证应用对未来版本的 Android 系统兼容性。

02

Q: 在 里面的 intent action 写 android.intent.action.Main 是不是就相当于可以查询所有 App 是否已安装？因为几乎所有 App 都会申明这个 intent action。

之所以添加应用包可见性的改动，是为了保障用户隐私，不希望应用可以随意查询手机上所有应用。目前对于哪一些 action 可以查询是没有限制的，但相信在最终版本中是不允许对 android.intent.action.Main 进行查询的，无法获取结果。

03

Q: 灰名单的限制具体是哪些？是其他 jar 包访问不到？

灰名单和其他 jar 包没有关系。无论在任何渠道，目前调用浅灰名单没有问题，但无法保证在未来版本浅灰名单中的非 SDK 接口是否会移至黑名单，所以我们建议浅灰名单中的非 SDK 接口尽量减少调用。如果非 SDK 接口在深灰名单，就表明该非 SDK 接口是根据 targetSDKversion 区分，不同版本对于是否可以调用限制不同。这个限制和 jar 包无法访问是没有关系的，不管是从哪里调用这个接口。

非 SDK 接口限制文档

https://developer.android.google.cn/distribute/best-practices/develop/restrictions-non-sdk-interfaces

04

Q: 国外可以通过 Google Play policy 去控制 targetSdkVersion。国内环境，APK 的 targetSdkVersion 可以不升级，也可以安装使用，继续访问用户隐私数据 Android 新系统，对这个方向有没有什么想法 ？

其实我们也能看到国内的生态也对隐私和安全性越来越重视，之前也有看到工信部联合主流国内应用商店，对 targetSdkVersion 有了升级要求，虽然可能会相比我们对这个要求慢一些，但至少也是在不断升级。另外对于 targetSdkVersion 比较老的应用，从 Android 10 开始也会有一些系统层面的限制，比如 targetSdkVersion 小于 17 的应用，在安装和每次运行时都会给到用户提示警告。这些措施也都是希望联合整个 Android 生态中所有的参与者一起推进 targetSdkVersion 的升级，希望通过所有应用都升级至高版本的 targetSdkVersion 来让用户获得更好的安全性和隐私方面的体验。

应用包可见性

01

Q: 应用包名可见性会不会影响 deeplink、applink 等功能？

应用包名可见性的改动不会影响 deeplink 和 applink，因为底层系统会有一些改动，所以对于应用来说继续使用 deeplink 和 applink 理论上是不会有改动影响的。如果您要启动新的服务或启动过其他的应用，如果您的应用不可以看到其他的应用，是无法启动其他应用的组件。

API

01

Q: Android 10 或者 Android 11 中使用了黑名单或者灰名单的 API 后，会被 Google Play 应用商店拒绝吗？

如果应用使用了黑名单中的接口，运行时可能会有异常从而导致应用无法正常使用，那么 Google Play 是会拒绝上架的。私有名单的限制是 Android 系统层面执行的，我们做这个限制的目的并不是为了限制开发者，当开发者应用遇到问题时可以考虑是否必须要使用这个接口，或者也可以向我们反馈告知合理需求，希望开放公开的 SDK 接口来满足相应需求。

SDK

01

Q: 对于 targetSdkVersion 非 Android 11 的应用会有什么影响吗？

我们在每一次更新新的版本的时候会考虑尽量减少对于应用的影响。从这个角度来看，我们会尽量把行为变更放在 targetSdkVersion 升级之后。如果应用还没有升级到最新版本的 targetSdkVersion，就不会受到行为变更的影响。如果现有您的应用已经遵循我们的实践指南，受到变更的影响就会很小。但因为在 Android 11 中我们对系统底层也做了一些改动，比如权限管理、一次性权限还有分区存储的一些变更，我们也希望大家可以在 Android 11 模拟器或真机中调试自己的应用，以确保没有问题。

Android 11 行为变更指南:

https://developer.android.google.cn/preview/behavior-changes-all

02

Q: 是否能再解释一下 targetSdkVersion 的工作机制，比如运行在 Android 11 上的 App，Android 会根据各 App 的 targetSdkVersion = 30 / 29 / 28 来执行不同的代码吗？

我们在每次发布新版本的 Android 时，比如即将发布的 Android 11，改动会分为两类。第一类就是长期性的改动，不论 targetSdkVersion 版本，只要在系统中运行时改动就会长期执行。第二类就是根据 targetSdkVersion 来决定具体行为。如果改动是按照 targetSdkVersion 来决定，有一些改动只适用于 targetdkVersion 30 以上，那么您的应用 targetSdkVersion 是 29 或者以下的话，这些改动是不会影响您的应用行为的。只有升级到 targetSdkVersion 30 或以上，这些改动才会生效。

参考文档:

https://developer.android.google.cn/preview/behavior-changes-all

其他

01

Q: 关于 Android 虚拟机近期有什么更新？

在三月份我们发布了关于虚拟机的相关更新介绍，目前最新版本的虚拟机支持直接运行 ARM 应用，无需再构建 x86 版本，可以直接使用 ARM 版本。虚拟机可以高效地直接将 ARM 指令转换成 x86 指令，直接运行 ARM 应用也可以获得很好的性能。欢迎大家体验尝试。

02

Q: Android 是否考虑采用方法传递回调参数的形式解决回调，现在这种 Activity 的回调形式用起来很不方便。

在 Java 当中，如果大家惯用 Java 的 Callback，用起来可能会觉得语法比较复杂，其实在其他语言里都有支持 Lambda Expression 和 Functional Programming 的类似概念。如果大家还没有使用 Kotlin 的话，我们强烈建议大家可以去尝试一下，因为在 Kotlin 里对 Lambda 表达式算是 "一等公民" 的支持。如果大家情况允许的话可以尝试去选用 Kotlin。

03

Q: 画中画的窗口大小现在能支持自定义了吗？

目前还不可以，可以通过 setAspectRatio() 来设置宽高的比例，但是不可以指定一个具体的尺寸。画中画的窗口大小应该由用户去决定。

04

Q: 支不支持代码动态设置？

目前来说 标记只支持在 manifest 里面定义，不能在应用运行时动态设计。

05

Q: 一般 App 可能会有渠道包，例如 com.example.xiaomi com.example.huawei，在 manifest 是否能写 com.example.*？

目前在 manifest 中使用 getPackageInfo 或者 getInstalledPackages 去查询应用是否安装，必须要使用完整的应用包名才可以。

06

Q: 输入法动画有 Demo 参考吗？低版本如 Android 10 有办法使用吗？

GitHub 中我们提供了相应示例，通过参考示例代码可以有更完整的了解: https://github.com/android/user-interface-samples/tree/master/WindowInsetsAnimation

目前只有在 Andorid 11 中可以使用这个最新的 API，在低版本中无法使用。我们也会去评估是否可以支持在低版本的 Android 系统中使用。

07

Q: ApplicationExitInfo 的崩溃退出信息有多详细？是在崩溃后下一次启动 app 才能获取？

当应用崩溃之后，相关信息会存储在缓冲区，在应用即时可以存取。一般来说，当应用崩溃之后，用户会尝试再次打开应用，所以可以在下一次打开的时候将崩溃退出信息汇报至后台，开发者可以去查看分析具体是什么原因导致的。

08

Q: OBB、AAB 的功能有重叠，OBB 的初始化下载能否有保障？或者对于 OBB 的最佳实践是哪些场景？

其实 OBB 和 App Bundle 之间本身是没有重叠的，OBB 是为了带有很大资源包的游戏所单独设计的，Play 允许为每个游戏添加最多两个 OBB 文件，每个的上限是 2GB，所以最大可以包含 4GB 的资源包。而 App Bundle 是有比较严格的下载大小限制的，无法实现下载 4GB 的资源包，可以简单的理解为 OBB 是为游戏打造的，而 App Bundle 是为其他应用打造的。我们在上个月专门为游戏应用推出了一个跟 App Bundle 类似的产品，名为 Play Asset Delivery，让游戏也可以被拆分成多模块按照 App Bundle 的方式去分发。

参考文档: Google Play 优化高质量游戏交付

09

Q: Android 11 对于无障碍模式是否有限制或功能增强？

Android 在最近几年的版本中一直对无障碍模式、accessibility 都有越来越好的支持。在 Android 11 中也不会有更多的限制，并且还会有一些功能上的增强。请大家继续关注 Android 11 进展，我们在未来的开发者预览或者 Beta 版本中可能就会有一些关于无障碍模式的新功能公布。

即将到来的 Android 11 Beta

Android 11 第四个开发者预览版现已发布，带来了最新的 bug 修复、API 更新，以及可供您的应用测试的最新功能。为了更好地应对当下的挑战，我们更新了版本的发布日程，Beta 1 版本将于 6 月 3 日发布。为了更好地向大家介绍 Beta 1 的情况，以及为大家提供所需的技术资源，届时我们将举办一场线上开发者活动——Android 11: The Beta Launch Show。

请前往 Android 11 开发者网站了解详情，另外请继续和我们分享您的想法！

Android 11 开发者网站

https://developer.android.google.cn/preview

分享使用反馈

https://developer.android.google.cn/preview/feedback.html