HarmonyOS 鸿蒙Next中【上架检测FAQ】元服务禁止使用so文件

概述

元服务禁止使用so文件，是指元服务软件包中不允许集成任何Native so文件。

元服务只能使用元服务API集，而so文件对应的是C API，违反元服务生态规则要求。禁止集成native so文件可提高元服务安全性。即元服务每个hap、hsp的libs目录下，不能包含后缀为“.so”的文件。

您的元服务存在使用非元服务API集的问题，不符合审核标准。

元服务不能集成native so文件，静态检查hap、hsp的libs目录下，不能包含后缀为“.so”的文件。

应用上架前迭代版本测试可使用DevEco Testing应用上架预检功能在本地设备/虚拟机提供黑盒专业测试能力，提前发现上架基础体验类问题，提升上架审核效率。

应用上架提审前可使用云测试应用上架预检功能在云端提供远程黑盒专业测试，包含多品类，多设备，多OS的兼容测试能力，提前发现上架基础体验类问题，提升上架审核效率。

上架预检生成检测报告后，导入到AppAnalyzer工具进行诊断和分析，获得可能的故障原因并生成体检报告。

更多关于HarmonyOS 鸿蒙Next中【上架检测FAQ】元服务禁止使用so文件的实战教程也可以访问 https://www.itying.com/category-93-b0.html

鸿蒙Next元服务禁止使用so文件，上架检测会严格核查。开发者需将C/C++代码编译为鸿蒙动态库（.so文件需转换为.hap包支持的格式）。应用应使用ArkTS/ArkUI开发，确保符合鸿蒙应用架构规范。

更多关于HarmonyOS 鸿蒙Next中【上架检测FAQ】元服务禁止使用so文件的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html

根据您提供的FAQ内容，这是一个非常明确的HarmonyOS Next上架规范。核心信息可以总结如下：

1. 核心规则 在HarmonyOS Next中，元服务（原子化服务）的软件包（HAP/HSP）内严格禁止包含任何原生的.so动态库文件。这不仅是技术限制，更是生态安全策略。

2. 根本原因

生态隔离与安全：元服务被设计为运行在受控的、高安全性的沙箱环境中，其能力边界被严格限定在公开的元服务API集内。.so文件对应的是底层的C/C++ API，直接调用会突破此边界，引入不可控的安全风险（如内存破坏、未授权访问等）。
设计原则：元服务的定位是轻量化、即用即走、安全可控的服务。禁止Native库是为了确保其行为完全符合鸿蒙生态的预期和管理。

3. 检测与修改

检测位置：检查每个HAP或HSP包的libs目录（通常路径如entry/build/default/outputs/default/entry-default-unsigned.hap解压后查看），确保其中没有.so文件。
依赖排查：常见的.so文件来源包括：
- 直接引入的第三方预编译Native库。
- 项目中的C/C++代码（cpp目录）被编译后生成的.so文件。对于元服务项目，不应包含cpp目录或Native模块。
解决方案：必须移除所有对Native .so文件的依赖。所需功能应完全使用ArkTS/TS语言及HarmonyOS提供的元服务API来实现。如果依赖的第三方SDK包含了.so，则需要寻找其纯JS/TS版本或寻找功能等效的鸿蒙官方API替代。

4. 上架前自检工具 FAQ中提到的工具链是合规上架的关键：

结论：在开发HarmonyOS Next元服务时，必须遵循纯ArkTS/JS开发范式，彻底避免引入任何Native代码或库。这是上架审核的硬性要求，旨在保障整个鸿蒙元服务生态的安全性和一致性。请在上架前务必使用推荐的工具完成自检。