JNA Android 开发环境搭建与交叉编译构建指南

系统编程后端【免费下载链接】jnaJava Native Access项目地址https://gitcode.com/gh_mirrors/jn/jna点击查看免费下载导读本文基于 JNA 仓库中的 www/AndroidDevelopmentEnvironment.md 整理扩充完整讲解如何在 Linux 主机上借助 Android NDK 为 ARM、x86、MIPS 等架构交叉编译 JNA 的核心原生库libjnidispatch.so并说明如何将产物dist/jna.jar、dist/jna-platform.jar正确接入 Android 应用包括 Android Studio/Gradle、android-maven-plugin 与 Eclipse 插件等不同工程形态。读完本文你将掌握 JNA Android 环境的全部前置条件、ant -Dos.prefixandroid-*系列构建命令、NDK 工具链与NDK_PLATFORM的配置语义以及构建脚本native/Makefile、native/build.xml背后的源码级工作机制能够独立完成一次完整的 Android 目标构建与部署。为什么 JNA 需要单独的 Android 构建环境JNA 的核心是一个名为jnidispatch的 JNI 原生库其 C 源码位于仓库 native/ 目录主要文件包括dispatch.c、callback.c、dll-callback.c。与普通桌面平台不同Android 的 APK 运行在 Dalvik/ART 虚拟机上原生库必须被打包进 APK 并通过 APK 的lib/abi/目录加载。因此主机平台如 Linux x86-64无法直接运行或加载 Android 的原生库测试必须在目标平台真机或模拟器上执行而不能在构建主机上执行Android 原生库的 ABI如 armeabi、armeabi-v7a、arm64-v8a、x86、x86_64、mips、mips64与桌面平台的 ELF 结构不同必须使用 Android NDK 提供的交叉编译工具链来构建从源码结构看JNA 在运行时通过 Platform.java 检测 JVM 是否为 Androidjava.vm.name包含dalvik并自动设置jna.nounpacktrue因为 Android 上原生库必须与 APK 一起打包见 Platform.java。一、环境准备SDK/NDK、PATH 与 NDK_PLATFORM按照 www/AndroidDevelopmentEnvironment.md 的说明Android 构建需要满足以下前置条件1. 安装 Android SDK 与 NDK下载并安装 Android NDK仓库文档与 native/Makefile 中记录的版本示例为 NDK r10e/r12b平台目录为platforms/android-21实际使用请选择与目标 Android 版本匹配的 NDK并相应调整下面的路径NDK 提供交叉编译所需的toolchains/target-4.9/prebuilt/linux-x86_64/bin/工具链以及platforms/android-api/arch-abi/下的系统头文件与库。2. 将 NDK 工具链加入 PATHnative/Makefile中 Android 分支会直接以$(PREFIX)gcc、$(PREFIX)ranlib、$(PREFIX)strip等形式调用编译器与工具因此这些工具必须出现在PATH中。以 NDK r12b 为例完整的环境配置如下原文示例export NDK_PLATFORM/home/matthias/bin/android-ndk-r12b/platforms/android-21 export PATH$NDK_PLATFORM/../../toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/:$PATH export PATH$NDK_PLATFORM/../../toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/:$PATH export PATH$NDK_PLATFORM/../../toolchains/mips64el-linux-android-4.9/prebuilt/linux-x86_64/bin/:$PATH export PATH$NDK_PLATFORM/../../toolchains/mipsel-linux-android-4.9/prebuilt/linux-x86_64/bin/:$PATH export PATH$NDK_PLATFORM/../../toolchains/x86-4.9/prebuilt/linux-x86_64/bin/:$PATH export PATH$NDK_PLATFORM/../../toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/:$PATH注意上述工具链前缀与 JNA 的架构命名一一对应见下表依据 native/MakefileJNA 架构os.prefix工具链前缀PREFIX链接目标 HOSTandroid-armarm-linux-androideabi-arm-linux-eabiandroid-armv7arm-linux-androideabi-arm-linux-eabiandroid-aarch64aarch64-linux-android-aarch64-linux-androidandroid-x86i686-linux-android-i686-linux-androidandroid-x86-64x86_64-linux-android-x86_64-linux-androidandroid-mipsmipsel-linux-android-mipsel-linux-androidandroid-mips64mips64el-linux-android-mips64el-linux-android3. 设置 NDK_PLATFORM 环境变量NDK_PLATFORM指向 NDK 中某个platforms/android-api目录。native/Makefile通过它计算SYSROOT$(NDK_PLATFORM)/arch-$(AARCH)其中AARCH由架构推导arm→arm、armv7→arm、aarch64→arm64、x86→x86、x86-64→x86_64、mips→mips、mips64→mips64C 头文件搜索路径-I$(NDK_PLATFORM)/arch-$(AARCH)/usr/include链接库搜索路径-L$(NDK_PLATFORM)/arch-$(AARCH)$(ALIBDIR)/32 位为/usr/libaarch64/x86-64/mips64 为/usr/lib64并以-nostdlib方式显式链接-lgcc -lc -ldl -lm。若未显式设置native/Makefile会使用默认值NDK?/Developer/Applications/android-ndk-r10e、NDK_PLATFORM?$(NDK)/platforms/android-21。因此推荐通过环境变量显式指定避免默认路径与本地安装不符。二、交叉编译构建ant -Dos.prefix 全架构演练环境变量配置好后即可在仓库根目录执行构建。单架构构建命令为原文核心命令ant -Dos.prefixandroid-arm dist-Dos.prefix是 JNA 构建系统识别目标平台的关键参数。native/build.xml中会将android-*前缀映射为make.OSOSandroid并根据后缀把ARCH设置为arm、armv7、aarch64、x86-64、x86、mips、mips64见 native/build.xml随后调用native/Makefile完成libjnidispatch.so与测试库的编译再把产物打包成${os.prefix}.jar例如android-arm.jar最终由dist目标统一复制到dist/目录见 build.xml。原文示例为一次性构建全部 7 个 Android 架构ant -Dos.prefixandroid-aarch64 ant -Dos.prefixandroid-armv7 ant -Dos.prefixandroid-arm ant -Dos.prefixandroid-mips64 ant -Dos.prefixandroid-mips ant -Dos.prefixandroid-x86-64 ant -Dos.prefixandroid-x86逐个执行以上命令或按需只构建应用所需架构即可生成与仓库 lib/native/ 下预置产物同名的一系列android-*.jar。各架构的编译参数差异源码级native/Makefile的 Android 分支针对不同架构设置了不同的编译选项native/Makefileandroid-arm-mthumb-interwork -marcharmv5te -mtunexscale -msoft-float -fstack-protector兼容老一代 ARM 设备android-armv7-marcharmv7-a -mfloat-abisoftfp -mfpuvfpv3-d16 -Wl,--fix-cortex-a8针对 Cortex-A8 的硬件缺陷做链接修正android-aarch6464 位 ARM 目标AARCHarm64库路径为/usr/lib64android-x86-marchi686android-x86-64-m64。所有 Android 架构统一启用-fpic -ffunction-sections -funwind-tables -fno-short-enums并定义-DFFI_STATIC_BUILD -DNO_JAWT -DNO_WEAK_GLOBALS -DFFI_MMAP_EXEC_WRIT1 -DFFI_MMAP_EXEC_SELINUX0 -Dmalloc_getpagesizegetpagesize()链接参数包含-Wl,-shared,-Bsymbolic -Wl,--build-idsha1 -Wl,-z,max-page-size16384 -Wl,-z,common-page-size16384。libffi 的静态编译JNA 的闭包Closure机制依赖 libffi。Android 分支中native/Makefile会以--hostHOST交叉配置仓库内置的 native/libffi 源码树并使用--enable-static --disable-shared --with-picyes生成静态 libffi再与dispatch.o、callback.o一起链接进libjnidispatch.so。这正是 Android 上 JNA 可以独立携带全部依赖、无需系统预装 libffi 的原因。三、测试必须在目标平台上运行原文档明确指出Tests must be run on the target platform, not the build platform.这是因为交叉编译出的libjnidispatch.so面向 Android ABI无法在桌面 JVM 中加载。仓库为此提供了android-test-setup目标build.xml用于将测试配置到 Android 模拟器/真机环境通过shared目录作为设备存储卡挂载点。结合源码可推断典型流程为在主机上执行ant android-test-setup完成测试类编译与准备将测试 jar、jnidispatch.so、testlib.so等推送/挂载到模拟器或真机可访问的存储目录在设备端运行 JUnit 测试测试结果再回传主机分析。与桌面端ant testfork JVM 在本机跑不同Android 场景必须依赖设备侧执行这也是 JNA 工程对 Android 测试的基本约束。四、将构建产物集成进 Android 应用1. 基础用法jna.jar 与 jna-platform.jar构建完成后将dist/jna.jar核心库和/或dist/jna-platform.jar平台封装库源码位于 contrib/platform加入应用即可。dist目标会把 lib/native/ 下各架构的android-*.jar内含对应 ABI 的libjnidispatch.so一并复制到dist/。JNA 运行时通过 Platform.java 计算原生库资源前缀Android 上arch为 arm 系时统一归一为arm最终资源前缀形如android-arm、android-x86等从而从 jar 内com/sun/jna/prefix/libjnidispatch.so路径加载库。2. Android Studio / Gradle直接使用 AAR仓库aar目标build.xml会把各架构的原生库按标准 ABI 目录打进 AAR 包JNA 产物AAR 内 jni 路径ABIandroid-aarch64.jarjni/arm64-v8aandroid-arm.jarjni/armeabiandroid-armv7.jarjni/armeabi-v7aandroid-mips.jarjni/mipsandroid-mips64.jarjni/mips64android-x86-64.jarjni/x86_64android-x86.jarjni/x86AAR 还包含classes.jar、AndroidManifest.xmlpackage 为com.sun.jna并带有由 ant 工具类 CalcAndroidVersion.java 计算的versionCode以及构建所需的占位R.txt与字符串资源。将 AAR 作为依赖后Gradle 会自动为各 ABI 抽取对应原生库无需手动干预。CalcAndroidVersion的版本号计算规则为见 CalcAndroidVersion.javaandroidVersion 1000000 * major 10000 * minor 100 * revision (release 时为 99)3. android-maven-pluginjna.jar 可直接使用原文档说明如果使用 android-maven-pluginjna.jar可以原样使用原生库会被自动复制进项目。其依据是 JNA 将原生库以com/sun/jna/os.prefix/libjnidispatch.so形式内嵌在 jar 的 classpath 资源中Maven 的 Android 打包流程会把 jar 内的.so资源抽取并归入 APK 的lib/abi/目录。4. Google Eclipse 插件需要手动处理使用 Google 的 Eclipse Android 插件时原生库不会自动归类到 APK 的 ABI 目录。原文档明确要求必须手动从jna.jar的lib/armeabi中移除libjnidispatch.so并将其放入你项目工程的libs/armeabi目录。即在 Eclipse 工程中jna.jar内的.so需要被解压出来放到工程的libs/armeabi/对应的 ABI 目录下构建时由插件将其打进 APK。这一约束的根本原因与前述相同Android 只从 APK 的lib/abi/目录加载原生库。五、Android 平台运行时行为小结构建与部署之外JNA 在 Android 上还有一些与桌面不同的运行时行为可以从 Platform.java 中得到印证平台识别通过os.name以Linux开头且java.vm.name含dalvik判定为 AndroidANDROID8禁用解包Android 上自动设置jna.nounpacktrue原生库随 APK 分发不再在运行时解包到临时目录无 AWTHAS_AWT在 Android 上为false相关桌面特性不可用C 库名Android 与 Linux 一致使用c/mWindows 才使用msvcrt/msvcrt与 CE 的coredll。结语从环境变量配置、NDK 工具链 PATH 设置到ant -Dos.prefixandroid-*逐架构交叉编译再到dist/jna.jar、dist/jna-platform.jar、AAR 以及 Maven/Eclipse 工程的不同集成方式JNA 的 Android 开发链路清晰且完全由仓库的 native/Makefile、native/build.xml、build.xml 与 Platform.java 支撑。掌握本文所述方法后你既能独立完成多 ABI 的 JNA Android 构建也能理解各集成方式背后的打包与加载机制从而在实际项目中避免“原生库未打进 APK”或“ABI 目录不匹配”等典型问题。更多相关指引可继续查阅仓库 README.md 中的 Android 开发环境说明。赞分享系统编程后端【免费下载链接】jnaJava Native Access项目地址https://gitcode.com/gh_mirrors/jn/jna点击查看免费下载相关推荐JNA Windows 开发环境搭建与 Native 库构建完全指南MSVC、Cygwin 与交叉编译实战JNA Windows 开发环境搭建与 Native 库构建完全指南MSVC、Cygwin 与交叉编译实战 导读本文是 JNAJava Native Ac系统编程后端JNA 在 macOS 上的开发环境搭建与本地/交叉编译实战指南JNA 在 macOS 上的开发环境搭建与本地/交叉编译实战指南 JNAJava Native Access通过一个薄薄的 JNI 桥接层让 Java 程序系统编程后端5种实用场景解析如何用JavaScript汉字拼音库提升开发效率5种实用场景解析如何用JavaScript汉字拼音库提升开发效率 在中文应用开发中汉字拼音转换是一个常见但复杂的需求。无论是实现搜索功能、内容排序还是构建CLINLP上一篇Headscale-WebUI常见问题解答解决部署与使用中的10个痛点下一篇StyleX 版本演进深度解析从 0.11 到 0.19 的核心 API、编译优化与工具链变迁创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考