Iibchara-dev（讨论 | 贡献） |
Iibchara-dev（讨论 | 贡献） |
||
| 第64行： | 第64行： | ||
<tr> | <tr> | ||
<td>w</td> | <td>w</td> | ||
<td>x</td> | <td>.x</td> | ||
<td>y</td> | <td>.y</td> | ||
<td>zzz</td> | <td>-zzz</td> | ||
<td>k</td> | <td>-k</td> | ||
<td>something</td> | <td>-something</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td>5</td> | <td>5</td> | ||
<td>10</td> | <td>.10</td> | ||
<td>101</td> | <td>.101</td> | ||
<td>android12</td> | <td>-android12</td> | ||
<td>9</td> | <td>-9</td> | ||
<td>g30979850fc20</td> | <td>-g30979850fc20</td> | ||
</tr> | </tr> | ||
</table> | </table> | ||
2024年2月15日 (四) 22:55的版本
前言
随着Android系统的发展，碎片化问题对Android社区的生产影响越来越严重。
此前Android通过Project Treble等项目，将供应商驱动和系统解耦、将系统组件进行拆分，衍生出了system、system_ext、product、odm、vendor等分区，而gki内核项目就是Android在内核方面的解耦，使得内核的碎片化减少。
- 碎片化的危害：
- 安全更新需要耗费大量人力
- 很难合并长期支持的更新
- 妨碍 Android 平台进行版本升级
- 很难将内核更改贡献回上游 Linux
具体细节请参考：通用内核映像
GKI 1.0内核和GKI 2.0内核的区别
gki1.0内核与gki2.0最大的区别就是使 OEM 无需供应商参与即可提供内核安全修复和问题修复 (LTS)，简单来说就是1.0只能算OEM内核的gki，还是属于aosp内核的下游，例如MTK平台的gki，高通平台的gki，也就是dalao们常说的qgki（qcom-gki）,而2.0才能直接使用Google所维护aosp内核。
小知识：不少手机厂商随着gki2.0内核的发展，纷纷都开始直接使用Google编译好的gki2.0内核，如内核的 suffix 以g开头，那就是Google所编译的gki内核。 例：5.10.101-android12-9-g30979850fc20，g30979850fc20就是 suffix 部分
GKI内核与boot分区的改动
- 在
ro.board.first_api_level=29及小于29的boot镜像中，boot镜像包含通用的 ramdisk 和内核。
- 在
ro.board.first_api_level=30的boot镜像中，boot镜像包含通用的 ramdisk 和OEM GKI内核。
- 在
ro.board.first_api_level=31和ro.board.first_api_level=32的boot镜像中，boot 镜像包含通用的 ramdisk 和 Google GKI 内核。
- 对于发布时搭载
ro.board.first_api_level=33及大于33 的设备，通用 ramdisk 将从 boot 镜像中移除，并放置在单独的 init_boot 镜像中。此更改会使 boot 镜像仅保留 Google GKI 内核。因为 magisk 需要修补RamDisk，来获取root权限，因此在ro.board.first_api_level=33及大于33 的设备需要提取 init_boot 镜像进行修补。
如何查看 ro.board.first_api_level=？（下列方法二选一）
- 使用mt管理终端功能，输入
getprop ro.board.first_api_level
- 在开发者调试，开启手机USB调试，使用电脑终端，输入adb shell，授权adb调试权限，输入
getprop ro.board.first_api_level
GKI内核与vendor_boot分区的诞生
Android 11 引入了通用内核映像 (GKI) 的概念。为了能够使用 GKI 轻松启动任意设备，ro.board.first_api_level=30及30以上 设备可以使用启动映像头文件版本 3。在版本 3 中，所有供应商专用信息都已从 boot 分区分离出来并转移到新的 vendor_boot 分区中。
因此，我们需要修改cmdlime来设置Android设备的SELinux为宽容时，应该修改vendor_boot分区中的cmdlime参数，而不是boot或init_boot。
具体参考：供应商启动分区
小知识：4.19版本的Android内核是具有gki特性的，只不过没有加入KMI功能，只在Google pixel机型上支持，属于内测版本。
GKI内核与KMI接口
KMI 全称 Kernel Module Interface，相同 KMI 的内核版本是兼容的 这也是 GKI 中“通用”的含义所在；反之，如果 KMI 不同，那么这些内核之间无法互相兼容，刷入与你设备 KMI 不同的内核镜像可能会导致死机。
具体来说，对 GKI 的设备，其内核版本格式应该如下：
| KernelRelease := | |||||
|---|---|---|---|---|---|
| Version | PatchLevel | SubLevel | AndroidRelease | KmiGeneration | suffix |
| w | .x | .y | -zzz | -k | -something |
| 5 | .10 | .101 | -android12 | -9 | -g30979850fc20 |
其中，w.x-zzz-k 为 KMI 版本。例如，一个设备内核版本为5.10.101-android12-9-g30979850fc20，那么它的 KMI 为 5.10-android12-9；理论上刷入其他这个 KMI 的内核也能正常开机。
请注意：
- 内核版本中的 SubLevel 不属于 KMI 版本的一部分！
- 内核的 KMI 版本与 Android 版本并不一定相同！
- 新的 Android 设备上可能采取了防回滚机制，它不允许刷入一个安全补丁更旧的内核。比如，如果你的设备内核是 5.10.101-android12-9-g30979850fc20，它的安全补丁为 2023-11；即使你刷入与内核 KMI 一致的内核，如果安全补丁级别比 2023-11要老（例如2023-06），那么很可能会无法开机。因此，在保持 KMI 一致的情况下，优先采用安全补丁级别更新的内核！
GKI内核ABI监控
GKI和ABI的关系主要体现在通过ABI监控工具和符号列表来维护和管理KMI的稳定性，以确保内核的稳定和兼容性。
KMI并非包含内核中的所有符号，甚至并非包含完整的3万多个导出符号。相反，可供模块使用的符号都明确列在一组符号列表文件中，这些文件在内核树的根目录中公开维护。所有符号列表文件中所有符号的并集定义了一组作为稳定版维护的KMI符号。
为了减少需要作为稳定版维护的符号的数量和类型，GKI 内核具有将导出符号限制在模块所需符号范围内的功能。对于外部编译的模块，您需要有一个模块使用的符号列表，以便 GKI 内核可以导出这些符号。例如，模块用于小米机型的符号存储在内核源码的 android 目录下。
具体参考：Android 内核 ABI 监控