​  

在OpenHarmony 4.1的整机启动流程中,按照以下步骤进行服务和应用的启动:

  1. 内核加载与init进程:bootloader通常通过设置cmdline来指定内核的位置,并引导内核启动。

    例如: 
    kernel /boot/zImage initrd=initramfs.img console=ttyAMA0,115200 
    root=/dev/mmcblk0p2 rootwait
    someapp=arg1,arg2
    

    内核启动后会加载init进程,如init=/init root/dev/xxx

  2. 基础环境初始化:init进程挂载tmpfs和procfs,创建基本的dev设备节点,提供一个基本的根文件系统。

    tmpfs:这是一个内存上的文件系统,用于存储临时数据,比如在启动期间创建的目录、缓存等。它不会持久化到磁盘,当系统重启时会自动清除。
    
    procfs:这个文件系统提供内核运行时信息的接口,如进程列表、系统配置、硬件状态等。init进程通常会挂载procfs,以便在启动早期获取和管理这些信息。
  3. 热插拔事件监听:init进程启动ueventd来监控内核中的设备热插拔事件,为新插入的block设备分区(如system和vendor分区)创建相应的dev设备节点。

    当设备被插入或移除时,内核会通过 uevent(用户空间事件)机制发送消息给 ueventd。ueventd 作为系统服务的一部分,负责监听这些netlink事件,并根据接收到的事件类型动态管理相应的设备节点。
  4. 服务启动:挂载完分区后,init会扫描/system/etc/init目录下的init.cfg文件,根据配置启动各个系统服务,包括SA(Service Ability,能力服务)。

    init.cfg文件是关键组件,它定义了系统服务的启动顺序和命令。每个服务(如serviceName)都有一个名称和可执行文件路径数组,例如:
    {
        "services" : [
            {
                "name" : "listen_test",
                "path" : ["/system/bin/sa_main"]
            }
        ]
    }
    
    在这个例子中,listen_test服务会在启动时运行/system/bin/sa_main。配置文件是JSON格式的,开发者需要确保添加的服务和命令按照正确的结构编写。
    init.cfg会根据配置中的jobs部分来执行一系列命令,比如:
    {
        "jobs" : [
            {
                "name" : "post-fs-data",
                "cmds" : [ "start listen_test" ]
            }
        ]
    }
    
  5. 服务注册与管理:每个SA在启动时向samgr注册,并获得一个ID,应用可以通过这个ID来访问和调用SA提供的服务。在APP_FEATURE_INIT(Init)函数中,通过sm->RegisterFeature()方法将SA注册到Samgr,同时提供服务实例。

  6. 用户程序管理:foundation进程负责应用的生命周期管理和JS运行环境的准备。appspawn作为应用孵化器,当接收到foundation的请求时,会快速孵化出新的应用进程,以减少启动时间。

    Appspawn在OpenHarmony中作为应用孵化器,其主要功能是接收来自Foundation(基础服务层)或其他有权限的服务(如Ability Manager Service,AMS)的请求,这些请求通常以JSON格式包含启动新应用所需的信息。当appspawn接收到这样的请求时,它会按照指定的参数(如应用程序包名、动态库路径、用户和组ID等)来创建一个新的进程,并赋予相应的权限。
    
    在标准系统中,appspawn的服务名称是固定的,"appspawn",它通过监听本地socket等待客户端连接。小型系统则有所不同,appspawn在初始化后会注册服务并等待AMS或其他特定服务发送的进程间消息。
    
    开发过程中,开发者需要了解如何使用appspawn提供的接口(如CreateClient、ConnectSocket等)来与appspawn进行通信,并构建包含应用程序启动参数的消息结构。

    这些步骤是基于标准系统移植指南中的描述,并且适用于小型和标准系统设备,如Hi3516DV300、Hi3518EV300和RK3568等。对于不同内存级别的设备(如小型系统和轻量系统),可能有不同的启动组件和适配策略。

 

启动子系统内部涉及以下组件:

  • init启动引导组件

    init启动引导组件对应的进程为init进程,是内核完成初始化后启动的第一个用户态进程。init进程启动之后,读取init.cfg配置文件,根据解析结果,执行相应命令(主要是job命令集合,见job接口说明)并依次启动各关键系统服务进程,在启动系统服务进程的同时设置其对应权限。

  • ueventd启动引导组件

    ueventd负责监听内核设备驱动插拔的netlink事件,根据事件类型动态管理相应设备的dev节点。

  • appspawn应用孵化组件

    负责接收用户程序框架的命令孵化应用进程,设置新进程的权限,并调用应用程序框架的入口函数。

  • bootstrap服务启动组件

    提供了各服务和功能的启动入口标识。在SAMGR启动时,会调用bootstrap标识的入口函数,并启动系统服务。

当前OpenHarmony标准系统默认支持以下几个镜像:

镜像名称挂载点说明
boot.imgNA内核和ramdisk镜像,bootloader加载的第一个镜像
system.img/system系统组件镜像,存放与芯片方案无关的平台业务
vendor.img/vendor芯片组件镜像,存放芯片相关的硬件抽象服务
updater.img/升级组件镜像,用于完成升级;正常启动时不加载次镜像
userdata.img/data可写的用户数据镜像

​在编写代码时,开发者需要遵循这些步骤,确保服务的正确加载顺序和应用的初始化。每个SA的服务启动脚本(如init.cfg)应符合JSON格式,并且理解如何配置服务类型(boot, normal, condition),以及何时使用on-start, on-stop, on-restart命令执行。

Logo

社区规范:仅讨论OpenHarmony相关问题。

更多推荐