设计 Android AI 模型下载通知与状态恢复

直接回答

模型下载通知应反映权威传输状态，而不是成为状态存储本身。定义一个任务身份和用户易懂的阶段，例如排队、等待网络约束、传输中、暂停、已取消、校验、安装、失败或就绪。只有总量可信时才展示字节进度，并把校验和模型加载与传输字节完成分开。提供明确操作，例如打开详情或取消，并确保点击通知后进入同一个制品及其当前状态。如果用户拒绝通知权限或关闭通知频道，任务状态仍必须能在应用内查看，不能据此推断已取消或已完成。 Android 通知行为取决于权限和频道设置。Android 13 及更高版本中，许多应用的通知需要运行时权限；用户可以拒绝，因此应用不能假设通知一定可见。通知频道创建后由用户控制，应用不能强行重新打开被关闭的频道。根据适用的平台条件，可为需要用户持续感知的任务选择前台服务；持久 WorkManager 任务则是另一种调度方式。正确选择取决于任务要求、执行时长和平台规则。不能声称某个 API 保证下载不会中断，也不能说通知能够绕过操作系统限制。 仓库当前下载代码通过 Flow 暴露 Progress、Completed 和 Error；ModelManager 还暴露 downloading、downloaded、loading、ready、error 等模型状态，以及字节和进度 StateFlow。这些只是项目源码事实，不能证明 Cove 有某个公开通知频道或已经分发应用。界面应有意将内部传输状态映射为用户文案，而不是直接显示原始错误字符串。通知需要告知当前阶段和可操作事项，但不得包含模型路径、用户提示词、凭据或带令牌的完整 URL。 长时间传输开始前，应先确定通知策略：只有前台服务运行期间才需要通知吗？任务是否应等待不计费网络？用户能否暂停或取消？关闭通知是仅隐藏卡片还是取消任务？应用如何处理用户停用频道？这些决定会影响信任。除非应用明确说明并测试，否则滑动关闭通知不要等同于取消。同样，取消按钮应解释究竟只取消当前请求、保留已验证的部分字节，还是删除候选文件。字节保留规则应根据制品身份和续传验证决定，而不是为了简化通知。 尽可能用一个状态归约器同时驱动应用内卡片和系统通知。两个界面从同一个传输所有者读取状态，只是呈现方式不同。对同一制品的重复通知应更新现有项目，而不是制造提示噪音。第二个模型则使用自己的身份和状态。用户点击通知后，应依据稳定的任务或制品键跳转详情页，并从所有者重新读取当前状态；不要相信 Intent 中可能已过期的文字。如果任务已在通知延迟期间结束，展示终态，不要因此重新启动下载。 测试矩阵应包含权限允许、拒绝、之后撤销、频道关闭、应用前后台、屏幕重建、任务等待约束、总量未知、暂停、明确取消、失败、校验和就绪。针对与应用 min/target SDK 相关的平台版本测试权限及频道行为。如果选择的工作机制承诺持久执行，还需模拟进程重建。确认隐藏、关闭或停用通知不会丢失任务状态。检查无障碍标签和通知文案是否简洁、非技术化；详细诊断只在应用内提供并经过脱敏。 ### 操作步骤 1. 定义权威任务状态和身份。将制品修订、调度状态、字节数与分母来源、校验、安装及运行时就绪设为独立字段。 2. 根据需求选择前台服务或持久工作。核对适用 Android 权限、服务类型、启动时机及 WorkManager 约束；不能仅因某接口会显示通知就选择它。 3. 把相同状态映射到通知和应用内界面。提供稳定详情入口、用户操作和关闭频道后的回退路径，并区分传输结束和可用状态。 4. 明确关闭和取消语义。说明滑动关闭是否只隐藏通知；明确取消命令应发送给任务所有者，并说明部分文件保留规则。 5. 测试权限、频道与生命周期。覆盖授权、拒绝、撤销、应用后台、任务停止、屏幕重建、重试、校验失败及最终成功后的状态一致性。 ### 验收标准 - 通知文字是当前权威任务状态的映射，不会自行驱动或虚构任务状态。 - 权限拒绝或频道关闭后仍能在应用内查看任务和恢复，不会误判取消或完成。 - 传输结束、校验、安装和运行时就绪分别表示。 - 隐藏与取消有不同且测试过的行为，并绑定准确制品身份。 ### 比较 | 界面或机制 | 适用作用 | 边界 | |---|---|---| | 系统通知 | 简要状态和返回任务的快捷入口 | 用户可拒绝或关闭频道，不是权威任务存储 | | 应用内传输页 | 详细状态与恢复操作 | 应观察共享任务，不能再创建写入者 | | 前台服务或 WorkManager | 执行或调度机制 | 按需求选择；都不能保证所有系统状态下永不中断 | ### 常见问题 **通知意味着模型下载一定会继续运行吗？**不意味着。任务执行取决于所选服务或工作机制以及 Android 限制。通知只展示状态，不会授予调度权限，也不保证持续传输。 **用户拒绝通知权限怎么办？**应用内仍要提供权威状态和恢复路径，并继续遵守任务策略。拒绝权限影响可见性，不能被当成用户取消。 **滑动关闭通知是否应该取消下载？**只有行为已明确说明、无障碍可用且经过测试时才可以。最好分开“隐藏状态”和明确的取消操作，避免一次滑动意外丢弃工作或部分文件。 **通知什么时候可以显示模型已就绪？**只有所需校验、安装和运行时检查均成功后。字节百分比不足以证明就绪；若未测试离线任务，不得作此承诺。

任务继续运行，但通知权限或可见性发生变化

用户开始下载模型后把应用切到后台，随后拒绝通知权限或关闭对应频道。再次打开应用时，用户需要知道任务是在等待、执行、取消、校验还是已就绪，不能根据通知消失自行猜测。

决策

以传输所有者为状态来源，同时在通知和应用内呈现。把权限和频道可见性与任务执行及用户取消分开处理。

预期结果

用户可在应用内找回当前任务，理解阶段及可用操作，不会误认为隐藏或未经校验的下载已经完成。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• 传输所有者的状态模型
• 通知权限与频道设置路径
• 取消、隐藏、校验及恢复测试

收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。

实施流程

To ensure consistency, the mapping between notification states and underlying download conditions should be explicitly recorded, alongside the process recreation fixture, and the cancel and return test results should be captured for direct comparison. These evidence items together establish a verifiable record of how each state is triggered and displayed, allowing the release wording to be grounded only in what has been observed and recorded rather than assumed from expected behavior.

1. 定义单一任务状态模型. 分别表示等待、运行、停止、取消、传输完成、校验、安装、加载和失败，并绑定稳定制品键；字节数还应携带分母来源。
2. 按需求选择执行方式. 确认是否需要用户可见的持续工作、持久调度、网络约束或前台交互。核对当前平台的权限和服务规则，不能假设显示通知就让任务具备持久性。
3. 在两个界面呈现同一状态. 由任务所有者状态映射通知与应用详情页。使用稳定动作入口来重新读取当前状态；通知应观察任务，不能再发起第二次传输。
4. 明确操作和关闭语义. 区分点击打开、暂停、重试、取消和隐藏。说明关闭通知是否只隐藏卡片，以及取消是否保留已验证的部分文件；所有命令都需绑定准确制品身份并交由所有者处理。
5. 测试权限和设置变化. 覆盖拒绝或撤销权限、频道关闭、后台运行、约束等待、总量未知、取消、校验失败和成功。每次转换之后都确认应用内恢复入口和阶段文案准确。

验收标准

• 通知状态始终映射任务所有者，过期展示本身不能开始、完成或取消任务。
• 用户拒绝权限或关闭频道后仍可在应用内查看任务与恢复。
• 界面区分传输、校验、安装和运行时就绪。
• 关闭通知与取消任务有不同且经过测试的行为，并绑定对应制品。

决策对照表

需要避免的失败模式

• 把通知可见性当作任务状态
• 拒绝通知权限后丢失应用内恢复入口
• 传输完成后立即展示模型就绪

Common pitfalls to avoid include showing completion before verification has actually occurred and losing user control when the download moves into a background state. Release wording must be limited strictly to the recorded evidence, preventing any implication of readiness or completion beyond what the captured test results explicitly demonstrate, thereby protecting users from misleading status updates and preserving their ability to manage the download process at all times.

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Android persistent background work
• Android 通知运行时权限
• Android 通知频道
• Android WorkManager 任务管理
• Android 前台服务类型

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题