Google 工程师提议：让 Android 内核回归 Linux 主线

Android 设备是基于 Linux 内核的，但从一开始，这些设备就没有运行主线内核。这期间，那些设备上的树外代码量一直被视为一个问题，为减少这样的代码已经投入了大量的资源。

在 2018 年Linux Plumbers大会上，谷歌工程师 Sandeep Patil 谈了这个问题以及如何解决这个问题。在 Android 设备上运行主线内核的梦想还没有实现，但它可能比很多人认为的来得要快。

他表示，Android 内核起初是一个来自主线的长期稳定（LTS）版本；这些版本结合 Android 核心的专有代码构成了Android公共内核版本。供应商选择一个公共内核，然后添加更多的树外代码，从而创建一个特定于片上系统（SoC ）的内核，并提供给设备制造商。最终，这些 SoC 内核中的其中一个被冻结，可能加入了另外一些树外代码，作为一个特定设备模型的内核。现在，只需要几周就可以把一个 LTS 版本合并到 Android 公共内核中，但它仍然需要几年才能成为设备内核。这就是为什么 Android 设备总是运行古老的内核。

这一过程存在很多问题。Android Core 必须准备好在一系列旧的内核上运行，这个限制使它很难使用新内核的特性。内核更新缓慢，或者更常见的是根本不更新。大量树外代码（如数百万行）的使用使得要合并新的稳定更新变得很难，即使可以这样做，把结果提供给用户也会让供应商感到害怕，因而这种做法并不常见。Android 内核没有持续集成过程，不可能把 Android 系统运行在主线内核上。总之，Android 内核的开发和管理方式从一开始就消除了使用 Linux 带来的许多优势，但是，解决其中许多问题的工作正在进行之中。

至于旧内核：Oreo 版本需要使用 3.18、4.4 或 4.9 版本的内核——与以前的版本相比，这是一个进步，之前根本没有内核版本的要求。Pie 版本进一步缩小了范围，要求设备必须提供 4.4.107、4.9.84 或 4.14.42（或更高的稳定版本）。Android 开发人员正试图“更上一层楼”，强制并入稳定更新。这改善了现状，但基本内核仍然是两年（甚至更久）之前的，Android Core 仍然需要在 3.18 版本的内核上工作。

Patil 指出，一些人担心稳定更新会导致退化，但是，这两年里，并入那些稳定更新仅使 Android 项目遇到一次退化。特别是 4.4.108 造成了破坏，这就是为什么现在不需要 4.4.107 之后的东西。否则，他说，对于 Android 系统，稳定更新已被证明是高度可靠的。

其中一个原因可能是持续集成测试的情况正在改善；例如，LKFT现在正在 LTS、‑rc 和 Android 公共内核上运行功能测试。有更多的测试正通过KernelCI进行，Android 开发人员也在为Linux测试项目做出贡献。内核补丁在一个名为Cuttlefish的模拟设备上进行预提交测试，它既可以运行 Android，也可以运行主线内核。SoC 供应商正在进行更多的测试，到目前为止，还没有人报告 LTS 内核更新的问题。他们确实遇到了树外代码合并冲突，但这并不奇怪。

即便如此，对 Android 厂商来说，内核升级仍然是一个大问题，他们担心向已部署的设备发送大量的更改。因此，设备通常不会在交付后升级内核——这很糟糕，但这比之前要好，那会，SoC 发布后，其内核无法升级。不过，谷歌计划继续推动供应商发布更新，最终甚至在设备发布后也会强制更新到较新的 LTS 版本。在某些时候，LTS 版本会包含在 Android 安全公告中，因为获得所有 Bug 修复是很有价值的。Patil 呼应了 Greg Kroah-Hartman 的说法，即不存在此类“安全漏洞”；“只是有一些 Bug”应该被修复。

设备无法运行主线内核的问题仍然存在；当然，问题是所有那些树外代码。尽管如此，Android 公共内核中的代码数量已经大大减少了，这主要是为了在上游进行更改。现在，Android 公共内核中只有大约 30 个补丁，需要增加大约 6500 行代码才能启动 Android。最终的计划是将其变为零，但是仍然有许多问题需要处理，包括解决绑定器中的优先级继承问题、将能耗感知调度引入主线以及将 SDCardFS 文件系统桥接移到上游。

他说，Treble项目推出了一个新的“供应商接口”API，它实现了一种硬件抽象层。和这个接口同时提出的还有通用系统映像（GSI）的概念，它是 Android 开源项目的一个构建，可以在任何 Android 设备上启动。如果 GSI 可以在特定设备上引导，那么制造商就正确地实现了供应商接口。

目前，内核被认为是供应商接口的一部分——供应商必须将其作为底层实现的一部分提供。不过，Android 的计划是提供一个基于主线的通用内核映像。设备将按预期运行这个内核；为了实现这一点，供应商将提供一组内核模块来添加必要的硬件支持。要做到这一点，除了其他方面外，还需要把内核符号名称空间移到上游。

这种设计显然不会消除树外代码问题，因为在许多或大多数情况下，这些模块不是来自主线。但是，这里仍然有一个重要的变化：特定于供应商的代码将被降级为可加载模块，因此就不会更改核心内核。例如，供应商提供自己的 CPU 调度程序的日子应该结束了；所有树外代码都必须借助常规模块来使用通用内核映像。这将迫使代码做好进入上游的准备，这是朝着正确方向迈出的一步。

最后，Patil 说，Android 内核团队现在正积极地尝试在发布前把代码移到上游。他们恢复了主动报告漏洞和其他问题的工作，并与上游合作解决这些问题。除此之外，该项目还有许多目标，包括从 staging 树中去除 ashmem 和 ion 模块、改进 Android 对设备树的使用等等。工作进展顺利；总有一天，“安卓问题”可能会离我们远去。

查看英文原文：https://lwn.net/SubscriberLink/771974/ade4e5fb18058302/