自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
快閃記憶體耗損管理
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android Automotive 內部儲存空間會使用刷新和寫入週期的快閃記憶體。
如果快閃記憶體故障,系統可能會無法使用。車輛的壽命很長
(通常超過 10 年),快閃記憶體必須非常可靠。本頁面說明
以及原始設備製造商 (OEM) 如何降低刷新記憶體裝置故障的風險。
Flash 記憶體裝置採用穿戴式技術,可解決清除和寫入限制
資料整理及在整個系統中平均分配寫入,避免單一區塊失敗
執行大量寫入作業快閃記憶體的估計壽命取決於:
- 寫入次數
- 寫入模式
- 快閃記憶體可用的大小。更大的儲存空間大小意味著佩戴水平
演算法可以將寫入分散到更多區塊上。
- 佩戴水平技巧
- 環境因素。例如:運作溫度範圍
通常是攝氏 -20 到 85 度超出這個範圍的溫度可能會進一步縮短壽命
因此不會有特別的快顯效果
快閃記憶體壽命可以運用這個公式計算:
$$
\frac{Max\ erase\ cycles * Storage\ capacity}{Data\ written\ per\ year} = {Flash\ memory\ lifespan\ in\ years}
$$
然而,在快閃記憶體完全穿戴之前,系統會長時間停止運作
可用儲存空間就會越少,eMMC 的生命週期也可能更短,具體取決於
處理關卡和寫入模式等另外,預估費用
思考應用程式運作不正常或惡意應用程式會有什麼影響
在沒有特殊權限的情況下,將大量垃圾資料寫入記憶體。
為了在快閃記憶體實際發生前就偵測到潛在問題,適當的儲存空間健康狀態
監控功能應內建監控功能
實作快閃記憶體
Android Automotive 支援讓原始設備製造商 (OEM) 保護及監控系統的功能
來延長其壽命
減少閃光燈
原始設備製造商 (OEM) 擔心內部儲存空間有閃光燈,也可以新增 SD 卡,
所用的儲存空間SD 卡應具備以下屬性:
- 採用後,SD 卡就會加密,安全儲存應用程式資料。
- SD 卡插槽必須位於安全的地方 (使用者不應將 SD 卡移除
經常更新)。
- SD 卡無法用於在 Automotive 系統和電腦之間轉移資料。
- 退出 SD 卡不會影響運作中的系統。但除非將其移除
請更換圖片
SD 卡上的應用程式
為了進一步保護 Android Automotive 系統的內部儲存空間,原始設備製造商 (OEM) 可以指定是否要
第三方應用程式可安裝在內部儲存空間中,因此只能寫入
和分區如要設定,請在
資源疊加層:
<bool name="config_allow3rdPartyAppOnInternal">false</bool>
為了確保只要符合以下條件,即可確保安裝在 SD 卡上,是由汽車應用程式開發人員建構的第三方應用程式
汽車相關規定,汽車應用程式開發人員必須提供
android:installLocation=["auto" | "preferExternal"]
。
如果車輛不允許在內部儲存空間安裝第三方應用程式,請安裝應用程式
缺少此標記 (或如果 installLocation=internalOnly
設定)。
取得磁碟指標
AAOS 13 推出 Car 功能,推出 Flash 記憶體過度使用監控及指標收集功能
監控計時器。詳情請參閱
監控快閃記憶體用量。
Android 8 推出了「儲存空間」系統服務,可針對磁碟和刷新進行取樣及發布
記憶體指標,例如整體磁碟用量、快閃記憶體生命週期估計值
以及每個應用程式磁碟的 I/O 統計資料原始設備製造商 (OEM) 可根據這項資訊,在內部儲存空間顯示警告給使用者
就會開始失敗,或特定應用程式的磁碟 I/O 執行過多時詳情請參閱
實作儲存空間。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間: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"]],["上次更新時間: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)."]]