PDF Reader v1.1.7 保活拉活与通知文案逆向报告#

竞品：PDF Reader（包名 com.first.pdfreader）
样本版本：1.1.7（versionCode 17）
报告日期：2026-08-19
测试设备：Pixel 6a（bluejay），Android 16 / API 36

1. 结论先行#

1. 该竞品不是“永久保活”，而是用前台服务、开机广播、JobScheduler、WorkManager、AlarmManager、系统事件和 FCM 组成多入口恢复网。
2. 当前样本的两个基础调度间隔都在 APK 构造默认值中写为 15 分钟：JobScheduler 15 分钟、WorkManager 15 分钟；未发现它们受 Remote Config 控制的证据。15 分钟是调度请求值，不是系统承诺的准点执行时间。
3. 开机可以拉起：本次重启后，系统以 BOOT_COMPLETED 原因允许 QShxGYSnE 启动前台服务，常驻通知 ID 为 2001。
4. 划掉最近任务后，进程和前台服务继续存在；这证明“没有被杀”，不等于发生了拉活。
5. 普通后台停止后，持久化 Job 在本次测试约 7 分钟后重新创建进程，但 Android 16 拒绝了其后台恢复前台服务的尝试；所以“进程被拉起”和“前台保活恢复”是两件事。
6. Force Stop 是明确边界：进程、服务和调度被系统停止；观察窗口内没有自动恢复，之后出现的启动由用户手动点击桌面图标触发。
7. Android 13+ 通知权限是该方案的硬门槛。撤销 POST_NOTIFICATIONS 后，即使强制执行 Job，也不会恢复前台服务；重新授权后同一路径可以恢复。
8. 当前高优先级 FCM 客户端路径内置 9 组可达通知模板，从中随机选择；本报告已完整列出 12 个资源配置下的标题、正文和按钮。服务端人群、频控、发送时间和实际投放比例无法从 APK 证明。
9. APK 还打包了 _112、_112_fcm、_112_home、_112_time 四组备用资源。当前 FcmMessage.k() 没有引用这些资源，因此不能把它们认定为当前 FCM 的实际线上文案。

2. 样本与证据边界#

本报告使用四类口径：

• 静态事实：Manifest、DEX 反编译和 APK resources 中直接可见。
• 动态观察：本次测试机操作及 dumpsys、logcat、进程/服务状态结果。
• 合理推断：由多条事实组合出的解释，但不是服务端或生产策略证明。
• 未验证：APK 和当前测试不能确认的外部状态。

3. 保活与拉活技术结构#

3.1 核心链路#

应用初始化 / 开机 / 系统事件 / Alarm / Job / Work / FCM
                         │
                         ▼
                    统一入口 q()
                         │
          ┌──────────────┴──────────────┐
          │ 通知权限允许                │ 启动异常
          ▼                             ▼
QShxGYSnE 前台服务              Job 8703，约 5–7 秒兜底
          │
          ├─ onTaskRemoved() → q()
          └─ onDestroy() → q()

这是一张“多触发入口 + 一个统一恢复入口”的网，不是单点黑科技。

3.2 组件清单#

3.3 关键实现参数#

4. 真机验证结果#

5. FCM 与本地通知行为#

PzDotX.onMessageReceived() 先调用统一恢复入口 q()。只有高优先级消息会进入本地模板通知分支；客户端还检查通知权限、应用前后台、锁屏、横竖屏、本地 5 分钟节流和 07:00–22:59 时间窗。通过检查后，FcmMessage.k() 从 9 个 notifyDocPDF_fcm_01…09 模板中随机选一个。

这说明 FCM 同时承担两件事：

1. 给进程一次短时执行机会，并尝试恢复保活链路。
2. 在客户端条件允许时展示营销/召回通知。

无法从 APK 得出的内容包括：服务端发送计划、人群分群、每日上限、时区策略、消息 TTL、实际优先级降级比例、A/B 配置和线上模板采用率。

6. 当前 FCM 路径的 9 组完整默认文案#

以下是代码当前直接引用的默认 English 文案，不是人工改写。

资源包含 12 个配置：默认 English、ja、de、vi、ko、fr、mr、es、ms、it、pt、zh-rTW。没有 zh-rCN；简体中文设备若无其他运行时处理，将回落到默认资源。全部本地化原文见附录 A。

7. APK 内备用通知资源#

APK 另外存在 title/content1…9_112、_112_fcm、_112_home、_112_time 四组资源。当前高优先级 FCM 方法实际读取的是不带后缀的基础资源，因此下面只能称为“已打包资源”，不能称为当前线上 FCM 文案。

四组备用资源的默认 English 标题/正文一致：

备用资源还打包了按钮词：Check、Convert、Edit、Scan、Try、Update、View，并提供相同的 12 个语言配置。日语的 _112、_112_home、_112_time 存在若干不同写法，进一步说明这些资源可能服务于历史或不同入口，但仅凭资源名无法证明运行时路由。

8. 风险与可借鉴边界#

8.1 可以借鉴#

• 用统一恢复入口收口 Service、Job、Work、Alarm、Boot 和 FCM，减少多入口行为不一致。
• 把“已有服务维持”“进程拉起”“任务恢复”“用户召回”分成不同指标验证。
• 给每种触发入口独立埋点：触发来源、是否启动进程、FGS 是否获批、通知是否展示、点击是否回流。
• Android 13+ 在用户触发需要通知的功能时申请通知权限，并明确解释用途。

8.2 不建议照搬#

• QShxGYSnE 为 exported=true 且未见组件级权限保护，扩大了外部调用面；这属于实现风险，不应直接复制。
• 使用 FOREGROUND_SERVICE_SPECIAL_USE 不等于自然满足商店政策；必须有真实、持续、用户可感知且合规的用途和声明。
• “15 分钟双调度”会增加耗电、审查和 OEM 限制风险，而且不能保证准点或永久保活。
• 用“紧急文件”“重要文件”等措辞制造不存在的事件，可能造成误导和通知退订；竞品资源存在不代表我方应照搬。

8.3 尚未发现的能力#

• 未在 DEX 字符串中发现已知同厂兄弟包名，因此没有证据证明跨 App 互相拉活。
• 未发现客户端内置服务端凭证。
• 未证明 Remote Config 能修改本报告中的 15 分钟基础间隔。
• 未证明客户端 9 组模板就是生产服务端当前全部投放素材；只证明它们在当前 APK 的高优先级 FCM 本地路径中可达。

9. 推荐结论#

竞品真正值得学习的是“多入口恢复网 + 统一恢复入口 + FCM 召回”的结构，不是追求不可实现的永久保活。若用于我方产品，推荐把目标定义为：

1. 用户明确需要的持续任务使用合规 FGS。
2. 可延迟任务使用 WorkManager/JobScheduler，接受系统调度。
3. FCM 用于合规召回和事件通知，不作为可靠永久拉活承诺。
4. Force Stop、通知权限关闭、后台 FGS 启动受限都作为明确产品边界。
5. 通知文案必须对应真实用户事件，并设置服务端总频控和退订机制。

附录 A：当前可达 FCM 文案的全部 12 个本地化配置#

本附录由 APK resource table 直接提取。每个语言均列出 9 个当前代码可达模板的 Title、Body、Button。

A.1 Default English（default）#

A.2 日本語（ja）#

A.3 Deutsch（de）#

A.4 Tiếng Việt（vi）#

A.5 한국어（ko）#

A.6 Français（fr）#

A.7 मराठी（mr）#

A.8 Español（es）#

A.9 Bahasa Melayu（ms）#

A.10 Italiano（it）#

A.11 Português（pt）#

A.12 繁體中文（zh-rTW）#