Google 致力于为黑人社区推动种族平等。查看具体举措

未来的 Android 版本

对于当前的 Android 版本,我们建议以设备中的内核模块的形式构建和推出所有板专属代码。对 Android 而言,内核的其余部分为一个整体(无论它是单片内核,还是其中的一部分是作为内核模块编译的)。

该单片内核是可以在 SoC 供应商的参考硬件上启动的 SoC 内核,但仅限于此。如今,对 SoC 内核的处理方式与通用内核类似;SoC 内核在板专属代码库中会有大量副本。这种分发模型使得系统会针对每个分支中的同一错误采取不同的方式修复 SoC 内核;这样一来,由于会在不同的时间择优挑选或修复同一错误的方式不同,未来的内核更新会有延迟。为了解决这一问题,必须单独提供 SoC 内核,以便使用 SoC 的每个人都可以为同一 SoC 内核做出贡献。

单片内核碎片

SoC 内核会随着时间的推移在各个 Android 版本以及 ODM 之间逐渐碎片化。

图 1. 设备内核副本

此示例说明了以下事实:

  1. 每个人都需要花费大量的时间和精力对板专属分支/标签进行交叉合并。
  2. 等待交叉合并的同时,Android 设备制造商会修补他们自己的内核以获取错误/安全漏洞修复程序。
  3. 与父级的偏离导致未来的升级/合并变得很困难。

通用 SoC 内核

针对通用 SoC 内核提议的模型可解决上行合并更改(如 SoC 专属错误修复程序、LTS 升级和安全漏洞修复程序)导致的问题。例如,按 SoC 和内核进行过统一的理想场景具有以下工作流程。

图 2. Android 8.x 及更高版本的设备内核

此工作流程旨在通过与设备制造商展开协作以采用最新的通用 SoC 内核,解决内核代码库碎片化的问题。Android 8.x 及更高版本为 ODM 提供了各种可能的选项,使 ODM 不需要维护自己的 SoC 内核,而是依赖通用 SoC 内核进行升级,例如获取 LTS 升级、错误修复程序和安全漏洞补丁程序。

我们初步的计划是推动所有 ODM/供应商都使用单一的 SoC 内核源。未来,我们计划朝着每个 SoC 分发单个内核二进制文件的方向发展。

上游内核变更

为了更轻松且更自动化地更新为较新的内核版本,并为 ODM 提供更安全可靠的平台来构建产品,我们强烈建议 SoC 供应商在上游更改其内核,并让 kernel.org 主代码库接受这些更改。一开始,这样做需要付出额外的努力和工程资源,但从长远来看,这可以节省时间和资金。与未经社区审核的代码相比,合并后的代码质量更高,错误和安全问题也更少(这些错误和安全问题的严重程度通常更低)。

如果将对 SoC 的全面支持合并到上游,社区便可以在内部的内核 API 随时间推移而不断发展的同时,做出必要的 API 更改,从而延长平台的使用寿命。通过将硬件平台添加到诸多由社区管理的内核测试平台中的一个(如 kernelci.org),还可以在开发版本和稳定版本中自动对内核进行回归测试。

如需获取与 Linux 内核社区协作以将您的代码上游化的相关帮助,请参阅以下资源:

  • Documentation/process(在 4.9 版及更低版本中为 Documentation/development-process
  • Documentation/CodingStyle
  • Documentation/SubmittingPatches

社区稍作审核就会接受独立的驱动程序和文件系统,并将其纳入内核的暂存区,然后在其中努力提高代码质量。