remote

wangyukun/remote

Fork 0

Commit Graph

Author	SHA1	Message	Date
郑博文	44767ed370	feat(android-ffi): viewer-core 的 JNI 薄层，arm64 交叉编译通过（QUIC 栈上手机的第一道关）方案变更说明（A2 落地修正）：原裁决选 UniFFI，但实查 Maven Central 与 maven.mozilla.org 均无 uniffi Kotlin 运行时构件（404），自编译发布成本超过收益。改为裸 JNI：阶段 0（真机）已验证该链路，接口刻意保持窄（连接/取帧/发输入/销毁），将来若引入 UniFFI 只替换本层。线程与锁纪律（决定接口形态）： - nativeNextFrame 等帧期间不持会话锁（clone Arc<Session> 后即释放），桌面静止 500ms 帧间隔不会卡住 UI 线程的输入调用 - destroy 前必须先停解码线程，Kotlin 侧顺序纪律保证（已登记风险清单） - 句柄 = Box 裸指针（永不为 0），destroy 后置 0 帧返回约定：byte[] = [keyframe 标志 1][seq 8][ts 8][w 4][h 4][Annex-B payload]，定长 25 字节头，Kotlin 切片零 JNI 往返。 viewer-core 适配：Session.frames 改 Arc<tokio Mutex>，next_frame 取 &self，使解码线程与输入线程可并发借用同一 Session。验证： - 桌面 cargo build -p android-ffi 零警告 - cargo ndk -t arm64-v8a --release：quinn/ring/rustls 交叉编译全部通过（消除阶段 1 最大未知：QUIC 栈能否编到 Android） - libandroidffi.so 4.2MB，10 个 Java_com_verify_remote_RustBridge_* 符号导出正确	2026-10-29 18:27:34 +08:00
郑博文	34df7b070b	feat(viewer-core): 新增安卓主控的连接/协议/收帧层（阶段 1 桌面验证通过）定位（2026-10-29 方案裁决 A1-A4）：纯 Rust、平台无关，只做「怎么连 + 收发什么」——QUIC 会话、协议 v2 认证、视频帧流、输入上行、Ping/Pong、KeyFrameReq。解码/渲染/触摸全在 Kotlin 侧，本 crate 不碰像素、不依赖 openh264（dev-dependency 仅验证工具用）。设计要点 - PeerTarget::Direct 是唯一的连接形态；不做中继、不定义 Relay 变体（《多平台架构设计》§6.1 裁决）。将来设备码+打洞只换 connect() 内部。 - 帧经容量 2 的 mpsc 交付，不丢帧：跳帧决策属于看得到解码器状态的消费方（Kotlin），Rust 层丢帧会重演 R-3 教训（跳帧断参考链）。 - insecure_skip_verify=false 时明确报错而非静默放行——证书钉扎登记在方案阶段 4，安全红线不允许默默降级。 - 双流结构与桌面 viewer 一致（流1 认证+视频，流2 输入+控制），入会即请求 IDR。验证（headless，桌面→桌面 127.0.0.1） - 单测 3 passed（帧契约、默认配置、strict-verify 显式报错） - examples/headless_check：300 帧，seq 违例 0、keyframe 标志不符 0、解码成功 300/300、RTT 路径工作（RTT=1ms 出现） - 全 workspace 回归：common 20 passed，构建全绿	2026-10-29 18:14:27 +08:00

Author

SHA1

Message

Date

郑博文

44767ed370

feat(android-ffi): viewer-core 的 JNI 薄层，arm64 交叉编译通过（QUIC 栈上手机的第一道关）

方案变更说明（A2 落地修正）：原裁决选 UniFFI，但实查 Maven Central 与
maven.mozilla.org 均无 uniffi Kotlin 运行时构件（404），自编译发布成本超过收益。
改为裸 JNI：阶段 0（真机）已验证该链路，接口刻意保持窄（连接/取帧/发输入/销毁），
将来若引入 UniFFI 只替换本层。

线程与锁纪律（决定接口形态）：
- nativeNextFrame 等帧期间不持会话锁（clone Arc<Session> 后即释放），
  桌面静止 500ms 帧间隔不会卡住 UI 线程的输入调用
- destroy 前必须先停解码线程，Kotlin 侧顺序纪律保证（已登记风险清单）
- 句柄 = Box 裸指针（永不为 0），destroy 后置 0

帧返回约定：byte[] = [keyframe 标志 1][seq 8][ts 8][w 4][h 4][Annex-B payload]，
定长 25 字节头，Kotlin 切片零 JNI 往返。

viewer-core 适配：Session.frames 改 Arc<tokio Mutex>，next_frame 取 &self，
使解码线程与输入线程可并发借用同一 Session。

验证：
- 桌面 cargo build -p android-ffi 零警告
- cargo ndk -t arm64-v8a --release：quinn/ring/rustls 交叉编译全部通过
  （消除阶段 1 最大未知：QUIC 栈能否编到 Android）
- libandroidffi.so 4.2MB，10 个 Java_com_verify_remote_RustBridge_* 符号导出正确

2026-10-29 18:27:34 +08:00

郑博文

34df7b070b

feat(viewer-core): 新增安卓主控的连接/协议/收帧层（阶段 1 桌面验证通过）

定位（2026-10-29 方案裁决 A1-A4）：
纯 Rust、平台无关，只做「怎么连 + 收发什么」——QUIC 会话、协议 v2 认证、
视频帧流、输入上行、Ping/Pong、KeyFrameReq。解码/渲染/触摸全在 Kotlin 侧，
本 crate 不碰像素、不依赖 openh264（dev-dependency 仅验证工具用）。

设计要点
- PeerTarget::Direct 是唯一的连接形态；不做中继、不定义 Relay 变体
  （《多平台架构设计》§6.1 裁决）。将来设备码+打洞只换 connect() 内部。
- 帧经容量 2 的 mpsc 交付，**不丢帧**：跳帧决策属于看得到解码器状态的消费方
  （Kotlin），Rust 层丢帧会重演 R-3 教训（跳帧断参考链）。
- insecure_skip_verify=false 时明确报错而非静默放行——证书钉扎登记在方案
  阶段 4，安全红线不允许默默降级。
- 双流结构与桌面 viewer 一致（流1 认证+视频，流2 输入+控制），入会即请求 IDR。

验证（headless，桌面→桌面 127.0.0.1）
- 单测 3 passed（帧契约、默认配置、strict-verify 显式报错）
- examples/headless_check：300 帧，seq 违例 0、keyframe 标志不符 0、
  解码成功 300/300、RTT 路径工作（RTT=1ms 出现）
- 全 workspace 回归：common 20 passed，构建全绿

2026-10-29 18:14:27 +08:00

2 Commits