专栏：HarmonyOS 三方库适配实战（21/30）
核心问题：架构、依赖库、符号和包内路径为什么会让已编译的.so在设备上加载失败？
摘要
Native 编译通过，只证明某个目标文件被链接出来；设备加载还依赖 ABI 匹配、动态依赖可用、库名与模块注册一致，以及.so真正进入安装包。本文对教学libtextnative.so做四次读回：构建目录、ELF 头、NEEDED依赖和 HAP 归档。arm64-v8a 与 x86_64 均确认入包，但没有设备，因此结论止于包结构检查，不能写成dlopen成功。
加载链上有五个关口
图 1：构建、ELF、依赖、打包和设备加载是五个不同证据。
- CMake 为预期 ABI 生成目标；
- ELF 机器类型与目录名一致；
NEEDED的共享库在系统或包内可用；- HAP/HAR 中路径和库名正确；
- 目标设备架构匹配并实际加载。
前四项能离线检查，第五项必须有目标环境。
操作前固定候选，避免检查错文件
本篇面向已经生成 Native HAP、准备排查加载链的读者。使用 DevEco SDK 中的llvm-readelf，而不是另一套系统工具链。工程 product 为 default，目标与兼容配置为 API 12；安装 SDK 为 6.0.2/API 22，不能据此声称所有 API 22 设备已验证。
先将本次 HAP 放入单独审计目录并记录 SHA-256。后续 ELF 检查必须针对从这个 HAP 提取的文件，不能一个命令读 obj 中间产物、另一个命令读上一轮 HAP。下面使用自建可信候选，且输出目录必须是新目录：
$hap=Resolve-Path'.\entry-default-unsigned.hap'Get-FileHash$hap-Algorithm SHA256$unpack=Join-Path$env:TEMP('hap-abi-'+[guid]::NewGuid())New-Item-ItemType Directory-Path$unpack|Out-Nulltar-xf$hap-C$unpack
