Android内核似乎要向主线内核靠拢

2018.11.15

 

Android设备都基于linux内核，但是这些设备从一开始并没有跑主线内核，因为添加了很多不在主线上的代码，这些主线外代码的内核代码的问题，正在想办法处理；虽然说现在就在这些Android设备上运行主线内核代码并不容易，但是比我们预想的可能更接近。

 

Android内核从主线LTS内核而来，添加了Android指定代码来得到Android Common Kernel发行版；厂商用这个发行版，并添加一堆主线外的内核代码来制造出运行在指定SoC上的内核。一般合并一个LTS内核到Android Common Kernel可能只需要几个星期，但是之后作为内核在设备上出现还需要几年，这也是为什么Android设备的内核都很古老的原因。

 

这一内核更新套路还带来其他的问题，Android核需要能够运行在一系列古老内核中，这一约束使Android很难用上新的内核特性，内核升级很缓慢，甚至是不会升级。用了大量非主线代码，上百万行，使它很难合并新的稳定更新。Android内核没有连续迭代开发，也不能在主线内核上跑安卓，Android内核这种管理和开发方式使很多使用linux的优势不复存在，所以需要处理这个问题。

 

关于旧内核：AndroidO需要使用3.18/4.4/4.9内核中的一种，这是一大提升，以前根本没有要求使用什么版本内核；AndroidP进一步缩小了这一要求：必须使用4.4.107/4.9.84/4.14.42或其后的稳定版。Android开发者正在试图强制接纳稳定更新。现在状况有变化，但是基础内核的迭代仍然需要两年，Android核仍然需要支持内核直到3.18。两年以来稳定更新仅出现一次回退，就是4.4.108打破了一些东西，这也是为什么现在要求内核要求到4.4.107之后的原因；除此之外，稳定更新非常可靠。

 

现在持续集成的测试一直在提升，LKFT测试一直在为LTS -rc和Android Common Kernel运行功能测试。更多的测试也在KernelCI进行，Android开发者也在为Linux Test Project贡献代码，内核补丁在能够同时运行Android和主线内核的Cuttlefish通过预提交测试，SoC厂商也会做更多测试。现在没有啥厂商提出LTS出现问题，厂商只看到了合并他们非主线代码产生的冲突，不过明显在意料之中。

 

不过现在对于厂商来说，升级内核依旧是个大麻烦，厂商害怕给部署了的设备提供大量修改，所以设备一般卖出以后就不会升级内核，不过很明显比之前好一点。谷歌计划继续推动厂商在设备启动后继续提供新LTS版的更新，在某些时候，LTS发行版将包含在Android安全公告中，获得bug修复的价值是很大的。Patil重复了Greg Korah-Hartman的态度，没有安全相关的bug，bug就是bug，必须全部修复。

 

由于非主线代码导致主线内核不能在设备上运行的情况依旧，不过在Android Common Kernel中这部分代码正在逐渐减少，逐步提到主线不就好了～现在只有30个补丁，大概6500行代码在Android Common Kernel，用于boot Android的，最终计划是将这个数字变为0，但是还有一些问题需要处理如：binder的优先级继承，EAS调度进内核主线，SDCardFS文件系统桥。

 

Treble项目提出一个新的厂商接口API，实现了一系列的硬件抽象层，以及普适镜像GSI(AOSP编出来即可在所有设备运行的system.img)，GSI能跑的设备就是正确实现了接口的设备。现在，内核正考虑作为厂商接口的一部分，厂商必须提供内核作为底层实现，计划是Android提供一个基于主线的一般内核镜像，然后设备需要能运行这个内核，当然，厂商将会提供一系列的内核模块来提供必要的硬件支持，内核符号的命名空间也需要上浮。这一设计当然不能消除非主线代码，因为这些内核模块的代码几乎都不是来自主线，但是通过这些内核模块厂商自定的代码将会降到内核模块级别，所以就不需要修改内核。厂商使用自己的CPU调度器的日子将结束，因为所有非主线代码都将与一般内核协作，也就是只能用内核模块能调到的接口。

 

最后，Patil说，Android内核团队正在积极的试着在向主线提过代码后才使用，重新努力主动报告漏洞和其他问题，并与主线协力解决这些问题，除了这些，还有其他的一些目标如让ashmem和ion模块离开staging树，提升Android对设备树的使用。总有一天这些Android问题将会被解决。

 

文末总结：

 

谷歌似乎想把Android这个名称与硬件相关剥离开，从此Android剥开成为三部分，一部分是运行在用户态的统一不变层；而第二部分内核还是linux内核，把非主线代码能提的提，不能提的扔；第三部分是厂商自主的部分，厂商自主的内核模块的编程接口是内核的导出符号，而厂商自主的用户态驱动则是HAL层下的实现；非常和谐，厂商就是负责鸡零狗碎的厂商，而谷歌是掌控开发者的谷歌，linux还是那个毫不妥协的linux。似乎谷歌向linux妥协了，然后顺手压榨了一把厂商？

 

关于cuttlefish，是一个基于crosvm的emulator；而crosvm是与qemu同一层次的东西；emulator是啥我就不说了。