Deep Cleaner v1.0.3 通知清理与通知干预方案#
产品：Tidyvo Cleaner（内部项目名：Deep Cleaner）
版本：v1.0.3
竞品基线：Photo Recovery V1.0.3（com.files.photo.recovery.restore.pro）
文档性质：产品与技术方案，不代表开发授权或实现状态
证据日期：2026-08-11 至 2026-08-12
当前 Tidyvo 具体需求入口：Notification Cleaner 已在 Tidyvo 线上 v1.0.5 的上一版本加入；本文保留权限和竞品机制基础，当前通知联动、ID 17、常驻恢复、中台及生产文案以 Tidyvo 具体执行方案 为准。
执行口径：Deep Cleaner v1.0.3 全盘复刻 Photo Recovery V1.0.3 已确认的通知清理、通知召回、后台恢复、权限链和广告链路。本文中的风险说明只用于标记测试重点，不得据此删除、降频、弱化或替换竞品机制；竞品服务端不可观测或尚未动态确认的行为保留同等客户端能力与配置字段，并明确标记待验证。
1. 结论#
v1.0.3 增加 Notification Cleaner（通知清理），直接目的之一是以真实可用的通知管理功能，引导用户授予 Android Notification access（通知使用权：允许本 App 查看和管理其他 App 通知的系统权限）。
获得权限后，产品按竞品调用链感知其他 App 新产生的通知、取消非 ongoing 且不在竞品白名单模型中的通知，并将竞品已确认字段写入本地通知历史。
本版需要同时建设两套彼此独立的系统：
- 通知清理系统：管理其他 App 的通知，使用
NotificationListenerService（Android 提供的通知监听服务，可接收其他 App 的通知变化）对应的通知使用权。 - 通知触达系统：由 Deep Cleaner 向用户发送本地通知或
FCM（Firebase 云消息服务，用于后台向手机推送消息）通知，Android 13+ 需要POST_NOTIFICATIONS（允许本 App 发通知的权限）。
两项权限的技术状态分别记录；产品入口、引导顺序和授权后的页面跳转按竞品已确认链路复刻，包括从 Notification Cleaner 入口先进入所有文件访问权限引导，再进入通知使用权设置。
1.1 权限和技术词白话对照表#
| 专业词 | 白话解释 | 在本方案中的作用 |
|---|---|---|
POST_NOTIFICATIONS |
允许 Tidyvo 自己给用户发通知 | 发清理提醒、存储提醒和远程推送 |
Notification access |
允许 Tidyvo 查看和管理其他 App 的通知 | 实现通知清理；必须由用户在系统设置手动开启 |
NotificationListenerService |
Android 给 App 使用的“通知观察员”组件 | 收到新通知时通知 Tidyvo，也允许按规则清除通知 |
FCM |
Google/Firebase 提供的远程推送通道 | 后台想给某台手机发消息时负责送达 |
| 本地通知 | 不经过服务器，由手机上的 App 自己定时生成的通知 | 离线提醒、定时召回 |
| 通知栏 | 手机顶部下拉后显示通知的区域 | 被管理或被清理通知原本出现的位置 |
| 白名单/允许名单 | 不进行拦截的一组 App | 微信、电话或用户指定 App 的通知继续正常显示 |
| 包名 | Android 中每个 App 的唯一身份，例如竞品的 com.files.photo.recovery.restore.pro |
判断通知来自哪个 App；不是用户看到的 App 名称 |
getActiveNotifications() |
Android 提供的“读取当前通知栏里还有哪些通知”能力 | 权限服务刚连接时检查已有通知 |
cancelNotification(key) |
Android 提供的“按唯一编号移除一条通知”能力 | 把符合清理规则的通知从系统通知栏移走 |
NotificationBean |
竞品自己定义的一条通知记录格式 | 把被隐藏通知整理后存在竞品本机数据库中 |
PendingIntent / Intent |
Android 中预先约定“点击后做什么、打开哪里”的指令 | 通知点击跳转或恢复原通知操作；本方案不保存原始指令 |
| 路由 | App 内部的页面地址 | 决定点击通知后进入通知清理页、首页或其他功能页 |
| 前台服务 | Android 要求长期运行任务必须向用户展示通知的一种服务 | 只能用于用户明确知道的持续任务，不等于普通前台页面 |
WorkManager |
Android 的延迟任务调度工具 | 在系统允许时同步配置、清理过期本地记录，不保证精确时间 |
| Firebase Remote Config | Firebase 的远程参数配置服务 | 竞品用它远程调整规则；Deep Cleaner 可换成自有后台 |
| 中台/自有后台 | 我们自己的服务端配置和数据系统 | 管理开关、文案、频率、语言和灰度策略 |
| 灰度分组 | 只让一部分用户先使用某套规则 | 小范围验证策略，出现问题时可快速停用 |
| 埋点 | 只记录用户是否看到、点击或完成某一步的行为事件 | 计算授权率、清理使用率和通知点击率，不上传通知正文 |
| APK 静态确认 | 从安装包代码或资源中确认“具备这条逻辑” | 能证明代码存在，但不能完全证明线上每次都会执行 |
| 动态验证 | 在专用测试机实际操作并观察结果 | 用来确认授权后真实行为和不同手机的兼容性 |
2. 竞品事实还原#
2.1 已确认#
| 环节 | 竞品行为 | 证据等级 |
|---|---|---|
| 功能入口 | 存在 Notification Cleaner、Notification Management 和 Notification Hide 页面 |
APK 静态确认 |
| 权限引导 | 先展示解释页，再打开系统通知使用权设置；返回 App 时检查授权，成功后自动进入管理页 | APK 静态确认 |
| 权限说明 | 宣称需要完整权限来管理各 App 通知，并提供通知记录和恢复功能 | APK 文案确认 |
| 通知监听 | 使用 NotificationListenerService（通知观察员） 监听当前通知和新通知 |
Manifest 与代码确认 |
| 连接初始化 | 服务连接后调用 getActiveNotifications()，也就是读取当前通知栏里已有的通知 |
代码确认 |
| 默认处理 | 内部开关开启时，对非允许集合且非本 App 的通知调用 cancelNotification(key)，也就是从通知栏移走这条通知 |
代码确认 |
| 本地记录 | 被处理的通知转换为 NotificationBean（竞品内部的通知记录格式） 并写入手机本地数据层 |
代码确认 |
| 白名单 | 存在按 App 管理的允许集合；白名单通知不被隐藏 | 代码与页面结构确认 |
| 页面说明 | “通知将被阻止并列在这里”；用户可随时在 Notification Management 查看 | APK 文案确认 |
| 功能开关 | 开启代表阻止通知；关闭代表让通知重新显示在系统通知栏 | APK 文案确认 |
| 通知召回 | 通知素材 ID 17 路由 noticlean，使用未读数量或“通知过载”文案召回 |
配置与资源确认 |
| 商业化 | 离开 Notification Management 时配置了插屏广告场景 | 代码确认 |
2.2 尚未动态验证#
以下不能写成竞品已确认事实：
- 用户授权后，Pixel 6a 上实际取消通知的成功率。
- 是否默认打开“隐藏通知”开关，还是需要用户二次开启。
- 白名单的默认 App 清单及系统通知排除规则。
- 通知记录具体保存多少天、最多多少条。
- 删除单条、批量清空、恢复通知的实际交互和结果。
- 是否保存通知图片、操作按钮或原始
PendingIntent（通知原本的点击操作指令）。 - 重启、强停、权限撤销、系统升级后的监听恢复情况。
3. Deep Cleaner v1.0.3 产品定位#
3.1 用户价值#
复刻竞品通过 Notification Cleaner 获取通知使用权、隐藏非白名单普通通知、保存本地历史并形成召回和广告转化入口的完整产品链路。
3.2 功能入口#
- 一级归属：
Tools - 功能名称：
Notification Cleaner - 中文名称：
通知清理 - 通知点击路由：
tools/notification-cleaner - 不新增底部 Tab，不改变现有四个一级导航。
3.3 页面链路#
Tools
→ Notification Cleaner 功能说明页
→ 用户点击 Enable notification access
→ Android 系统通知使用权设置
→ 用户手动授权 Tidyvo Cleaner
→ 返回后重新校验
→ 通知清理首页
→ 开启通知隐藏
→ 按竞品逐 App 开关模型管理白名单
→ 非 ongoing 且不在白名单的通知被取消并写入管理列表
4. 权限规则#
| 状态 | 页面行为 | 用户操作 |
|---|---|---|
| 未授权 | 展示功能价值、读取范围、处理方式和隐私说明 | Enable notification access |
| 正在前往系统设置 | 不提前显示“已开启” | 系统页面手动授权 |
| 已授权 | 展示通知管理首页；默认功能开关按本版最终决策执行 | 开启隐藏或管理白名单 |
| 用户取消返回 | 按竞品返回校验和再次引导逻辑复刻 | 再次进入竞品授权链 |
| 权限被撤销 | 停止监听与隐藏，保留入口并说明功能已暂停 | 前往系统设置恢复 |
| 系统组件异常 | 不宣称通知已被清理 | 重试或重新授权 |
授权说明、按钮、页面顺序和系统设置跳转按竞品原文与交互复刻，不另行增加会改变授权转化路径的我方保护说明。
5. 通知清理规则#
5.1 默认处理流程#
收到新通知后按竞品已确认顺序处理：
- 检查全局隐藏开关。
- 判断通知是否为 ongoing（持续通知）。
- 判断来源包名是否位于白名单集合。
- 若非 ongoing 且不在白名单，调用
cancelNotification(key)。 - 将竞品
NotificationBean对应字段写入本地数据库。
5.2 竞品白名单与 ongoing 规则#
- 内置竞品已确认的约 280 个默认白名单包名，并将 Deep Cleaner 自身包名运行时加入白名单。
- ongoing 通知按竞品判断直接放行。
- 用户逐 App 开关结果按竞品
NOTIFICATION_APP_WHITE_LIST_KEY同构方式持久化。 - 不额外增加竞品不存在的“高风险通知分类后默认放行”规则；是否放行只由 ongoing 状态和白名单决定。
5.3 本地记录字段#
按竞品 NotificationBean 保存已确认字段：
- 本地记录 ID
- 来源包名（Android 用于唯一识别来源 App 的技术名称）
- App 显示名称与本地图标引用
- 通知标题和正文摘要
- 通知产生时间
- 通知被隐藏时间
- 通知类别和分组键（系统可得时）
- 图片字段（系统通知可取得时）
禁止上传中台：通知标题、正文、发送者、验证码、通知图片、原始 Intent（Android 页面跳转或操作指令）、聊天内容及其他个人内容。
5.4 列表和清理#
- 默认按时间倒序，按日期分组。
- 管理页交互按竞品已确认界面复刻：通知历史列表、单条详情/删除能力和底部“清除所有”。
- “清理”必须区分两个动作：从系统通知栏隐藏、从 Tidyvo 本地历史删除。
- 已经被系统清除的通知不能承诺“恢复到原 App 通知栏”；只允许在 App 内查看历史摘要。
- 用户关闭总开关后按竞品逻辑停止隐藏；历史记录沿用竞品本地持久化行为。
6. 白名单设计#
页面名称：Allowed apps（允许的应用）。
- 内置竞品约 280 个包名的默认白名单。
- 用户可以按 App 开启或关闭隐藏。
- 开启“允许”表示该 App 的通知继续显示在系统通知栏。
- 关闭“允许”表示普通通知可被 Notification Cleaner 隐藏。
- Deep Cleaner 自身包名运行时强制加入白名单。
- 新安装 App 和列表默认状态按竞品实现复刻，不另设我方默认保护策略。
7. 通知触达与召回#
Notification Cleaner 作为竞品 ID 17 的召回落地页，素材、变量、频控和路由按竞品配置复刻：
| 场景 | 触发条件 | 文案变量 | 点击目标 |
|---|---|---|---|
| 通知积压提醒 | 本地确有被隐藏且未读记录 | 真实未读数量 | Notification Cleaner |
| 长时间未查看 | 有未读记录且超过配置天数 | 真实天数或不显示数字 | Notification Cleaner |
| 功能暂停 | 权限被撤销且用户此前启用过功能 | 使用竞品对应无变量素材 | 权限说明页 |
竞品已确认的固定数字、风险式表达和通用无变量素材全部进入 Deep Cleaner 复刻文案池；固定素材标记 fixed_claim=true，该标记只用于识别和测试，不阻止发布。
8. 自有后台配置#
自有后台作为策略真源（所有线上通知规则以它为准），Firebase Remote Config（Firebase 远程参数配置服务）不是必需项；FCM（远程推送通道）只负责把消息送到手机。
后台至少支持：
- 功能总开关和版本开关。
- 国家、语言、版本、Android 版本和灰度分组（先让一部分用户使用某套策略）。
- 通知场景开关、开始/结束时间、时区。
- 每日上限、最小间隔、冷却期、同素材重复次数。
- 通知栏最大可见数量。
- 文案池、语言、路由和优先级。
- 紧急停发开关。
- 本地兜底配置版本。
多语言条数不受 Firebase Remote Config 的“语言数量”概念限制，真正边界来自参数数量、模板体积、运营维护和客户端解析成本。建议后台以 scene + locale + template_id 管理，客户端内置英文兜底，不为每种语言创建一套独立代码逻辑。
9. 埋点#
只上传行为和状态，不上传通知内容：
| 事件 | 关键字段 |
|---|---|
notification_cleaner_entry |
entry_source |
notification_access_guide_view |
source |
notification_access_click |
source |
notification_access_result |
result、return_source |
notification_cleaner_switch |
enabled |
notification_rule_change |
action、app_category |
notification_intercept_result |
result、reason，不传来源包名和内容 |
notification_history_view |
record_count_bucket |
notification_history_clear |
scope、count_bucket |
notification_recall_show |
campaign_id、template_id |
notification_recall_open |
campaign_id、template_id |
核心漏斗：
功能入口曝光
→ 权限说明页到达
→ 点击授权
→ 系统授权成功
→ 开启通知隐藏
→ 首次实际处理通知
→ 次日仍保持授权
10. 常驻与系统干预的关系#
Notification Cleaner 与前台服务、Job、WorkManager、Alarm、开机/升级广播和 FCM 按竞品恢复链完整建设：
- 通知监听服务持续接收通知事件。
- 前台服务使用竞品
START_STICKY、onDestroy和onTaskRemoved恢复逻辑。 - FCM 保留远程消息和进入恢复链的同等客户端能力。
- WorkManager 按约 18 分钟目标周期配置。
- 持久 Job 按约 24 分钟目标周期配置，快速 Job 保留 4～6 秒兜底。
- Alarm 按约 8 小时配置长周期恢复入口。
- 开机和版本更新后重新安排完整恢复链。
- 非小米设备的未来 365 天时间戳、删除常驻通知后拉起服务、2 分钟间隔、每日 99 条和广告通知
-1无上限能力均进入复刻范围。
Android 和不同厂商 ROM 可能延迟或阻止部分行为；该限制只影响测试结果表述，不改变实现范围。
11. 验收标准#
- 未授权时不能读取、隐藏或宣称已清理通知。
- 授权必须由用户在 Android 系统设置中手动完成。
- 返回 App 后以系统真实状态判断，不以点击按钮代替授权成功。
- 总开关关闭后不再隐藏新通知。
- 竞品约 280 个默认白名单、Deep Cleaner 自身包名和 ongoing 放行规则生效。
- Tidyvo 自身通知不被监听链路清除。
- 本地历史删除和系统通知隐藏的文案不混淆。
- 权限撤销后功能状态立即变为暂停。
- 中台请求和埋点抽样不包含通知标题、正文、发送者、验证码或图片。
- 竞品固定数字和风险式素材可按原文展示，并能通过
fixed_claim标记识别来源。 - Android 主要版本及至少 Pixel、Samsung、Xiaomi 三类系统分别验证授权、监听、隐藏、白名单、撤权和重启路径；未测机型必须标记未验证。
12. 下一步验证清单#
要把竞品事实补齐，需要在专用测试机上完成一次可控动态实验：
- 创建两个自有测试 App 通知，一个加入竞品允许名单，一个不加入。
- 授予竞品通知使用权，记录首次授权完整页面和默认开关状态。
- 验证非白名单通知是否从系统通知栏消失并进入管理页。
- 验证白名单、常驻、媒体播放和系统通知是否被保护。
- 验证关闭功能、撤销权限、重启和强停后的行为。
- 记录管理页的单删、批量清空、筛选和退出行为。
- 全程只使用虚构通知内容，不读取或记录个人通知。
完成这组测试后，再把未确认项收口为最终 PRD 规则。