自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
闪存磨损管理
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android Automotive 内部存储设备使用支持上千次清除和写入周期的闪存。如果闪存出现故障,系统可能会无法使用。由于汽车的使用寿命较长(通常为 10 年以上),因此闪存必须非常稳定可靠。本页面介绍了闪存行为,以及 OEM 可以如何降低闪存设备发生故障的风险。
闪存设备使用耗损均衡技术解决清除/写入限制的问题,具体方法是在整个系统内均匀地放置数据和分配写入操作,以避免单个块因密集写入而发生故障。闪存的预计使用寿命取决于以下因素:
- 写入次数
- 写入模式
- 闪存的可用大小。较大的存储空间意味着耗损均衡算法可以将写入分摊到较多的块中。
- 耗损均衡技术
- 环境因素。例如:工作温度范围通常介于 -20 到 85 摄氏度之间。如果温度超出此范围,闪存的使用寿命会进一步缩短。
您可以使用以下公式计算闪存的寿命:
$$
\frac{Max\ erase\ cycles * Storage\ capacity}{Data\ written\ per\ year} = {Flash\ memory\ lifespan\ in\ years}
$$
不过,随着可用存储空间的减少,系统可能会早在闪存彻底磨损之前就停止正常运行,并且根据所使用的均衡技术和写入模式,eMMC 的使用寿命甚至可能会更短。此外,这方面的估算并没有将行为异常的应用或恶意应用的影响考虑在内,这些应用可能会在没有特殊权限的情况下将大量垃圾数据写入闪存以中断 Automotive 系统。
为了在潜在的闪存故障实际发生之前就检测出来,应将适当的存储设备运行状况监控功能整合到整体系统运行状况监控功能中。
实现闪存
借助 Android Automotive 支持的功能,OEM 可以保护和监控其系统的内部存储设备,以延长其使用寿命。
减少闪存磨损
如果 OEM 担心内部存储设备上的闪存磨损问题,也可以增加 SD 卡,SD 卡支持足够快的数据写入速度,可用作合并存储设备。SD 卡应具有以下属性:
- 合并后,SD 卡会加密,可以安全地存储应用数据。
- SD 卡槽必须位于安全的位置(不要让用户频繁移除 SD 卡)。
- SD 卡不能用于在 Automotive 系统和计算机之间传输数据。
- 弹出 SD 卡不会影响正在运行的系统。不过,除非需要更换,否则不应移除 SD 卡。
安装在 SD 卡上的应用
为了进一步保护 Android Automotive 系统的内部存储空间,OEM 可以指定是否允许第三方应用安装在内部存储设备中,以便应用只能向其安装所在的分区写入数据。要进行配置,请在资源叠加层中设置以下配置:
<bool name="config_allow3rdPartyAppOnInternal">false</bool>
为确保第二方应用(由汽车应用开发者构建的应用)可以安装在 SD 卡上(如果汽车提供授权),汽车应用开发者必须将 android:installLocation=["auto" | "preferExternal"]
纳入应用的清单文件中。
如果汽车禁止将第三方应用安装在内部存储设备上,在没有上述标记的情况下(或者如果配置了 installLocation=internalOnly
设置),应用安装将会失败。
获取磁盘指标
AAOS 13 引入了闪存过度使用监控和指标收集,作为汽车监控定时器的一部分。如需了解详情,请参阅监控闪存用量。
Android 8 中引入了 storaged,这是一项系统服务,会对磁盘和闪存指标进行采样并发布,例如有关总体磁盘使用情况、估算的闪存使用寿命和磁盘 I/O 统计数据(按应用统计)的信息。当内部存储设备开始出现故障或特定应用执行的磁盘 I/O 过多时,OEM 可以使用这些信息向用户发出警告。如需了解详情,请参阅实现 storaged。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-26。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-26。"],[],[],null,["# Flash wear management\n\nAndroid Automotive internal storage uses flash memory with thousands of erase and write cycles.\nIf flash memory fails, the system can become unusable. As vehicles have long lifespans\n(typically more than 10 years), flash memory must be extremely reliable. This page describes\nflash memory behavior and how OEMS can mitigate the risk of flash memory devices failing.\n\nFlash memory performance\n------------------------\n\n\nFlash memory devices use wear leveling techniques to work around erase and write limitations by\narranging data and distributing writes evenly across the system so that no single block fails\ndue to intensive writes. The estimated life of flash memory depends on:\n\n- **Number of writes**\n- **Write patterns**\n- **Available size of flash memory.** Larger storage size means the wear leveling algorithm can spread the writes across a larger number of blocks.\n- **Wear leveling techniques**\n- **Environmental factors.** Examples include an operating temperature range of usually -20 to 85 Celsius. Temperatures outside this range could further shorten the lifespan of the flash memory.\n\n\nFlash memory lifespan can be calculated with the help of this formula: \n$$ \\\\frac{Max\\\\ erase\\\\ cycles \\* Storage\\\\ capacity}{Data\\\\ written\\\\ per\\\\ year} = {Flash\\\\ memory\\\\ lifespan\\\\ in\\\\ years} $$\n\n\nHowever, the system would stop functioning properly long before the flash memory completely wears\nout as the usable storage size decreases, and the eMMC may have an even shorter lifespan depending\non the leveling techniques and the write patterns used. In addition, this estimate does not\nconsider the effects of misbehaved or malicious apps, which could disrupt Automotive systems by\nwriting large blocks of junk data to flash memory without special permissions.\n\nTo detect the possible flash memory failure before it actually happens, proper storage health\nmonitoring should be built in as part of the overall system health monitoring\n\nImplement flash memory\n----------------------\n\n\nAndroid Automotive supports features that enable OEMs to protect and monitor their systems'\ninternal storage to prolong its lifespan.\n\n### Reduce flash wear\n\nOEMs concerned about flash wear on internal storage can also add an SD card fast enough to be\nused as adopted storage. The SD card is expected to have the following properties:\n\n- When adopted, the SD card is encrypted and is safe for storing app data.\n- SD card slot must be in a safe location (users are not expected to remove the SD card frequently).\n- SD card cannot be used for transferring data between Automotive systems and a computer.\n- Ejecting the SD card doesn't affect a running system. However, it shouldn't be removed unless it needs to be replaced.\n\n### Apps on SD cards\n\n\nTo further protect the internal storage of Android Automotive system, OEMs can specify whether\nthird-party apps can be installed on internal storage so that apps can write only to the\npartition on which they are installed. To configure, set the following configuration in\nthe resource overlay: \n\n```scdoc\n\u003cbool name=\"config_allow3rdPartyAppOnInternal\"\u003efalse\u003c/bool\u003e\n```\n\nTo ensure second-party apps (those built by car app developers) can be installed on SD cards if\nthe car mandates, car app developers must include\n`android:installLocation=[\"auto\" | \"preferExternal\"]` in the app's manifest file.\n\nIf the car does not allow third-party apps to be installed on internal storage, app installation\nfails without this flag (or if the `installLocation=internalOnly`\nsetting is configured).\n\n### Get disk metrics\n\n\nAAOS 13 introduced Flash Memory Overuse monitoring and metrics collection as part of Car\nWatchdog. For details, see\n[Monitor flash memory usage](/docs/automotive/watchdog/wd_flash_memory).\n\n\nAndroid 8 introduced *storaged,* a system service that samples and publishes disk and flash\nmemory metrics, such as information about overall disk usage, flash memory lifetime estimation,\nand per app disk I/O stats. OEMs can use this information to warn users when the internal storage\nbegins to fail or when specific apps are performing too many disk I/Os. For details, see\n[Implement storaged](/docs/core/tests/debug/storaged)."]]