ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
พื้นที่เก็บข้อมูลแบบดั้งเดิม
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android รองรับอุปกรณ์ที่มีพื้นที่เก็บข้อมูลแบบดั้งเดิม ซึ่งกำหนดให้เป็นระบบไฟล์ที่ไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ที่มีคลาสและโหมดสิทธิ์ POSIX ที่ไม่เปลี่ยนแปลง
แนวคิดของพื้นที่เก็บข้อมูลแบบดั้งเดิมจะรวมพื้นที่เก็บข้อมูลที่จำลองและแบบพกพา
พื้นที่เก็บข้อมูลแบบพกพาหมายถึงพื้นที่เก็บข้อมูลภายนอกที่ระบบไม่ได้
นำมาใช้ จึงไม่ได้จัดรูปแบบและเข้ารหัสหรือเชื่อมโยงกับอุปกรณ์ใดอุปกรณ์หนึ่ง
เนื่องจากพื้นที่เก็บข้อมูลภายนอกแบบดั้งเดิมมีการป้องกันข้อมูลที่จัดเก็บไว้เพียงเล็กน้อย โค้ดของระบบจึงไม่ควรจัดเก็บข้อมูลที่ละเอียดอ่อนไว้ในพื้นที่เก็บข้อมูลภายนอก กล่าวโดยละเอียดคือ ควรจัดเก็บไฟล์การกําหนดค่าและไฟล์บันทึกไว้ในที่จัดเก็บข้อมูลภายในเท่านั้นที่จะสามารถปกป้องไฟล์เหล่านั้นได้อย่างมีประสิทธิภาพ
พื้นที่เก็บข้อมูลภายนอกสำหรับผู้ใช้หลายคน
ตั้งแต่ Android 4.2 เป็นต้นไป อุปกรณ์จะรองรับผู้ใช้หลายคน และพื้นที่เก็บข้อมูลภายนอกต้องเป็นไปตามข้อจำกัดต่อไปนี้
- ผู้ใช้แต่ละรายต้องมีที่จัดเก็บข้อมูลภายนอกหลักแยกต่างหากของตนเอง และจะต้องไม่มีสิทธิ์เข้าถึงที่จัดเก็บข้อมูลภายนอกหลักของผู้ใช้รายอื่น
- เส้นทาง
/sdcard
ต้องนำไปยังพื้นที่เก็บข้อมูลภายนอกหลักที่ถูกต้องสำหรับผู้ใช้ โดยอิงตามผู้ใช้ที่กระบวนการทำงานอยู่
- พื้นที่เก็บข้อมูลสำหรับไฟล์ OBB ขนาดใหญ่ในไดเรกทอรี
Android/obb
อาจแชร์ระหว่างผู้ใช้หลายคนเพื่อเพิ่มประสิทธิภาพ
- แอปต้องเขียนไม่ได้ในที่จัดเก็บข้อมูลภายนอกรอง ยกเว้นในไดเรกทอรีเฉพาะแพ็กเกจตามที่สิทธิ์แบบรวมอนุญาต
การใช้งานแพลตฟอร์มเริ่มต้นของฟีเจอร์นี้ใช้ประโยชน์จากเนมสเปซเคอร์เนล Linux เพื่อสร้างตารางการต่อเชื่อมแบบแยกต่างหากสำหรับแต่ละกระบวนการที่แยกจาก Zygote จากนั้นใช้การต่อเชื่อมแบบบอนด์เพื่อมอบพื้นที่เก็บข้อมูลภายนอกหลักที่ถูกต้องสำหรับผู้ใช้แต่ละรายลงในเนมสเปซส่วนตัวนั้น
เมื่อบูต ระบบจะเมานต์ FUSE daemon ของที่จัดเก็บข้อมูลภายนอกแบบจำลองรายการเดียวที่ EMULATED_STORAGE_SOURCE
ซึ่งซ่อนจากแอป หลังจากแยกกระบวนการของ Zygote แล้ว ระบบจะเชื่อมโยงการต่อเชื่อมไดเรกทอรีย่อยเฉพาะผู้ใช้ที่เหมาะสมจากภายใต้ D-Bus ของ FUSE ไปยัง EMULATED_STORAGE_TARGET
เพื่อให้เส้นทางของพื้นที่เก็บข้อมูลภายนอกแก้ไขได้อย่างถูกต้องสำหรับแอป เนื่องจากแอปไม่มีจุดต่อเชื่อมที่เข้าถึงได้สำหรับพื้นที่เก็บข้อมูลของผู้ใช้รายอื่น แอปจึงเข้าถึงได้เฉพาะพื้นที่เก็บข้อมูลของผู้ใช้ที่เริ่มต้นแอป
การใช้งานนี้ยังใช้ฟีเจอร์เคอร์เนลซับต้นไม้ที่แชร์เพื่อนำไปเผยแพร่เหตุการณ์การต่อเชื่อมจากเนมสเปซรูทเริ่มต้นไปยังเนมสเปซแอปด้วย ซึ่งจะช่วยให้ฟีเจอร์ต่างๆ เช่น คอนเทนเนอร์ ASEC และการต่อเชื่อม OBB ทำงานได้อย่างถูกต้องต่อไป โดยระบบจะดำเนินการนี้โดยการต่อเชื่อมรูทไฟล์เป็น "แชร์" แล้วต่อเชื่อมอีกครั้งเป็น "สเลฟ" หลังจากที่สร้างเนมสเปซ Zygote แต่ละรายการแล้ว
อุปกรณ์เก็บข้อมูลภายนอกหลายเครื่อง
ตั้งแต่ Android 4.4 เป็นต้นไป ระบบจะแสดงอุปกรณ์พื้นที่เก็บข้อมูลภายนอกหลายเครื่องแก่นักพัฒนาแอปผ่าน Context.getExternalFilesDirs()
,
Context.getExternalCacheDirs()
และ
Context.getObbDirs()
อุปกรณ์จัดเก็บข้อมูลภายนอกที่แสดงผ่าน API เหล่านี้ต้องเป็นส่วนที่อยู่กับอุปกรณ์แบบถาวร (เช่น ช่องการ์ด SD ในส่วนแบตเตอรี่) นักพัฒนาแอปคาดหวังว่าข้อมูลที่จัดเก็บไว้ในตำแหน่งเหล่านี้จะพร้อมใช้งานเป็นเวลานาน ด้วยเหตุนี้ คุณจึงไม่ควรแสดงอุปกรณ์พื้นที่เก็บข้อมูลชั่วคราว (เช่น ไดรฟ์สำหรับเก็บข้อมูลจำนวนมากแบบ USB) ผ่าน API เหล่านี้
สิทธิ์ WRITE_EXTERNAL_STORAGE
ต้องให้สิทธิ์การเขียนเข้าถึงพื้นที่เก็บข้อมูลภายนอกหลักในอุปกรณ์เท่านั้น แอปต้องไม่ได้รับอนุญาตให้เขียนไปยังอุปกรณ์จัดเก็บข้อมูลภายนอกรอง ยกเว้นในไดเรกทอรีเฉพาะแพ็กเกจตามที่สิทธิ์ที่สังเคราะห์ไว้อนุญาต การจํากัดการเขียนด้วยวิธีนี้ช่วยให้ระบบล้างไฟล์ได้เมื่อมีการถอนการติดตั้งแอปพลิเคชัน
Android 6.0 รองรับอุปกรณ์เก็บข้อมูลแบบพกพาที่เชื่อมต่อกับอุปกรณ์เป็นระยะเวลาสั้นๆ เท่านั้น เช่น แฟลชไดรฟ์ USB เมื่อผู้ใช้เสียบอุปกรณ์แบบพกพาเครื่องใหม่ แพลตฟอร์มจะแสดงการแจ้งเตือนเพื่อให้ผู้ใช้คัดลอกหรือจัดการเนื้อหาของอุปกรณ์นั้นได้
ใน Android 6.0 ระบบจะถือว่าอุปกรณ์ที่ไม่ได้นำส่งเป็นแบบพกพา เนื่องจากพื้นที่เก็บข้อมูลแบบพกพาเชื่อมต่อเพียงระยะเวลาสั้นๆ แพลตฟอร์มจึงหลีกเลี่ยงการดำเนินการที่หนักหน่วง เช่น การสแกนสื่อ แอปของบุคคลที่สามต้องผ่านเฟรมเวิร์กการเข้าถึงพื้นที่เก็บข้อมูลเพื่อโต้ตอบกับไฟล์ในพื้นที่เก็บข้อมูลแบบพกพา ระบบจะบล็อกการเข้าถึงโดยตรงอย่างชัดเจนเพื่อเหตุผลด้านความเป็นส่วนตัวและความปลอดภัย
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","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-27 UTC"],[],[],null,["# Traditional storage\n\nAndroid supports devices with traditional storage, which is defined to be a\ncase-insensitive filesystem with immutable POSIX permission classes and modes.\nThe notion of traditional storage encompasses emulated and portable storage.\nPortable storage is defined as any external storage that is not [adopted](/docs/core/storage/adoptable) by the\nsystem and therefore not formatted and encrypted or tied to a specific device.\nBecause traditional external storage offers minimal protection for stored data,\nsystem code should not store sensitive data on external storage. Specifically,\nconfiguration and log files should only be stored on internal storage where\nthey can be effectively protected.\n\nMulti-user external storage\n---------------------------\n\nStarting in Android 4.2, devices can support multiple users, and external\nstorage must meet the following constraints:\n\n- Each user must have their own isolated primary external storage, and must not have access to the primary external storage of other users.\n- The `/sdcard` path must resolve to the correct user-specific primary external storage based on the user a process is running as.\n- Storage for large OBB files in the `Android/obb` directory may be shared between multiple users as an optimization.\n- Secondary external storage must not be writable by apps, except in package-specific directories as allowed by synthesized permissions.\n\nThe default platform implementation of this feature leverages Linux kernel\nnamespaces to create isolated mount tables for each Zygote-forked process,\nand then uses bind mounts to offer the correct user-specific primary external\nstorage into that private namespace.\n\nAt boot, the system mounts a single emulated external storage FUSE daemon\nat `EMULATED_STORAGE_SOURCE`, which is hidden from apps. After\nthe Zygote forks, it bind mounts the appropriate user-specific subdirectory\nfrom under the FUSE daemon to `EMULATED_STORAGE_TARGET` so that\nexternal storage paths resolve correctly for the app. Because an app lacks\naccessible mount points for other users' storage, they can only access\nstorage for the user it was started as.\n\nThis implementation also uses the shared subtree kernel feature to\npropagate mount events from the default root namespace into app namespaces,\nwhich ensures that features like ASEC containers and OBB mounting continue\nworking correctly. It does this by mounting the rootfs as shared, and then\nremounting it as slave after each Zygote namespace is created.\n\nMultiple external storage devices\n---------------------------------\n\nStarting in Android 4.4, multiple external storage devices are surfaced\nto developers through `Context.getExternalFilesDirs()`,\n`Context.getExternalCacheDirs()`, and\n`Context.getObbDirs()`.\n\n\u003cbr /\u003e\n\nExternal storage devices surfaced through these APIs must be a semi-permanent part of the device (such as an SD card slot in a battery compartment). Developers expect data stored in these locations to be available over long periods of time. For this reason, transient storage devices (such as USB mass storage drives) should not be surfaced through these APIs.\n\n\u003cbr /\u003e\n\nThe `WRITE_EXTERNAL_STORAGE` permission must only grant write\naccess to the primary external storage on a device. Apps must not be\nallowed to write to secondary external storage devices, except in their\npackage-specific directories as allowed by synthesized\npermissions. Restricting writes in this way ensures the system can clean\nup files when applications are uninstalled.\n\nUSB media support\n-----------------\n\nAndroid 6.0 supports portable storage devices which are only connected to the\ndevice for a short period of time, like USB flash drives. When a user inserts a\nnew portable device, the platform shows a notification to let them copy or\nmanage the contents of that device.\n\nIn Android 6.0, any device that is not adopted is considered portable. Because\nportable storage is connected for only a short time, the platform avoids heavy\noperations such as media scanning. Third-party apps must go through the [Storage Access Framework](https://developer.android.com/guide/topics/providers/document-provider.html) to interact with files on portable storage; direct access is explicitly\nblocked for privacy and security reasons."]]