恢复离线 AI 应用时核验模型是否真正可用

直接回答

Android 应用数据成功恢复，并不能证明本地 AI 模型已经存在或可用。恢复的偏好可能记着用户选过的模型 ID、先前下载状态或设置进度，但对应文件也许被排除、存放在缓存目录、留在旧设备的可移动卷上，或已被另一版本的制品替代。应把恢复的元数据看作需要核对的声明，而不是模型就绪的证明。既不能假设 Android 一定恢复了每个模型文件，也不能假设一个文件都不会恢复；结果取决于存储位置、清单规则、操作系统和目标版本、传输类型、Provider 行为及制品本身。 先辨认实际的数据传输方式。Android Auto Backup 与设备到设备迁移是不同模式。对于目标 SDK 为 API 31 或更高的应用，在 Android 12 或更高系统上可通过数据提取规则分别配置云端备份和设备传输；若还支持更早系统，也需要维护相应的旧式规则。一些厂商设备上，android:allowBackup=false 可能关闭云备份，却不关闭设备到设备传输。因此，一个清单开关、一次模拟器恢复或一次云端测试，都不足以代表所有受支持路径。每项测试应记录系统版本、target SDK、应用构建、传输类型及实际生效的规则。 按用途和实际存储来源盘点每个恢复状态。记住模型选择的用户偏好不是模型本身；数据库记录说“已下载”也不是文件检查。保存于系统可能纳入备份的应用目录，与放进缓存或 no-backup 目录的数据适用规则不同；云备份和设备迁移也可能有不同规则。检查下载器实际使用的目录和配置文件域，不要根据“内部存储”这样的产品术语猜测是否会传输。不要引用脱离传输方式和系统版本背景的统一备份体积限制。 外部文档 URI 也要单独核对。Android 备份指导提醒，恢复的 URI 可能已经失效，或在新设备上指向不同内容。记住 URI 或持久授权标记，并不证明新安装已能读取模型字节。展示制品可用前，应在当前授权范围内重新解析 URI 并尝试受限读取；失败时提供显式重新选择或支持的修复路径。不得把 content URI 拼成猜测的文件路径，也不能为让恢复看起来成功而悄悄扩大存储权限。 在启用推理之前核对制品身份。检查期望模型或版本是否确实位于应用可控路径，长度及可用完整性证据是否相符，预期运行时能否解析和加载，以及代表性就绪检查是否通过。如果来源没有可信摘要，要说明这个核验限制；不能凭文件名相同或数据库值匹配就伪造验证成功。模型就绪必须与应用安装、偏好恢复、网络可用和旧设备上的历史成功分开记录。 首个恢复后页面应呈现真实证据。如果制品丢失、过期、不可访问或被运行时拒绝，应显示可以恢复的未就绪状态，同时保留其他无关的用户数据。用户可以选择重新选取本地制品、暂缓设置，或在看清网络与存储影响后开始支持的下载。不能仅因恢复偏好写着用户以前选过模型，就启动可能很大的文件传输。另一台设备上过去的选择不等于用户允许此设备在当前计量或漫游连接上未经提示产生流量。 云端恢复和设备迁移应分开测试，并在每一种完成后尝试断网启动。使用恢复了模型选择但没有文件、文件版本不匹配、外部 URI 无效和制品有效等夹具。观察真实文件与网络请求，不要只读偏好布尔值。只有当本地资产存在且必需运行时检查在受测配置中通过后，模型依赖的断网任务才算就绪。用户选择恢复下载时，那是另一条修复流程，应单独测试，并且不能宣称所有设备或传输方式表现相同。

新手机恢复了设置，却没有可用模型

Android 设备设置完成后，本地助手显示已恢复的模型选择和 ready 标志。模型文件被当前备份规则排除，旧设备保存的 Provider URI 在新手机上也无法解析。

决策

先确认传输路径的规则，从当前存储重新解析模型制品并执行本地就绪检查；不信任旧元数据，也不自动下载。

预期结果

应用准确提示推理尚未就绪，保留其他已恢复数据，并等待用户重新选择制品或明确批准修复下载。

需要收集的证据

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

• ANDROID-AUTO-BACKUP-2026-01：Android Auto Backup 默认可能包含多数应用数据；面向 Android 12/API 31 的目标应用应分别配置云备份和设备传输规则。
• ANDROID-PROCESS-RESTORE-2026-01：进程内任务状态与持久数据及原生运行时资源属于不同恢复边界。

隐私声明需要数据清单和流量证据；“本地模型”标签本身不是证明。

实施流程

1. 列出恢复模式与版本. 记录源与目标系统版本、target SDK、应用构建、云备份或设备迁移路径、清单属性，以及每个受支持版本使用的 XML 规则。分别测试两种模式，不能把一次成功恢复推广为通用结论。
2. 分离偏好设置和模型制品. 列出模型 ID、选择版本、已下载标志、用户选择、数据库记录、content URI、模型文件、缓存和临时数据。逐项跟踪实际存储路径、纳入或排除规则，而不是从字段名称推断。
3. 核验恢复后的引用. 首次启动时检查制品身份、当前文件是否存在、长度是否可读、可用完整性证据和 URI 授权。不接受过期状态或无法解析的引用；不猜测路径，也不删除其他用户数据。
4. 让本地检查决定就绪状态. 制品通过适用检查后才初始化目标运行时。将安装、恢复的选择、文件存在、运行时加载和代表性断网任务分开显示，每个失败阶段都有真实可恢复结果。
5. 修复流量前要求当前选择. 必要模型缺失时，说明重新选择或下载的可用方式，以及已知的网络和存储影响。不能只凭备份偏好或另一台设备上的历史选择开始大文件或计量网络下载。
6. 分别断网验证两类传输. 对云恢复和设备迁移分别注入制品缺失、版本不符、URI 无法访问及制品有效等场景，然后断网运行依赖模型的任务。记录可见状态、制品身份和请求，不保存提示词或私人媒体。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 每种受测系统版本、target SDK 和发行配置分别记录云备份与设备传输的纳入规则。
• 没有核实当前制品及必要运行时检查前，恢复的偏好或 URI 不会把模型标成已就绪。
• 制品丢失或无效时不会自动发起网络请求、删除无关恢复数据或错误开放离线就绪功能。
• 用户重新下载前需作出当前选择，并获知可确认的网络和存储影响。

决策对照表

需要避免的失败模式

• 不能把恢复的 modelId、installed 布尔值或旧设备的 URI 当成当前文件存在和可读的证据。
• 不能假设云备份和设备到设备迁移具有相同规则，也不能宣称关闭 allowBackup 在所有厂商设备上都禁用 D2D。
• 不能因旧设备曾选择过模型，就在新设备上静默消耗计量或漫游网络下载大文件。

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

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

来源与相关证据

• Android privacy and security
• Android Developers：使用 Auto Backup 备份用户数据
• Android Developers：数据备份概览
• Android Developers：测试备份与恢复

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

常见问题