GSYVideoPlayer RTMP 模块 16 KB 页面大小兼容构建与验证指南【免费下载链接】GSYVideoPlayerVideo players (IJKplayer, ExoPlayer, MediaPlayer), HTTPS, 16k page size, danmaku (bullet chat) support, external subtitles, support for filters, watermarks, and GIF screenshots, pre-roll and mid-roll ads, multiple simultaneous playback, basic seeking/dragging, volume and brightness adjustment, play-while-cache support项目地址: https://gitcode.com/GitHub_Trending/gs/GSYVideoPlayer导读本文基于仓库 third_party/rtmp-client/README_EN.md 展开系统讲解 GSYVideoPlayer 如何将 AntMedia RTMP 客户端重构为正式 Android Library 模块gsyVideoPlayer-rtmp并解决 Android 16 KB 页面大小page size适配难题。读者将掌握RTMP 原生库的构建工具链与 ABI 矩阵、max-page-size与common-page-size两个链接参数的底层区别、基于llvm-readelf的 ELF 静态校验方法以及发布前必须执行的真机协议回归流程。背景为什么 RTMP 模块需要一次“16 KB 改造”GSYVideoPlayer 的 RTMP 能力建立在 AndroidX Media3 的media3-datasource-rtmp之上但该组件不包含任何原生 RTMP 实现运行时依赖 AntMedia 的rtmp-client:3.2.0。这意味着真正的 RTMP 协议栈握手、AMF 编解码、FLV 封装、socket 传输全部在 JNI 原生库librtmp-jni.so中完成Java 侧只负责通过System.loadLibrary(rtmp-jni)加载并调用 native 方法见 RtmpClient.java。问题出在 Android 对应用原生库的加载约束上。Android 15API 35及以上要求应用与游戏支持16 KB 页面大小此前为 4 KB。在 16 KB 设备上任何PT_LOAD段对齐不是 16 KB0x4000的.so都会导致安装或加载失败。此前仓库采用的 JitPackv3.2.0.m2工作区方案只额外传入了max-page-size16384但其NDK r21e 编译产物仍保留了旧的PT_GNU_RELRO布局——RELRO 段结束地址未落在 16 KB 边界依然过不了 16 KB 设备的严格校验。为此自 2026-08-19 起RTMP 的 Java API 与四个 ABI 的原生库被收编为正式 Android Library ModulegsyVideoPlayer-rtmp纳入 settings.gradle 的模块体系与其他 GSY 模块共用同一版本号与发布流水线。模块定位与发布坐标模块的元信息定义在 gsyVideoPlayer-rtmp/gradle.propertiesPROJ_NAMEgsyvideoplayer-rtmp PROJ_ARTIFACTIDgsyvideoplayer-rtmp PROJ_DESCRIPTION16 KB-compatible RTMP client module for GSYVideoPlayer and AndroidX Media3双渠道发布坐标${PROJ_VERSION}跟随主项目版本号Maven Centralio.github.carguo:gsyvideoplayer-rtmp:${PROJ_VERSION}GitHub Packagescom.shuyu:gsyvideoplayer-rtmp:${PROJ_VERSION}在 doc/DEPENDENCIES_EN.md 中可以看到对应的实际依赖写法示例如版本13.2.1时implementation io.github.carguo:gsyvideoplayer-rtmp:13.2.1以及 GitHub Packages 渠道的等价坐标implementation com.shuyu:gsyvideoplayer-rtmp:13.2.1模块的核心技术基线如下项目取值说明上游仓库AntMediaLibRtmp-Client-for-Android协议实现来源固定提交pinned revision3af67842f517f9c6bbd22b961878624d0c44b713构建可复现的关键NDK22.1.7171670r22b与本地gsy-ijk工具链一致CMake3.22.1与cmake_minimum_required一致minSdk23见模块构建配置ABIarm64-v8a、x86_64、armeabi-v7a、x86四 ABI 全覆盖原生库产物位于 gsyVideoPlayer-rtmp/src/main/jniLibs 下每个 ABI 目录各含一份librtmp-jni.so。16 KB 适配的核心原理两个对齐参数Android 官方并不强制要求 NDK r28——r28 只是默认启用16 KB 对齐。本模块刻意保留 NDK r22b并在链接阶段显式传入两个参数见 CMakeLists.txttarget_link_options(rtmp-jni PRIVATE -Wl,-z,max-page-size16384 -Wl,-z,common-page-size16384 -Wl,-z,relro -Wl,-z,now )两个参数的作用截然不同理解它们的区别是读懂整个模块的关键max-page-size16384对齐 ELF 的PT_LOAD段。链接器会按 16 KB 对齐所有可加载段的内存与文件偏移这是满足 16 KB 设备加载器检查的必要条件common-page-size16384影响旧链接器legacy linker生成的PT_GNU_RELRO布局。r22b 的 GNUld不会自动感知 16 KB 页面只设置max-page-size时 RELRO 段结束地址仍可能停在 4 KB 边界上同时传入common-page-size后PT_GNU_RELRO的结束地址也会落在 16 KB 边界从而通过 Android 加载器的 RELRO 检查。配套的-Wl,-z,relro与-Wl,-z,now则分别启用 RELRO 重定位只读与立即绑定即BIND_NOW这两项是出厂安全基线也是下文静态校验清单的组成部分。值得一提的旁证仓库已对现有 r22b 构建的gsy-ijk各 64 位.so做过逐库隔离安装扫描确认它们能通过 Android 17 的 16 KB 检查因此本次改造无需重编 IJK工作量收敛在 RTMP 一个模块上。原生库构建源码组成与正确性补丁构建入口README 记录的模块重建命令为./third_party/rtmp-client/build-module.sh该脚本负责固定上游提交与工具链 → 应用已记录的原生 C 正确性补丁 → 重建四个 ABI → 更新 gsyVideoPlayer-rtmp/src/main 下的 Java API、许可证与.so→ 构建并校验模块 release AAR最终产物为gsyVideoPlayer-rtmp/build/outputs/aar/gsyVideoPlayer-rtmp-release.aar说明当前仓库快照中可直接检视与执行的脚本为 third_party/rtmp-client/verify-aar.shbuild-module.sh按 README 记录存在于构建流程中。CMake 源文件构成CMakeLists.txt 展示rtmp-jni共享库由上游src/main/cpp下的这些单元组成add_library(rtmp-jni SHARED ${RTMP_CPP_DIR}/rtmpmuxer.c ${RTMP_CPP_DIR}/librtmp-jni.c ${RTMP_CPP_DIR}/librtmp/amf.c ${RTMP_CPP_DIR}/librtmp/hashswf.c ${RTMP_CPP_DIR}/librtmp/log.c ${RTMP_CPP_DIR}/librtmp/parseurl.c ${RTMP_CPP_DIR}/librtmp/rtmp.c ${RTMP_CPP_DIR}/flvmuxer/xiecc_rtmp.c )其中librtmp/rtmp.c是协议核心librtmp/amf.c负责 Action Message Format 编解码flvmuxer/xiecc_rtmp.c承担 FLV 封装rtmpmuxer.c与librtmp-jni.c则是 JNI 桥接层。编译选项还包含NO_CRYPTO、_FORTIFY_SOURCE2与-fstack-protector-strong栈保护并做了-ffile-prefix-map/-fdebug-prefix-map以去除构建路径信息。原生 C 正确性补丁补丁 third_party/rtmp-client/patches/0001-native-c-correctness.patch 针对上游xiecc_rtmp.c做了两处修正补充#include string.h——原文件使用memcpy/memset却未显式包含头文件在部分编译环境下属于隐式声明属于潜在未定义行为为rtmp_close()补上return 0;——原函数末尾缺少显式返回语句返回值不确定会污染上层错误判断。这类“能编译但语义有瑕疵”的 C 代码正是模块在固定提交之外还要单独维护一份补丁的原因。Java API 与 JNI 稳定性模块向 Media3 暴露两个公共类RtmpClient.java面向拉流/推流的通用客户端。静态块中System.loadLibrary(rtmp-jni)核心方法为open(url, isPublishMode)、read(data, offset, size)、write(data[, offset, size])、pause(boolean)、isConnected()、close()并内置RtmpIOException错误码体系从-1的RTMP_READ_DONE到-27的RTMP_SANITY_FAIL涵盖 DNS 不可达、握手失败、连接丢失、AMF 编码失败、URL 解析错误等场景。同时支持setSendTimeout/setReceiveTimeout调整 socket 超时默认 10000 ms传非正数会重置回默认值RTMPMuxer.java面向推流封装提供open、writeVideoH.264 NAL、writeAudioAAC、read、close、write_flv_header、file_open/file_close本地录制 FLV等 native 方法。由于这些类被 Media3 直接引用、native 方法遵循显式 JNI 命名consumer-rules.pro 特别使用-keepclasseswithmembernames保留io.antmedia.rtmp_client.**的 native 方法名确保消费者开启 R8 优化后 JNI 符号解析依然稳定-keepclasseswithmembernames class io.antmedia.rtmp_client.** { native methods; }构建产物验证verify-aar.sh 全流程解读运行方式./third_party/rtmp-client/verify-aar.sh脚本默认校验gsyVideoPlayer-rtmp/build/outputs/aar/gsyVideoPlayer-rtmp-release.aar也可通过第一个参数传入自定义 AAR 路径。它从ANDROID_SDK_ROOT/ANDROID_HOME定位 NDK r22b22.1.7171670的llvm-readelf在 Darwin 与 Linux 主机上分别选用darwin-x86_64与linux-x86_64宿主工具链。四 ABI 的 ELF 静态检查清单脚本将 AAR 解包后对arm64-v8a、x86_64、armeabi-v7a、x86四份jni/abi/librtmp-jni.so逐一执行以下断言全部通过才输出PASSPT_LOAD Align 0x4000解析每个LOAD段的最后字段必须全部等于 16 KBGNU_RELRO结束地址 16 KB 对齐取PT_GNU_RELRO的vaddr memszmod 16384 0BIND_NOW动态段-dW中必须存在验证立即绑定stack canary符号表中必须出现__stack_chk_fail验证-fstack-protector-strong生效NDK r22b 身份.note段-n中必须匹配72 32 32 62即 r22b 的 ASCII 码防止工具链漂移。AAR 内容完整性检查ELF 检查之外脚本还验证打包内容classes.jar中必须包含io/antmedia/rtmp_client/RtmpClient.class与io/antmedia/rtmp_client/RTMPMuxer.class两个公共 API 类Media3 的消费入口必须包含META-INF/LICENSE-antmedia即固定版本上游许可证保证分发合规。全部通过后输出PASS module AAR: four ABIs, Media3 RTMP API classes and upstream license are packaged静态校验之外真机协议回归README 明确强调静态校验不能替代协议测试。ELF 对齐、BIND_NOW、栈保护这些检查只能证明“能装、能加载”不能证明“能播”。因此正式发布前必须在 16 KB 真机上完成一轮真实 RTMP 拉流、停止、重新拉流的回归循环在 16 KB 设备上安装集成gsyvideoplayer-rtmp的版本对真实 RTMP 地址执行拉流确认画面与音频正常停止播放后重新拉流同一地址与不同地址各一次确认连接重建与资源释放无异常可结合仓库的app模块中Rtmp16KbPageInstrumentedTestapp/src/androidTest的用例思路把上述流程固化为设备测试。总结gsyVideoPlayer-rtmp模块的价值在于三点其一用显式的max-page-sizecommon-page-size双参数让 NDK r22b 产物完整通过 16 KB 页面大小检查摆脱了对 NDK r28 的升级依赖其二通过固定上游提交、记录补丁、可复现的 CMake 配置与verify-aar.sh静态校验把“对齐、加固、工具链身份、API 完整性”全部固化为可自动检查的断言其三通过双渠道 Maven 坐标与统一版本号让 RTMP 能力与 GSYVideoPlayer 主工程保持同步发布。对任何需要自行维护 16 KB 兼容原生库的团队而言这套“构建脚本 ELF 校验 真机回归”的组合都是可直接复用的范本。【免费下载链接】GSYVideoPlayerVideo players (IJKplayer, ExoPlayer, MediaPlayer), HTTPS, 16k page size, danmaku (bullet chat) support, external subtitles, support for filters, watermarks, and GIF screenshots, pre-roll and mid-roll ads, multiple simultaneous playback, basic seeking/dragging, volume and brightness adjustment, play-while-cache support项目地址: https://gitcode.com/GitHub_Trending/gs/GSYVideoPlayer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GSYVideoPlayer RTMP 模块 16 KB 页面大小兼容构建与验证指南
GSYVideoPlayer RTMP 模块 16 KB 页面大小兼容构建与验证指南【免费下载链接】GSYVideoPlayerVideo players (IJKplayer, ExoPlayer, MediaPlayer), HTTPS, 16k page size, danmaku (bullet chat) support, external subtitles, support for filters, watermarks, and GIF screenshots, pre-roll and mid-roll ads, multiple simultaneous playback, basic seeking/dragging, volume and brightness adjustment, play-while-cache support项目地址: https://gitcode.com/GitHub_Trending/gs/GSYVideoPlayer导读本文基于仓库 third_party/rtmp-client/README_EN.md 展开系统讲解 GSYVideoPlayer 如何将 AntMedia RTMP 客户端重构为正式 Android Library 模块gsyVideoPlayer-rtmp并解决 Android 16 KB 页面大小page size适配难题。读者将掌握RTMP 原生库的构建工具链与 ABI 矩阵、max-page-size与common-page-size两个链接参数的底层区别、基于llvm-readelf的 ELF 静态校验方法以及发布前必须执行的真机协议回归流程。背景为什么 RTMP 模块需要一次“16 KB 改造”GSYVideoPlayer 的 RTMP 能力建立在 AndroidX Media3 的media3-datasource-rtmp之上但该组件不包含任何原生 RTMP 实现运行时依赖 AntMedia 的rtmp-client:3.2.0。这意味着真正的 RTMP 协议栈握手、AMF 编解码、FLV 封装、socket 传输全部在 JNI 原生库librtmp-jni.so中完成Java 侧只负责通过System.loadLibrary(rtmp-jni)加载并调用 native 方法见 RtmpClient.java。问题出在 Android 对应用原生库的加载约束上。Android 15API 35及以上要求应用与游戏支持16 KB 页面大小此前为 4 KB。在 16 KB 设备上任何PT_LOAD段对齐不是 16 KB0x4000的.so都会导致安装或加载失败。此前仓库采用的 JitPackv3.2.0.m2工作区方案只额外传入了max-page-size16384但其NDK r21e 编译产物仍保留了旧的PT_GNU_RELRO布局——RELRO 段结束地址未落在 16 KB 边界依然过不了 16 KB 设备的严格校验。为此自 2026-08-19 起RTMP 的 Java API 与四个 ABI 的原生库被收编为正式 Android Library ModulegsyVideoPlayer-rtmp纳入 settings.gradle 的模块体系与其他 GSY 模块共用同一版本号与发布流水线。模块定位与发布坐标模块的元信息定义在 gsyVideoPlayer-rtmp/gradle.propertiesPROJ_NAMEgsyvideoplayer-rtmp PROJ_ARTIFACTIDgsyvideoplayer-rtmp PROJ_DESCRIPTION16 KB-compatible RTMP client module for GSYVideoPlayer and AndroidX Media3双渠道发布坐标${PROJ_VERSION}跟随主项目版本号Maven Centralio.github.carguo:gsyvideoplayer-rtmp:${PROJ_VERSION}GitHub Packagescom.shuyu:gsyvideoplayer-rtmp:${PROJ_VERSION}在 doc/DEPENDENCIES_EN.md 中可以看到对应的实际依赖写法示例如版本13.2.1时implementation io.github.carguo:gsyvideoplayer-rtmp:13.2.1以及 GitHub Packages 渠道的等价坐标implementation com.shuyu:gsyvideoplayer-rtmp:13.2.1模块的核心技术基线如下项目取值说明上游仓库AntMediaLibRtmp-Client-for-Android协议实现来源固定提交pinned revision3af67842f517f9c6bbd22b961878624d0c44b713构建可复现的关键NDK22.1.7171670r22b与本地gsy-ijk工具链一致CMake3.22.1与cmake_minimum_required一致minSdk23见模块构建配置ABIarm64-v8a、x86_64、armeabi-v7a、x86四 ABI 全覆盖原生库产物位于 gsyVideoPlayer-rtmp/src/main/jniLibs 下每个 ABI 目录各含一份librtmp-jni.so。16 KB 适配的核心原理两个对齐参数Android 官方并不强制要求 NDK r28——r28 只是默认启用16 KB 对齐。本模块刻意保留 NDK r22b并在链接阶段显式传入两个参数见 CMakeLists.txttarget_link_options(rtmp-jni PRIVATE -Wl,-z,max-page-size16384 -Wl,-z,common-page-size16384 -Wl,-z,relro -Wl,-z,now )两个参数的作用截然不同理解它们的区别是读懂整个模块的关键max-page-size16384对齐 ELF 的PT_LOAD段。链接器会按 16 KB 对齐所有可加载段的内存与文件偏移这是满足 16 KB 设备加载器检查的必要条件common-page-size16384影响旧链接器legacy linker生成的PT_GNU_RELRO布局。r22b 的 GNUld不会自动感知 16 KB 页面只设置max-page-size时 RELRO 段结束地址仍可能停在 4 KB 边界上同时传入common-page-size后PT_GNU_RELRO的结束地址也会落在 16 KB 边界从而通过 Android 加载器的 RELRO 检查。配套的-Wl,-z,relro与-Wl,-z,now则分别启用 RELRO 重定位只读与立即绑定即BIND_NOW这两项是出厂安全基线也是下文静态校验清单的组成部分。值得一提的旁证仓库已对现有 r22b 构建的gsy-ijk各 64 位.so做过逐库隔离安装扫描确认它们能通过 Android 17 的 16 KB 检查因此本次改造无需重编 IJK工作量收敛在 RTMP 一个模块上。原生库构建源码组成与正确性补丁构建入口README 记录的模块重建命令为./third_party/rtmp-client/build-module.sh该脚本负责固定上游提交与工具链 → 应用已记录的原生 C 正确性补丁 → 重建四个 ABI → 更新 gsyVideoPlayer-rtmp/src/main 下的 Java API、许可证与.so→ 构建并校验模块 release AAR最终产物为gsyVideoPlayer-rtmp/build/outputs/aar/gsyVideoPlayer-rtmp-release.aar说明当前仓库快照中可直接检视与执行的脚本为 third_party/rtmp-client/verify-aar.shbuild-module.sh按 README 记录存在于构建流程中。CMake 源文件构成CMakeLists.txt 展示rtmp-jni共享库由上游src/main/cpp下的这些单元组成add_library(rtmp-jni SHARED ${RTMP_CPP_DIR}/rtmpmuxer.c ${RTMP_CPP_DIR}/librtmp-jni.c ${RTMP_CPP_DIR}/librtmp/amf.c ${RTMP_CPP_DIR}/librtmp/hashswf.c ${RTMP_CPP_DIR}/librtmp/log.c ${RTMP_CPP_DIR}/librtmp/parseurl.c ${RTMP_CPP_DIR}/librtmp/rtmp.c ${RTMP_CPP_DIR}/flvmuxer/xiecc_rtmp.c )其中librtmp/rtmp.c是协议核心librtmp/amf.c负责 Action Message Format 编解码flvmuxer/xiecc_rtmp.c承担 FLV 封装rtmpmuxer.c与librtmp-jni.c则是 JNI 桥接层。编译选项还包含NO_CRYPTO、_FORTIFY_SOURCE2与-fstack-protector-strong栈保护并做了-ffile-prefix-map/-fdebug-prefix-map以去除构建路径信息。原生 C 正确性补丁补丁 third_party/rtmp-client/patches/0001-native-c-correctness.patch 针对上游xiecc_rtmp.c做了两处修正补充#include string.h——原文件使用memcpy/memset却未显式包含头文件在部分编译环境下属于隐式声明属于潜在未定义行为为rtmp_close()补上return 0;——原函数末尾缺少显式返回语句返回值不确定会污染上层错误判断。这类“能编译但语义有瑕疵”的 C 代码正是模块在固定提交之外还要单独维护一份补丁的原因。Java API 与 JNI 稳定性模块向 Media3 暴露两个公共类RtmpClient.java面向拉流/推流的通用客户端。静态块中System.loadLibrary(rtmp-jni)核心方法为open(url, isPublishMode)、read(data, offset, size)、write(data[, offset, size])、pause(boolean)、isConnected()、close()并内置RtmpIOException错误码体系从-1的RTMP_READ_DONE到-27的RTMP_SANITY_FAIL涵盖 DNS 不可达、握手失败、连接丢失、AMF 编码失败、URL 解析错误等场景。同时支持setSendTimeout/setReceiveTimeout调整 socket 超时默认 10000 ms传非正数会重置回默认值RTMPMuxer.java面向推流封装提供open、writeVideoH.264 NAL、writeAudioAAC、read、close、write_flv_header、file_open/file_close本地录制 FLV等 native 方法。由于这些类被 Media3 直接引用、native 方法遵循显式 JNI 命名consumer-rules.pro 特别使用-keepclasseswithmembernames保留io.antmedia.rtmp_client.**的 native 方法名确保消费者开启 R8 优化后 JNI 符号解析依然稳定-keepclasseswithmembernames class io.antmedia.rtmp_client.** { native methods; }构建产物验证verify-aar.sh 全流程解读运行方式./third_party/rtmp-client/verify-aar.sh脚本默认校验gsyVideoPlayer-rtmp/build/outputs/aar/gsyVideoPlayer-rtmp-release.aar也可通过第一个参数传入自定义 AAR 路径。它从ANDROID_SDK_ROOT/ANDROID_HOME定位 NDK r22b22.1.7171670的llvm-readelf在 Darwin 与 Linux 主机上分别选用darwin-x86_64与linux-x86_64宿主工具链。四 ABI 的 ELF 静态检查清单脚本将 AAR 解包后对arm64-v8a、x86_64、armeabi-v7a、x86四份jni/abi/librtmp-jni.so逐一执行以下断言全部通过才输出PASSPT_LOAD Align 0x4000解析每个LOAD段的最后字段必须全部等于 16 KBGNU_RELRO结束地址 16 KB 对齐取PT_GNU_RELRO的vaddr memszmod 16384 0BIND_NOW动态段-dW中必须存在验证立即绑定stack canary符号表中必须出现__stack_chk_fail验证-fstack-protector-strong生效NDK r22b 身份.note段-n中必须匹配72 32 32 62即 r22b 的 ASCII 码防止工具链漂移。AAR 内容完整性检查ELF 检查之外脚本还验证打包内容classes.jar中必须包含io/antmedia/rtmp_client/RtmpClient.class与io/antmedia/rtmp_client/RTMPMuxer.class两个公共 API 类Media3 的消费入口必须包含META-INF/LICENSE-antmedia即固定版本上游许可证保证分发合规。全部通过后输出PASS module AAR: four ABIs, Media3 RTMP API classes and upstream license are packaged静态校验之外真机协议回归README 明确强调静态校验不能替代协议测试。ELF 对齐、BIND_NOW、栈保护这些检查只能证明“能装、能加载”不能证明“能播”。因此正式发布前必须在 16 KB 真机上完成一轮真实 RTMP 拉流、停止、重新拉流的回归循环在 16 KB 设备上安装集成gsyvideoplayer-rtmp的版本对真实 RTMP 地址执行拉流确认画面与音频正常停止播放后重新拉流同一地址与不同地址各一次确认连接重建与资源释放无异常可结合仓库的app模块中Rtmp16KbPageInstrumentedTestapp/src/androidTest的用例思路把上述流程固化为设备测试。总结gsyVideoPlayer-rtmp模块的价值在于三点其一用显式的max-page-sizecommon-page-size双参数让 NDK r22b 产物完整通过 16 KB 页面大小检查摆脱了对 NDK r28 的升级依赖其二通过固定上游提交、记录补丁、可复现的 CMake 配置与verify-aar.sh静态校验把“对齐、加固、工具链身份、API 完整性”全部固化为可自动检查的断言其三通过双渠道 Maven 坐标与统一版本号让 RTMP 能力与 GSYVideoPlayer 主工程保持同步发布。对任何需要自行维护 16 KB 兼容原生库的团队而言这套“构建脚本 ELF 校验 真机回归”的组合都是可直接复用的范本。【免费下载链接】GSYVideoPlayerVideo players (IJKplayer, ExoPlayer, MediaPlayer), HTTPS, 16k page size, danmaku (bullet chat) support, external subtitles, support for filters, watermarks, and GIF screenshots, pre-roll and mid-roll ads, multiple simultaneous playback, basic seeking/dragging, volume and brightness adjustment, play-while-cache support项目地址: https://gitcode.com/GitHub_Trending/gs/GSYVideoPlayer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考