Android_boot

本文详细介绍了Android设备的启动过程,包括上电后bootloader的执行、boot.img的加载、Linux Kernel的启动及Android系统的四个主要启动步骤:init进程、native服务、SystemServer以及Home启动。

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

上电,执行bootable/bootloader/*程序,加载boot.img到RAM,boot.img包含内核,引导程序是运行的第一个程序,它是针对特定主板和芯片的,不属于Android操作系统的一部分,
引导程序是OEM厂商或者运营商加锁和限制的地方,引导程序分两个阶段进行:
第一阶段:
第二阶段:
Linux Kernel启动,路径kernel/*,Kernel由bootloader加载,经自解压、初始化、载入built-in驱动程序,完成启动,Kernel启动后会创建若干内核线程(Kernel thread),之后
装入并执行程序/sbin/init/,载入init process,切换至user-space。(不是很明白)


Android启动,Android从Linux系统启动有四个步骤:
init进程启动()
native服务启动()
SystemServer,Android服务启动(详见Android_boot_SystemServer.md)
Home启动()
<think>嗯,用户询问的是Android系统中PRODUCT_BOOT_JARS的定义和用法,这是个比较专业的Android编译系统问题。用户可能是Android系统开发工程师,正在处理系统级模块的开发或封装工作。从引用资料来看,用户似乎已经在研究BootJar的实战应用,特别是如何隐藏模块源码。这问题涉及Android构建系统的核心机制,需要准确解释清楚。先梳理关键概念:PRODUCT_BOOT_JARS是Android编译系统里的特殊变量,主要用途是声明哪些jar包属于核心框架层。这些jar包会被特殊处理——不会被打包进普通APK。参考引用3的内容,"动态JAR参与编译但不打包进apk"的特性描述得非常准确,这正是PRODUCT_BOOT_JARS的核心价值。使用场景方面,引用1提到的"隐藏模块源码封装为BootJar"案例很典型。系统级服务如引用5的CarService框架就需要这种机制,避免每个APP都包含重复的框架代码。另外引用3提到的白名单机制也要强调,系统在package_whitelist.txt里的注册不可或缺。技术细节上需要说明:-定义位置:通常在build/target/product/下的mk文件中全局配置-语法格式:变量采用累加赋值PRODUCT_BOOT_JARS+=ModuleName-生效原理:在编译boot镜像阶段通过classloader预加载用户可能还需要知道实际操作时的坑,比如忘记添加白名单会导致ClassNotFoundException。这部分可以放在相关建议里,毕竟系统开发最怕运行时找不到类。相关问题的设计要围绕深度应用展开:优化方向问依赖管理是否科学,扩展性方面考虑如何实现可插拔的系统服务,安全性则涉及权限控制——这些都是实际开发中必然遇到的衍生问题。最后要特别强调"动态加载"与"静态包含"的根本区别,引用4关于dex文件是否剥离的说明正好佐证这点。用户如果要做系统裁剪,dexstripping的配置也值得延伸讨论。</think> ### Android中`PRODUCT_BOOT_JARS`的定义与使用场景 #### **1. 核心定义** `PRODUCT_BOOT_JARS`是**Android编译系统(如`Android.mk`或`Android.bp`)中的全局变量**,用于声明需要预加载到系统启动类路径(`BOOTCLASSPATH`)中的JAR模块。这些模块会被编译到系统核心框架层(`framework`),**运行时由系统类加载器优先加载**,无需打包进APK中(动态加载)[^1][^3]。 --- #### **2. 核心作用与技术原理** - **动态加载机制**: 添加到`PRODUCT_BOOT_JARS`的模块**不会被打包进APK**(如引用3所述`compileOnly`的作用),仅在系统启动时由`bootclasspath`加载到内存,供所有APP共享。 ```makefile # 示例:在系统mk文件中声明 PRODUCT_BOOT_JARS += RabbitDex # 添加自定义模块[^1] PRODUCT_BOOT_JARS += commonApi # 添加系统级JAR[^3] ``` - **类加载优先级**: 系统会优先加载`BOOTCLASSPATH`中的类(覆盖APP内部相同类),**确保框架层的一致性**。 - **白名单控制**: 需在`package_whitelist.txt`注册模块包名,否则运行时抛出`ClassNotFoundException`[^3]: ```plaintext # build/core/tasks/check_boot_jars/package_whitelist.txt com\.zhiqin\.commonApi\..* # 允许commonApi包下的所有类被系统加载 ``` --- #### **3. 典型使用场景** 1. **系统服务封装**(如引用5的CarService): 将车载服务API(如`car-lib.jar`)加入`PRODUCT_BOOT_JARS`,使所有车机APP共享同一框架代码。 2. **核心模块复用**: 将通用加密、网络模块声明为`BOOT_JAR`,避免每个APP重复打包。 3. **隐藏系统源码**: 通过动态加载封装内部实现(如引用1的`RabbitDex`),仅暴露接口给APP开发者。 --- #### **4. 与静态JAR的关键区别** | **特性** | `PRODUCT_BOOT_JARS`(动态JAR) | 静态JAR | |------------------|-----------------------------------|------------------------| | **编译方式** | `LOCAL_JAVA_LIBRARIES` | `LOCAL_STATIC_JAVA_LIBRARIES` | | **打包行为** | 不打包进APK(系统预加载) | 直接打包进APK | | **应用场景** | 系统级服务、核心框架模块 | 第三方库、业务逻辑代码 | | **代码可见性** | 对APP隐藏实现(仅暴露接口) | 代码随APK分发 | > 注:静态JAR会增加APK体积(引用3),而动态JAR需系统签名和白名单支持[^3][^4]。 --- #### **5. 配置注意事项** - **系统兼容性**: 模块需使用Android SDK接口,避免依赖设备特定硬件(如非标准HAL)。 - **DEX优化**: 若需保留`.dex`文件(如调试场景),在`Android.mk`中设置`LOCAL_DEX_PREOPT := nostripping`[^4]。 - **依赖管理**: 动态JAR模块不可依赖非`BOOT_JAR`的第三方库(需确保自身闭环)。 --- #### **相关建议** - **避免滥用**:仅核心模块使用此机制,过度使用会增加系统启动负担。 - **权限控制**:动态JAR需系统签名,防止恶意模块注入。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值