OpenHarmony-XTS认证流程
说明:
1.文章由移远通信技术股份有限公司提供
2.以下内容包含了个人理解,仅供参考,如有不合理处,请联系笔者修改/删除,17352182159(微信同号)。
一、写作背景
OpenHarmony XTS认证是开放原子开源基金会推出的生态兼容性测评体系,旨在确保设备和应用在OpenHarmony系统上稳定运行并保持接口一致性。
笔者在第一次进行XTS认证时,对整个测试认证流程不熟悉,耗费了较多的时间,最终送检模组/开发板也是通过了兼容性测评,拿到了开放原子基金会发放的OpenHarmony生态产品兼容性证书。本次参考OpenHarmony官网提供的测评指南,加上笔者个人的理解,以OpenHarmony 5.X Release版本-标准系统为例,整理这篇文章,希望可以对各位送测伙伴提供帮助。
二、认证前需要了解的事项
1.测评项
兼容性测试包括:acts、acts-validator、hats、dcts、ssts
acts(application compatibility test suite)应用兼容性测试套件,看护北向HAP兼容、OpenHarmony开发API兼容。
acts-validator 应用兼容性补充测试套件,需要根据引导完成手工测试。
hats(Hardware Abstraction Test Suite )硬件抽象兼容性测试套,看护HDI层接口。
dcts(Distributed Compatibility Test Suite )分布式兼容性测试套,看护分布式兼容性。
ssts(System Security Test Suite )系统安全漏洞测试套,看护已知系统安全漏洞补丁的修复情况。
2.支持的测评类型
OpenHarmony支持如下几种类型:
1.轻量系统(参考内存>=128KB)
面向MCU类处理器例如Arm Cortex-M、RISC-V 32位的设备,硬件资源极其有限,支持的设备最小内存为128KiB,可以提供多种轻量级网络协议,轻量级的图形框架,以及丰富的IOT总线读写部件等。可支撑的产品如智能家居领域的连接类模组、传感器设备、穿戴类设备等。
2.小型系统(参考内存>=1MB)
面向应用处理器,例如Arm Cortex-A的设备,参考内存≥1MB,提供更高的安全能力,提供标准的图形框架,提供视频编解码的多媒体能力。典型产品有智能家居领域的IPCamera、电子猫眼、路由器以及智慧出行域的行车记录仪等。
3.标准系统(参考内存>=128MB)
面向应用处理器,例如Arm Cortex-A的设备,参考内存≥128MB,提供增强的交互能力,提供3D GPU以及硬件合成能力,提供更多控件以及动效更丰富的图形能力,提供完整的应用框架。典型产品有高端的冰箱显示屏等。当前我们所使用的模组/开发板一般申请标准系统。
三、认证流程

兼容性测评主要步骤如下:
步骤 1 申请OpenHarmony兼容性测评的企业(以下简称“申请方”)在开放原子开源基金会网站申请企业帐号。
步骤 2 申请方从Gitee平台获取代码进行适配开发;从OpenHarmony官网兼容性XTS专区获取兼容性测试套件并在本地测试执行,自测试完成后,申请方可获取测试报告;从OpenHarmony官网兼容性PCS专区获取PCS自检表并填写PCS自检表;如需申请失败项豁免,请前往OpenHarmony兼容性平台进行豁免申请,获取豁免结果;兼容性测试与PCS自检也可委托兼容性工作组授权的兼容性测评合作中心进行。
步骤 3 申请方首次申请测试报告评审时,应签署OpenHarmony兼容性平台所示《OpenHarmony兼容性协议》及《OpenHarmony兼容性平台隐私声明》;申请方上传测试报告、PCS自检表和镜像到OpenHarmony兼容性平台,申请方还应在上传测试报告同时向OpenHarmony兼容性工作组寄送产品样品。
步骤 4 OpenHarmony兼容性工作组收到申请方上传的测试报告和产品样品后进行测评,并给出测评结果。若测评通过,则进入步骤5;若测评不通过,则OpenHarmony兼容性工作组将通知申请方进行整改。
步骤 5 若步骤4测评通过,则OpenHarmony兼容性工作组将按需启动复测流程。如未被选中复测,则申请方通过本次OpenHarmony兼容性测评。如被选中复测,则复测所用的兼容性测试套件包将由OpenHarmony兼容性工作组上传至平台。申请方自OpenHarmony兼容性平台下载前述复测套件包并在本地执行,生成复测报告后上传到OpenHarmony兼容性平台。
步骤 6 OpenHarmony兼容性工作组对申请方复测报告进行评审,若复测评审通过,则本次OpenHarmony兼容性测评通过;若复测评审不通过,OpenHarmony兼容性工作组将通知申请方整改。
步骤 7 OpenHarmony兼容性测评通过后,开放原子开源基金会将发放证书,在OpenHarmony官网进行展示,并授权申请方在其设备类OpenHarmony兼容产品及其包装、营销材料上使用OpenHarmony兼容性标识。
注:认证流程完整来自OpenHarmony官网提供的测评指南
四、软/硬审核
1.硬件审核
选择合适的模组/开发板:比如SG368Z-AP,SG530C-CN等;
选择合适的芯片:比如RK3568,UIS7885等;
选择硬件是否带屏:是/否;
按照PCS自检表第页“OpenHarmony标准系统兼容性规范”对模组/开发板规格进行检查,PCS自检表获取地址:https://www.openharmony.cn/systematic;
模组/开发板送测邮寄数量:模组/开发板≥5。
2.软件审核
选择合适的操作系统:比如OpenHarmony 5.0.3 Release,OpenHarmony 5.1.0 Release等;
确保搭配硬件可以正常运行且基础功能正常;
软件方面的其余审核在测试阶段可以通过修改软件来改进。
另外,建议在开始测试前先对产品信息修改,具体修改如下表:
| API接口 | 接口定义及返回值要求 | 备注 |
| GetDeviceType() | 设备类型。最多32个字符,不允许使用中文。用以标识设备的品类,设备生命周期内固定。 | 非经典设备无需填写,保持默认 |
| GetManufacture() | 公司英文名简称。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetBrand() | 品牌英文名称。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetMarketName() | 外部产品英文名称。也叫传播名,用户可见。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetProductSeries() | 产品系列英文名称。用以对不同类型产品进行分类管理。最简情况下,系列下可能只有一个型号,此时可以使用型号信息代替系列。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetProductModel() | 型号。设备关键信息之一,用以标识一类设备。用户可见,通常打印在设备铭牌上,是不同产品的区分标识。该值也是进行认证所需的关键数据,需要采用英文描述。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetSoftwareModel() | 内部软件子型号。多硬件共软件时区分软件分支。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetHardwareModel() | 内部硬件子型号。最多32字符。设备生命周期内固定。 | 不要超过32个字符 |
| GetSerial() | 设备序列号。标识设备的关键信息,在多个设备间流转业务时一般需严格保持一致,用户可见。最多64字符。设备生命周期内固定。 | |
| GetOsFullName() | 操作系统及版本号。系统名与版本号之间以英文字符'-'连接,不能包含空格。最多64字符。随软件版本变更。 | |
| GetDisplayVersion() | 用户可见的软件版本号。注意是整个系统的软件版本号而非OpenHarmony版本号。最多64字符。随软件版本变更。 | 不要超过64个字符 |
| GetBootloaderVersion() | Bootloader版本号。最多64字符。随软件版本变更。 | |
| GetSecurityPatchTag() | 安全补丁标签。标识当前OS的安全补丁级别。最多64字符。随软件版本变更。以补丁发布日期作为版本号,格式为"年/月/日",参考示例格式。 | 注意格式,比如2025/10/01 |
| GetAbiList() | abi兼容性列表。多个取值以英文逗号','分隔,仅在有生态的系统且系统中包含native应用时使用。最多64字符。设备生命周期内固定。 | |
| GetSdkApiVersion() | 系统软件API Version。设备当前版本API版本,仅在有生态的系统使用,一般是整数。随软件版本变更。 | |
| GetFirstApiVersion() | 设备首版本的系统软件API Version。仅有生态的系统使用,一般是整数。设备生命周期内固定。 | |
| GetIncrementalVersion() | 差异版本号。在设备型号确定的情况下,即在"设备类型"+"公司"+"品牌"+"产品系列"+"操作系统及版本号"+"型号"+"内部硬件子型号"+"内部软件子型号"均相同的情况下,此值必须可以唯一标识软件版本。随软件版本变更。 | 用例中会有检查,这个字段不要超过32位(ActsInitNdkTest;ActsStartupSysDeviceInfoTest) |
| GetVersionId() | 版本Id。由多个字段拼接而成:$(设备类型) + '/' + $(公司英文名简称) + '/' + $(品牌英文名称) + '/' + $(产品系列英文名称) + '/' + $( 操作系统及版本号 ) + '/' + $(型号) + '/' + $(内部软件子型号) + '/' + $(系统软件API level ) + '/' + $(差异版本号) + '/' + $(构建类型)。在所有厂家的所有设备范围中,可以唯一标识版本。最多255字符。多个组成字段间以英文符号'/'分隔。随软件版本变更。 | 自动拼接,无需填写 |
| GetBuildType() | 构建类型。同一基线代码的不同构建类型,比如debug、release,log、nolog等。可以用多个标识以英文冒号':'分隔。最多32字符。随软件版本变更。 | |
| GetBuildUser() | 构建user。最多32字符。随软件版本变更。 | |
| GetBuildHost() | 构建host。最多32字符。随软件版本变更。 | |
| GetBuildTime() | 构建时间。Epoch Time,自1970年至今的秒数。最多32字符。随软件版本变更。 | |
| GetDevUdid() | 设备标识符。注意与设备序列号进行区分,设备标识符一般是基于设备序列号进一步计算后得出,两者并不相同。长度64字符。设备生命周期内固定。 |
以上字段修改在base/startup/init/services/etc/param/ohos.para文件中修改对应字段,安全补丁标签在ssts测试项介绍如何修改。
五、测试前置准备
·windows系统为win10及以上,内存建议32G及以上;
·hdc可以正常连接;
·windows系统中python版本:python3.7及以上版本;
--看当前windows下python版本指令:python -V,第一次安装python版本,需要重启电脑;
·本地windows机器联网
--需要登录OpenHarmony下载测试套件及测试资源
--兼容性平台提交送测需要连接网络
·测试过程中设备网络需要连通(插sim卡或以太网连接或wifi连接);
--试过程中发现,acts个别用例不能使用公司网络进行测试;
·分布式兼容性测试需要提前申请分布式盒子;
--申请分布式盒子,从发起申请到拿到分布式盒子中间有一段时间,提前申请;
--申请方式:OpenHarmony兼容性平台->兼容性测评->分布式测试盒管理->创建申请->填写信息->提交申请->等待申请通过->基金会邮寄分布式盒子到申请方;
--此外也可以自行购买分布式盒子
六、测试套件获取与说明
测试套件获取一般有两种方式:从官网下载/自己编译。官网只提供arm32的测试套件。ssts测试套件,标准系统arm32、arm64、X86等均适用。其余测试套件(acts, acts-validator ,dcts,hats)如果我们编译的是arm64或者其他镜像,就需要自己编译对应的测试套件。
1.从官网下载测试套件
XTS测试套件官网地址:https://www.openharmony.cn/systematic?tab=xts;
进入XTS测试套件官网选择送测设备对应分支,下载各测试套件(以acts为例)选择对应分支与系统类型下载resource文件,拷贝到acts\resource目录下,需要注意的是保存到本地(windows机器)时,保存路径中不要包含中文。

2.自己编译测试套件
如果我们编译的不是arm32镜像,就需要自己编译对应的测试套件。以rk5368为例,编译各测试套件的详细流程如下:
·acts与acts-validator测试套件编译:
--下载对应基线完整代码;
--全量编译代码;
-- 进入到acts目录:cd test/xts/acts;
--编译acts:./build.sh product_name= rk3568 system_size=standard target_arch=arm64;
字段说明:这里的rk3568 是设备名称,不带target_arch=arm64默认编译的是32位;
# acts测试套件:将编译产物/out/rk3568/suites/acts/acts,拷贝到本地(windows机器),本地存储路径中不要包含中文;
# acts-validator测试套件:将编译产物/out/rk3568/suites/acts/acts-validator,拷贝到本地(windows机器),本地存储路径中不要包含中文;
--从官网下载对应分支的acts资源文件,放到acts/resource目录下
·hats测试套件编译:
--下载对应基线完整代码;
--全量编译代码;
-- 进入到hats目录:cd test/xts/hats;
--编译hats:./build.sh product_name= rk3568 system_size=standard target_arch=arm64;
字段说明:这里的rk3568 是设备名称,不带target_arch=arm64默认编译的是32位;
# hats测试套件:将编译产物/out/rk3568/suites/hats,拷贝到本地(windows机器),本地存储路径中不要包含中文;
--从官网下载对应分支的hats资源文件,放到hats/resource目录下
·dcts测试套件编译:
--下载对应基线完整代码;
--全量编译代码;
-- 进入到dcts目录:cd test/xts/dcts;
--编译dcts:./build.sh product_name= rk3568 system_size=standard target_arch=arm64;
字段说明:这里的rk3568是设备名称,不带target_arch=arm64默认编译的是32位;
# dcts测试套件:将编译产物/out/oriole/suites/dcts,拷贝到本地(windows机器),本地存储路径中不要包含中文;
--从官网下载对应分支的dcts资源文件,放到dcts/resource目录下
·ssts测试套件获取:ssts测试套件,标准系统arm32、arm64、X86等均适用,无需编译,直接从官网下载。
3.测试套件下各部分作用说明

·config:存放测试框架的配置文件,用于调整测试参数和行为;
·resource:包含测试所需的各种资源文件,如配置文件、辅助脚本等,需要我们从官网去下载;
·testcases:存放具体的测试用例源码,是测试套件的核心;
·tools:包含测试工具,如自动化测试框架、测试数据生成器等;
·run.bat:用于在Windows环境下执行批处理脚本,是自动化执行测试套件的关键文件;
·reports:存放测试报告,测试过程中会自动生成此目录
4.修改配置文件
下载/编译的测试套件,我们需要手动修改配置文件,目的是在测试的时候测试工具可以准确识别连接到对应的测试设备,具体修改在config/user_config.xml文件下修改。这里提供两种修改方案:识别指定的一台测试设备和识别多台测试设备。

4.1 修改配置文件识别一台指定设备进行测试
这种修改适用于指定设备进行测试,如果我们的windows机器在进行XTS测试的同时,连接其他设备进行调试,推荐使用这种修改方案,具体修改点如下:
--ip:127.0.0.1
--port:8710
--sn:hdc list targets 查看sn号填入
-- hdc -t xxxxx shell,可以在测试的同时连接其他设备进行调试

4.2 修改配置文件识别多台设备进行测试
这种修改适用于多台设备连接到同一台windows机器上并行测试,可以缩短测试时间,acts测试比较耗时,推荐使用此修改方案之后连接多台设备并行测试(个人推荐三台设备测试),具体修改点是config/user_config.xml文件中device字段改为false。

七、XTS自测试
XTS自测试项包括acts,acts-validator,hats,dcts,ssts。自测试是为了发现失败/异常测试项,并进行分析修复/豁免,确保满足测评要求。
1.acts测试
acts测试主要用于验证设备和业务应用在应用层面,确保Harmony应用包(HAP)能在OpenHarmony系统上稳定运行,验证OpenHarmony开发API的接口一致性和功能正确性,通过测试用例确保应用具备一致性的业务体验。具体测试流程如下:
(1)连接测试设备到windows机器,acts测试需要连接wifi或插上SIM卡,保证可以可以正常上网;
(2)hdc list targets 查看连接设备数量是否与实际连接数量一致,acts测试推荐使用三台设备并行测试;
(3)运行测试脚本acts/run.bat(双击运行);
(4)输入测试指令进行测试;
--全量acts测试指令:run acts
--测试单个Modules指令:run –l ActsGraphicImageTest
--测试多个Modules指令:run –l ActsGraphicImageTest;ActsAvcodecNdkTest
--测试单个用例指令:run –l ActsGraphicImageTest –ta class: imagePixelMapTest#ImagePixelMapTest_0200
说明:上述ActsGraphicImageTest;ActsAvcodecNdkTest在实际测试时需要换成目标测试用例名称,这里只是以这两个Modules为例;多个Modules测试,需要主要分隔Modules的”;”是英文符号。
2.acts-validator测试
acts-validator测试是OpenHarmony兼容性测试套件中的应用兼容性补充测试套件,其核心作用是通过手工测试验证设备对HAP(Harmony Ability Package)应用包和OpenHarmony开发API的兼容性补充要求。用于补充自动化测试(acts套件)未覆盖的兼容性场景,例如复杂交互逻辑或特定API的手动验证,确保设备在真实用户场景下能正确处理应用功能与系统接口的交互。
只有带屏设备需要完成此项测试,建议只使用一台设备进行测试,具体测试流程如下:
(1)将USB连接到标准系统设备,hdc list targets查看设备正确连接;
(2)执行acts-validator\run.bat,输入命令:run validator -ta update:true ,完成辅助资源的推送安装;
(3) 打开Validator应用进入主界面,选择待测模块(目前包括:ArkUI系统动效看护,Camera相机基本功能,Audio音频录制和播放,Player音视频完整播放,Experience性能基础体验等模块的测试项)进入二级目录,选择一个测试项进入测试页面,满足操作提示所要求的测试项,则左下角绿√图标按键生效,点击绿√图标后返回上级目录,二级目录通过测试项列表栏变绿标记测试通过;点击右下角红×按键同样返回二级目录,相应的测试项列表栏变红标记测试失败。

(4) 当所有模块的测试项均标记通过或失败,可返回一级目录点击上部最右报告生成按键生成可视化报告,并弹出提示框告知生成报告已生成,在run.bat中输入Y确认测试结束,待脚本执行完毕,即可生成可视化报告。

3.hats测试
hats测试聚焦于硬件抽象层(HAL)与设备驱动程序之间的接口(HDI),通过测试这些接口的规范性和一致性,确保硬件操作能被系统正确识别和执行。例如,测试输入设备(触摸屏、按键)、传感器(陀螺仪、加速度计)、音频设备等硬件功能的接口调用是否正常,通过覆盖硬件功能的完整测试流程(如设备初始化、参数设置、状态回调等),HATS能够发现硬件驱动或接口实现中的潜在问题,避免因硬件兼容性导致的系统崩溃或功能异常。具体测试流程如下:
(1)连接测试设备到windows机器;
(2)建议只使用一台设备测试hats,hdc list targets查看设备正确连接;
(3)运行测试脚本hats/run.bat(双击运行);
(4)输入测试指令进行测试,具体参考acts测试
4.dcts测试
dcts测试主要作用是验证分布式场景下设备与业务应用的兼容性,确保跨设备协同功能(如数据共享、任务迁移等)的稳定性和一致性。通过模拟多设备交互场景,测试分布式数据管理、硬件资源共享、跨设备服务调用等关键功能,确保设备在分布式环境中能正确响应协同请求。具体测试流程如下:
4.1 分布式盒子申请
提前向开放原子基金会申请对应版本的分布式盒子,从发起申请到拿到分布式盒子中间会有一定的时间间隔,申请使用时长为60天,若到期后仍需使用,可申请延期最多30天
--申请网站: https://compatibility.openharmony.cn/console/#/box;
4.2组网测试
(1)推送组网hap到测试设备;
执行/dcts/resource/dcts_resource.bat脚本,推送组网hap到测试设备,推送成功后设备会重启。


(2)组网
组网方式可分为以下两种:通过WIFI的方式组网/通过网口直连的方式组网。
·WIFI组网方式如下:
通过WIFI的方式组网,两端设备需连接同一WIFI,之后测试设备和分布式盒子都打开dcct,按照提示完成WIFI组网。WIFI组网会有网络不稳定导致测试结果与实际偏差较大,更推荐使用以太网组网。

·以太网组网方式如下:

--路由器网关地址设置为:192.168.0.1;
--测试设备和分布式盒子都选择“以太网”组网;

--测试设备和分布式盒子设置不同的IP;

--在hap内点击发现可用设备,显示界面会出现对端设备名称;

--分布式盒子向测试设备发起组网申请;
--测试设备弹出连接码后在分布式盒子上输入对端(测试设备)的连接码;

--已连接设备列表出现对端设备名称后组网成功,就可以开始正常测试了。
4.3 测试
(1)连接测试设备到windows机器;
(2)只使用一台测试设备和分布式盒子组网测试hats,hdc list targets查看设备正确连接;
(3)确保组网成功后,运行测试脚本dcts/run.bat(双击运行);
(4)输入测试指令进行测试,具体参考acts测试。
5.ssts测试
ssts测试通过检测已知漏洞的修复状态,确保设备及时更新安全补丁,防范潜在风险。具体测试流程如下:
(1)连接测试设备到windows机器;
(2)建议只使用一台设备测试hats,hdc list targets查看设备正确连接;
(3)运行测试脚本ssts/run.bat(双击运行);
(4)输入测试指令进行测试,具体参考11.2的acts测试。
八、测试报告查看及BUG处理
1.测试报告查看
acts,hats,dcts,ssts测试报告生成后,都会存储在对应测试套件reports文件夹下,以下对个文件夹/文件简单说明:
--log文件夹:log下存放测试过程中的log文件;
--result文件夹:result下的报告会记录测试设备相关字段,以及整体通过情况;
-- details_report.html文件:测试生成的详细报告;
-- failures_report.html文件:失败项测试报告;
-- passes_report.html文件:通过项测试报告;
-- summary_report.html文件:测试报告摘要
2.失败用例处理
XTS失败用例处理流程如下:
(1)在自检表查询失败用例是否是必解项,以及测试用例测试接口对应源码仓;
(2)分析是功能代码缺陷还是用例本身bug或设备不支持对应功能;
(3)如果分析是用例本身bug或设备不支持对应功能,申请豁免。豁免材料中详以图片+文字的形式详细说明整个分析过程,豁免材料格式未做统一限制,但是务必详细;
(4)功能代码缺陷需要详细分析log正向修复;其中acts-validator失败项大概率是设备不支持对应功能,比如:屏幕朗读、手柄等;ssts失败项一般会是OpenHarmony-SA-Patch-label-test用例失败,失败原因是安全补丁过期,修复方案是从社区获取截止当前的最新安全补丁导入到源码中,然后修改补丁日期;补丁获取参考:https://gitcode.com/openharmony/security/tree/master/zh/security-disclosure/2025;
(1)搜索测试用例代码,明确测试内容;
(2)在测试用例中添加日志,定位失败位置;
(3)单编测试hap打印日志;
--编译前删除/out/rk3568;
--单编指令: ./build.sh product_name=rk3568 system_size=standard target_arch=arm64 suite=xxx;
--字段suite对应的gn配置文件中ohos_js_app_suite字段;
--单编后hap路径: /out/rk3568/suites/haps;
--用新生成的hap替换原始测试套件中的hap,重新进行测试,在log中过滤新加日志关键词;
(4)找到对应的功能代码源码,添加日志,重新编译镜像烧录测试;
(5)定位问题,修复验证提交合入。
总台来说:
ssts:优先排查安全补丁是否过期;
dcts:优先使用以太网单独测试,之后排查p2p功能是否正常,涉及p2p相关测试打开wifi不连接进行测试;
acts-validator:优先排查设备是否支持对应测试功能;
hats:优先排查硬件是否支持对应功能,其次判断测试模块底层走的HDF框架还是Linux原生框架;
acts:
--web相关优先排查网络连接并单独测试,其次排查是否是因为公司内网限制导致用例失败,之后排查用例中使用的链接是否可以正常访问;
--弹窗相关失败,测试过程中尝试手动点击对应组件,判断是否因为屏幕分辨率与测试用例中预期分辨率不一致或失焦导致用例失败;
--hap安装或调用相关,优先排查测试套件中有无对应的测试资源文件,对应的测试hap签名是否可用;
注:在测试用例中添加日志只是为了方便我们定位问题,实际提交时测试套件源码是不允许修改的!
九、平台提交送测
对所有失败项修复/申请豁免,进行二轮全量测试,测试无误后在平台提交兼容性测评申请。提交兼容性申请平台:https://compatibility.openharmony.cn/console/#/personal,申请流程如下:
(1)申请企业账号 ;
(2)兼容性测评创建申请;
(3)按照页面提示填写相关信息,提交对应材料,提交材料时有5个对应的界面
--联系人;
--产品定义:需要填写测评类型,操作系统类型,操作系统版本号,模组/开发板(传播名),模组/开发板型号,CPU架构,是否支持安装应用,是否带屏,是否允许公示,基本信息描述,外观图;
--软件定义:软件版本号,安全补丁标签,版本ID,版本Hash,PCID;
--报告上传:镜像文件,XTS报告,PCS自检表,测评豁免申请(在另一个界面申请);
--样机寄送:快递单号,快递物品清单,备注。
提交前需要对设备字段以及其他信息进行检查,产品字段设置参考上述软件审核的“ 产品信息”进行定义,在测试界面会对各字段进行打印。
兼容性平台提交需要填写信息具体见下表:
| 平台填写信息/提交材料 | 填写说明 | |
| 联系人 | 企业联系人 | 按照实际填写 |
| 企业联系电话 | 按照实际填写 | |
| 企业邮箱 | 按照实际填写 | |
| 产品定义 | 测评类型 | 按照实际选择,eg:模组/开发板 |
| 标准系统类型 | 按照实际填写,eg:标准系统 | |
| 操作系统版本号 | 选择OpenHarmony版本号;eg:OpenHarmony 5.1.0 Release | |
| 模组/开发板名称(传播名) | 传播名会在证书上体现;eg:移远通信SG368Z-AP智能模块 | |
| 模组/开发板型号 | 填写产品型号;eg:SG368Z-AP | |
| 芯片型号 | 填写产品芯片型号;eg:RK3568 | |
| CPU架构 | 按照实际填写,eg:arm64 | |
| 是否支持安装应用 | 是/否 | |
| 是否带屏 | 是/否 | |
| 是否允许公示 | 发证即公示 | |
| 基本信息描述 | xxx开发版主要用于Openharmony......,主要应用xxx领域 | |
| 外观图 | 开发版正面和背面图各一张,产品居中,400*400,白底 | |
| 软件定义 | 软件版本号 | 与GetDisplayVersion()获取的一致 |
| 安全补丁标签 | 与GetSecurityPatchTag()获取的一致;eg:2025/09/01 | |
| 版本ID | 与GetVersionId()获取的一致 | |
| 版本Hash | default | |
| PCID | /out/rk3568/packages/phone/system/etc/pcid.sc;将编译的这个文件上传 | |
| 报告上传 | 镜像文件 | 包含镜像,烧录文档,烧录工具,如果是64位测试套件,测试套件也需要包含 |
| XTS报告 | 所有测试报告打包压缩为zip,最大700MB | |
| PCS自检表 | 填写下载自检表表格第一页工作表 | |
| 样机送检界面填写 | 快递单号 | 按实际填写 |
| 快递物品清单 | 在提交界面下载物品清单表格,按实际填写,公司名称填写全程 | |
| 备注 | 无特殊说明可空白 | |
| 样机寄送注意事项 | 投递地址 | 实物投递地址:北京市海淀区北清路156号J园区Q6,兼容性工作组收,13671335601 |
| 包含 | 模组/开发板>=5套,为防止混乱,快递内应附有实物明细列表,单位名称,联系人及电话 | |
| 寄送时间 | 提交申请之前寄送,在提交申请的时候样机最好寄送到基金会 | |
十、豁免申请
豁免申请平台:https://compatibility.openharmony.cn/console/#/exempt,对于用例本身存在缺陷或设备不支持测试性项内容的用例需要在平台提交豁免申请,详细流程如下图所示:


具体填写参考下图。下图是一个豁免通过的截图,在新建豁免申请中关联兼容性测评的测评编号,之后按照提示选择我们要豁免的用例。
豁免附件中要包含豁免用例的测试报告以及对豁免分析报告,豁免分析报告没有固定的模板与格式要求,笔者推荐写成world文档,以图片+文字的形式详细说明是用例缺陷/设备不支持。
豁免审核和兼容性审核在基金会是不同的小组来完成的,一般审核周期为14个工作日。

十一、总结
以上是OpenHarmony-XTS认证的整个流程,提交申请后审核周期一般为十四个工作日,若兼容性测评或者豁免申请被驳回,需要重新分析后提交对应的材料,驳回重新提交的审核周期也是十四个工作日,所以在提交前务必对基础信息进行确认。XTS认证的规则也会随着版本不同有所更新,本文所写适用于OpenHarmony 5.X Release版本,通过测评的产品也会在OpenHarmony官网进行展示。
十二、参考文件
OpenHarmony官网:https://www.openharmony.cn/HomePage
更多推荐

所有评论(0)