任务目标： 将7885 解耦项目的OpenHarmony框架从OH4.1Release升级到OH5.0Release。 项目结构说明： 由社区sig工程和laval工程组成，社区sig工程负责编译OH框架和开源产品仓，laval工程负责编译展锐镜像。 工程具体说明可查阅：https://gitee.com/cooperation-team-7885/make_pac/blob/5.0/READM

OpenHarmony 通过打patch方式实现产品特性化修改 环境 系统：OpenHarmony 4.1 release 设备：开发者手机 介绍 openharmony对产品需要定制化修改底座代码仓的情况，build子系统提供了先打入patch再开始编译的一种编译方式。 #build/hb/util/prebuild/patch_process.py def patch_apply(self,

1、 升级包简介 升级包里面有两个文件，包括build_tools.zip 和update.bin。 build_tools.zip：用来辅助升级的工具，包括升级的可执行文件updater_binary和升级脚本，镜像描述 update.bin：TLV编码的文件，所有的升级内容按照TLV格式序列化存储&#xff0c

前提 进行系统升级功能适配，需要保证bootload下图形原厂驱动、input原厂驱动正常，例如能正常显示开机logo等。 启动updater镜像 以本地升级为例，进行手动升级测试，需要通过hdc命令进入updater模式，相关命令如下： hdc reboot updater #重启进入updater模式 hdc updater_reboot #updater模式下重启进入正常模式 进入upd

简介 升级包安装组件运行在updater分区，其功能主要包括读取misc分区信息获取升级包状态，对升级包进行校验，确保升级包合法有效；然后从升级包中解析出升级的可执行程序，创建子进程并启动升级程序。具体升级的动作由升级脚本控制。本文将介绍如何针对OpenHarmony L2场景适配updater模式。 升级方式 从OTA包的升级方式来说分为本地升级和网络OTA升级。 本地升级：将制作好的OTA

添加外部依赖

简介 编译构建子系统提供了一个基于Gn和ninja的编译构建框架。根据产品配置，编译生成对应的镜像包。其中编译构建流程为 preloader->loader->gn->ninja build文件夹下的subsystem_config.json文件，主要包含子系统名称与路径信息，在preloader阶段被加载，根据子系统名称和

编译产品：rk3568 1、编译报错，缺少Xcursor.h [OHOS_ERROR] ../../third_party/flutter/glfw/src/x11_platform.h:39:10: fatal error: 'X11/Xcursor/Xcursor.h' file not found [OHOS_ERROR] #include <X11/Xcursor.h> [OHOS_ERR

search_pkg_server为测试服务器代码，先将search_pkg_server文件夹拷贝到base/update/updateservice下 修改base/update/updateservice下的bundle.json文件。在bundle.json文件的sub_component中添加: "build": { "sub_component": [ + "//base/updat