内部缓存、图库和 RAM 是三个不同的边界；删除一个副本不能证明所有副本都已删除。
端到端加密保护图片的传输路径；图片打开后，可见副本的安全性还取决于设备以及应用的存储方式。但 Android 上并非每个临时文件都是公开的，缓存中的每张图片也不会自动进入图库。
评估风险时，不要笼统地说“缓存泄漏”，而应区分三个位置：应用私有存储、图库等共享空间，以及进程的活动内存即 RAM。它们各有不同的访问权限和生命周期。
解密后的图片可能留在哪里？
| 位置 | 常见用途 | 安全注意事项 |
|---|---|---|
| 应用私有内部缓存 | 快速再次显示图片 | 其他普通应用不应能自由访问 |
| 图库或共享空间 | 保存、编辑或分享图片 | 可能被有权限的应用和备份服务访问 |
| RAM 和显示组件内存 | 使用时处理图片 | 临时性不等于能抵御已被攻陷的设备 |
| 导出的副本或预览 | 在另一应用中打开文件 | 可能有独立的删除周期 |
Android 存储文档区分应用专属空间和共享空间。因此，“每个缓存文件都会被 MediaStore 索引”的说法不正确；存储路径、所用 API 和权限才是决定因素。
内部缓存有哪些保护？
Android 将应用专属内部空间与其他普通应用隔离。官方指南建议将敏感临时数据存放在这里。应用或系统可能在卸载应用之前删除缓存文件，但开发者不应仅依赖设备空间不足来触发清理。应用专属文件指南。
这种保护不等于“任何人都无法提取文件”。攻击者对锁定手机、已解锁手机、存在漏洞的操作系统或具有 root 权限的设备，其访问能力并不相同。可信的取证主张必须说明设备型号、系统版本、锁定状态及攻击者的访问类型。
为什么只放在 RAM 中不保证彻底删除？
避免将未加密副本写入磁盘，可以减少持久副本的数量。清理敏感缓冲区也可能是防御设计的一部分。但不能仅仅提及“RAM 清零”，就宣称恢复的可能性为零。
图片在处理过程中可能被复制到多个缓冲区、库或显示组件中。清除一个缓冲区本身并不能证明所有副本都已删除。即使没有生成持久文件，显示时能访问数据的恶意软件仍可能复制它。加密和内存管理相辅相成，而非相互替代。
用户可以做什么？
- 将保存到图库与自动下载分开检查。 为在应用内显示而接收媒体，不一定等于保存到图库。
- 控制图片备份。 导出的图片可能独立于聊天被上传到云端。
- 检查其他应用的图片和文件权限。 不要将完成某项任务所需的访问权与对整个图片集合的永久访问权混为一谈。
- 用测试图片检查。 查看接收、打开、保存和删除之后，哪些副本仍留在图库或其他应用中。
- 删除应用数据之前，检查恢复方式。 “清除缓存”“清除存储空间”和退出账户的后果不同；第二项可能删除所需的密钥或本地数据。
使用不敏感的图片测试很有帮助，但图库里没有文件，并不能证明设备上毫无痕迹。
开发者应如何测试清理？
检查应覆盖完整的媒体路径：接收、解密、显示、分享、关闭页面、退出账户和再次登录。正在进行的下载或预览生成操作必须与退出策略协调；否则，清理后可能又写入新文件。这是可以测试的场景，不是关于所有消息应用的已证实主张。
针对具体版本进行测试，并记录文件位置和每个步骤的结果。Android 安全建议强调最小化访问权限，并将敏感数据存放在合适的位置。
这对 Livara 意味着什么？
Livara 威胁模型不保证保护已被攻陷或处于解锁状态的设备。仅有传输加密文档，并不能证明“缓存中不会留下任何未加密副本”。这种主张需要检查具体应用版本及其媒体处理路径。
总结： 了解图片副本的位置和数量。减少多余副本、使用合适的设备锁并保持更新都很重要；没有测试和威胁模型支持的“零恢复”承诺不是可靠标准。
