系统角度解读Android P新特性

引言

2018年3月8日，谷歌发布了Android P的预览版，预计今年的Q3季度发布final release版本，有不少文章从开发者角度介绍了Android P的新特征，初步来看给感觉这次大版本似乎并没有什么改变。接下来，将从系统Treble，System，Framework，Runtime, Security等多方面来解读一下Android P的变化。

这是我的微信公众号：Android达摩院(AndroidAcademy)，出品的文章，欢迎大家关注，后续会有更多精彩内容。

Treble计划

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

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

treble.jpg

• Product: OEM相关定制，主要包括Apps，产品sysprops等
• System：Android系统的Framework和Daemons
• Treble Interface: Treble接口
• Vendor: 硬件相关
• 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兼容性对于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或者ODM属性必须有自己的命名空间，比如vendor., ro.vendor, persist.vendor等
4. vendor init使用vendor_init域名，保障只使用vendor相关权限，不可访问system-only的属性

VINTF(Vendor Interface)被分离成硬件无关(Framework)和硬件相关两部分。为了进一步规范化系统架构，定义了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

VNDK.jpg

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

其中VNDK + Framework libs组成system.img, Vendor libs组成vendor.img。