android ROM ---(1)高通平台 Android O 升级学习

1. Android Project Treble

 与iOS相比，安卓系统有一个致命弱点，那就是新版本系统升级太慢，除了谷歌Nexus和Pixel等亲儿子机型，其他OEM商的机型更新新系统需要用户漫长的等待，这也造成了安卓平台的碎片化问题。谷歌一直在努力解决这一问题，但却一直见不到成效。在2017年Google I/O大会前，搜索巨人又出手了，它们推出了Project Treble，试图从Android O开始让系统升级变的更简单、更迅速，同时为OEM商节省更多资金。

Project Treble的点子来源于安卓兼容性测试（CTS），在CTS的框架下，开发者无需针对特定机型进行调整就能写出安卓设备通用的应用。

在Project Treble的全新模块化体系下，谷歌直接将由芯片制造商用于控制底层程序的“Vendor Implementation（VI）”接口和整体的安卓框架分离。

这样一来，新的供应商接口就可以通过供应商测试套件进行验证了，该套件与前面提到的CTS类似，可以确保VI接口的前向兼容性。而在Project Treble之前，每次有新系统，厂商就必须升级大量安卓代码，现在OEM商则可以直接跳过芯片供应商这一关了。

在新的框架下，OEM商可以选择直接将新版系统推送给用户，整个过程只是升级安卓架构那么简单。

2.  Android N和Android O image 组成

 

      1）模块化，谷歌、SoC供应商、OEM 各自的负责的内容分开。

      2）供应商模块被移动到独立的映像中，从而加快软件升级及发布的过程。

      3） 供应商和OEM模块从系统映像中分离出来，HAL 层进行了重构，kerenl 4.9 后kernel 模块化（SDM485 支持新的kernel）

 3 支持Android O 的平台 

4 Android O兼容性 变化

5. OTA 编译方式推荐

打上禁用系统/供应商 image 分开的补丁

6 Image 分离

在Project Terble 中，原 系统Image 分成 系统Image 和 Vendor Iamge.

配置好编译的 Android makefiles 变量，确保Vendor编译成独立的Image：

模块属性变量 

LOCAL_MODULE_OWNER:= <vendor name> 

LOCAL_PROPRIETARY_MODULE := true 

LOCAL_MODULE_PATH:= $(TARGET_OUT_VENDOR) # for /vendor/<file> 

LOCAL_MODULE_PATH:= $(TARGET_OUT_VENDOR_APPS) 

LOCAL_MODULE_PATH:= $(TARGET_OUT_VENDOR_ETC) 

LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR_EXECUTABLES)  

LOCAL_MODULE_PATH_32 := $(TARGET_OUT_VENDOR)/lib 

LOCAL_MODULE_PATH_64:= $(TARGET_OUT_VENDOR)/lib64 

所有供应商二进制文件必须写到 /data/vendor 下（非/vendor下）

包括 vendor HALs, proprietary daemons 和command

Vendor Image 执行时不允许直接调用System image 的函数。

 7 HAL 重构

 O 以前HAL接口声明在C和C++头文件定义。在O中，这些声明在HAL中用HIDL重写。

8 Binderized vs. Non-Binderized HIDL HAL