
Android มีการพัฒนาอยู่ตลอดเวลาเพื่อรองรับอุปกรณ์เก็บข้อมูลประเภทต่างๆ และคุณลักษณะต่างๆ Android ทุกรุ่นรองรับอุปกรณ์ที่มี ที่เก็บข้อมูลแบบดั้งเดิม ซึ่งรวมถึงที่เก็บข้อมูลแบบพกพาและจำลอง อุปกรณ์จัดเก็บข้อมูล แบบพกพา สามารถจัดเตรียมได้จากสื่อทางกายภาพ เช่น การ์ด SD หรือ USB ซึ่งใช้สำหรับการถ่ายโอนข้อมูลชั่วคราว/การจัดเก็บไฟล์ สื่อทางกายภาพอาจยังคงอยู่กับอุปกรณ์เป็นระยะเวลานาน แต่ไม่ได้เชื่อมโยงกับอุปกรณ์และอาจถูกลบออก การ์ด SD มีให้บริการเป็นที่เก็บข้อมูลแบบพกพาตั้งแต่ Android 1.0; Android 6.0 เพิ่มการรองรับ USB ที่เก็บข้อมูล จำลอง มีให้โดยการเปิดเผยส่วนหนึ่งของที่เก็บข้อมูลภายในผ่านเลเยอร์จำลอง และพร้อมใช้งานตั้งแต่ Android 3.0
ตั้งแต่ Android 6.0 เป็นต้นมา Android รองรับ พื้นที่เก็บข้อมูล ที่ปรับใช้ได้ ซึ่งมีให้โดยสื่อทางกายภาพ เช่น การ์ด SD หรือ USB ซึ่งเข้ารหัสและจัดรูปแบบให้ทำงานเหมือนที่เก็บข้อมูลภายใน ที่เก็บข้อมูลที่ปรับใช้ได้สามารถเก็บข้อมูลแอปพลิเคชันได้ทุกประเภท
สิทธิ์
การเข้าถึงที่จัดเก็บข้อมูลภายนอกได้รับการปกป้องโดยสิทธิ์ต่างๆ ของ Android ตั้งแต่ Android 1.0 เป็นต้นไป การเข้าถึงการเขียนจะได้รับการปกป้องด้วยสิทธิ์ WRITE_EXTERNAL_STORAGE
เริ่มตั้งแต่ Android 4.1 การเข้าถึงการอ่านได้รับการป้องกันด้วยการอนุญาต READ_EXTERNAL_STORAGE
เริ่มตั้งแต่ Android 4.4 เป็นต้นไป เจ้าของ กลุ่ม และโหมดของไฟล์ในอุปกรณ์จัดเก็บข้อมูลภายนอกจะได้รับการสังเคราะห์ตามโครงสร้างไดเร็กทอรี สิ่งนี้ทำให้แอพสามารถจัดการไดเร็กทอรีเฉพาะแพ็คเกจบนที่จัดเก็บข้อมูลภายนอกโดยไม่ต้องใช้สิทธิ์ WRITE_EXTERNAL_STORAGE
แบบกว้าง ตัวอย่างเช่น แอปที่มีชื่อแพ็กเกจ com.example.foo
สามารถเข้าถึง Android/data/com.example.foo/
ได้อย่างอิสระบนอุปกรณ์จัดเก็บข้อมูลภายนอกโดยไม่ต้องให้สิทธิ์ สิทธิ์การสังเคราะห์เหล่านี้ทำได้โดยการรวมอุปกรณ์เก็บข้อมูลดิบไว้ใน FUSE daemon
เริ่มตั้งแต่ Android 10 เป็นต้นไป แอปที่กำหนดเป้าหมายเป็น Android 9 และค่าเริ่มต้นที่ต่ำกว่าเป็นพื้นที่เก็บข้อมูลแบบเดิม และสามารถ เลือก ใช้พื้นที่เก็บข้อมูลแยกได้ แอปที่กำหนดเป้าหมายเป็น Android 10 และเริ่มต้นเป็นพื้นที่เก็บข้อมูลแยกสามารถ เลือกไม่ใช้ได้ชั่วคราว ใช้แอตทริบิวต์ manifest requestLegacyExternalStorage
ซึ่งควบคุมโมเดลพื้นที่จัดเก็บ เพื่อเปลี่ยนสถานะเริ่มต้น
เนื่องจากการอนุญาตทั้ง READ_EXTERNAL_STORAGE
และ WRITE_EXTERNAL_STORAGE
เป็นแบบจำกัดแบบซอฟต์ หากโปรแกรมติดตั้งไม่ได้อนุญาตแอปไว้ในรายการที่อนุญาตพิเศษ การอนุญาตจะควบคุมการเข้าถึงคอลเลกชันเสียงและภาพเท่านั้น โดยไม่มีการเข้าถึงการ์ด SD สิ่งนี้มีผลแม้ว่าแอพจะขอพื้นที่เก็บข้อมูลเดิม สำหรับข้อมูลเพิ่มเติมเกี่ยวกับทั้งข้อจำกัดแบบตายตัวและข้อจำกัดแบบซอฟต์ โปรดดู ข้อจำกัดแบบฮาร์ดและซอฟต์ใน Android 10
หากโปรแกรมติดตั้งอนุญาตพิเศษ แอพที่ทำงานในโหมดดั้งเดิมจะได้รับสิทธิ์แบบไม่แยก การอนุญาตจะควบคุมการเข้าถึงการ์ด SD และคอลเลคชันเสียงและภาพ กรณีนี้จะเกิดขึ้นเมื่อแอปกำหนดเป้าหมายเป็น Android 9 หรือต่ำกว่าและไม่ได้เลือกใช้พื้นที่เก็บข้อมูลแยกต่างหาก หรือกำหนดเป้าหมายเป็น Android 10 และเลือกไม่ใช้
สามารถระบุสถานะรายการที่อนุญาตพิเศษได้ในขณะติดตั้งเท่านั้น และไม่สามารถเปลี่ยนแปลงได้จนกว่าจะติดตั้งแอปแล้ว
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าสิทธิ์ READ_EXTERNAL_STORAGE
โปรดดูที่ setWhitelistedRestrictedPermissions()
ในคลาส PackageInstaller.SessionParams
Android 13 แนะนำการอนุญาตสื่อแบบละเอียดเพื่อสนับสนุนแอพที่เข้าถึงไฟล์มีเดียที่สร้างโดยแอพอื่น แอปต้องขอสิทธิ์สื่อแบบละเอียดหนึ่งรายการขึ้นไปซึ่งระบุไว้ใน สิทธิ์สื่อแบบละเอียด แทนสิทธิ์ READ_EXTERNAL_STORAGE
สิทธิ์รันไทม์
Android 6.0 ขอแนะนำรูปแบบ การอนุญาตรันไทม์ ใหม่ที่แอพร้องขอความสามารถเมื่อจำเป็นในรันไทม์ เนื่องจากโมเดลใหม่มีสิทธิ์ READ/WRITE_EXTERNAL_STORAGE
แพลตฟอร์มจึงจำเป็นต้องให้สิทธิ์การเข้าถึงพื้นที่เก็บข้อมูลแบบไดนามิกโดยไม่ฆ่าหรือรีสตาร์ทแอปที่ทำงานอยู่ ทำสิ่งนี้โดยรักษามุมมองที่แตกต่างกันสามแบบของอุปกรณ์เก็บข้อมูลที่ติดตั้งทั้งหมด:
-
/mnt/runtime/default
จะแสดงต่อแอปที่ไม่มีสิทธิ์ในการจัดเก็บพิเศษ และไปยังรูทเนมสเปซที่มีadbd
และคอมโพเนนต์ระบบอื่นๆ อยู่ -
/mnt/runtime/read
แสดงไปยังแอปที่มีREAD_EXTERNAL_STORAGE
(ตั้งค่าLEGACY_STORAGE
สำหรับ Android 10) -
/mnt/runtime/write
แสดงไปยังแอปที่มีWRITE_EXTERNAL_STORAGE
ในเวลา Zygote fork เราสร้างเนมสเปซเมานต์สำหรับแต่ละแอปที่รันอยู่และผูกเมานต์มุมมองเริ่มต้นที่เหมาะสมเข้าที่ ในภายหลัง เมื่อให้สิทธิ์รันไทม์ vold
จะกระโดดเข้าไปในเมานต์เนมสเปซของแอพที่รันอยู่แล้ว และผูกเมานต์มุมมองที่อัปเกรดเข้าที่ โปรดทราบว่าการลดระดับสิทธิ์จะส่งผลให้แอปถูกฆ่าเสมอ
ฟังก์ชัน setns()
ที่ใช้ในการนำคุณลักษณะนี้ไปใช้ต้องใช้ Linux 3.8 เป็นอย่างน้อย แต่แพตช์ได้รับการแบ็คพอร์ตไปยัง Linux 3.4 เรียบร้อยแล้ว สามารถใช้การทดสอบ PermissionsHostTest
CTS เพื่อตรวจสอบพฤติกรรมเคอร์เนลที่ถูกต้อง