Android P 系统新特性概述

蔚落 2022-03-26 07:12 713阅读 0赞

## 1. 引言 ##

2018 年 3 月 8 日，谷歌发布了 Android P 的预览版，初步来看给感觉这次大版本似乎并没有什么改变。接下来，将从系统 Treble、System、Framework、Runtime、Security 等多方面来解读一下 Android P 的变化。

## 2. Treble 计划 ##

Treble 计划是一个非常重要的变革，对系统层面的影响很大。Google 每发布一个 Android 大版本，到厂商和 APP 的适配，过程是漫长的，每一次大版本适配工作的艰难厂商最能体会，各种兼容性问题。正如去年发布的 Android O，目前 Android O 机型用户量比较小，APP 都没能快速跟进把 targetSdk 适配到 O 的情况下，Android P 又即将到来，Android 系统的碎片化一直是一个痛点。该计划的核心主旨是让系统与硬件相关的解耦，加快系统升级速度。Treble 始于 Android O，到 Android P 又得以进一步完善。

接下来，来看看Treble在整个Android系统的位置：

![image][]

图中各个层级：

1.  Product：OEM 相关定制，主要包括 Apps、产品 sysprops 等
2.  System：Android 系统的 Framework 和 Daemons 等
3.  Treble Interface: Treble 接口
4.  Vendor: 硬件相关
5.  ODM: ODM 相关定制，比如 VINTF 支持

最中间 Treble Interface 组成成分，在 Android O 添加的接口：C++ 依赖（使用 VNDK）、IPC 调用（使用 HIDL)，SELinux、通用 Kernel 接口、Android Verified Boot（AVB）；到 Android P 新增接口：Java 依赖（使用 System SDK ）、系统 Properties。从图中可以看出 Treble 计划是希望底层 Vendor 用旧版本，也能支持 System 层升级为新版本，从而保证 Android 大版本可快速升级。

#### System Property 更新 ####

这里需要注意，System Property 兼容性对于 Treble 来说是非常糟糕的，它允许平台和 Vendor 之间通过非稳定通道进行跨进程通信，这与 Treble 的分离解耦背道而驰。 为此，Treble 计划通过分离 Properties 到 Platform 和 Vendor。Platform 进程只能访问 Platform 属性，Vendor 进程只能访问 Vendor 属性, 当然也是允许 Platform 属性去暴露给 Vendor 进程。

1.  所有 Platform 对外暴露的属性位于 system/sepolicy/public/property\_contexts，Vendor 无法访问其他的平台属性
2.  所有可用于 Vendor Init 脚本的属性位于 system/core/init/stable\_properties.h，Vendor Init 脚本不能使用其他的平台属性来作为 action triggers
3.  Vendor 属性必须有自己的命名空间，比如 “vendor.”、“ro.vendor.”、“persist.vendor.” 等
4.  Vendor Init 使用 vendor\_init 域名，保障只使用 Vendor 相关权限，不可访问 system-only 的属性

#### VNDK（Vendor NDK）供应商原生开发套件 ####

VINTF（Vendor Interface）被分离成硬件无关（Framework）和硬件相关（Hal）两部分。为了进一步规范化系统架构，定义了 CKI（Common Kernel Interface）作为通用系统镜像必须依赖的内核接口集，并且对 Kernel 分支也进行了有效的精简。 VTS 会测试 HAL、Kernel、 VNDK 的可靠性，CTS 测试通用系统接口、framework feature。从 Android O 以后就强制要求，通过 CTS/VTS 则会为 system 解耦合的适配提供了保障。

Treble 语境中，Vendor 是指片上系统的 HAL 层和外围设备，不依赖于硬件的软件则不属于 Vendor  
，而 VNDK 是指 Vendor 用于实现 HAL 层所提供的系统库。

*  Platform 和 Vendor 的构建是相互隔离的。
 *  Platform lib 对应 system.img。
 *  Vendor lib 对应 vendor.img。
 *  大多数情况下，Vendor lib 跟系统核心不能相互使用；Vendor lib 不允许 dlopen 私有的系统库
 *  合作伙伴不允许为自己的产品在 VNDK 新增 lib，只能贡献到 AOSP

![image][image 1]

这一切都是为系统库与 Vendor 库之间的解耦合，在 Android P 上采用该方案，则下一个大版本 Android Q 更新，可以直接将新的 System Q 加上老 Vendor P，组成新版本 Android。

- VNDK + Framework libs -> system.img
    - Vendor libs -> vendor.img

Android P 新添加命名空间：

*  System 命名空间 /system/lib/;
 *  Vendor 命名空间有 /system/lib/vndk、/system/lib/vndk-sp、/vendor/lib/vndk、/vendor/lib/vndk-sp

## 3. System ##

### 3.1 存储性能提升 ###

FDE 用于 Android 6.0, FBE 用于Android 7.0，并且会创建 DE 和 CE 两个目录，提供更好的用户体验和隐私安全。 FDE 很快会被彻底移除， 另外，未来会有更快的加密算法。

#### 文件系统 ####

文件系统配额从 Android 8.0 开始支持，三个主要目标是：

*  当打开设置时能快速计算存储使用情况，提供更好的用户体验。
 *  更快和更公平的 cache 管理，通过 quotas 来管控滥用的 app。
 *  通过配额方式来限制应用滥用存储空间。

Fair cache 策略：

1.  分配 cache 配额给每个 App（基于他们使用的频率），删除最老的 cached 文件，直到有足够的空闲空间。
2.  最佳实践：定期调用新方法以保证系统有机会去删除缓存文件，可以 follow PackageInstaller、DownloadManager 和 DocumentsUI，限制滥用 App。
3.  设备应该卸载恶意 App，或者删除大文件。
4.  避免设备卡在循环的重启过程。
5.  阻止 App 使用 block90% 或者 inodes50%。
6.  exFAT：Google 没有资源支持相关的更新工作，只有会部分补丁。
7.  vold：跟 fw 通信方式，由 socket 调整为 binder 方式，用于提高性能；这是继 installerd 之后的再一次由 socket 转变成 binder 模块。
8.  TRIM：该过程会运行 f2fs GC 操作，并且在夜间空闲时间来被调度执行。
9.  FUSE: 已被删除，采用 sdcardfs, 后续会有 esdfs 用于更深远的优化。
10. 更快的文件拷贝：FileUtils.copy 比纯 userspace 的方式快 35~50%。
11. FDE、FUSE、ASECs 这些都被删除。

### 3.2 Kernel ###

*  Framework 域的 feature 后续依赖 Kernel 3.18 或之后的版本，3.10 将不再维护。另外 Kernel 4.14 已推到 AOSP。
 *  ION：libion 在 Android P 上已支持新的 Kernel ION 接口，强烈建议 使用 libion，而非直接使用 ion ioctl 调用。
 *  kernel + clang：强烈建议采用 clang 5.0 或之后版本，出错信息提供精准定位，占用内存和编译速度快，而 gcc 有一定的历史问题。
 *  sdcardfs：android O 默认的文件系统（ro.sys.sdcardfs=1），Android O 上默认的文件系统是 sdcardfs，但允许关闭，回退到 FUSE。而 Android P 则计划直接删除 FUSE，很快会更新一版 sdcardfs。对于文件系统，即便不使用 sdcardfs，也强烈推荐使用基于内核的文件系统，而非用户空间。

### 3.3 LMKD 调整 ###

##### 基于内核的 LMK 缺点： #####

*  依赖于硬编码的剩余内存限制，而非基于内存紧张情况来调整；
 *  厂商定制化比较多，也就意味着原有的设计比较死板，不适合增加 policy 定制，没有以 group 方式来杀进程；
 *  在 slab shrinker API 中插桩，Shrinkers 本应该快速 drop 不再使用 caches 并退出，以避免拖慢内存扫描进程。但事实上，LMK 执行的工作量包括搜索目标进程以及杀掉它们，这个过程并非快速完成的动作  
    有可能出现把重要的进程杀掉，而非重要进程并没有被杀
 *  从内核 4.12 中会移除 LMK;

##### 替代方案：用户态 LMKD + memory cgroups #####

*  可打造更智能的基于内存压力的杀进程策略 memory cgroups，内存压力事件，内存记账功能，额外的控制类似 relaim 和 swappiness 能被更方便的记录日志和 track；
 *  该方案的挑战：每个 App 需要有内存记账；杀进程组耗时，cgroups 之间的 task 转移代价比较高；
 *  相应解决方案：最新内核已降低内存开销，应用启动时间增加了 3%，在多个小的 LRU 队列并不高效；
 *  杀进程组耗时的问题，通过将杀进程过程移到 AMS 锁之外；
 *  LMKD 的杀进程组委托给 ActivityManager；

##### 用户态LMKD策略： #####

*  通过 ro.config.low\_ram 属性来划分低内存设备和高性能设备
    
     *  低内存设备：中等内存压力出现得比较常见，杀进程主要针对 medium 和 critical 内存压力情况，配置 oom\_adj\_score，内存压力基于 swap 使用情况。杀进程策略会延迟，尽量保持服务处于运行中的状态。
     *  高性能设备：优先考虑性能和尽可能留有更多内存来优化用户体验。杀的策略会提前，一次会杀多个进程以保证内存处于低压力状态，更加激进地释放内存以保持系统处于低内存压力的状态。

##### 未来 #####

*  提高杀进程策略，基于输入信号（可用内存、task大小、内存压力值、内存压力事件的频繁程度）。
 *  合并杀进程策略，提供更多 control 机制。
 *  探索杀的时机，以及内存压力的潜力。
 *  配合 cgroups v2。

### 3.4 F2FS ###

sdcardfs 和 fuse 才是一个层面的东西，sdcardfs 比 fuse 的的性能更好，对同一文件的操作，fuse 需要经历 6 次用户态与内核态的切换，而 sdcardfs 只需要两次。

（F2FS，Flash-Friendly File System）文件系统重要特性：

1.  后台清理：当文件系统碎片化比较严重的时候，读写速度会有所下降，开启一个反碎片的后台线程来清理文件碎片；
2.  异步 discard：discard 文件系统的淘汰存储空间，对于减少闪存过度 GC 是很有必要的，当同步的 discard 对用户来说会有比较大的延迟，故采用异步 discard；
3.  原子写：SQLite 是 Android 默认的数据库，通过管理记录文件来保障数据安全，这会带来大量冗余的写和同步操作；原子写能有效减少记录文件；

**F2FS 相比 ext4 在文件顺序写、随机写以及 SQLite 方面有较大幅度的提升。Google 将持续调整 F2FS 的性能与稳定性方面的表现。**

### 3.5 性能 ###

在 Android O 上将 Binder 大锁拆分为更细粒度的锁，便真正解决了 Binder 锁竞争问题。

*  内核驱动代码在必要时可采用 RT 调度器，避免在驱动里有长时间地禁用抢占
 *  建议
    
     *  如果可能，建议使用 mem cgroups
     *  userdata 文件系统，建议采用 f2fs
     *  关闭不需要的内核配置项
     *  移除不必要的日志
     *  在早期的内核中建议低内存设备要开启 KSM，之后的版本不要使用 KSM

Android P 上更加注重相同性能下如何改进功耗，EAS 作为通用的基于功耗模型和性能数据的 CPU 调度算法，而非 tuning 的方式。 为什么 Android 采用 EAS 调度算法呢？需要一个标准的结合功耗和性能的调度器，能通过 Framework 来调整调度策略，这里需要考虑资源负载均衡、大小核、cpufreq、 governor、减少大核的使用、平衡功耗问题。

## 4. Framework ##

### 4.1 AMS ###

从 Android P 开始，只有当 Intent-Flag 中指定了 FLAG\_ACTIVITY\_NEW\_TASK，才允许在非 Activity 场景启动 Activity。 App 必须拥有 FOREGROUND\_SERVICE 权限，才允许使用前台服务，否则会抛出异常。

目前很多 APP 开发者们对 Android O 的一些后台限制行为不太了解这些变更，遇到问题可能误以为系统问题，所以这里说到这顺便提一下关于 Android O 对后台行为的一些管控。

*  后台服务（Background Service）限制
    
     *  当进程处于后台 1 分钟后会进入 idle 状态，系统停止其后台服务，也就意味着应用处于后台必须1分钟内处理完收尾工作，不允许在后台长时间监控系统，从而节省功耗；对于应用后台执行用户不可感知的操作，官方推荐使用 JobScheduler。
     *  后台进程不允许通过 startService 方式启动服务，否则当 targetSdk>=26 的情况下会抛出 IllegalStateException。
     *  对前台服务（Foreground Service）不会有这个限制，因为前台服务都会挂一个前台通知对用户来说是可见的 。Android O 新增 startForegroundService()，用于启动前台服务，但有一个限制条件就是应用必须服务启动后 5 秒之内调用 startForeground()，否则会抛出 ANR
 *  广播（Broadcast）限制:
    
     *  应用无法使用其清单注册的大部分隐式广播，但部分隐式广播是被允许的, 比如 BOOT\_COMPLETED、LOCALE\_CHANGED 等。这样做是为了省电和性能，防止大量 APP 通过监听各种广播来拉起自己。
     *  清单注册的显式广播和动态注册的隐式广播依然可以正常工作。

### 4.2 PMS ###

重构 PackageManger，减少核心服务的代码复杂度，将 permission、intent 等代码移到单独的类，将 user management、dex、shortcuts 等不相关代码移到子包；尽可能操作本地数据，避免加锁；同时增加单元测试。

PMS 在 Android O 主要改动是优化启动时间，将操作尽可能并行化执行，在 Android P 上主要改动是扫描过程 scanPackageOnly()， 下一步提取更多的子组件和类，比如 Intent resolution、package verification、dexopt 等，减少修改对象成员的方法。

### 4.3 WMS ###

在 Android O 上，结构化窗口对象模型和容器层次结构, 提高 CTS 覆盖率并引入单元测试，SurfaceFlinger 中引入层级结构用于 SurfaceView，引入 Task 快照。在 Android P 上，继续提升创建对象模型，同步 APP Transitions、WindowScope 工具。

过度使用 Stack ID, Stack 管理着类似的 task 和 activity，特定的窗口模式，例如 HOME\_STACK\_ID、FULLSCREEN\_STACK\_ID、FREEFORM\_STACK\_ID，这就导致同一个 Stack 的 task 和 activity 不允许有不同的窗口模式。新的方案允许有多个 WindowContainers，窗口模式不再受限于 Stack ID。

采用同步的 APP Transitions， animations 的过程可不再需要 WMS 大锁。另外 Transitions、WindowScope 工具是一个类似于 systrace 的工具，可用于方便查看 WindowManager 和 SurfaceFlinger，仅在 userdebug 版本开启，对性能影响较小。

### 4.4 续航提升 ###

之前关于续航方面，有 JobScheduler、Doze 限制隐式广播、后台服务和定位限制，缓存 wakelock 释放等功能， 一直以来 Google 在功耗方面没有从整体上的策略，不同 OEM 往往会有不同的策略针对功耗，比如 Force stop app、kill activity/service 等。这次 Android P 在功耗方面也是重点，Google 计划在 Android P 上采用机器学习的思路来预测用户使用习惯，来做省电优化。 从而把 APP 分为四类 Active、working\_set、frequent、rare，划分到不同 bucket 的 App 则采取对 Jobs、Alarms、Network、FCM 等限制策略。

目前很多应用为了后台存活，都挂 fg-service，其实 Google，包括厂商都非常不建议开发者一直这样使用的，应该尽量克制，只要需要的场景使用，比如后台导航、后台播放音乐。 这也是为什么 fg-service 一定要显示通知，为的是让用户可知应用的行为，对于不该后台活动的依然挂前台通知，那么用户可能会主动杀它，甚至卸载。

### 4.5 机器学习 ###

在 Android O 中引入神经网络 API，提供 Android 内置的机器学习，在 Android P 中又进一步扩展和改进 TensorFlow。

在 Android P 上采用 AI 预测用户行为来进行更智能化的省电策略，在 UI 搜索界面也使用到机器学习，AI 正在逐步强化 Android 系统。

Dynamic App 需应用商店支持，资源文件、配置、语言、App 内部基于版本格式的信息等都可以采用 Dynamic App 来精简 APK 尺寸。

Autofill：平台、插件、app、浏览器，一套完整的自动填充框架解决方案。

### 4.6 Location ###

**电话体验** 提升打电话的用户体验，扩展 APIs 从而支持不同 APP 的电话并发，Telecom 可跟踪所有的活动来电，但只有一个应用可获取焦点。另外， 调整 SIM 状态改变的广播，SIM\_STATE\_CHANGED 改为 SIM\_CARD\_STATE\_CHANGED和SIM\_APPLICATION\_STATE\_CHANGED 广播。 也同步调整了 TelephonyManager。

**活动检测** 活动检测会结合传感器和声音数据，能识别走路、跑步、骑车、开车、上下楼梯，甚至要区分使用者是在汽车、地铁、火车，还是摩托车，也能识别睡眠模式， 当 AR 检测到处于开车模式，则停止通知以避免打扰开车人员。为系统提供使用者活动状态转换的 API。

**室内导航** 一直以来无法做到精准的 WIFI 室内定位，此次 Android P 系统支持了 IEEE 802.11mc WiFi 协议，室内导航功能即将到来，应用能使用室内定位，为定位服务提供便利。

**CHRE** 优化功耗就意味着需要尽可能少的唤醒 AP，比如 Doze 模式、后台定位限制模式。定义一个 Context Hub 运行时环境，在该环境下的 CPU 不允许直接运行 Java/Linux，只允许执行特殊的功能。 在 Android P 实现了 Context Hub Service，使用起来更加简单。后续可以有 always-on、低功耗模式。

## 5. Runtime ##

### 5.1 ART 和 libcore ###

在安装、更新、OTA 的时候 ART 需从 APK 里提取压缩过的 dex 并进行校验，这样既浪费空间，也浪费 CPU 时间。 为此，正在做的方案是采用未压缩的 dex 文件，商店将会对其进行 Java 校验并将校验结果直接在安装过程使用。 对于 dex 文件开始采用一个新的紧凑的格式，减少对内存和存储空间的使用，更加智能的布局优化，更少的闪存读取。

关于调试方面，使用 JVMTI 来替代 ART debugger，提供更多的扩展功能，包括断点、异常等事件，本地变量审查，字段监测，类的重定义。

Backtraces 使用 Java 上下文来显示，省去使用 addr2line 来转换的一个过程，方便调试分析问题。

将 Kotlin 作为 Android 官方正式语言，其性能并不会比 Java 执行慢。

**Profiles in the Cloud** 从 Android N 开始使用 Profile 方式编译，对于存储空间、内存、功耗、CPUs 使用率都有益处，但目前 Profile 只是本地的方式，在优先之前仍需要等待获取 Profile。未来收集用户的 Profile，并上传到云端（Google play），在安装时从云端获取 Profile 直接使用到新用户。 大概能提升 20% 的冷启动性能。

**core lib** 升级 libcore 代码到 OpenJDK 9。APP 弃用策略，Android 将添加支持的最低版本，当 targetVersionSdk < 17 的 App 则会弹出警告框。 从 bootclasspath 中移除 Apache HTTP 库、JUnit。

### 5.2 Soong 编译系统 ###

采用 Soong 来编译 Java，从 GNU Make 移植到 Soong

跨版本构建过程：

![image][image 2]

Android P 到处可见的 Android.bp，所有依赖必须使用 Android.bp，androidmk 工具可用于将 [Android.mk][] 文件转换为 Android.bp 文件；

### 5.3 私有API ###

Android P 在运行时强制限制应用通过反射方式来操作被标记为 @hide 的类、方法、属性。 将 API 分为 4 类：白名单、灰名单、深灰名单、黑名单。

*  当 API 属于白名单不限制
 *  灰名单（targetSdk ≥ P）警告
 *  黑名单抛出 NoSuchFieldException/NoSuchMethodException 异常。
 *  深灰名单，介于灰名单和黑名单之间，取决 targetSdk，当（targetSdk ≥ P）按黑名单方式处理，当（targetSdk < P）按灰名单方式处理。

对于黑名单只允许平台 APP 使用，对于灰白名单的 API 虽然不会直接抛出异常，但不再保证跨版本的兼容性，这样限制是为了后续新版本能更快地完成适配。

Google 之所以要设计灰白黑名单，也是为了给应用一个过渡时机，也给 Android 一个完善公开 API 的机会，对于某些很重要的 @hide 接口，可能也会考虑适当增加公开接口，另外那些 API 会被第一批加入黑名单，还需拭目以待。对于 AOSP 的黑名单和深灰名单将放入 CTS 测试，进而限制厂商不能轻易修改名单。

关于兼容性测试，Google 目前有 CTS/VTS/GTS，其中 CTS 主要测试 API 行为，VTS 针对 Treble 计划以及测试 HW 实现，GTS 针对 GMS 需求和分销协议， 很快 Google 还会推出 STS，用于隐私测试。从 Top 应用的测试数据来看，目前国内大多数的 APP 都存在兼容性问题，问题主要集中在热修复、混淆、加固以及依赖 internal API。

另外，@SystemApi 不再向后兼容，几乎所有的系统 API 都需要权限。 /vendor/priv-app 将在 Android P 上支持，权限会被限制有 vendorPrivileged 标识的权限。

## 6. Security ##

将所有网络流量从明文转向 TLS，更改网络安全性配置（Network Security Configuration）的默认值，以阻止所有明文流量。 为保护用户隐私，当应用 UID 空闲时，断开应用对摄像头、话筒、传感器的使用，如果应用强制使用则会产生错误，从而进一步防止流氓应用后台手机隐私数据。

FBE 加密：FBE 将会更容易支持高端元数据加密的设备以及对 sdcard 的支持。对于 OEMs 能够更简单地移植。对于低端设备，更快速的算法，适合所有机型的移植。

## 总结 ##

*  Android P 的 Treble 计划为后续 Android 大版本可快速升级提供支撑；
 *  用全新的 Soong 编译系统，将 [Android.mk][] 全面替换为 Android.bp；
 *  私有 API 的限制进一步规范化 Android 生态，但同时也面临着生态圈中大多数的 APP 都不可用的风险挑战；
 *  默认采用 sdcardfs 提升存储性能，F2FS 相比 ext4 在文件顺序写、随机写以及 SQLite 方面有较大幅度的提升；
 *  Framework 逐步优化 PMS、WMS大锁，未来应该还优化 AMS 锁；
 *  逐步试水 AI 技术，增强对 APP 后台管控，以提升系统续航能力；

总之，Google 一方面从系统层面不断优化 Android 系统，另一方面致力于改善 APP 生态，不断加强对非友善 APP 的管控，减少其对系统性能与续航的影响。

[image]: /images/20220326/b09d8d609010444b9aea1137a7359cb5.png
[image 1]: /images/20220326/70eae4596bd941f5a25b028d8c1e3975.png
[image 2]: /images/20220326/cd68732ccd6e422ea0d57d60993d8873.png
[Android.mk]: http://Android.mk