android架构拆分方案-结构相关方案与技术

上上android架构拆分思想https://blog.csdn.net/dongyi1988/article/details/128617738

上文编译拆分https://blog.csdn.net/dongyi1988/article/details/128629011

android如此大系统，结构上有一些耦合依赖比较严重的模块，需要设计解耦方案。

android架构官网地址https://source.android.google.cn/docs/core/architecture?hl=zh-cn

规范统一HIDL/AIDL接口

https://source.android.google.cn/docs/core/architecture/hidl?hl=zh_cn

boot变更

follow https://blog.csdn.net/dongyi1988/article/details/103994321可知boot包含kernel，ramdisk，dtb三大部分，以及参数cmdline；

Boot Image Header的版本变化可以看到boot内容的变更

https://source.android.google.cn/docs/core/architecture/bootloader/boot-image-header

android R涉及boot改动内容太多，linux解耦参考https://blog.csdn.net/dongyi1988/article/details/128731557

GKI（通用内核镜像）

https://source.android.google.cn/docs/core/architecture/kernel?hl=zh-cn

DTB&DTBO（设备树&设备树叠加层）

https://source.android.google.cn/docs/core/architecture/dto/partitions

https://blog.csdn.net/dongyi1988/article/details/103995862 2、多设备树叠加层合入(dtbo)

ko模块（linux动态加载模块）

https://www.bbsmax.com/A/Ae5RN42r5Q/

DLKM 分区,动态加载模块分区https://source.android.google.cn/docs/core/architecture/partitions/vendor-odm-dlkm-partition

ODM、product、version编译

这几个镜像是集合到super里面的sparse格式压缩镜像，原格式一般是文件系统格式，开机时直接挂载使用。

查编译日志，编译mk文件可以看到编译规则。

GSI（通用系统镜像）

android system域解耦参考https://blog.csdn.net/dongyi1988/article/details/128739983

https://developer.android.google.cn/codelabs/using-android-q-gsi#0

https://source.android.google.cn/docs/setup/build/gsi

vendor（平台仓）

高通和MTK开始分仓了，肯定会用到VNDK，具体细节查看源码。

VNDK（The Vendor Native Development Kit）

google官网https://source.android.google.cn/docs/core/architecture/vndk

使用方式参考官网或源代码。

技术扩展

开机logo自适应方案

https://blog.csdn.net/dongyi1988/article/details/103995862 1、多开机画面适配

SELinux

SELinux 也有域的概念、system与vendor域添加位置不同，启动加载不同https://source.android.google.cn/docs/security/features/selinux/vendor-init?hl=zh-cn

https://blog.csdn.net/dongyi1988/article/details/103994152日志种多次加载SELinux文件规则也是受开机流程影响，第一次load rootfs的policy，第二次load system的policy，第三次 load vendor的policy。

Overlayfs

Overlayfs是一种类似aufs的一种堆叠文件系统,

https://blog.csdn.net/qq_15770331/article/details/96699386

域的实现

下面6个域所用镜像与剥离用到的技术（除拆包、打包、仓库管理、签名外）如下：

system系统域，主要system.img，用VNDK与其它域拆分，等效于GSI，注意system域的SELinux；

vendor芯片域，分vendor.img和boot.img，

vendor.img需要VNDK与其它域拆分，可利用芯片厂商的vendor仓隔离，注意vendor域的SELinux，

boot.img需要动态库、设备树与设备树叠加、boot镜像打包等技术，等效于GKI，注意boot的启动流程与boot域的SELinux；

device设备域，分dtbo.img、ko动态库、硬件固件、硬件相关配置文件

dtbo.img需要设备树与设备树叠加技术，注意android源码是支持多设备叠加层merge的（https://blog.csdn.net/dongyi1988/article/details/103995862 第2节）

ko动态库与硬件相关配置文件可以存储在odm.img，通过cmdline适配加载，注意这个跨域（域看你的理解与划分，odm域的固件、配置文件和硬件配置部分可划给device域）；

odm厂商域，主要odm.img，里面内容包括app、配置文件、固件等；

product产品域，主要product.img，里面内容包括app、配置文件等；

version版本域，主要version.img，里面二进制存放加密的设备信息，利用设备信息启动过程中进行版本的自适应，设备信息可以包括使用哪些硬件、选择什么logo、overlayfs堆叠选择等；

https://source.android.google.cn/docs/core/architecture/partitions?hl=zh_cn

满足差异性需求也可以用自适应。碰到过自适应到极致的方案，这个方案用一个OTA包升级所有产品。这个方案兼容代码量、OTA的冗余不敢想。

android官网系统分区布局，将系统的差异化定制为system_ext。

Modem、安全、稳定性等拆分解耦没涉及，实际拆起来还有不少问题要解决。

---

---

---

拆分解耦没有定式，例如域拆分有多细，差异怎么划域、哪些差异需求自适应、哪些差异内容拆分做版本等问题，均有不同答案。带着绝不做重复事情的懒惰思想去拆分解耦，就是最适合自己的方式。

拆分解耦虽然是google和芯片平台方案商都在干的，也是厂商为了产品的多样性、技术迭代成长必须要做的，但是只看得到眼前的只有几个产品的小厂商不认为有性价比。因为拆分解耦会多出拆分任务，并且需要架构的合理规划。

拆分虽然好，但是老板不听话啊。

这种拆分解耦思想也可以应用到非终端、非android的项目。

The end!