Android系统解耦方案

Android系统的mainlane计划

随着android-Q的到来，google对android framework中某些模块进行了独立解耦，不在运行在systemserver中,同时禁止各个odm/oem厂商修改这部分代码,仅仅提供了代码实现和一个单独的apk供厂商集成。

这一举措提高了google对android系统的管控力。如果说之前treble计划是促进了厂商的适配效率，那么mainlane就是强制厂商提升自身软件建设能力来提升升级效率的方案。

Mainlane后的升级策略

google会逐渐将aosp的主要代码进行分离，形成独立的apk由自己进行升级，不再依赖厂商的OTA。

之前的升级策略:

mainlane后的升级策略:

 

mainlane升级的影响

在android-O以前，所有厂商自身的客制化主要是通过修改systemserver实现的。修改的代码和AOSP交叉在一起，虽然得到了便利，但在每次版本升级都不断的引入CTS问题和兼容性问题。

Android-S开始mainlane计划强制厂商从AOSP解耦，保证AOSP代码的纯净。

对于厂商来讲，需要经过一些痛苦的架构变更，这一点索尼比较有远见，在android-O开始就做了完全的解耦。

组件化的思路

当前主流实现

插桩的方法简单直接，对AOSP实现的复用性比较高，如果各个厂商能够克制的修改是一个非常便捷的方法。但是事与愿违，各个厂商对AOSP代码的修改十分激进，甚至大量的修改google的原生逻辑，通过各种手段规避CTS问题进而引入系统兼容性问题、稳定性问题、内存碎片化和系统体积激增。google也意识到了这个问题，所以treble+mainlane计划随之产生。

解耦思路一:各行其是

模仿google的实现方案，例如:google封闭了networkstack，那么厂商的团队可以单独实现一个APK组件包含自己针对网络需求客制化的实现。

方案如下:

sdk和vendor feature分离的好处:

1.保证AOSP代码稳定性，减少兼容性问题

2.厂商组件fatal，不会导致上层重启

3.系统主体运行更加顺畅

解耦思路二:一刀切

直接创建一个和systemserver平行的进程也是一种比较好的办法。仅仅需要搭建一个平台，就可以解决所有客制化需求。

对比各行其是的组件化解耦，这种解耦方法更加适合作为过渡方案。

实现如下:

对比差异:

1.厂商的所有客制化需求杂糅在一个进程中，不符合软件工程中的解耦原则

2.一个模块的一场导致整个厂商的server进程重启，从进程角度看还是会导致上层重启

需要解决的问题

vendor service实现不是很复杂，需要实现基础的框架，打通和AOSP的hal native服务 插件的接口，注册binder，设置系统常驻服务等

SDK标准化需要确保内置应用可以访问但是外部应用无法访问，构建新的注释和权限似乎是一个很好的选择

sepolicy管控着对vendor和system的访问，所以vendor service可能需要搭建自由的hidl接口访问google服务，同时作为systemApp属性，需要额外增加一下权限

vendor native service:厂商对于native service的修改也要迁移出来，如wificond，netd等，google很可能也会mainlane这部分代码。

关于分区

OEM厂商增加的一系列组件最好单独放在一个分区中(和vendor一个分区也是一个选择)。因为google尝试锁定system分区，那么qcom等芯片厂商也可能锁定vendor分区。从升级的角度来讲，仅仅修改自身搭建的chip vendor也是一个非常高效的结构。