Deep Cleaner v1.0.3 通知系统详细配置执行方案#

产品：Tidyvo Cleaner（内部项目名：Deep Cleaner）
版本：v1.0.3
竞品基线：Photo Recovery V1.0.3（com.files.photo.recovery.restore.pro）
用途：按竞品 V1.0.3 已确认机制进行完整复刻，指导产品、后台、运营和 Android 开发配置；本文件不是开发授权
配置真源：Deep Cleaner 自有后台；FCM 只负责远程消息送达

当前 Tidyvo 具体需求入口：本文保留竞品机制、证据和同构字段基础；结合线上 v1.0.5 产品能力后的17个具体场景、规则、落地页和生产文案，以 Tidyvo 基于线上 v1.0.5 的竞品同构通知系统具体执行方案 与 12语言生产文案配置表 为准。

执行口径：本项目当前全盘复刻竞品，不做简化版，不以“激进、骚扰、合规或体验风险”为由删减、降频、弱化或替换竞品能力。凡静态反编译或运行时已经确认的机制、参数、文案、权限链、通知清理、后台恢复和广告场景均进入复刻范围；风险只作为测试与结果说明。尚未确认的服务端行为保留同等客户端能力和配置字段，并标记待验证，不能自行猜测为确定规则。

1. 这版最终要做成什么#

v1.0.3 建设三套互相配合的能力：

1. 通知清理：引导用户开启“通知使用权”，自动隐藏非允许名单中的普通通知，并在 Tidyvo 内展示通知历史。
2. 通知召回：根据真实清理结果、存储状态、截图数量、待清理数量等条件发送本地通知或 FCM 通知。
3. 常驻与恢复：维持必要的通知监听和配置同步；设备重启、App 更新或任务被系统回收后，在系统允许的范围内恢复任务。

两种权限必须分清：

2. 竞品配置基线#

竞品把通知配置分为总策略和素材策略两层。

2.1 总策略#

这些是竞品 APK 内置兜底值，不代表线上所有用户当前都使用 Online_B。

2.2 单素材策略#

竞品每个通知素材还有自己的间隔和次数限制。Deep Cleaner 后台也按这个结构配置：

先检查总策略
→ 再检查具体场景是否满足
→ 再检查该素材自己的频控
→ 从合格文案中选择一条
→ 生成通知
→ 用户点击后进入配置好的页面

3. Deep Cleaner 后台需要配置哪些页面#

本章中的后台不是另做一套“推荐逻辑”，而是用自有后台复刻竞品 Firebase Remote Config 的作用。字段含义和客户端执行方式要与竞品保持一致；字段名称可以按我方中台规范调整。

后台建议拆成五个配置页面。

3.1 页面一：全局策略#

后台必须内置两套与 APK 兜底同构的策略组：

Offline_A 和 Online_B 是竞品 APK 内置配置名称，不是 Firebase 标准术语。后台还必须允许新增其他远程策略组，并可按版本、国家、设备和比例分配。线上到底给哪些用户使用哪组规则，属于运营发布动作。

3.2 页面二：通知场景#

每一行代表一种通知。运营可单独开启、关闭或修改规则。

3.3 页面三：多语言文案池#

每条文案不是直接写死在场景里，而是独立建模板：

weight 是随机权重：同一场景两条文案都填 50，理论上各选中约一半。

3.4 页面四：路由#

路由失效、参数错误或页面不可达时统一回到 home。

3.5 页面五：灰度和发布#

发布一套通知配置时必须选择：

• App 版本：仅 v1.0.3 及以上。
• 国家或地区。
• 系统语言。
• Android 版本。
• 用户分组比例，例如 1%、10%、50%、100%。
• 生效时间和结束时间。
• 回滚到哪个历史配置版本。

4. 通知优先级和统一拦截规则#

4.1 竞品实际调度模式#

竞品不是只在 09:00、12:00 等固定时间发送，而是以“时间窗口 + 循环间隔 + 总上限 + 单素材间隔”的方式不断尝试。Deep Cleaner 必须复刻这一调度模型：

进入允许发送时间窗口
→ 按策略组的 interval_time 周期尝试
→ 检查全局开关、权限和设备状态
→ 检查 upper_limit 与 max_visible_ntf
→ 从 ntf_items 中选择当前可用素材
→ 检查该素材的 intervalTime、upperLimit、repetitions
→ 生成 normal_ntf / ad_ntf / res_ntf / filter_ntf
→ 保存本次展示时间和次数
→ 等待下一轮

固定时间点可以作为后台额外支持的 fixed_slots 模式，但不是竞品主调度模型，也不能替换 interval 模式。

4.2 展示前置门槛#

竞品通知核心构造链存在以下门槛，Deep Cleaner 逐项复刻并提供后台开关：

屏亮、未锁、竖屏的准确适用通知类型仍要通过指令级复核或动态测试确认，后台先保留独立开关，不把三者硬编码为所有通知的绝对条件。

4.3 通知类型#

每类通知必须独立配置：开关、频道、优先级、是否常驻、是否自动取消、声音、震动、可见性、上限、间隔、点击路由和删除行为。

4.4 竞品特殊通知属性#

这些属性受 Android 版本和厂商 ROM 限制。“代码已配置”不等于所有设备都一定置顶、不可清除或成功重启服务。

当多个通知同时满足条件时，按以下顺序选一条：

1. 权限或功能异常提醒。
2. 用户刚完成操作后的结果提醒。
3. 有真实数据的待清理提醒。
4. 存储空间不足提醒。
5. 通知积压提醒。
6. 长时间未使用召回。
7. 通用品牌提醒。

发送前统一检查：

总开关是否打开
→ 用户是否允许 Tidyvo 发通知
→ 当前是否在允许时段
→ 是否达到竞品配置的最小安装时长
→ 全局每日上限是否已满
→ 全局最短间隔是否满足
→ 场景条件是否仍然真实
→ 场景冷却是否满足
→ 通知栏可见数量是否超限
→ 文案变量是否有真实值
→ 通过后才展示

任何一步不满足时，按该通知类型的竞品调度规则记录跳过或等待下一循环；不能统一假定“错过后永不补发”。

5. 逐场景通知配置#

5.0 竞品通知 ID 与 Deep Cleaner 路由总表#

竞品常规轮询启用了 14 个通知 ID，另有 3 个事件通知 ID。Deep Cleaner 后台必须完整建档，不以现有 NTF_001～010 替换或删减：

ID 5、8、10、11 属于竞品功能语义与 Deep Cleaner 当前功能不完全一致的情况。复刻要求仍保留通知 ID、素材池和后台开关；无法等价跳转时必须回退到已登记页面，不能指向不存在的页面。

5.0.1 竞品完整原始文案池#

后台建立 competitor_source_text 字段保存竞品原文，另建 production_text 放 Deep Cleaner 实际展示文案，避免混淆“原样研究”和“当前上线文案”。

竞品 ID 9 中的 1.8GB、35%、23 和 8.5GB 是硬编码素材，不是已确认的实时扫描结果。按“竞品如何做就如何做”的研究口径，这些原文进入复刻素材库；后台必须额外标记 fixed_claim=true，方便测试和发布前识别。

5.1 竞品 ID 为正式执行主线#

第 5.0 与 5.0.1 节的竞品 17 个通知 ID、路由、单素材频控及完整原始文案池是本版正式执行主线。以下 NTF_001～NTF_010 是早期整理的我方附加场景，不得替换、覆盖或限制竞品 ID；本版默认不开启，只有常老大另行明确加入时才作为竞品主线之外的增量场景。

NTF_001：真实待清理结果（附加场景，默认关闭）#

文案池：

NTF_002：长时间未清理#

NTF_003：截图积压#

NTF_004：大文件提醒#

NTF_005：存储空间不足#

NTF_006：视频压缩未完成#

NTF_007：通知积压召回#

NTF_008：通知使用权被关闭#

NTF_009：To clean 待处理召回#

NTF_010：FCM 运营召回#

6. Notification Cleaner 详细配置#

6.1 权限获取链路#

权限说明页文案：

6.2 授权成功后的默认状态#

Pixel 6a 真机进入 隐藏通知管理 时，通知隐藏 总开关为开启。反编译进一步确认状态容器以 Boolean.TRUE 初始化，读取持久化字段 NOTIFICATION_APP_WHITE_LIST_ENABLED_KEY 时，只要本地值不是明确的 false 就按开启处理。因此竞品首次无本地记录的默认值可以锁定为 true。

Deep Cleaner 按竞品行为实现：

• 提供一个全局 通知隐藏 开关，副文案为“在通知栏中隐藏应用通知”。
• 开关状态本地持久化；重启 App 后保持用户上次选择。
• 后台保留 notification_hide_default_enabled，只决定首次无本地记录时的初始值；按竞品固定为 true。
• 竞品隐藏页实际存在逐 App 开关列表：包名集合表示白名单，开关选中表示保留该 App 通知；全局隐藏关闭时逐 App 开关整体禁用。页面没有单独命名为“白名单”的二级入口。

6.3 通知处理规则#

收到通知
→ 总开关是否开启
→ 是否为 Tidyvo 自身通知
→ 是否为系统关键或持续任务通知
→ 来源 App 是否在允许名单
→ 是否符合用户配置的隐藏范围
→ 符合才从通知栏移走
→ 在本机写入一条历史记录

反编译确认竞品真实判断顺序：

全局隐藏是否开启
→ 当前通知是否 ongoing（持续通知）
→ 来源包名是否在白名单集合
→ 若非 ongoing 且不在白名单：cancelNotification(key)
→ 将 packageName、tag、postTime、title、text、picture 写入 NotificationBean 数据库

竞品内置约 280 个包名作为默认白名单，覆盖电话、短信、联系人、系统设置、闹钟、导航、媒体、VPN/工具、主流社交和购物 App；运行时还会把竞品自身包名加入白名单。用户可在隐藏页逐 App 修改，结果持久化到 NOTIFICATION_APP_WHITE_LIST_KEY。因此不是“所有第三方普通通知都清除”，而是“非持续通知且来源不在白名单才清除并入库”。

6.4 管理页#

“清理”有两层含义，页面必须分开写：

• Hide from notification bar：从系统通知栏移走。
• Delete history：删除 Tidyvo 本机保存的历史记录。

不能承诺把已经清除的通知重新放回原 App 的通知栏。

7. 常驻与恢复配置#

竞品已确认使用前台 Service、约 24 分钟 Job、18 分钟 WorkManager、约 8 小时 Alarm、开机/升级广播和 FCM 多路恢复。Deep Cleaner 方案要把每一路用途写清：

竞品的下列行为属于复刻范围，后台必须有开关与参数，测试时逐项验证：

• 通知时间写成未来 365 天。
• 用户清除常驻通知后重新启动前台服务。
• Service 销毁或划掉任务后立即拉起自己。
• 4–6 秒、18 分钟、24 分钟、8 小时多路恢复。
• 普通通知 2 分钟间隔、上限 99 条。

7.1 调度链配置字段#

7.2 前台常驻通知配置#

Deep Cleaner 必须保留厂商、Android 版本和服务类型开关，并记录：是否成功启动、是否被系统停止、通知是否可清除、清除后是否进入恢复链、恢复耗时和失败原因。

8. 后台配置示例#

下面是给中台开发看的简化结构，产品按表格配置，不要求运营直接写代码：

{
  "config_version": "1.0.3-001",
  "master_switch": true,
  "emergency_stop": false,
  "global_rule": {
    "start_time": "08:00",
    "end_time": "21:30",
    "timezone_mode": "device_local",
    "daily_cap": 4,
    "global_interval_minutes": 180,
    "max_visible_notifications": 2,
    "new_user_silence_hours": 24
  },
  "scenes": [
    {
      "scene_id": "NTF_007",
      "enabled": true,
      "trigger_type": "local_event",
      "condition": {
        "notification_access": true,
        "notification_cleaner_enabled": true,
        "unread_hidden_count_gte": 10
      },
      "delay_minutes": 30,
      "daily_cap": 1,
      "cooldown_hours": 24,
      "priority": 75,
      "route": "notification_cleaner",
      "template_pool_id": "POOL_NOTICE",
      "expire_minutes": 720
    }
  ]
}

字段后续若由自有中台统一定义，可以改名，但含义不能丢失。

9. 配置发布步骤#

第一步：先建全局开关#

必须先完成 master_switch、emergency_stop、时段、每日总上限和全局间隔。没有紧急停发能力，不允许开启生产通知。

第二步：建路由字典#

把第 3.4 节的所有页面登记到后台，并验证非法路由会回到 Home。

第三步：建场景#

先按竞品 ID 1、2、3、5、6、7、8、9、10、11、12、13、17、18 创建常规轮询场景，再创建 ID 14、15、16 三个事件场景；NTF_001～010 是结合 Deep Cleaner 真实业务补充的我方场景，两套编号分别保存，不能互相覆盖。

第四步：录入文案#

先录英文和简体中文；每条文案必须绑定语言、场景、变量和权重。变量缺失时必须换用无变量兜底文案，不能显示 {size} 之类占位符。

第五步：建策略组#

完整建立竞品 Offline_A 与 Online_B，再建立远程灰度组。每个策略组都能配置通知类型、素材、频控、路由、厂商和系统版本。策略发布范围由常老大另行确认，文档不擅自把某一组限定为唯一生产策略。

第六步：逐场景测试#

每个场景验证：条件满足、条件不满足、点击跳转、变量正确、冷却生效、每日上限、停发条件和紧急关闭。

第七步：灰度发布#

按内部测试 → 1% → 10% → 50% → 100%推进。每一级至少观察授权率、通知关闭率、点击率、卸载率、崩溃率和用户投诉。

10. 埋点与报表#

10.1 通知触达事件#

10.2 通知清理漏斗#

Tools 卡片曝光
→ 进入权限说明页
→ 点击开启通知使用权
→ 系统授权成功
→ 打开通知隐藏总开关
→ 首次成功隐藏测试通知
→ 次日权限仍有效

不向中台上传通知标题、正文、发送者、验证码、图片或来源包名。数量只上传区间，例如 1-9、10-49、50+。

11. 最终验收清单#

后台#

• 有总开关和紧急停发。
• 有版本、国家、语言、Android 版本和用户比例灰度。
• 每个场景可以独立控制条件、频次、时段、文案和路由。
• 配置有版本记录，支持回滚。
• 变量缺失不会发出错误文案。

通知规则#

• 全局上限、场景上限和素材上限同时生效。
• 多场景冲突时按优先级只选一条。
• 用户刚打开或刚清理后进入静默期。
• 条件失效后不补发过期通知。
• 展示的数量和容量都来自真实本地数据。

Notification Cleaner#

• 未授权时不读取、不隐藏、不宣称清理成功。
• 用户从系统设置授权后才开始工作。
• 总开关关闭后新通知正常显示。
• 允许名单、系统关键通知和持续任务通知受到保护。
• 权限撤销后立即显示暂停状态。
• 本地历史真机确认支持点击单条进入详情、底部“清除所有”；代码存在单条删除交互。未看到批量选择 UI，不按竞品能力写入批量删除。
• 通知内容不上传中台。

动态验证#

• 发布前用 Deep Cleaner 自建测试通知复验允许名单和隐藏名单。
• Pixel 已验证重启、划掉任务和权限撤销/恢复；覆盖安装、Doze 与异常杀进程作为开发阶段系统测试。
• Pixel 已测；Samsung、Xiaomi 必须在有对应设备时单独验收。
• 已补证通知管理页、全局隐藏开关、逐 App 开关模型；首次默认值、白名单持久化、自动取消与入库已由反编译调用链锁定，shell 动态样本作为辅助证据。

12. 当前文档缺口审计与补证状态#

12.1 2026-08-12 首轮真机新增事实#

• Pixel 6a 当前安装版本核验为 V1.0.3（versionCode 4）。
• 用户现场观察：启动页直接请求 POST_NOTIFICATIONS（允许本 App 发通知）；当前系统状态显示该权限已授权。由于本轮没有清除 App 数据，启动弹窗本身尚未由 ADB 重新复现。
• 首页“通知清理”入口已截图确认。
• 点击“通知清理”后，当前设备首先进入“请允许访问所有文件权限”引导页，而不是直接进入通知使用权引导；说明竞品会把通知清理入口串入存储高权限申请链。
• 首轮截取该页面时尚未授权；随后已按常老大授权开启所有文件访问，当前系统状态为 MANAGE_EXTERNAL_STORAGE=allow。
• 首轮截取该页面时尚未获得通知使用权；随后已开启，系统详情和监听服务运行状态见 12.2。
• 前台服务已运行，通知 ID 为 2084960406，状态包含 ONGOING_EVENT / NO_CLEAR / FOREGROUND_SERVICE。
• WorkManager、priority 400 持久 Job 和约 8 小时 Alarm 再次在运行时确认。
• 动态证据统一保存在 evidence/photo-recovery-v1.0.3/2026-08-12/；广告点位按页面、触发动作、广告格式和前后截图固定，不点击广告素材。

12.2 2026-08-12 权限开启后新增事实#

• 常老大明确授权本轮测试所需权限后，测试机已开启所有文件访问与通知使用权。
• Pixel 系统的 Photo Recovery 通知使用权详情页显示总开关已开启，并允许读取 Real-time（持续通信）、Conversations（会话）、Notifications（普通通知）、Silent（静默通知） 四类通知。
• 权限开启后，MyNotificationListenerService 已作为系统绑定服务运行。
• 虚构 shell 测试通知发布后未保留在活动通知输出，符合竞品清除路径预期；但仍需独立自建通知 App 做交叉验证，当前不能只凭 shell 通知断言所有第三方通知一定被清除。
• 强停并重新启动竞品后，通知监听服务和前台服务均重新出现；前台服务仍为 ID 2084960406 且 START_STICKY。
• 冷启动/重新启动多次进入 Google Mobile Ads AdActivity；实际页面为启动画面上的全屏灰色遮罩、底部广告卡片和顶部 Continue to app，启动广告点位已动态确认。
• 测试中曾因坐标操作误触一次广告并打开 Chrome 外部落地页；该行为已记录为测试偏差，未继续操作落地页，之后广告只用返回键关闭。

12.3 2026-08-12 通知清理页面与开关补证#

• 权限开启后，首页“通知清理”直接进入 NotificationManagementActivity，页面标题为“通知管理”。
• 顶部唯一设置入口为“隐藏通知管理”；其下按时间列出通知记录，字段为应用图标、标题、正文、日期。
• 页面底部存在“清除所有”按钮；本轮未点击，以免删除测试机现有通知历史。未看到筛选、搜索、单选、批量选择或白名单入口。
• NotificationHideActivity 页面只有一个总开关：标题“通知隐藏”，副文案“在通知栏中隐藏应用通知”。当前状态为开启。
• 开关关闭后，页面 XML 出现按 App 展示的开关列表，但各 App 开关为禁用状态且保持选中；这说明竞品内部具备按 App 状态模型，不过全局关闭时不可编辑。当前可见范围未出现“允许名单/白名单”文案。
• 使用 shell 构造的开关前后测试通知都未在活动通知队列或通知管理可见区域留下可复核记录，因此该组结果不能证明开关真实拦截差异；原因可能是 shell 通知生命周期、来源限制或列表刷新机制。自动清除与入库仍须使用独立测试 App 交叉验证。
• 测试结束后已把“通知隐藏”恢复为开启，与进入页面时状态一致。

12.4 常驻、权限变化、重启和退出广告补证#

• 划掉 Photo Recovery 最近任务卡后，3 秒与 15 秒两个观察点中，MyNotificationListenerService 仍由系统绑定，前台服务仍为 isForeground=true / startRequested=true，进程 PID 未变化。结论：划任务不会终止其通知监听和常驻前台服务。
• 执行设备重启并等待 sys.boot_completed=1 后，在没有手动打开竞品的情况下，竞品进程已自动出现；通知监听服务重新由系统绑定，前台服务重新以前台通知 ID 2084960406 运行。通知使用权授权项也保持存在。
• 临时撤销通知使用权后，监听组件从系统授权集合和运行服务中移除；重新授权约 5 秒后重新绑定。测试结束已恢复授权。
• 强制进入 Deep Doze 后系统状态为 mState=IDLE；观察 10 秒时通知监听仍由系统绑定，前台服务仍为 isForeground=true / startRequested=true。随后已执行 unforce 与电池状态恢复，设备回到 ACTIVE。
• am kill 对前台进程没有造成终止；shell 无权直接 kill -9 普通 App UID，因此“异常进程死亡后的精确秒级重建”未形成动态证据。可确认的是划任务不死、重启后自启、权限恢复后重绑。
• 从通知管理页退出时，本次没有出现实际插屏，直接回到首页。静态代码确认 onDestroy() 会检查 NotificationExitInt 场景并在场景可用时请求广告，因此正确规则是“退出触发广告请求，是否展示取决于广告场景开关、频控和填充”，不能配置成每次必现。
• FCM 客户端分支、通知渠道与路由已由反编译确认；由于没有竞品 Firebase 服务端凭据，无法向竞品安装实例发送可控线上 FCM。该限制不影响 Deep Cleaner 按同等字段接入自有 FCM，但竞品线上 Remote Config/FCM 当前激活值只能标注为服务端不可观测。

12.5 最终证据边界#

本轮已完成单台 Pixel 6a、Android 当前系统版本上的可执行测试矩阵。以下不是继续操作测试机即可消除的缺口：

• Samsung、Xiaomi 等其他 ROM 需要对应实机。
• 24 小时真实通知发送序列需要持续观察周期，当前以调度代码和瞬时系统任务快照为依据。
• 竞品 FCM/Remote Config 实际线上值需要竞品服务端权限或可控消息入口。
• 独立通知测试 APK 需要 Android 构建工具；当前工作区只有 platform-tools，没有 JDK/SDK 构建链。竞品核心取消、白名单和入库规则已由完整代码路径锁定，不再作为方案阻塞项。

13. Deep Cleaner 开发验收测试步骤#

1. 清除 Deep Cleaner 测试数据，重新安装 v1.0.3，录制从首次启动到通知权限、通知使用权的完整链路。
2. 分别记录拒绝、允许、返回、永久关闭后的页面状态与再次引导方式。
3. 用两个自建测试通知来源制造普通、ongoing、媒体播放和高优先级通知。
4. 开启通知隐藏后验证：非白名单是否清除、白名单是否保留、记录是否入库。
5. 操作 Notification Management 的单条详情、单删、清除所有、允许名单、总开关和退出。
6. 连续观察至少 24 小时，记录每条 Deep Cleaner 通知的时间、ID、类型、标题、正文、路由、频道和清除行为。
7. 分别测试亮屏、锁屏、横屏、竖屏和通知栏已有 0～6 条时的展示差异。
8. 划掉常驻通知、划掉最近任务、停止服务、进入 Doze、重启设备、覆盖安装，记录每条恢复链是否生效和耗时。
9. 使用合法可控的测试 FCM 验证普通优先级和高优先级分支。
10. 导出测试结束后的系统状态和脱敏 App 数据，只保留自建虚构通知，不读取个人通知。

14. 复刻完成判定#

只有同时满足以下条件，才能称为“按照竞品完成复刻方案收口”：

• 后台能表达 Offline_A、Online_B 及远程新策略组。
• 客户端能执行总策略、单素材策略、四种通知类型及完整路由。
• 17 个通知 ID/事件场景及原始素材池均已建档。
• Notification Cleaner 授权、监听、白名单、自动清除、入库和管理页规则均有动态证据。
• 前台服务、Job、WorkManager、Alarm、开机/更新和 FCM 恢复链均有对应配置与测试结果。
• 竞品特殊通知属性及厂商差异均有记录。
• 未确认项不再靠推断，而是经测试确认或明确标注仍未验证。

15. 与旧方案的关系#

《Deep Cleaner v1.0.3 通知清理与通知干预方案》已同步为完整复刻口径；本文件仍是实际配置和执行主文档。若两份文档出现冲突，一律按“竞品已确认能力、参数、文案、权限链、恢复链和广告场景全部复刻”的原则处理，不允许恢复为保守替代方案。

16. 真机图证#

以下均为 Pixel 6a 上的竞品 Photo Recovery V1.0.3 实际截图。截图只用于竞品机制和广告点位证据，不代表 Deep Cleaner 已实现。

16.1 首页通知清理入口#

16.2 点击通知清理后先索要所有文件访问#

页面标题为“请允许访问所有文件权限”，正文称需要完全访问设备存储来搜索丢失或删除文件。说明通知清理入口会被竞品现有权限流水线先拦截，而非直接进入通知使用权说明。

16.3 Android 通知使用权列表#

Photo Recovery 位于系统 Allowed（已允许） 分组。

16.4 通知使用权详情#

系统页面显示 Allow notification access 已开启，Real-time、Conversations、Notifications、Silent 四类均勾选。

16.5 冷启动广告点位#

实际结构为：启动页继续显示在背景，页面加灰色遮罩；底部显示 Advertisement 广告卡；顶部显示 Photo Recovery / Continue to app。系统 Activity 为 Google Mobile Ads AdActivity。本轮未点击广告素材。

16.6 通知管理历史页#

顶部只有“隐藏通知管理”入口；历史列表展示应用图标、标题、正文和日期，底部为“清除所有”。本轮没有点击清除按钮。

16.7 通知隐藏总开关开启#

页面标题“隐藏通知管理”，配置项标题“通知隐藏”，副文案“在通知栏中隐藏应用通知”。进入时总开关为开启。

16.8 通知隐藏总开关关闭#

该图用于证明开关可由用户主动关闭。测试结束后已恢复开启状态。