自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
通用内核映像 (GKI) 项目
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本页介绍了通用内核映像 (GKI) 项目以及它如何提高 Android 稳定性并增强安全性。
历史信息
每部搭载 Android 的设备都需要一个正式版内核。在 GKI 之前,内核是自定义的,基于 Android 通用内核 (ACK),并由系统芯片 (SoC) 供应商和 OEM 进行设备专属更改。
这种自定义可能会导致内核代码中有多达 50% 是树外代码,而非来自上游 Linux 内核或 ACK。因此,GKI 之前的内核的自定义性质导致了严重的内核碎片化。
碎片化的代价
内核碎片化会对 Android 社区产生若干负面影响。
安全更新需要耗费大量人力
Android 安全公告 (ASB) 中引用的安全补丁必须向后移植到每个设备内核中。但是,由于存在内核碎片化问题,向正常使用的 Android 设备传播安全修复的代价非常之高。
很难合并长期支持更新
长期支持 (LTS) 版本包含安全修复和其他重大 bug 修复。事实证明,使用最新的 LTS 版本是提供安全修复的最有效方式。我们发现,ASB 报告的内核安全问题中有 90% 都已在保持最新状态的 Pixel 设备上得到修复。
不过,由于设备内核中所有的自定义修改,很难仅将 LTS 修复合并到设备内核中。
碎片化导致很难向已被实际使用的设备添加需要更改内核的 Android 新功能。Android 框架代码必须考虑不同的内核变体,并且无法依赖在内核中实现的新 Android 功能,这减缓了创新速度并导致了代码大小和复杂性增加。
很难将内核更改贡献回上游 Linux
由于将补丁提取到生产内核中的碎片化方式,从 LTS 版本在上游可用到在设备中可用之间产生了长达 18 个月的延迟。由于上游内核发布与产品发布之间的这种长时间延迟,又导致 Android 社区很难将所需的功能和驱动程序馈送到上游内核中。当用户提交改进建议时,代码库已发生更改,因此很难显示补丁的相关性。
解决碎片化问题:通用内核映像
通用内核映像 (GKI) 项目通过统一核心内核并将 SoC 和板级支持从核心内核移至可加载的供应商模块中,解决了内核碎片化问题。GKI 还为供应商模块提供稳定的内核模块接口 (KMI),因此模块和内核可以独立进行更新。GKI 内核的一些特性包括:
- GKI 内核基于 ACK 源代码构建而成。
- GKI 内核是每个架构和每个 LTS 版本的单内核二进制文件以及关联的可加载模块。
- GKI 内核已经过关联 ACK 支持的所有 Android 平台版本的测试。在 GKI 内核版本的生命周期内不会发生功能废弃。
- GKI 内核为给定 LTS 中的驱动程序提供了稳定版 KMI。
- GKI 内核不包含 SoC 专用代码或板级代码。
如需查看 GKI 架构的映像,请参阅内核概览。
通用映像
从 Android 12 开始,发布时搭载内核版本 5.10 或更高版本的设备必须附带 GKI 内核。通用内核映像 (GKI) 发布 build 会定期更新,且会随着 LTS 和重大 bug 修复定期更新。由于 KMI 的二进制文件稳定性保持不变,因此您无需更改供应商映像即可安装这些启动映像。GKI 项目的目标如下:
- 在使用 GKI 内核替换产品内核时,不会引入明显的性能或能效降低问题。
- 使合作伙伴无需供应商参与即可提供内核安全修复和 bug 修复。
- 降低设备主要内核版本的升级成本。
- 通过按照清晰的升级过程更新内核版本,只为每个架构维护一个 GKI 内核二进制文件。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-06。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-03-06。"],[],[],null,["# Generic Kernel Image (GKI) project\n\nThis page describes the Generic Kernel Image (GKI) project\nand how it increases Android stability and improves security.\n\nHistory\n-------\n\nEvery Android-powered device needs a production kernel. Prior to GKI, kernels\nwere custom and based on the Android Common Kernel (ACK), with device-specific\nchanges made by system on chip (SoC) vendors and OEMs.\n\nThis customization could result in as much as 50% of kernel\ncode being out-of-tree code and not from upstream Linux kernels or ACKs.\nAs such, the custom nature of pre-GKI kernels resulted in\nsignificant kernel fragmentation.\n\nCosts of fragmentation\n----------------------\n\nKernel fragmentation has several negative effects on the Android community.\n\n### Security updates are labor intensive\n\nSecurity patches cited in the\n[Android Security Bulletin (ASB)](/docs/security/bulletin)\nmust be backported into each of the device kernels. However, due to kernel\nfragmentation, it's prohibitively expensive to propagate security fixes to\nAndroid devices in the field.\n\n### Difficult to merge Long-Term Supported updates\n\nThe *Long-Term Supported (LTS)* releases include security fixes and\nother critical bug fixes. Staying up to date with LTS releases has proven\nto be the\nmost effective way to provide security fixes. On Pixel devices, it was\ndiscovered that 90% of the kernel security issues reported in the ASB had\nalready been fixed for devices that stay up to date.\n\nHowever, with all of the custom modifications in the device kernels, it's\ndifficult to just merge the LTS fixes into device kernels.\n\n### Inhibit Android platform release upgrades\n\nFragmentation makes it difficult for new Android features requiring\nkernel changes to be added to devices in the field. Android Framework\ncode had to account for the different kernel variations and couldn't\nrely on new Android features being implemented in the kernel\nThis slowed down innovation and caused increased code size and\ncomplexity.\n\n### Difficult to contribute kernel changes back to upstream Linux\n\nThe fragmented way of pulling patches into the production kernels caused a\ndelay of up to 18 months from the point where an LTS release was available\nupstream, to when it was in a device.\nThis long delay between upstream kernel release and products makes it difficult\nfor the Android community to feed needed features and drivers into the\nupstream kernels. By the time a user submitted suggestions for improvements, the\ncodebase had changed, making it hard to show the relevance\nof the patch.\n\nFix the fragmentation: Generic Kernel Image\n-------------------------------------------\n\nThe **Generic Kernel Image (GKI) project** addresses kernel fragmentation by\nunifying the core kernel and moving SoC and board support out of the core kernel\ninto loadable vendor modules. GKI also presents a stable Kernel Module\nInterface (KMI) for vendor modules, so modules and kernel can be updated\nindependently. Some characteristics of the GKI kernel are:\n\n- The GKI kernel is built from the ACK sources.\n- The GKI kernel is a single-kernel binary plus associated loadable modules per architecture, per LTS release.\n- The GKI kernel is tested with all Android Platform releases that are supported for the associated ACK. There's no feature deprecation for the lifetime of a GKI kernel version.\n- The GKI kernel exposes a stable KMI to drivers within a given LTS.\n- The GKI kernel doesn't contain SoC-specific or board-specific code.\n\nFor an image of GKI architecture, refer to the\n[Kernel overview](/docs/core/architecture/kernel).\n\n### Common Image\n\nBeginning with Android 12, devices shipping with kernel version 5.10 or higher\nmust ship with the GKI kernel. [Generic Kernel Image (GKI) release\nbuilds](/docs/core/architecture/kernel/gki-release-builds) are updated regularly\nand updated regularly with LTS and critical bug fixes.\nBecause binary stability is maintained for the KMI, you can install these boot\nimages without making changes to vendor images. The GKI project has these goals:\n\n- Don't introduce significant performance or power regressions when replacing the product kernel with the GKI kernel.\n- Enable partners to deliver kernel security fixes and bug fixes without vendor involvement.\n- Reduce the cost of upreving the major kernel version for devices.\n- Maintain a single GKI kernel binary per architecture by updating kernel versions with a clear process for upgrading."]]