Smart PDF Reader v1.2.5 保活、拉活与通知逆向报告#

竞品包名：com.smartpdf.viewer
APK versionName / versionCode：1.2.5 / 26
静态样本、真机观察日期：2026-08-20
结论口径：静态 APK 与本次测试机状态；服务端 FCM、远端配置和真实重启均未操作，不外推为全量线上策略。

1. 结论先行#

1. Smart PDF 是本批样本中已真机确认常驻前台服务的一款：启动后 com.cell.document.nKhGkwcc 以 specialUse 类型运行，startForegroundCount=1，常驻通知 ID 为 1；从最近任务划掉后 10 秒，进程、FGS 与常驻通知仍存在。
2. 它有两类本地召回：
   • 高优先级 FCM 到达后：从 APK 内置 9 组模板随机选一组，发布本地通知；
   • 本地定时路径：AlarmManager → PibuBCOOqe → l82.d(...) → 本地通知，随机范围为上述 9 组加 1 组 AI 摘要文案。
3. 实机已捕获一条真实普通提醒：⏲️ 是時候完成了！（是时候完成了）/ 您的 PDF 轉換正在等待完成。 🔃（您的 PDF 转换正在等待完成），ID 8194。约 4 秒后它以同一 ID 更新到静默提醒渠道，证明“连续提醒”代码在当前机上实际走通。
4. 所有普通提醒点击先进入 OutOpenActivity，取消连续提醒并记录 action，再转交 SplashActivity；静态未能把 notify_fcm_* / notify_timing_* 精确还原为最终工具页，不能写成“直接打开某功能”。
5. 这不是 Force Stop 绕过：二次连续验证强停后 0、5、20 秒均为 stopped=true，进程、服务、活跃通知、闹钟和 Job 均未列出。前台服务只能解释“划掉任务后仍在”，不能解释“强停后自恢复”。

2. 样本与验证边界#

本次复查时测试机的 POST_NOTIFICATIONS 已是 granted=true；这不是本轮修改的结果，因此能够观察到实际通知。文件访问权限仍未授权，未读取或写入任何用户文件。

3. 总体机制图（静态 + 动态）#

FCM 高优先级消息                         本地计划时间
       │                                      │
       ▼                                      ▼
wHByvi(FirebaseMessagingService)      AlarmManager（ELAPSED_REALTIME_WAKEUP）
       │                                      │
       └── 随机内置模板 ────────────► PibuBCOOqe → l82.d(...)
                                                  │
                                                  ▼
                                    s11.u / s11.t → notify(8194)
                                                  │
                         4 秒连续静默更新 ───────┘
                                                  │
                                  点击 / 划除分别取消连续提醒
                                                  ▼
                               OutOpenActivity → SplashActivity

启动、开机/升级广播、Job 失败兜底 ─► nKhGkwcc 前台服务 → notify(1)

4. 普通通知：触发、频控、文案与点击#

4.1 两条普通提醒路径#

4.2 展示门槛与频控（静态事实）#

l82.d(...) 和 FCM 路径都会进入 zv2.a(...) 一类展示判断。其可核验条件如下：

4.3 内置正文模板（默认语言）#

FCM 和定时路径均从本地 NotifyItem 列表随机选取。下表 01–09 为两条路径共用的功能/文件话术；10 仅加入本地定时路径。英文后紧跟中文释义。

这些文案存在于 APK，不代表文件库真的更新、发现了新文件、存在待处理转换，或用户版本一定过时；它们是留存召回话术，真实业务状态未做绑定证据。

4.4 通知构建与连续提醒#

4.5 点击拉活 / 路由边界#

通知 ContentIntent
  → OutOpenActivity（读取 action，取消连续提醒，记录点击）
  → SplashActivity（携带 action；可能携带 filePath）
  → 后续由 Splash 初始化与混淆分发决定

因此它是“通知点击启动应用并传入归因 action”，不是可确认的某功能页深链，也没有证明后台静默拉起可见页面。

5. 前台服务、开机和 Job 兜底#

5.1 常驻前台服务#

**正确结论：**它在用户划掉任务后确有 FGS 持续运行证据；但不应把这写成“永久保活”或“强停可恢复”。

5.2 开机/升级与 Job#

6. 真机观察摘要#

7. 对我方的可借鉴与避坑#

1. 将三件事分开设计与验收： FCM 触发、定时提醒、FGS 持续任务不能混称“保活”。每一条都要有授权、频控、点击路由、取消和 Force Stop 验收。
2. 如果通知采用本地模板，必须绑定真实状态。 本样本中“文件已更新”“新文件已检测到”“转换等待完成”是内置召回话术，未看到与真实文件状态的绑定；我方不应在无证据时做这类暗示。
3. FGS 只服务于可见且持续的用户任务。 该样本使用 specialUse 并以常驻通知呈现功能按钮；是否合规、是否能过审核和能否长期存活仍依设备/系统约束，不能照抄为通用后台方案。
4. 点击不要只落在初始化页。 这里 action 在 OutOpenActivity → SplashActivity 中转；更稳妥的我方方案是对 action 做白名单，并最终落到可完成的具体任务，未知 action 回首页。

8. 未验证项#

• 未发送真实 FCM、未抓取 Firebase/远端配置网络请求；FCM 服务端受众、频次、消息 TTL 和真实优先级未知。
• 未真实重启设备、未测 MY_PACKAGE_REPLACED、Doze、OEM 省电限制或系统杀进程后的 Job/FGS 恢复。
• 未点击普通/常驻通知，因此 notify_fcm_*、notify_timing_*、resident_* 的最终工具落点未确认。
• 未验证用户关闭通知、关闭单独渠道、拒绝文件权限时 FGS/定时提醒的完整降级表现。
• 未评价 OCR、编辑、AI、广告或订阅能力；本报告仅覆盖保活、拉活与通知证据。