XuqmGroup-AndroidSDK/docs/DEBUG_PROGRESS.md

62 行
3.4 KiB
Markdown

# Android SDK 调试记录
更新时间2026-04-30 12:16 CST
## 当前状态
- 本地联调 IP`192.168.113.37`
- 模拟器:`emulator-5556`、`emulator-5558`
- 样例 App`com.xuqm.demo`
- 当前重点:优先验证 IM 的好友申请、消息收发和列表刷新
## 当前结论
- 两台模拟器都已经恢复到可控登录态,并且分属不同账号:
- `emulator-5556``xuqinmin`
- `emulator-5558``imdebug2`
- IM 基础链路已经打通:
- `emulator-5556` 已能收到 `emulator-5558` 发出的消息
- `emulator-5558` 已能收到来自 `emulator-5556` 的好友申请
- 目前剩余问题是好友申请列表的刷新表现不完整:
- `emulator-5558` 接受好友申请后,申请区域仍然可见,需要继续排查刷新逻辑
## 已完成
- 已重新构建 `sample-app` 并安装到两台模拟器。
- 已确认两台模拟器都安装了同一版样例 App。
- 已完成启动抓日志,验证了 `update-service``im-service` 的联调链路。
- 已再次覆盖安装最新样例 App,并重新拉起两台模拟器。
- 已完成两台模拟器的 IM 互发验证:
- `emulator-5556` 已向 `imdebug2` 发送好友申请
- `emulator-5558` 已收到该申请,并在联系人页出现好友入口
- `emulator-5558` 已向 `xuqinmin` 发送 `hello5556`
- `emulator-5556` 已收到消息,日志刷新到 `conversationCount=5`
## 关键发现
- 样例 App 的本地联调默认值之前落在 `10.0.2.2`,和当前实际调试 IP 不一致,已统一回 `192.168.113.37`
- 设备启动时,旧缓存的登录态会让 App 直接进入主界面,随后 IM 接口先打出 `403`
- `restoreSdkSession()` 之前是异步跑的,旧 session 失效时,主界面可能先出现再刷新失败。
- `UpdateSDK.checkAppUpdate()` 实际请求的是 `appId=ak_demo_chat`,并且日志已经返回 `versionName=1.0.1`、`versionCode=2`、`needsUpdate=true`、`downloadUrl=https://sentry.xuqinmin.com/files/apk/xuqm-chat-demo-1.0.1.apk`,所以当前看到的更新弹窗是 update-service 这条数据驱动的,不是租户平台版本管理页是否有记录直接决定的。
- 版本管理页当前用的是租户应用 `app.id`,而样例 App 仍然使用 `appKey=ak_demo_chat` 作为更新和 IM 的作用域,两个视图不一致时,页面空但弹窗出现是正常现象。
- `emulator-5558` 在接受好友申请后,联系人页仍然保留了 `好友申请1` 的可见区域,说明好友申请列表的刷新路径还需要继续排查。
## 已修复
- 样例 App 的本地联调默认 Host 改回 `192.168.113.37`
- `AuthRepository` 现在会在启动前检查缓存是否可用,失效时会清缓存。
- `XuqmSampleApp` 已改为在 `Application.onCreate()` 阶段同步恢复登录态,避免先进入主界面再触发无效 IM 请求。
## 近期验证
- `emulator-5556` 已通过联系人页向 `imdebug2` 发起好友申请。
- `emulator-5558` 已收到好友申请通知,并可在联系人页看到申请入口。
- `emulator-5558` 已向 `xuqinmin` 发送测试消息 `hello5556`
- `emulator-5556` 已收到该消息,日志侧刷新成功。
## 下一步
- 继续排查 `emulator-5558` 好友申请列表接受后未消失的问题。
- 验证群组列表、群成员和消息收发在两台模拟器上的稳定性。
- 保持两台模拟器分属不同账号,继续做 IM 侧的联调回归。