lmlm：Hey v1.3.5 升级到 libXray v26.7.28，并说明此前回退的原因
在支持 libXray v26.7.28 的问题讨论中，作者更新：v1.3.5 已升级到 libXray v26.7.28（工具链换成 star4277/ohos-go v1.26.5）。此前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV（日志停在 VPN created，没有 Xray started）；根因是自身桥接代码：新版 libXray 加载后又调用 setenv 设置资源目录，而 Go 的 c-shared 库在 dlopen 返回后会另起线程异步初始化运行时，此时改环境变量会与初始化线程竞争并读到野指针崩溃，与工具链本身和 TLS 无关。修法是把设置资源目录的时机挪到首次加载库之前，已在真机反复验证。sing-box 同步用新工具链重编，版本仍是 1.12.25，1.13.18 因 libbox API 大改暂缓。
作者原文@popsiclelmlm更新：v1.3.5 已升级到 libXray v26.7.28（工具链换成 star4277/ohos-go v1.26.5）。
之前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV（日志停在
VPN created，没有Xray started）。定位下来根因是我们自己桥接代码的问题：新版 libXray 加载后，代码里紧接着又调用了setenv设置资源目录，而 Go 的 c-shared 库在 dlopen 返回后会另起线程异步初始化运行时，这时候再改环境变量会和初始化线程产生竞争，导致其读到野指针崩溃。和工具链本身、TLS 都没有关系——这也印证了你和 @huopingzi 反馈的「TUN fd → setTunFd()」路径本身是可行的。修法是把设置资源目录的时机挪到首次加载库之前，真机上反复验证过（连续多次连接均正常，VLESS/REALITY 通，sing-box 切换到新核心跑 VLESS 也验证了数据面有真实吞吐）。sing-box 同步用新工具链重编了（版本仍是 1.12.25，1.13.18 因 libbox API 大改暂缓）。
感谢你和 @huopingzi 提供的工具链信息和调用方式参考，这个 issue 先关闭，后续如果要跟进原生 TUN 直连（去掉 tun2socks 这一跳）或 sing-box 1.13.18 会再开新 issue 跟踪。