zijunchiang/opendance-android
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity
30 Commits 2 Branches 4 Tags
31b6ddd0fa96ca5a52c58e96b5ff0c4196953860
Commit Graph
30 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
zijunchiang 31b6ddd0fa test(packaging): APK 产物版本元数据校验（T-AND-013）+ 修 die 在定义前被调用 
文档 §11.2 要求「版本号单一来源 + 可核对」。本仓库原有校验只覆盖**构建配置**
（gradle verifyReleaseVersion 比 versionName ↔ project.yaml）。但版本号真正被
系统与用户看到的地方是 **APK 的 AndroidManifest**：安装界面、应用信息页、
dumpsys package 读的都是它。构建缓存、复用旧 APK、打包时拷错文件都会造成
「配置全对、产物是旧版」——配置层校验抓不到。

这不是假设：同批工作里 Windows 端 v0.2.1 的发布包就是配置文件全一致、
exe 属性页显示 0.1.0（opendance-windows/tasks/017-pe-version.md）。

新增：
  * build/check_apk_version.py：直接解析 APK 内 AndroidManifest.xml（二进制 AXML）
    的 versionName / versionCode。只依赖 Python 标准库，不需要 Android SDK/aapt2。
    AXML 解析：顶层 ResChunk_header → 字符串池（UTF-8 与 UTF-16 都要处理）→
    START_ELEMENT；属性名本身就在字符串池里，按文本匹配即可，无需资源映射表；
  * build/check-apk-version.sh：薄包装，期望版本缺省取 project.yaml，
    并校验 versionCode == 10000*主 + 100*次 + 修订（§11.1）；
  * build/verify.sh 步骤 3/3 新增「版本元数据」计分项（原先只 aapt2 打印一行）；
  * build/package-release.sh 打包前校验源 APK，不一致即 die。

交叉验证（与 aapt2 dump badging 逐项一致）：
  v0.1.0 APK -> versionCode 1 / versionName 0.1.0
  v0.2.0 APK -> versionCode 200 / versionName 0.2.0
  app/build/outputs/apk/release/app-release.apk -> 同 v0.2.0
反向验证（用真实旧产物当负例）：
  bash build/check-apk-version.sh dist-release/opendance-android-v0.1.0/app-release.apk
    ✗ versionName 是 '0.1.0'，期望 '0.2.0'
    ✗ versionCode 是 1，期望 200
    退出码 1

顺带修复：build/package-release.sh 第 31/33 行用 die 报版本不一致，但 die()
到第 40 行才定义。命中该分支时输出的是
    build/package-release.sh: 行 31: die: 未找到命令   （退出码 127）
脚本确实中止了，但用户完全看不出真实原因。现把 log()/die() 移到首次使用之前：
    [error] 版本号不一致：参数/versionName=9.9.9，project.yaml=0.2.0  （退出码 1）

未新发版本：APK 内容与 v0.2.0 完全一致（产物侧校验证明其 versionName/versionCode
本就正确），本次改动只涉及构建/校验脚本与文档，故不为它提版本号；
README.txt 的新增自检项会随下一次 Android 发布进入发布包。
 2026-09-17 04:29:52 +08:00
zijunchiang ad18427928 docs: 补齐部署必需的 Gitea 域名与属主（不再脱敏成占位符） 
域名与仓库属主属于「部署必需且非隐私」的信息，此前写成 `<Gitea 地址>/<owner>`
会让读者无法照抄 clone 命令。补成真实值：gitea.kasugano.cn / zijunchiang
（口令与访问令牌仍为占位符）。README.md 的 clone 地址与跨仓库链接、
README.txt 的 clone 地址均已更新。
 2026-09-17 03:07:25 +08:00
zijunchiang 7ebbaef631 feat(net,pose): 连接状态机与保活对齐 + MediaPipe 崩溃修复（T-AND-010/011/012） 
契约 websocket-keypoints 0.1.0 -> 0.2.0（向后兼容，子协议名与帧 version 不变；
先在 opendance-web 修改并提升版本，再同步三端快照）。

T-AND-011：连接状态异常、频繁重连（查实 3 个根因）
1. 保活用错了层：Windows 端有 5s 静默超时（只看应用层收到的帧），而本端只有
   OkHttp 的协议层 ping —— 它由底层库自动应答、**不暴露给应用层**，根本不能续命。
   画面里没人时 5s 必被踢、再重连，循环往复。
   - 契约新增 §1.1（welcome/config 声明 silentTimeoutMs 与 heartbeatIntervalMs，
     且心跳必须 < 静默超时的一半）与 §3.6（应用层 ping/pong）；
   - Windows 端超时 5s -> 15s、期望心跳 5s，并在 welcome/config 中下发；
   - 本端按声明发 ping，连续 3 个周期无 pong 才判定链路已死并主动重连。
2. 不该重连时也重连：契约新增 §7 关闭码策略，1000/1001/1002 与主动停止一律不重连。
3. frame_id 恒为 0：PoseDetector.detect() 算了 safeTimestamp 却忘了写回
   lastTimestampMs，接收端的丢包检测因此完全失效。已修。

其他对齐：
- 契约新增 §8 连接状态机 idle -> resolving -> connecting -> handshaking ->
  streaming -> degraded -> reconnecting -> stopped，两端同名便于对照日志；
  resolving 只对主机名生效，局域网直连 IP 直接进 connecting；
- 退避与抖动按 §7.1 冻结：0.5s -> 1 -> 2 -> 4 -> 8 -> 15s 封顶 + ±20% 抖动；
- 契约新增 §5 设备去重：hello 携带稳定 deviceId（ANDROID_ID 的 SHA-256 前 16 位，
  不含硬件序列号），Windows 端据此去重、旧连接以 1000 关闭；
- 新增 util/ConnectionLog（环形缓冲，最近 500 条：状态迁移 / close code /
  子协议协商 / 首帧时间 / 保活参数），运行页可一键导出（FileProvider）。

T-AND-012：MediaPipe 初始化崩溃（ExceptionInInitializerError: null）
- 诊断：新增 pose/PoseDiagnostics 展开 cause 链取真因（通常 UnsatisfiedLinkError）、
  区分 native 加载失败、比对设备 ABI 与 APK 内 ABI 并给出可执行结论；
- native 解压：packaging { jniLibs { useLegacyPackaging = true } }（AGP 8 release
  默认 extractNativeLibs=false，MediaPipe JNI 对它不兼容）；
- R8：补 -keepclasseswithmembernames 的 native 方法保留规则，并 -printseeds 输出
  seeds 供发布前核对（实测保留 20169 条 MediaPipe 条目）；
- 构建期新增 verifyReleaseAbi：release ABI 必须恰为 arm64-v8a/armeabi-v7a、
  每个 ABI 下必须有 MediaPipe native 库、模型资源必须存在；
- 未换库：诊断指向集成配置而非 MediaPipe 本身，保留 33 点契约零成本。

T-AND-010：版本号展示与单一来源
- 版本唯一来源 versionName（= project.yaml 的 version）；versionCode 按
  10000*主+100*次+修订 递增（0.2.0 -> 200）；
- 契约版本改为构建期解析 contracts/VERSION 后注入 BuildConfig（六项各自独立
  递增，原先的单个 CONTRACT_VERSION 常量已失真）；界面不再手写任何版本号；
- 新增 checkReleaseConsistency 并挂到 preBuild，三者不一致直接 BUILD FAILED。

README/DSH/THIRD_PARTY/tasks 同步更新（含「导出连接日志」「保活参数」
「最近断开原因」等新增可观察项与排查表）。

测试：56 项全部通过（新增 ReconnectPolicyTest 11 项、PoseDiagnosticsTest 12 项）；
build/verify.sh 全通过（单元测试 -> 构建 -> 签名/ABI/native/seeds/dex 校验）
v0.2.0 		2026-09-17 01:10:06 +08:00
opendance 392f4544f4 chore(contracts): 同步 0.5.0/0.7.0/0.4.0（场景管理路由与 Scene 模型） 2026-09-17 00:27:08 +08:00
opendance b96a8b0998 chore(contracts): 同步 data-models 0.6.0（Motion 增 thumbnailUrl） 2026-09-17 00:21:00 +08:00
opendance 30883508a8 chore(contracts): 同步契约 skeleton-topology 0.2.0（内部动作标准与骨骼重绑定） 2026-09-17 00:10:07 +08:00
opendance 3f9c4c7658 chore(contracts): 同步契约 0.5.0（模型一律转 VRM，Model 增 usable/unusableReason） 
来自 opendance-web 的契约变更，按 DSH 文档 7.2「先改 Web 端 contracts/ 再同步另两端」：
- model-formats.md -> 0.5.0：主力格式 VRM + humanoid 门槛与回退
- data-models.md -> 0.5.0：Model 增 usable / unusableReason
- VERSION 同步
 2026-09-17 00:05:02 +08:00
opendance 68783c37b6 docs: 消除 Gitea 模棱两可 Unicode 告警（全角标点紧邻 ASCII 时改为半角） 
依据 Gitea v1.27.3 modules/charset/escape_stream.go 的判定规则
（analyzeDetectResults：仅当左右相邻字符都不是非 ASCII 时才标记，
且 _common 表恒定生效），把说明文档中会被标记的全角标点
（，：；？！（） 等）改为半角，并保证成对括号宽度一致。
中文语境中的全角标点（左右均为中文）保持原样，不动代码与契约语义。
 2026-09-15 21:45:51 +08:00
zijunchiang ab88231ea0 docs: 全角 ｜ ／ ？ 改 ASCII（Gitea 混淆字符检测的剩余触发项） 2026-09-15 21:36:41 +08:00
zijunchiang 91e56135fc docs: 其余易混淆字符（x/>=/<=/~/OK 取代 × − ≥ ≤ ≈ ✓） 2026-09-15 21:34:50 +08:00
zijunchiang 264786134c docs: 新增「初次部署（从零跑起来）」；去混淆字符与真实内网信息 
- README.md / README.txt 新增初次部署章节：前置条件（JDK 17 / SDK 34 / Gradle 8.9）、
  获取代码与本地配置（local.properties 不入仓）、Debug/Release 构建、装到手机与相机权限、
  连接配置（只连 Windows 客户端，默认 8765 / /pose）、第一次跑通、自检清单、常见问题
- 单测数量按实际（30 项）修正
- 三库同源契约：':=' 写法修回、去掉真实 MariaDB 版本串
- 全文去除易被 Gitea 判为「模棱两可 Unicode」的字符
- 本机 JDK 路径与内网示例地址改占位符 / RFC 5737 文档网段
 2026-09-15 21:33:27 +08:00
zijunchiang 203dcd8a9c chore(contracts): 同步 rest-api（新增 POST /api/models/{id}/reanalyze） 2026-09-15 21:18:21 +08:00
zijunchiang 5563a78e07 chore(contracts): 同步契约到 0.4.0/0.3.0（GLB/VRM 主力格式、模型审核与骨骼分析） 2026-09-15 20:37:58 +08:00
zijunchiang cee82c7b36 chore(contracts): 同步契约（默认模型改用压缩包 sha256 匹配，补 sourceSha256 与确定性说明） 2026-09-15 19:36:42 +08:00
zijunchiang f9e88901dd chore(contracts): 同步契约到 rest-api/data-models/model-formats 0.3.0、database 0.2.0（模型压缩包转换与默认模型规则） 2026-09-15 13:55:59 +08:00
zijunchiang 6f15d119ed chore(contracts): 同步契约到 v0.2.0（rest-api / data-models / model-formats） 
Web 端需求变更带来的契约字段级改动：
- MotionFormat 枚举新增 vmd（MikuMikuDance 动作数据）
- rest-api 服务地址说明改为双端口语义（软件 API 端口给客户端 / 管理端端口给浏览器）
- model-formats 新增 §2.3 VMD 解析约定（标准 MMD 骨架、腿部 IK/FK 判定、手性转换）

三库契约文件保持逐字节一致。
 2026-09-15 08:45:06 +08:00
zijunchiang eb534ed7ee docs(contracts): 服务地址描述由 Docker 部署改为 Linux 业务服务部署（Web 端已去 Docker） 2026-09-15 01:27:50 +08:00
zijunchiang e9ea1b5811 fix(android): 修复进入推流页立即闪退（未捕获 Error） 
用户反馈：扫描到客户端后点击「开始推流」立刻闪退。

根因：PoseDetector.initialize() 只 catch (Exception)，而 MediaPipe 初始化
失败会抛 UnsatisfiedLinkError / NoClassDefFoundError / ExceptionInInitializerError
—— 这些都是 Error，不是 Exception，会直接冒泡成进程崩溃。

证据（对照实验）：新增 Robolectric 组合测试后
  改回 catch (Exception)：5 项测试 2 项失败
    - java.lang.UnsatisfiedLinkError: no mediapipe_tasks_jni in java.library.path
    - java.lang.NoClassDefFoundError: Could not initialize class ...PoseLandmarker
  改为 catch (Throwable)：5 项全部通过

修复与加固：
- PoseDetector / CameraController 全部改为捕获 Throwable，失败只提示不崩溃
- 移除 accompanist-permissions 0.34.0（2024-02 发布，会传递引入
  compose animation-core 1.6.0，与 Compose BOM 存在版本偏斜风险），
  改用平台 Activity Result API
- MediaPipe 回调在相机线程：所有 Compose 状态写入统一 post 回主线程
- WebSocket 连接、相机启动、单帧分析全部包上失败保护
- 新增 CrashLogger：未捕获异常落盘到 filesDir/crashes/，
  并在连接页直接展示堆栈（免去连 adb 抓 logcat）
- 新增 ScreenCompositionTest（Robolectric）：真实组合三个页面，
  覆盖「进入页面即崩溃」这一类缺陷，共 30 项单元测试
 2026-09-14 22:43:03 +08:00
zijunchiang fd50a7fdf3 docs(android): 用实现说明替换阶段三占位 README v0.1.0 2026-09-14 20:40:38 +08:00
zijunchiang 570b12c215 chore(android): 合并占位说明与阶段三实现 2026-09-14 20:40:22 +08:00
zijunchiang 84da39ad17 docs(android): 任务说明、DSH 约束与交付文档 2026-09-14 20:40:16 +08:00
zijunchiang 8f0eeb7697 feat(android): T-AND-007/008 连接页/运行页/关于页 + 骨架叠加 2026-09-14 20:40:16 +08:00
zijunchiang 5737a66afd feat(android): 设置持久化（推流参数与连接信息） 2026-09-14 20:40:16 +08:00
zijunchiang d27845ef43 feat(android): T-AND-005/006 WebSocket 推流 + 主机发现 2026-09-14 20:40:16 +08:00
zijunchiang 30c316a1cc feat(android): T-AND-003 MediaPipe Pose 端侧推理 2026-09-14 20:40:16 +08:00
zijunchiang 7a8dcfba25 feat(android): T-AND-002 CameraX 采集（KEEP_ONLY_LATEST） 2026-09-14 20:40:16 +08:00
zijunchiang 94ec0a68d9 feat(android): T-AND-004 239 字节帧编解码 + 跨端金标准向量测试 2026-09-14 20:40:16 +08:00
zijunchiang 2f6212d5bf feat(android): T-AND-001 工程骨架（AGP 8.7.3 + Gradle 8.9 + Compose） 2026-09-14 20:40:16 +08:00
zijunchiang 568664a9aa chore(contracts): 引入 opendance-web v0.1.0 契约只读快照 2026-09-14 20:40:15 +08:00
zijunchiang ce2d71d22e docs: 初始化占位说明与契约依赖 2026-09-14 19:02:39 +08:00