HarmonyOS鸿蒙Next中应用要支持64位so文件

概述

应用要支持64位so文件，是指当应用集成了native so代码（C/C++编写的库文件）时，需要提供对应64位架构的so文件。

so文件是Linux/Android系统中的共享目标文件（Shared Object File），属于动态链接库。在鸿蒙生态中，应用如果使用了Native代码，必须确保提供64位版本的so文件。

不同CPU架构对应的目录结构如下：

32位ARM架构：lib/armeabi-v7a

64位ARM架构：lib/arm64-v8a

您的应用集成native so，但在libs目录下未提供64位so文件，不符合审核标准。

负面案例：libs目录下存在仅32位包	正面案例：libs目录下提供64位包
	或

静态检查hap、hsp的libs目录下，需提供“arm64-v8a”的so文件，如何查看和构建32位和64位包架构，详情见详解华为应用市场2022年逐步减少32位包体上架应用和策略。

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

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

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

更多关于HarmonyOS鸿蒙Next中应用要支持64位so文件的实战教程也可以访问 https://www.itying.com/category-93-b0.html

HarmonyOS Next应用需支持64位so文件。开发者需将32位so文件升级为64位版本，或提供兼容的64位替代方案。应用打包时需确保所有so文件均为64位格式，以适配Next系统的64位架构要求。

更多关于HarmonyOS鸿蒙Next中应用要支持64位so文件的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html

在HarmonyOS Next中，应用必须提供64位（arm64-v8a）的Native库（so文件），这是上架应用市场的强制要求。如果您的应用仅包含32位（armeabi-v7a）so文件，将无法通过审核。

核心要点：

目录结构：确保在HAP/HSP包的libs目录下，为所有Native库提供对应的arm64-v8a子目录及64位so文件。可以同时提供32位和64位版本，但绝不能仅提供32位版本。
构建配置：在编译构建Native代码（C/C++）时，请确认您的构建工具链（如CMake）已正确配置并生成了ARM64架构的目标文件。
第三方库：如果使用了预编译的第三方so库，您必须向其供应商获取或自行编译对应的64位版本。

验证与测试：

提交前，请手动检查最终HAP包的libs目录结构。
强烈建议使用DevEco Testing的“应用上架预检”功能进行本地检测，或使用云测试的预检功能进行更全面的兼容性测试。这些工具能有效识别此类问题。
可将预检报告导入AppAnalyzer工具进行深度分析，获取具体的修复建议。