一.总括

升级部件位于base/update下，

├── packaging_tools     制作升级包
├── sys_installer       远程升级功能
├── sys_installer_lite
├── update_app           升级应用
├── updater              升级功能
└── updateservice        升级服务（负责进入升级过程）

1.update_app

base/update/app    # 升级客户端应用代码仓目录
├── entry          # 升级客户端应用代码目录
│ └── src          # 升级客户端源码目录
└── gradle         # 配置文件目录目录
    └── wrapper    # gradle配置文件目录目录

这个目录包含了升级客户端应用的代码。升级客户端应用通常是用户直接交互的界面，它负责：

• 展示升级信息给用户。

• 接收用户的操作指令，如开始升级、取消升级等。

• 与升级服务（updateservice）进行通信，以协调升级流程。

2.updateservice

base/update/updateservice  # 升级服务代码仓目录
├── adapter            # 变量参数配置，可能包含默认设置和兼容性处理
│   └── default_config
├── foundations        # 基础能力和模型，支持升级服务的核心功能
│   ├── ability
│   └── model
├── frameworks         # 数据转换框架，实现JS到C/C++与后端的交互
│   └── js
├── interfaces         # 升级客户端接口，定义与升级app和后端交互的API
│   └── inner_api
├── napi               # Native API接口，提供JS与原生代码交互的能力    
│   └── include
├── services           # 升级服务核心功能实现
│   ├── callback       # 回调函数，处理异步操作结果
│   ├── core           # 核心逻辑，版本检查、下载管理等
│   ├── engine         # 引擎服务，下载、解压、安装等技术实现
│   ├── firmware       # 固件升级逻辑和文件管理
│   ├── service        # 辅助服务，日志、配置等
│   ├── startup        # 启动逻辑，设备启动时自动检查升级
│   └── utils          # 实用工具函数，字符串处理、文件操作等
├── test               # 测试代码目录（未在原始目录中提及，但通常会有）
│   ├── unittest       # 单元测试
│   └── fuzztest       # 模糊测试
├── BUILD.gn           # 编译入口文件
└── bundle.json        # 部件描述文件
​
​
`updateservice`目录是一个升级服务客户端，负责与前端/app和后端交互，主要功能包括版本检查、下载管理（支持断点续传、错误重试等）、安装升级、状态查询、错误处理以及日志记录。通过`interfaces`目录定义的接口，升级客户端可以与后端服务进行交互，发起升级请求、查询升级状态等。`services`目录是升级服务的核心，包含了实现上述功能的各个组件。`napi`和`frameworks`目录则提供了JS与原生代码交互的能力，以及数据转换的框架，使得升级服务可以与前端应用无缝对接。

• napi：这个目录包含的是Native API接口，它的主要作用是提供桥梁，使得JavaScript（或其他前端语言）代码能够调用原生（如C/C++）代码提供的功能。这通常用于执行一些性能要求较高的任务，或者访问操作系统级别的功能，比如文件系统、网络请求等。在升级服务的上下文中，napi将代码封装成接口可用于提供下载、安装等操作的接口给前端应用。

• frameworks：这个目录可能包含了一些框架级别的代码，用于实现数据转换、流程控制等功能。frameworks/js特别指出了与JavaScript相关的内容，这个框架专门用于处理JavaScript与原生代码之间的数据转换和交互逻辑。它可能定义了如何格式化数据、如何发起请求以及如何处理响应等。

• interfaces：这个目录包含了升级客户端与后端服务之间的接口定义。这些接口是前端应用与后端服务器进行通信的桥梁，定义了双方需要遵守的协议和格式。在升级服务的场景中，interfaces可能定义了如何请求升级包、查询升级状态、报告错误等操作的API。这些接口通常使用HTTP/HTTPS、WebSocket等协议进行通信。

3.updater

├── BUILD.gn               # 项目的构建配置文件，使用GN构建系统定义项目的构建规则、依赖关系和输出目标。
├── bundle.json            # 项目或应用的配置文件，可能包含有关组件、依赖项、资源或打包信息的描述。
├── interfaces             # 接口定义目录
│   └── kits               # 包含更新服务所需的接口定义和头文件，这些接口用于客户端或其他服务与更新服务进行通信。
├── services               # 更新服务核心功能实现目录
│   ├── applypatch         # 负责应用补丁文件的模块，通常涉及二进制文件的差异比较和合并。
│   ├── BUILD.gn           # 服务模块的构建配置文件，定义了如何构建服务模块及其依赖项。
│   ├── common             # 包含通用的头文件、宏定义、枚举类型以及常用的工具函数。
│   ├── diffpatch          # 生成或应用差异补丁的模块，涉及文件内容的比较和差异计算。
│   ├── etc                # 存放配置文件、模板文件或其他辅助资源。
│   ├── factory_reset      # 提供工厂重置功能，恢复设备到初始状态。
│   ├── flashd             # 与闪存设备交互的模块，涉及固件的写入、擦除等操作。
│   ├── flow_update        # 管理更新流程的模块，确保更新过程的正确性和可靠性。
│   ├── fs_manager         # 文件系统管理器，负责文件读写、权限管理、挂载和卸载。
│   ├── hdi                # 硬件抽象层接口，用于底层硬件交互。
│   ├── hwfault_retry      # 硬件故障重试机制，确保更新过程的健壮性。
│   ├── include            # 公共头文件目录，供整个项目使用。
│   ├── log                # 日志管理模块，记录更新过程中的关键信息和错误。
│   ├── main.cpp           # 项目入口点，包含main函数和启动更新服务的代码。
│   ├── package            # 管理更新包的下载、验证和提取。
│   ├── ptable_parse       # 解析分区表，读取和解析设备上的分区信息。
│   ├── rust               # 包含Rust语言编写的代码模块，可能涉及性能优化或特定功能的实现。
│   ├── script             # 用于更新过程的脚本文件，可能是shell脚本等。
│   ├── sdcard_update      # 支持从SD卡进行更新的功能。
│   ├── ui                 # 提供用户界面，与用户交互，包括进度条、错误提示等。
│   ├── updater_binary     # 包含用于更新过程的二进制文件或工具。
│   ├── updater.cpp        # 更新服务的核心逻辑实现，可能包含版本检查、下载管理等功能。
│   ├── updater_init.h     # 更新服务初始化相关的头文件。
│   ├── updater_main.cpp   # 更新服务的主逻辑实现，包括更新流程、错误处理等。
│   ├── updater_main.h     # 更新服务主逻辑的头文件。
│   ├── updater_preprocess.cpp # 更新前的预处理逻辑，如检查空间、备份数据等。
│   ├── updater_ui.cpp     # 更新用户界面的实现。
│   ├── updater_ui.h       # 更新用户界面的头文件。
│   ├── updater_utils.cpp  # 更新服务中的实用工具函数，如字符串处理、文件操作等。
│   └── write_state        # 负责写入设备状态，涉及更新过程中的持久化操作。
├── test                   # 测试代码目录
│   ├── benchmarktest      # 性能测试，评估更新服务的性能和效率。
│   ├── fuzztest           # 模糊测试，通过注入随机数据发现潜在漏洞和错误。
│   └── unittest           # 单元测试，针对项目中的各个模块进行独立测试。
└── utils                  # 实用工具模块
    ├── BUILD.gn           # 工具模块的GN构建配置文件。
    ├── include            # 工具模块的头文件目录。
    ├── json               # 提供JSON解析和生成的功能，处理配置文件或通信数据。
    ├── partition_utils.cpp # 分区管理相关的实用工具函数。
    ├── updater_reboot.cpp  # 提供重启设备的功能，用于更新完成后的重启操作。
    ├── utils_common.cpp   # 包含通用的实用工具函数。
    ├── utils.cpp          # 其他实用工具函数的实现。
    ├── utils_fs.cpp       # 文件系统相关的实用工具函数。
    └── write_updater.cpp  # 用于写入更新状态或执行与更新相关的写入操作。
​

• 服务层代码（services）：这是升级流程的核心，包括升级包的下载、校验、应用等步骤的实现。它还包括了文件系统和分区管理、日志记录、升级脚本管理等重要功能。

• 用户界面（ui）：虽然通常我们认为用户界面属于前端，但在这种上下文中，updater 组件中的 ui 目录指的是升级过程中向用户展示的界面代码，如进度条、提示信息等。

• 资源（resources）：包括图片、字符串等用户界面所需的资源。

• 接口（interfaces）：定义了升级子系统与其他组件或模块之间的交互方式。

• 通用工具代码（utils）：为升级子系统提供通用的函数和工具。

关系

• 协作关系：这三个目录共同构成了OpenHarmony操作系统中的升级系统。updater 组件提供了升级流程的核心实现和用户界面，app 目录中的升级客户端应用提供了用户交互界面，而 updateservice 目录中的升级服务则负责处理后台逻辑和与客户端的通信。

• 依赖关系：升级客户端应用（app）通常依赖于升级服务（updateservice）提供的接口和功能。同样，updater 组件中的用户界面和服务层代码也可能依赖于 updateservice 中的某些功能。

• 模块化：这种目录结构体现了模块化设计的思想，将升级系统的不同部分拆分成独立的模块，有助于提高系统的可维护性、可扩展性和可重用性。