Android 系统面试问题

一.android gki和非gki的区别

Android GKI（Generic Kernel Image）和非GKI内核的主要区别在于内核设计和模块化程度，具体如下：

1. 内核设计

GKI：采用通用内核设计，与设备硬件分离，核心功能统一，厂商通过模块添加设备特定功能。

非GKI：设备厂商深度定制内核，通常与硬件紧密集成，导致碎片化严重。

2. 模块化

GKI：内核模块化，核心功能与设备驱动分离，厂商通过加载模块支持特定硬件。

非GKI：内核和驱动紧密耦合，模块化程度低，修改和更新复杂。

3. 更新和维护

GKI：简化内核更新，Google可直接更新通用内核，厂商只需更新模块。

非GKI：更新依赖厂商，通常滞后，且需要大量适配工作。

4. 兼容性

GKI：提升不同设备间的兼容性，通用内核减少碎片化。

非GKI：兼容性差，不同设备的内核差异大。

5. 开发与调试

GKI：开发者使用统一内核，调试更简便。

非GKI：不同设备需要不同内核，开发和调试复杂。

6. 安全性

GKI：安全更新更易实施，Google可直接推送补丁。

非GKI：安全更新依赖厂商，通常延迟。

总结：

GKI：模块化、易更新、兼容性好，简化开发和维护。

非GKI：定制化强，但更新慢、兼容性差，开发和维护复杂。

GKI是Android内核的未来方向，旨在解决碎片化问题，提升系统稳定性和安全性。

二.android中的A/B分区升级

Android 中的 A/B 分区升级（也称为无缝更新，Seamless Updates）是一种系统更新机制，旨在提高更新的可靠性和用户体验。它通过使用两个系统分区（A 和 B）来实现无缝更新，用户可以在设备正常使用的同时完成系统更新。

A/B 分区升级的工作原理

双系统分区：

设备上有两个相同的系统分区：A 分区和 B 分区。

一个分区用于当前运行的系统，另一个分区用于更新。

更新过程：

当系统更新时，更新包会被下载并安装到非活动的分区（例如，如果当前系统运行在 A 分区，则更新会安装到 B 分区）。

更新完成后，设备会在下次重启时切换到更新后的分区。

无缝切换：

用户可以在更新过程中继续使用设备，无需等待更新完成。

重启后，设备会自动切换到更新后的分区，用户几乎感知不到更新过程。

回滚机制：

如果更新后的系统出现问题，设备可以自动回滚到之前的分区，确保系统可用性。

A/B 分区升级的优点

无缝体验：

用户无需长时间等待更新完成，可以继续使用设备。

更新过程对用户透明，几乎没有中断。

更高的可靠性：

如果更新失败或新系统出现问题，设备可以回滚到旧分区，避免变砖。

更新过程中断电或意外中断不会导致设备无法启动。

减少停机时间：

传统的单分区更新需要设备进入恢复模式并花费较长时间，而 A/B 分区更新几乎不需要停机。

简化 OTA 更新：

设备厂商和运营商可以更轻松地推送 OTA 更新，用户也更愿意接受更新。

A/B 分区升级的缺点

存储空间占用：

需要额外的存储空间来维护两个系统分区，可能会减少用户可用空间。

复杂性增加：

实现 A/B 分区升级需要更复杂的系统设计和测试。

设备厂商需要调整分区布局和更新流程。

兼容性问题：

并非所有设备都支持 A/B 分区升级，尤其是低端设备或旧设备。

A/B 分区升级的实现

分区布局：

设备的分区表中需要定义两个系统分区（system_a 和 system_b）、两个引导分区（boot_a 和 boot_b）等。

更新流程：

更新包会被下载并验证，然后安装到非活动分区。

更新完成后，引导加载程序（Bootloader）会更新分区标记，指向新的活动分区。

用户界面：

用户可以在设置中查看更新进度，但无需手动干预。

A/B 分区升级与传统更新的对比：

总结：

A/B 分区升级是 Android 系统更新机制的重要改进，它通过双分区设计实现了无缝更新，提升了用

户体验和系统可靠性。尽管它需要更多的存储空间和更高的实现复杂度，但其优势使其成为现代

Android 设备的标配功能。

三.uboot如何向内核传参

uboot给内核传参的方式——tag

1.tag是什么？

tag 是一个数据结构：stract tag  这种数据格式在uboot和kernel是一样的，也就是说uboot在启动的时候将需要传给kernel的参数放在了DDR的某个地址处，而存放格式就是tag格式，然后kernel就会到这个地址去读取这些参数，读取方式也是按tag格式去读取的。

简单来说tag就像是一个数组一样，是一块连续的内存，里面存放了uboot需要传递给kernel的参数信息，我们通过定义一个指针params(static struct tag *params;)，先使其指向tag的存放地址(30000100，uboot也就是说在30000100的地方存放了一条信息，告诉kernel去0x54410001这个地方去读取tag(也就是uboot传递给kernel的参数))。

(1)struct tag，tag是一个数据结构，在uboot和linux kernel中都有定义tag数据机构，而且定义是一样的。

(2)tag_header和tag_xxx。tag_header中有这个tag的size和类型编码，kernel拿到一个tag后先分析tag_header得到tag的类型和大小，然后将tag中剩余部分当作一个tag_xxx来处理。

(3)tag_start与tag_end。kernel接收到的传参是若干个tag构成的，这些tag由ATAG_CORE类型的tag起始，到ATAG_NONE类型的tag结束。

(4)tag传参的方式是由linux kernel发明的，kernel定义了这种向我传参的方式，uboot只是实现了这种传参方式从而可以支持给kernel传参。

2.内核如何接收tag参数

启动内核的代码：theKernel (0, machid, bd->bi_boot_params);其中bd->bi_boot_params就是所有tag结构体所在的首地址，这个地址是保存在全局变量gd->bd中的，在uboot启动的前期会指定内存地址用于存放tag结构体，然后在启动内核的时候传给内核，内核拿到地址就会从该地址去遍历tag结构体，内核会判断tag的类型，如果是ATAG_CORE类型的tag则是起始的tag，如果是ATAG_NONE则是最后一个tag结构体，不用再往后遍历。

3.tag结构体

struct tag_header {
		u32 size;	//结构体的大小
		u32 tag;	//结构体的类型
	};

struct tag {
       struct tag_header hdr;
		union { 	//此枚举体包含了uboot传给内核参数的所有类型
				struct tag_core         core;
				struct tag_mem32        mem;
				struct tag_videotext    videotext;
				struct tag_ramdisk      ramdisk;
				struct tag_initrd       initrd;
				struct tag_serialnr     serialnr;
				struct tag_revision     revision;
				struct tag_videolfb     videolfb;
				struct tag_cmdline      cmdline;
				
				/*
				* Acorn specific
				*/
				struct tag_acorn        acorn;
				
				/*
				 * DC21285 specific
				 */
				struct tag_memclk       memclk;
				
				struct tag_mtdpart      mtdpart_info;
		} u;
};