如果说 5.1 到 7.1 是一道小坎。那 7.1 到 9.0 就是一道大坑，有很多需要注意的问题，下面简单记录一下。
1. 编译
编译工具链需要使用 64 位的，NDK, JDK 需要使用 64 位的，前期的 buildroot 集成的那些工具，也要更新为新的 64 位的，不然会出现各种奇怪的编译问题。
还有就是新的编译框架 NINJA。
之前有提过，7.1 有启用过 jack，但是现在 9.0 上已经完全看不到 jack 了。
8.0 开始，Android 引入了 Android.bp 来代替之前的 Android.mk。而 Android.mk 也同时支持，但是相信以后的版本，mk将会慢慢消失（所以我们要开始学习 bp 文件的编写，bp 文件的编写，会更加简单和明了）。
我们需要大概知道，编译系统会通过 soong 将 Android.bp 转化成 ninja 文件；所有的 makefile（mk文件）也会转化成 ninja 文件，然后两个 ninja 文件合并成一个文件，最终的编译，就是依赖这个 ninja 文件。
至于编译系统ninja，简单来说，就是一个专注编译速度的编译系统，更多资料可以参考 https://ninja-build.org/
2. project treble 架构
project 架构简单来说，就是将 vendor 从 system 中抽离出来，使 Android 与 vendor 供应商的开发由之前的胶水一般的黏连，变成了卡扣式连接。
好处是会改善产品的 Android 层面的升级迭代的速度，因为 Android 升级不再需要 vendor 也必须升级跟进了。
对于 vendor 来说，不用苦于 Android 的每个版本的更新迭代必须更新而投入的大量人力成本了。
对于我们目前的项目来说，qcom 很多与硬件相关的代码都已经移到了 vendor，需要对这个架构熟悉。
另外 selinux 策略的配置，也要区分 system 与 vendor 两套。例如 public， private，vendor 分别代表公用，system 专用， vendor 专用，例如新增的一个 verifyserver，需要在 public 定义域，然后在 private 定义规则，至于 vendor，也会依赖 public 的域的定义。
3. A/B 系统
关于 A/B 系统，简单来说就是产品上有两个系统，一个启用，一个用于后台更新，而更新后的系统，会切换为前台系统。
A/B 系统是 Android 为了解决无缝升级，以及升级后变砖的问题。
两套系统，带来的是对于更大的存储空间的要求，还有就是技术上需要投入新的研究，所以目前市面上很多产品都没有启用这个功能。
以目前对 9.0 sdk 的了解，qcom 也没有启用 A/B 系统，所以我们有一个大概的了解即可。
4. 关于 rootfs
5.1 以及 7.1 的系统，rootfs 是存放于 bootimg 中的 ramdisk。
9.0 中 bootimg 以及 recovery 依然保留 ramdisk，但是与 5.1 的 ramdisk 相比，这个 ramdisk 不再是 Android system 分区启动后所以依赖的 rootfs，而是有点像 5.1 中 recovery 的 ramdisk，也就是说，9.0 中的 bootimg 中的 ramdisk 的功能比较简单。
而 9.0 中 system 依赖的 rootfs，是直接打包到 system.img 中的，这个 rootfs，才是传统 Android 概念中的 rootfs，所以我们 buildroot 的定制要根据这些进行适当的修改。
而 init 的启动，也分为两个阶段，这一点可以从 init 的源码很容易看出来。
5. Verified Boot 2.0
Verified Boot 是 5.1 已经存在的概念，而 Verified Boot 2.0， 则是 Android 8.0 后引入的概念。
这个也是 project treble 引入的产物。简单来说，5.1 的 Verified boot 将验签相关的信息存放在被验签的镜像中，而公钥等放在验签链条的上一个镜像中。而 9.0 中的验签信息放在一个专用 vbmeta.img 中，bootloader 以及 boot 只需要在 vbmeta.img 获取验签信息的描述，就可以对其他所有分区进行验签，而不是像 5.1 那样，需要对其他分区信息进行读取操作。
6. 9.0 sdk 新增的镜像
dtbo： device tree blob
mdtp：qcom 安全相关
vbmeta：Verified boot 验签
vendor： Vendor 代码