 zijunchiang
|
669766ba60
|
V1.4.10: 修复广告过滤失效（gz.ac16.vip 广告被当成歌曲下载播放）
现场事故（新设备 SM-S9180 / Android 16，WebView 正常 → 走 JS 取址）:
277 JS [KtvApi] URL OK: 7303235 ls=1 via http://w.w345.my
278 点歌编号=7303235 标题=情歌(HD) 请求源=http://w.w345.my 状态=成功 urlHost=gz.ac16.vip
279 PLAY id=7303235 title=情歌(HD) src=local
即 gz.ac16.vip 的广告视频被当成歌曲下载、缓存并播放。
三处漏洞叠加:
1. ktv_api.js 的 isDemoUrl 不认识广告域名；且"ts 文件名与编号比对"用的是
/\/(\d+)\.ts/，只匹配纯数字名 —— my_ad_video.ts 这类非数字名字直接放行；
2. SongOkDownloadManager.buildDownloadUrl 的**成功分支完全没有广告校验**
（AdVideoFilter.isAdVideo 全项目只在"缓存地址"与"原生解析"两处被调用）；
3. SongApiClient.fetchFromDb 只做 isLikelyDemoUrl（纯 IP / r2.dev），挡不住广告域名。
且**内容校验挡不住广告**: 该广告通过 SongFileValidator（≥6MB/≥60s/TS 包完整），
被 isDownloaded() 一直复用，广告会反复播。
修复（单一闸门，全链路把关）:
- AdVideoFilter 新增 isTrustedSongUrl(url, musicno)：非 http(s)、命中广告特征
（路径 /ad_files/、my_ad_video、**域名 *.ac16.vip**）、或 URL 里 .ts 文件名不等于
点歌编号 → 一律不可信。真源恒为 /<musicno>.ts（已实测 txog.ktvsky.com 与
download.origjoy.com 两个 CDN 域共 6 首全部相符）。
- 该闸门接入全部出入口: JS isDemoUrl（同步加固 + KTV_BRIDGE_API 8→9）、
SongUrlResolver.isValidSongUrl、SongApiClient.fetchFromDb、
以及最终兜底 SongOkDownloadManager.buildDownloadUrl（成功/缓存两条分支）。
- 判定不可信时**同时删除已落盘的歌曲文件**（purgeCachedSongFile），
否则 isDownloaded() 会一直复用那个广告文件。
- 新增 SongOkDownloadManager.purgeLegacySongCacheOnce(): 升级后一次性清理历史遗留的
可疑歌曲缓存（marker: filesDir/song_cache_purged_v1）。只是让歌曲重新下载，不动用户数据。
- 新增回归测试 AdVideoFilterTest（6 例，用日志里的真实 URL 形态，含两个真源 CDN 域）；
该测试当场抓到本修复自身的一个 bug：正则把扩展名也捕获进去导致真源被误杀，已修正。
版本 1.4.9(29) 到 1.4.10(30)；签名证书不变。
|
2026-09-26 21:17:04 +08:00 |
|
|
zijunchiang
|
906fa210e4
|
V1.4.8: 按现场日志复盘优化取址等待与远程日志（含 15 秒白等修复）
依据用户提供的 1.4.7 现场日志（21 行，5 次点歌全部成功）复盘出四点：
1. 【行为，最大】每次点歌白等 15 秒。
日志里每首歌前都有一条「JS-BRIDGE 15s 未就绪」，紧跟着「NATIVE-SONG 取址成功 用时=3xx~7xxms」——
即取址本身只要 0.3~0.7 秒，但用户从按下点歌到开始下载要等 15.7 秒。
原因: 桥一旦不可用，SongApiClient 每次都仍等满 15 秒。
修复: KtvJsBridge 新增「已判定不可用」状态（markUnavailable/isUnavailable），
首次判定后后续点歌直接走原生通道；桥万一恢复（热更新重载成功）自动清除该状态。
2. 【日志去噪】持久状态只记一次。
原来「15s 未就绪」按每次点歌一条 WARN 输出，一天几百条且无新增信息。
现在只在状态首次变化时记一条 ERROR。
3. 【可定位】补上"为什么不可用"。
旧日志里没有任何 KtvApi 未导出/WebView 初始化失败的行，说明 init 回调根本没触发。
KtvJsBridge.init 增加 20 秒看门狗: onPageFinished 未回调时明确上报
「初始化超时：onPageFinished 未回调或 KtvApi 未导出」；
init 异常与 KtvApi 未导出也统一收敛到 markUnavailable。
4. 【上下文完整】启动关键行不再有 undefined。
旧日志的 STORAGE 行 serverip/clientip/user/traceid 全是 undefined（记在设备上下文之前），
而且 AppPaths.storageFacts() 会真实建目录、写探针、读 /proc/mounts —— 却跑在主线程。
现在把 STORAGE 移入 reportDeviceBootInfo() 的后台线程、在 refreshLogDeviceContext()
与 MiliLog.awaitServerIp() 之后上报: 上下文完整且不再阻塞主线程。
5. 【新增状态样本】每 6 小时一条 HEALTH（版本/在线/可用空间/曲库是否存在及大小/根目录）。
日志此前只有事件没有状态样本，无法排查"随时间变化"的问题（空间变少、曲库丢失、长期离线）。
6. 【字段一致】「请求源=」不再为空: 走原生兜底时 JS 的 reportSongResult 不会触发，
现在 SongUrlResolver 记录 lastHost，SongApiClient.lastSongSourceHost() 依次回退。
AGENTS.md 增补「写日志的五条约定」（只记一次/上下文完整/不做重活/可自我定位/状态样本+事件）。
版本 1.4.7(27) 到 1.4.8(28)；签名证书不变。ktv_api.js 未改动，KTV_BRIDGE_API 仍为 8。
|
2026-09-26 20:38:52 +08:00 |
|
|
zijunchiang
|
1687f87eca
|
V1.4.7: 新增原生取址兜底 —— 修复 WebView 不可用的老盒子无法点歌
证据（用户导出的 1.4.6 远程日志）:
- 两条失败记录只有 Kotlin 侧那一行
「点歌编号=... 详情=无法生成下载地址」，
而 JS ...（本版新加的 console 桥）、RAW-ERR、NET-ERR、点歌失败 一条都没有。
- 即 JS 侧从未执行 —— 隐藏 WebView 在这台盒子上从未就绪
（每条失败前正好有约 15s 的「等桥就绪」超时，时间吻合）。
- 于是 SongApiClient 只能回退 DB 的 cloud_url，取不到就报「无法生成下载地址」。
根因: 取址完全依赖 WebView 里的 ktv_api.js；GMUI2.0/Android 5.1.1 上
WebView 不可用（无法导出 window.KtvApi），桥永远 not ready。
修复:
- 新增 SongUrlResolver: 用 Kotlin 复刻 ktv_api.js 的协议
（GET <host>/i.php 取 token → GET <host>/music/do.php 取地址），
镜像多源排序（失败源沉底）与 isDemoUrl 校验（wb66/demo/纯IP/r2.dev/ts编号不一致）。
- 走与 JS 完全相同的裸 Socket「干净请求」通道（KtvJsBridge.rawCleanGet），
请求特征一致故风控表现一致，且不依赖 WebView 是否就绪。
- SongApiClient.getSongDownloadUrl 三处回退点改为:
桥未就绪 / JS 未取到地址 / 主线程调用 → 先走原生解析，再回退 DB。
- 补齐桥的生命周期可观测性: WebView 初始化失败、KtvApi 未导出、
15s 未就绪 均写入远程日志（以前只在 logcat，这就是本轮一开始没有线索的原因）。
已用 App 的真实身份( mac=800b510bf4fd / sn=2d7bb4a7d7f7 / VER=2.0 )
从本机复现协议: i.php 200 → do.php code=200 且返回
http://txog.ktvsky.com/.../480p/7303235.ts （与点歌编号一致），
证明参数顺序与签名算法正确。
版本 1.4.6(26) 到 1.4.7(27)；签名证书不变。ktv_api.js 未改动，KTV_BRIDGE_API 仍为 8。
|
2026-09-26 17:08:38 +08:00 |
|