---
name: "skill_log_keyword_aplog"
description: "AP log 关键词分析技能，适用于搜网异常、注册异常、睡眠率低和蜂窝状态时间线分析。"
---


# skill_log_keyword_aplog

## 搜网问题

## Modem 睡眠率低或不睡眠的问题

### 子场景: 蜂窝注册异常导致的 modem 睡眠率低 (高优先级)
- 不要只盯 `regState`。推荐按 `SIM/UICC -> 状态栏 -> 注册 -> Data/RF -> 睡眠/唤醒` 的顺序建立时间线，再下结论。
- 注册态判定必须有主次之分：
  - `reg_sim*_data_reg_rat.txt` 和 `reg_sim*_voice_reg_rat.txt` 是蜂窝注册态 SSOT
  - `reg_sim*_ims_reg.txt` 仅用于 IMS 注册判断
  - `reg_data_sub_serv_cell.txt` 只是 `NetworkBrainCenter: mServingCellInfo update to` 的业务侧快照，不是注册态真值
- 若 `reg_sim*_data_reg_rat.txt` 或 `reg_sim*_voice_reg_rat.txt` 中出现 `NOT_REG_*`、`DENIED`、`UNKNOWN`、`NOT_REG_MT_SEARCHING_OP` 等非注册态，则对应 `data_reg` / `voice_reg` 结论必须判为异常；不要被其他 section 中瞬时的 `in service` 或 `isOos=false` 覆盖。
- `reg_data_sub_serv_cell.txt` 中：
  - `dataRegState=0` 通常表示 `IN_SERVICE`
  - `dataRegState=1` 通常表示 `OUT_OF_SERVICE`
  - `isOos=false/true` 仅表示 NetworkBrain 当时观测到的 serving cell 是否 OOS
- 当 `reg_sim*_data_reg_rat.txt` / `reg_sim*_voice_reg_rat.txt` 与 `reg_data_sub_serv_cell.txt` 冲突时，优先以 `RILJ.*DATA_REGISTRATION_STATE` 和 `RILJ.*VOICE_REGISTRATION_STATE` 为准，并将 NetworkBrain 解释为业务层缓存、异步观测或状态抖动。

#### 分析顺序（推荐）
1. 先看 `SIM/UICC` 是否发生过状态突变
   - 重点文件：`reg_sim_state.txt / reg_sim_uicc_state.txt / reg_radio_state.txt`
   - 先确认是否存在 `ABSENT -> PRESENT`、`READY -> ABSENT`、slot 变化、subscription 重建。
   - 若 modem 睡眠异常前先发生 SIM 状态切换，应优先把它当成“上游触发事件”，不要直接从功耗现象跳到 App/GPS。

2. 再看状态栏或框架侧呈现是否与底层一致
   - 重点文件：`reg_status_bar.txt`
   - 可用来辅助确认 `无卡/无服务/有卡但无网/运营商名恢复` 的用户态可见时间点。
   - 这一步常用于验证 `SIM ready` 和 `网络恢复` 是否真的发生，而不是只存在于底层瞬时日志里。

3. 建立注册状态时间线，区分 “持续未注册” 和 “降级后在网”
   - 重点文件：`reg_sim*_data_reg_rat.txt / reg_sim*_voice_reg_rat.txt / reg_sim*_reg_fail.txt / reg_sim*_cell_info.txt`
   - 重点看 `.regState`、PLMN、RAT、`reasonForDenial`、`reg fail/rej cause`：
     - `REG_HOME / REG_ROAMING` 说明仍在网；即使 RAT 从 LTE/NR 降到 2G/3G/EDGE，也只是“降级驻网”，不能直接写成“持续搜网”。
     - `NOT_REG / NOT_REG_OR_SEARCHING / PLMN=0-0 / limited service`，或伴随连续 `reg fail`、反复 reject，才更符合“搜网常驻导致 modem 不睡”的判据。
     - `lte reg fail/rej cause 15` 需要单独留意，可能与欠费卡、策略限制或网络侧拒绝有关。
   - 双卡场景必须分 `SIM0/SIM1` 看，避免把另一张卡的正常驻网状态混入主结论。

4. 对 2G 场景必须拆开看 `CS` 和 `PS`
   - 不要因为 `VOICE_REGISTRATION_STATE = REG_HOME GSM` 就认为数据也稳定。
   - 典型异常模式是：`CS` 长时间 `REG_HOME GSM`，但 `PS(DATA)` 在 `REG_HOME EDGE` 和 `NOT_REG_MT_SEARCHING_OP` 之间来回抖动。
   - 这类问题不属于“完全无服务”，而是“低 RAT 驻网 + PS 不稳定”，会导致持续的网络状态变化和额外功耗。

5. 用框架侧 serving cell 作为辅助证据，不要把它当成唯一真相
   - 例如 `NetworkBrainCenter` 只重点跟踪 4G/5G，小区字段在 2G 时可能不完整，但 `inService / isOos / dataRegState` 的跳变仍然有价值。
   - 如果在 2G 场景反复看到 `isOos=true -> false` 与 `dataRegState=1 -> 0` 的切换，可作为 `PS 注册抖动` 的辅助侧证。
   - 这里的辅助侧证只能用于补充时序，不能反推“蜂窝注册已经正常”。

6. 把注册异常与数据面异常串起来
   - 重点文件：从 `reg_*`、`ril_*` 或相关过滤结果里看 `SETUP_DATA_CALL`、APN、cause code。
   - 若日志显示设备已经降到 `GERAN/EDGE`，随后反复 `SETUP_DATA_CALL`，并出现 `PDP_LOWERLAYER_ERROR(0x874)` 一类失败，要把它理解成“低 RAT 下 PS 数据建立不稳定/网络能力受限”的后果，而不是单纯 App 流量问题。
   - 若同一 APN 重试多次后偶发成功，说明问题更像“弱能力或不稳定”，不是配置完全错误。

7. 最后再对齐睡眠、唤醒、持锁
   - 重点文件：`power_modem_activityinfo.txt / power_stats_kernel_wakelock.txt / power_kernel_wakeup_source.txt / power_qcom_qrtr_qmi_ind.txt`
   - 若 `qrtr qmi` 和 `RIL UNSOL_RESPONSE_NETWORK_STATE_CHANGED` 的时间戳与注册切换高度对齐，说明它们更可能是“注册状态波动带来的结果”，而不是独立根因。
   - 若 kernel wakelock 本身不重，但 `network state changed / NAS serving system ind` 很密集，应优先归因为注册/服务状态抖动，而不是误判为普通 wakelock 持锁问题。

#### 结论判据
- `持续未注册/频繁搜网`：
  - 长时间 `NOT_REG* / limited service / PLMN=0-0`
  - 伴随连续 `reg fail/reject`
  - 结论可写成“搜网常驻导致 modem 睡眠率低”
- `降级后在网，但 PS 不稳定`：
  - `CS` 仍 `REG_HOME`
  - `PS` 在 `REG_HOME EDGE` 和 `NOT_REG` 间切换
  - 伴随 `SETUP_DATA_CALL` 重试、`PDP_LOWERLAYER_ERROR`
  - 结论应写成“注册/驻网异常导致 RAT 降级，随后 PS 数据不稳定进一步放大功耗”
- `单纯业务活跃`：
  - 注册长期稳定、RAT 稳定、无明显 reg fail
  - 再转去看“蜂窝移动数据常驻”或“GPS/定位触发”

#### 结论写法（推荐）
- 先写上游触发：`SIM/UICC 是否变化`、`是否发生 RAT 降级或 reg fail`
- 再写中间状态：`当前驻网 RAT`、`CS/PS 是否都稳定`
- 最后写功耗链路：`是否引发 network state changed / qmi serving system ind / data call retry / 睡眠率下降`
- 推荐表述：`SIM1 data_reg 异常，依据是 reg_sim1_data_reg_rat.txt 中 regState=NOT_REG_MT_SEARCHING_OP；reg_data_sub_serv_cell.txt 里的 dataRegState=0 只代表 NetworkBrain 某一时刻观测到 in-service，不构成注册正常的最终结论。`


### 子场景: 疑似 GPS 行为导致的modem睡眠异常.

#### 分析方法（从 MPSS=0% → GPS 证据链 → 归因验证）
1. 确认现象（MPSS 子系统不睡）
   - 看 `power_subsys_sleep_radio.txt / power_feat_power_teardown.txt / power_feat_power_mon.txt`：是否持续出现 `mpss: 0%`（apss/adsp/cdsp 正常有睡眠但 mpss 为 0）。

2. 对比“协议栈睡眠率”与“子系统睡眠率”（识别口径差异）
   - 看 `power_modem_activityinfo.txt`：RIL 的 `GET_ACTIVITY_INFO ModemActivityInfo` 统计的是 tx/rx/idle/sleep 四态；可能出现“modem(协议栈)睡眠率非 0，但 mpss 子系统睡眠率为 0”的不一致。
   - 用相邻两条 activityinfo 计算区间：`ΔmTimestamp`、`Δsleep/Δidle/Δrx/Δtx`，再算 `其他时间 = ΔmTimestamp - (Δsleep + Δidle + Δrx + Δtx)`；若“其他时间”占比较大，说明 activityinfo 并不能完全解释 mpss 的活跃来源，需要继续找系统/驱动侧唤醒源与业务触发点。

3. 排除网络侧异常（避免把“无服务/搜网”误判为 GPS）
   - 看 `reg_sim*_cell_info.txt / reg_sim*_data_reg_rat.txt / reg_other_crash.txt`：确认是否长期无服务、是否在频繁搜网/切网/重注册。
   - 若注册与信号相对稳定，且仍然 mpss=0%，更倾向是“上层触发导致数据面/定位链路常驻”。

4. 抽取 GPS/定位相关日志并做时间相关性
   - 使用关键字配置 `pacific_LogKeyWordConfig.ini`（gps 相关段）拆分：
     - `power_gps_gnsslocationprovider.txt`：`GnssLocationProvider`（例如 `GNSS HAL Requesting location updates from network provider for 10000 millis`）
     - `power_gps_location_singleton.txt`：`LocationSingleton`
     - `power_gps_fwk_starlocation.txt`：`Fwk-StarLocation`
     - `power_gps_monitor.txt`：`FEAT_POWER.*SysEvent gps`
     - `power_gps_debug.txt`：`LocationManagerService|requestCellInfoUpdateInternal`
   - 将上述定位日志的时间戳与 `mpss: 0%` 的统计窗口对齐：若存在“周期性请求网络定位/上报”（例如每隔数分钟触发一次），且覆盖整个异常区间，GPS/定位触发链路成立。

5. 归因与验证（最短闭环）
   - 常见触发源：系统定位服务/天气/前台应用请求定位，导致网络定位（NFW）或相关上报持续触发，进而使 MPSS 子系统难以进入睡眠。
   - 验证方式：关闭定位开关、限制相关应用定位权限、关闭天气定位、或停止定位相关服务后复测；观察 `mpss` 是否恢复>0、定位相关日志是否消失/频率显著下降。

### 子场景：应用使用蜂窝移动数据导致 modem 睡眠率低（MPSS=0%）


#### 分析方法（从现象 → 证据链 → 定位应用）
1. 确认现象（是否“睡不下去”）
   - 看 `power_subsys_sleep_radio.txt / power_feat_power_mon.txt`：是否持续出现 `mpss: 0%`、sleepRadio 时长增长但 MPSS 睡眠为 0。
   - 看 `power_modem_activityinfo.txt`：是否 `mSleepTimeMs=0` 或睡眠率极低，且 `mRxTimeMs` 持续增长（更像数据面常驻）。

2. 用 activityinfo 做区间核算（排除“统计口径误差”）
   - 用相邻两条记录计算区间：`ΔmTimestamp` 与 `Δsleep/Δidle/Δrx/Δtx`。
   - `其他时间 = ΔmTimestamp - (Δsleep + Δidle + Δrx + Δtx)`，若接近 0 且 `Δsleep=0`、`Δrx` 接近 `ΔmTimestamp`，说明 MPSS 主要在 RX/活跃而非睡眠。

3. 看是谁阻止 suspend（从“结果”追到“原因”）
   - 看 `power_kernel_wakeup_source.txt / power_stats_kernel_wakelock.txt`：
     - 若出现 `reason = Abort: Pending Wakeup Sources: ...`，说明系统尝试 suspend 被唤醒源阻止（suspend abort）。
     - 若 Pending 中包含 `rmnet_ctl / rmnet_ipa* / IPA_CLIENT_*`，通常指向蜂窝数据通路（IPA/rmnet）活跃或存在 pending 事务。

4. 关联到“哪个应用在用蜂窝数据”（把数据面活跃落到 UID）
   - 看 `data_stats_mobile_uid.txt`：按 `totalDun`（常见 300s）时间窗统计每个 UID 的 `rxBytes/txBytes/activeTime`。
   - 过滤 `uid=0`（kernel），按 `totalBytes=rxBytes+txBytes` 排序；同时关注 `activeTime`（流量不大但 activeTime 很高，常见于“频繁心跳/长连接保活”）。
   - 注意单位是 Bytes（不是 MB）；`uid=1000` 多为 system UID，不对应单个三方 App。

5. 验证与结论输出（最短闭环）
   - 关闭移动数据/强停疑似 App 后复测：是否 `mpss` 恢复 >0、`Pending Wakeup Sources` 消失或显著减少、`mSleepTimeMs` 开始增长。
   - 结论写法：同时给出 3 类证据
     - 现象：`mpss=0%` / `mSleepTimeMs=0`
     - 原因链路：`IPA/rmnet pending → suspend abort`
     - 责任归因：`data_stats_mobile_uid` Top UID（含包名/流量/activeTime）