# 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 侧的联调回归。