PDF Reader: View All PDFs（Lumio）v1.2.8 保活、拉活与通知逆向报告#

竞品包名：com.espublishing.pdfreader.viewer.editor
应用标签：PDF Reader: View All PDFs
样本版本：1.2.8（versionCode 30）
静态分析与真机验证日期：2026-08-20

1. 结论先行#

1. 该 APK 不是前台服务常驻型保活。已还原的业务链路是：远端配置启用后，MainActivity.onPause() 排一个延迟 WorkManager 任务；任务到点后展示一条本地“不活跃提醒”通知，并自行排下一轮。它的目标是离开 App 后的用户召回，不是维持进程常驻。
2. 该链路有明确总开关和频率参数：notification_configs.is_enable 为总开关，time_since_last_open_in_hour 为首次延迟，APK 默认值是 false / 24 小时。用户再次进入并离开主页面会取消同名旧任务并重新从该延迟开始计时。
3. ReminderWorker 是可执行的业务 Worker，不是只打包了 WorkManager。它按已保存的语言寻找远端 contents，优先当前语言、失败回退 English；从该语言通知列表按序轮换标题和正文，创建 inactivity_channel 后发布本地通知。
4. 点击通知只取包的 launcher intent 并回到 App，并没有在这条链路中看到文件、编辑器或会员页等目标深链参数。因此它是“回 App”召回，不能证明点击后一定进入某个特定业务页面。
5. 本次真机在“启动 → 后台”窗口内只看到 Firebase/传输 SDK 的网络 Job，未出现 ReminderWorker 的 WorkManager 系统任务；所以本机本次没有观察到已生效的不活跃提醒。原因可能是远端开关为关、远端尚未完成下发，或当前首启路径未满足调度时机，不能据此反推线上全量策略。
6. 真机真实划掉最近任务后，Lumio 任务条目、进程和 Service 均消失；startForegroundCount=0。Force Stop 后包进入 stopped=true，Service、Job、进程在 30 秒观察期内均未恢复。它没有绕过 Android Force Stop 的保活证据。
7. APK 有 FCM 基础组件，但当前基准 DEX 未见 com.longct... 自定义 FirebaseMessagingService 来把到达推送接到上述提醒链路。不能把“含 FCM”写成“FCM 可拉活并展示营销通知”。

2. 样本与证据口径#

本报告将证据分为四类：

• 静态事实：Manifest、DEX 代码、序列化字段或 APK 资源中直接可见的内容。
• 动态观察：本次测试机操作与 dumpsys、任务栈、进程状态的结果。
• 合理推断：由已证实调用链得出的产品/技术解释，不能替代服务端事实。
• 未验证：远端实际配置、发信、人群、频控、到达率或长期系统行为。

3. 已还原的业务调用链#

远端 RemoteData.notification_configs
  ├─ is_enable（默认 false）
  ├─ time_since_last_open_in_hour（默认 24）
  └─ contents[language_code].notifications[title, description]
                 │
                 ▼
MainActivity.onPause()
  └─ is_enable=true 时：取消同名旧 Work
     → 以 REPLACE 方式排 ReminderWorker（延迟 N 小时）
                 │
                 ▼
ReminderWorker.doWork()
  ├─ 取保存语言；当前语言无内容时回退 English
  ├─ 以 NotificationOpenTime % 列表长度选一条
  ├─ 创建高重要级 channel：inactivity_channel
  ├─ 已获 POST_NOTIFICATIONS 才发布本地通知
  └─ 再次排 ReminderWorker（形成“到点后下一轮”）
                 │
                 ▼
用户点击通知 → getLaunchIntentForPackage() → 回到 App launcher

3.1 DEX 代码锚点#

这是一个“本地延迟通知 + 打开 App 重置倒计时”的循环，不包括服务保活、开机自启或进程死亡后立刻补拉。系统对延迟 Work 的实际运行时机仍可施加 Doze、配额、后台限制等约束。

4. 通知配置与远端数据证据#

4.1 配置模型#

com.tech.core.remote.RemoteData.NotificationConfigs 的 Kotlin 序列化字段可直接还原为：

初始化代码会从 SharedPreferences 的 RemoteData 读取序列化对象；拉取成功路径也会将更新后的对象以同名键写回，并记录 “Remote config fetched successfully”。APK 同时注册 Firebase Remote Config 组件，但本次只证明它有一条命名为 RemoteData 的拉取、解析和本地缓存路径，没有把 Firebase Remote Config 与这一字段逐项建立唯一数据源关系。

4.2 文案不是本地硬编码模板#

ReminderWorker 先读取已保存的 Language；匹配不到语言内容时查 English；找不到内容或通知列表为空则不展示。与另一份 PDF Reader 报告中“本地 9 组可达 FCM 模板”不同，Lumio 这条提醒路径的业务标题/正文来自远端 contents，APK 没有给出可列举的默认营销文案。

APK 本地固定的仅是 channel 元数据：

5. WorkManager 调度细节#

5.1 排程入口#

MainActivity.onPause() 先读取 notification_configs.is_enable；为真才调用调度函数。调度函数执行顺序如下：

1. 取消唯一工作名 inactivity_reminder_work。
2. 创建 ReminderWorker 的 OneTimeWorkRequest。
3. 取 time_since_last_open_in_hour，空值回退 24，转换为毫秒初始延迟。
4. 以 ExistingWorkPolicy.REPLACE 重新排入同名唯一任务。

这意味着只要用户重新进入再离开主页面，旧倒计时就会被替换；代码没有在该 Worker 的创建处设置网络、充电、空闲、前台执行等业务约束。它是请求延后 N 小时，而非保证第 N 小时准点通知。

5.2 Worker 的显示、轮换与下一轮#

ReminderWorker 继承 CoroutineWorker，不是前台 Worker，也没有在其业务代码中调用 setForeground()。到点后：

1. 以 NotificationOpenTime % notifications.size 选择该语言列表中的一项。
2. 使用 title 和 description 生成本地通知；通知设为 auto-cancel。
3. POST_NOTIFICATIONS 被授予时才调用发布；成功路径将 NotificationOpenTime 加一。
4. 无论本轮是否找到文案，方法尾部都会再次调用同一排程函数。

字段名 NotificationOpenTime 容易误读：当前代码是“展示后递增，用于下一次取模轮换”，没有看到它等待用户点击通知后才递增。因此不能把它称为“通知点击次数”或真实打开次数。

5.3 点击路由#

Worker 取得 getLaunchIntentForPackage()，再以 PendingIntent.getActivity() 写入通知。可见 flag 用于清理/复用已有 launcher task，但未携带文件 URI、工具名、会员页或自定义 route。结论是“通知点击回 App”；点击后的最终首屏还会受已有任务状态、冷启动和 App 自身路由影响，未做逐页真机验证。

6. 保活、拉活与 FCM 的边界#

特别说明：Firebase Messaging Service 在某个早期快照中处于绑定状态，但 startForegroundCount=0；它是消息 SDK 服务，不是本报告已证实的保活前台服务。其后真实划掉任务时，该服务也随应用进程消失。

7. 真机验证结果#

未申请 MANAGE_EXTERNAL_STORAGE，未读取任何用户文件；也未改动竞品线上配置、通知权限或用户数据。

8. 首启广告观察（与本专项的关系）#

本次首次流程观察到：启动页约 16 秒后出现一条全屏广告，关闭后进入语言选择和三步引导。它说明首启漏斗可能被广告打断，但和不活跃提醒是两条不同路径：

• 全屏广告：本次动态观察，受网络、广告填充和频控影响。
• 不活跃提醒：APK 内已还原的本地 WorkManager 调度代码，受远端开关、通知权限与系统调度影响。

不能因为二者都依赖后台/远端能力，就把广告预加载、FCM、通知召回和进程保活混为一类能力。

9. 对我方的可借鉴与风险边界#

可以借鉴#

• 对“用户离开后提醒”使用唯一 OneTimeWork，并在用户重新活跃时 REPLACE 倒计时；语义清楚，也避免多条重复通知。
• 将开关、延迟、语言文案分层配置，但需在客户端设置安全默认值、上限、格式校验和无内容兜底。
• 通知点击应使用经过验证的内部 route，必要时附带真实业务对象 ID；仅回 launcher 会让效果归因和用户回流路径都不清楚。
• 埋点需拆开：任务排入、系统实际执行、权限拒绝、通知展示、点击、回到页面、后续转化。它们不是同一件事。

不建议照搬#

• 不把 WorkManager 的延迟任务宣传为“保活”或“定时必达”；系统可以推迟或取消。
• 不用无真实业务事件支撑的文案做高优先级重复提醒；本样本变量名虽叫“inactivity”，仍需要我方明确用户授权、频率上限和退订入口。
• 不用前台服务权限、FCM 依赖或 WorkManager 组件存在来代替真机验证；三者分别只说明不同层的可能性。
• 不将 Force Stop、通知权限关闭、系统后台限制视为异常；它们是 Android 的产品边界，应在验收标准中单列。

10. 未验证项与后续取证条件#

1. 当前线上 is_enable、实际延迟、语言文案、人群、频控和是否按国家/版本分流；需要受控网络抓包或获得授权的服务端配置，不能从 APK 猜测。
2. ReminderWorker 在该样本本机的真实出通知时间；需要远端启用后，以可控短延迟复现，且不得篡改竞品数据或配置。
3. 通知权限拒绝、重新授权、Doze、后台受限、重启和 OEM 系统下的实际执行时机；本次未做跨小时等待或重启实验。
4. FCM 到达后是否有 SDK 自动展示通知、服务端 data/notification payload 策略及 Force Stop 状态下行为；当前没有授权向竞品项目发送真实消息。
5. RemoteData 拉取端的实际服务端来源。APK 可见 Firebase Remote Config 组件和独立 RemoteData 缓存路径，但二者的字段映射尚未静态闭环。