Android Boot Sequence

本文详细介绍了Android操作系统的启动过程,从按下电源按钮开始到完成启动的全过程。包括BootROM、Bootloader、Linux内核、init进程、Zygote以及系统服务的启动等内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

In this post we will discuss about the boot process of Android operating system. As the Android is based on Linux Kernel , so its boot process will give good idea about Linux boot process also. Most android based systems run on ARM processors.

First of all we will see the meaning of various terms that is used in the android boot sequence.


  • BootROM- It is a hardwired code resided in CPU ASICS.
  • Bootloader- It is a small program which runs before the Android OS starts running.
  • Init process- It is the first process launched by Linux Kernel when it is finished with the setup.

Let's see what happens when a user presses power ON button--


Complete path the boot process takes when we press the power button on our android phones.


Step 1-System start-- Boot ROM code start execution from pre defined location. It load Bootloader into RAM and start execution.

  • A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the ASIC. This is to determine where to find the first stage of the boot loader.
  • B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.
[Android_boot_1.png]



Step 2 : Bootloader--

  • Bootloader perform execution in two stages, first stage It to detect external RAM and load program which helps in second stage, In second stage bootloader setup network, memory, etc. which requires to run kernel, bootloader is able to provide configuration parameters or inputs to the kernel for specific purpose.  
  • Android bootloader can be found at 
<Android Source>\bootable\bootloader\legacy\usbloader
  • Legacy loader contain two important files viz. init.S and main.c 1. init.s - Initializes stacks, zeros the BSS segments, call _main() in main.c
    2. main.c - Initializes hardware (clocks, board, keypad, console), creates Linux tags.
  • In embedded Linux uBoot is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders.

[Android_boot_2.png]

  • A. The first boot loader stage will detect and set up external RAM.
  • B. Once external RAM is available and the system is ready the to run something more significant the first stage will load the main boot loader and place it in external RAM.
  • C. The second stage of the boot loader is the first major program that will run. This may contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.
  • D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.
  • E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.


3. The Linux kernel

The Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.

[Android_boot_3.png]


  • A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.
  • B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.

4. The init process



[Android_boot_4.png]
init it very first process, we can say it is root process or grandmother of all processes. init process has two responsibilities 1. mount directories like /sys, /dev, /proc and 2. run init.rc script.


init process can be found at init : <android source>/system/core/init init.rc file can be found in source tree at <android source>/system/core/rootdir/init.rc  This is a script that describes the system services, file system and other parameters that need to be set up. The init.rc script is placed in system/core/rootdir in the Android open source project.
5. Zygote and Dalvik -


[Android_boot_5.png]

  • In a Java, We know that separate Virtual Machine(VMs) instance will popup in memory for separate per app, In case of Android app should launch as quick as possible, If Android os launch different instance of Dalvik VM for every app then it consume lots of memory and time. so, to overcome this problem Android OS as system named “Zygote”. 
  • Zygote enable shared code across Dalvik VM, lower memory footprint and minimal startup time. 
  • Zygote is a VM process that starts at system boot time as we know in previous step.
  • Zygote preloads and initialize core library classes.  
  • Normally there core classes are read-only and part of Android SDK or Core frameworks. In Java VM each instance has it’s own copy of core library class files and heap objects.
  • In short, The Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.


6. The system server-

[Android_boot_6.png]


  • The system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth.
  •  Start up of each service is currently written directly into the run method of the system server. 
  • The system server source can be found in the file frameworks/base/services/java/com/android/server/SystemServer.java in the open source project

Core Services:
1.     Starting Power Manager
2.     Creating Activity Manager
3.     Starting Telephony Registry
4.     Starting Package Manager
5.     Set Activity Manager Service as System Process
6.     Starting Context Manager
7.     Starting System Context Providers
8.     Starting Battery Service
9.     Starting Alarm Manager
10.   Starting Sensor Service
11.   Starting Window Manager
12.   Starting Bluetooth Service
13.   Starting Mount Service

Other services
1.    Starting Status Bar Service
2.     Starting Hardware Service
3.     Starting NetStat Service
4.     Starting Connectivity Service
5.     Starting Notification Manager
6.     Starting DeviceStorageMonitor Service
7.     Starting Location Manager
8.     Starting Search Service
9.     Starting Clipboard Service
10.   Starting Checkin Service
11.   Starting Wallpaper Service
12.   Starting Audio Service
13.   Starting HeadsetObserver
14.   Starting AdbSettingsObserver
 



7. Boot completed


Once System Services up and running in memory, Android has completed booting process, At this time “ACTION_BOOT_COMPLETED” standard broadcast action will fire.
<think>嗯,用户这次的问题很专业,是关于Android 7.1系统在关机充电状态下更新U-Boot的可行性。从提供的引用来看,用户应该是在进行嵌入式开发或系统移植工作,特别是RK3399和msm8909平台的修改经验。 用户引用的三段代码很有价值:引用[1]展示了U-Boot中BQ3060电量计驱动的修改,引用[2]是msm8909平台开机流程的aboot.c修改,引用[3]涉及关机充电的LED状态机。这些恰好构成解决关机充电时更新U-Boot的关键要素。 需要特别注意技术难点在于:关机充电时系统处于充电固件(charger mode)而非完整U-Boot环境。引用[2]中aboot.c的修改表明,高通平台通过target_pause_for_battery_charge()实现充电流程挂载,这正是突破口。 解决方案应该分三层考虑:首先是硬件上确保BootROM支持USB下载模式(如Rockchip的MaskROM模式),其次是软件上修改charger固件识别升级指令,最后是创建特殊的升级镜像格式。引用[1]中bq3060驱动添加的isexistbat标志位启示我们可以通过电池状态检测触发特殊模式。 用户可能还隐含了“不拆机更新”的需求,所以重点设计USB通信方案。考虑到Android 7.1的旧内核版本,建议采用USB Gadget框架实现CDC ACM虚拟串口,这样比开发MSC协议更稳妥。 测试环节要特别提醒风险,因为错误的U-Boot刷写会导致设备变砖。准备在回复中强调必须保留恢复分区,并给出具体的hexdump验证命令。用户既然能修改U-Boot源码,应该具备基本开发能力,但安全提示绝不能少。 最后生成的扩展问题要聚焦在嵌入式开发方向:fastboot协议扩展和BootROM机制是自然延伸,充电状态机优化则呼应引用[3]的LED控制问题。这些都能帮助用户深化系统移植工作。</think>在 Android 7.1 设备上实现**关机充电时更新 U-Boot**是可行的,但需深度修改系统底层代码,涉及**Bootloader 流程重构**和**充电固件增强**。以下是具体方案: --- ### **技术可行性分析** 1. **硬件基础** - 设备需支持 **USB OTG 或 UART 烧写模式**(如 Rockchip 的 MaskROM 模式[^1]) - 关机充电时 SoC 仍维持 **BootROM 运行**(如高通 PBL 或 Rockchip Miniloader) 2. **系统限制突破** - 默认充电流程仅调用 `charger` 服务(显示动画/电量)[^3] - **需劫持充电流程**,注入 U-Boot 更新逻辑 --- ### **实现步骤(以 Rockchip RK3399 + Android 7.1 为例)** #### **步骤 1:修改充电流程入口** 在 `aboot.c` 中重定向充电检测逻辑,使其可跳转到更新模式: ```c // android/bootable/bootloader/lk/app/aboot/aboot.c if (device.charger_screen_enabled && target_pause_for_battery_charge()) { // 原始充电流程 } else if (check_update_key() || usb_update_request()) { // 新增条件 launch_uboot_update(); // 跳转到U-Boot更新流程 } ``` *引用自高通平台修改逻辑[^2]* #### **步骤 2:扩展 U-Boot 的充电模式** 在 U-Boot 驱动层添加**升级指令监听**: ```c // u-boot/drivers/power/fuel_gauge/fg_bq3060.c void battery_check_update(void) { if (battery->isexistbat && usb_phy_connected()) { // 检测USB连接 if (usb_detect_update_cmd()) { // 监听特定升级指令 enter_flash_mode(); // 进入刷写模式 } } } ``` *参考电池检测逻辑[^1]* #### **步骤 3:构建升级协议** 通过 USB 实现简易通信协议: | 指令类型 | 字节序列 | 功能 | |----------|----------|------| | 握手信号 | `0x55 0xAA` | 建立连接 | | 擦除命令 | `0xDE 0xAD` | 擦除U-Boot分区 | | 数据包 | `0xDA + [size] + [data]` | 传输固件 | | 校验命令 | `0xBE 0xEF` | 验证固件完整性 | #### **步骤 4:修改充电界面交互** 在 `charger` 服务中添加升级提示: ```diff # frameworks/base/services/core/java/com/android/server/BatteryService.java public void onChargingStarted() { if (checkUsbUpdateMode()) { showUpdateScreen(); // 显示"检测到升级请求" } else { showNormalCharging(); } } ``` --- ### **关键挑战与解决方案** 1. **电源稳定性** - 问题:刷写时断电导致设备变砖 - 方案: - 刷写前强制 `battery->capacity >= 50%`[^1] - 实现**双备份 U-Boot**(主备分区切换) 2. **安全验证** - 问题:未签名固件可能植入恶意代码 - 方案: ```c if (!verify_signature(update_data)) { abort_update(); // 拒绝未签名固件 } ``` 3. **通信可靠性** - 问题:USB 传输错误 - 方案: - 添加 CRC32 校验:$$ \text{CRC} = \sum_{i=0}^{n} \text{data}[i] \oplus 0xEDB88320 $$ - 每 512 字节应答一次 ACK --- ### **操作流程示例** ```mermaid sequenceDiagram PC->>Device: 发送握手信号(0x55AA) Device->>PC: 返回设备ID PC->>Device: 发送擦除指令(0xDEAD) Device->>Device: 备份当前U-Boot Device->>PC: 返回就绪状态 loop 数据传输 PC->>Device: 数据包(0xDA + size + data) Device->>PC: ACK + CRC校验结果 end PC->>Device: 提交执行指令(0xBEEF) Device->>Device: 烧写新固件并重启 ``` --- ### **风险提示** 1. **变砖风险** - 错误修改 `aboot.c` 可能导致设备无法启动 - 建议保留 **Recovery 模式**作为救砖通道 2. **电池管理冲突** - 更新过程需禁用充电 IC 的看门狗(如 BQ3060 的 WD 寄存器[^1]) > ✅ **验证方法**: > 使用 `rkdeveloptool` 读取 U-Boot 版本: > ```bash > rkdeveloptool rl 0x4000 0x2000 /tmp/uboot.bin > strings /tmp/uboot.bin | grep "U-Boot" > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值