اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
مساحة التخزين التقليدية
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتوافق Android مع الأجهزة التي تتضمّن وحدة تخزين تقليدية، والتي يتم تعريفها على أنّها
نظام ملفات لا يراعي حالة الأحرف مع فئات وأوضاع أذونات POSIX غير القابلة للتغيير.
يشمل مفهوم مساحة التخزين التقليدية مساحة التخزين المحاكية والمحمولة.
يتم تعريف مساحة التخزين القابلة للنقل على أنّها أي مساحة تخزين خارجية لا
تستخدمها
النظام، وبالتالي لا يتم تنسيقها أو تشفيرها أو ربطها بجهاز معيّن.
بما أنّ مساحة التخزين الخارجية التقليدية توفّر الحد الأدنى من الحماية للبيانات المخزّنة، ينبغي ألا يخزن رمز النظام البيانات الحسّاسة على مساحة التخزين الخارجية. وعلى وجه التحديد، ينبغي عدم تخزين ملفات الإعدادات والسجلّات إلا على وحدة التخزين الداخلية حيث يمكن حمايتها بفعالية.
مساحة تخزين خارجية مخصّصة لعدة مستخدمين
بدءًا من الإصدار 4.2 من نظام التشغيل Android، يمكن للأجهزة السماح بتسجيل عدة مستخدمين، ويجب أن تستوفي مساحة التخزين الخارجية القيود التالية:
- يجب أن يكون لكل مستخدم مساحة تخزين خارجية أساسية معزولة، ويجب ألا يتمكن من الوصول إلى مساحة التخزين الخارجية الأساسية للمستخدمين الآخرين.
- يجب أن يحلّ مسار
/sdcard
محلّ ملف التخزين الخارجي الأساسي
الصحيح الخاص بالمستخدم استنادًا إلى المستخدم الذي تعمل العملية باسمه.
- قد تتم مشاركة مساحة تخزين ملفات OBB الكبيرة في الدليل
Android/obb
بين عدة مستخدمين كإجراء تحسين.
- يجب ألا تتمكن التطبيقات من الكتابة في مساحة التخزين الخارجية الثانوية، إلا في
الأدلة الخاصة بالحِزم على النحو المسموح به من خلال الأذونات المجمّعة.
يستفيد التنفيذ التلقائي لهذه الميزة على النظام الأساسي من مساحات أسماء ملفّات Linux kernel
لإنشاء جداول تثبيت معزولة لكل عملية تمّ تقسيمها بواسطة Zygote،
ثم يستخدم عمليات الربط لتوفير مساحة التخزين الخارجية الأساسية الخاصة بالمستخدم في مساحة الاسم الخاصة هذه.
عند بدء التشغيل، ينشئ النظام خادم FUSE وحيدًا لمحاكي مساحة تخزين خارجية
في EMULATED_STORAGE_SOURCE
، وهو مخفي عن التطبيقات. بعد
تشعب Zygote، يتم ربط تثبيت الدليل الفرعي المناسب الخاص بالمستخدم
من تحت برنامج FUSE الخدمي إلى EMULATED_STORAGE_TARGET
لكي تتم معالجة مسار التخزين الخارجي بشكل صحيح للتطبيق. ولأنّ التطبيق لا يحتوي على
نقاط تثبيت يمكن الوصول إليها لتخزين المستخدمين الآخرين، لا يمكنه الوصول إلا إلى
مساحة التخزين الخاصة بالمستخدم الذي تم تشغيله باسمه.
يستخدم هذا التنفيذ أيضًا ميزة kernel للفرع الفرعي المشترَك لانتشار أحداث التثبيت من مساحة الاسم الجذر التلقائية إلى مساحات أسماء التطبيقات، مما يضمن مواصلة عمل ميزات مثل حاويات ASEC وتثبيت حِزم OBB بشكلٍ سليم. ويتم ذلك من خلال تركيب نظام الملفات الجذر على أنّه مشترَك، ثم
إعادة تركيبه على أنّه تابع بعد إنشاء كل مساحة اسم Zygote.
أجهزة تخزين خارجية متعددة
بدءًا من الإصدار 4.4 من Android، يتم عرض أجهزة تخزين خارجية متعددة
للمطوّرين من خلال Context.getExternalFilesDirs()
،
Context.getExternalCacheDirs()
،
Context.getObbDirs()
.
يجب أن تكون وحدات التخزين الخارجية التي تظهر من خلال واجهات برمجة التطبيقات هذه
جزءًا شبه دائم من الجهاز (مثل فتحة بطاقة SD في ملف
التفاصيل عن البطارية). يتوقّع المطوّرون أن تكون البيانات المخزّنة في هذه المواقع متاحة
للفترات الطويلة. لهذا السبب، يجب عدم عرض
أجهزة التخزين المؤقت (مثل محركات الأقراص الصلبة USB للاستخدام الجماعي) من خلال
واجهات برمجة التطبيقات هذه.
يجب أن يمنح إذن WRITE_EXTERNAL_STORAGE
إذن الوصول بالكتابة
إلى مساحة التخزين الخارجي الأساسية على الجهاز فقط. يجب عدم
السماح للتطبيقات بالكتابة على أجهزة التخزين الخارجية الثانوية، إلا في
الأدلة الخاصة بالحِزم على النحو المسموح به من قِبل
الأذونات المجمّعة. يضمن حظر عمليات الكتابة بهذه الطريقة أن يتمكّن النظام من تنظيف
الملفات عند إلغاء تثبيت التطبيقات.
يتوافق نظام التشغيل Android 6.0 مع أجهزة التخزين المحمولة التي يتم توصيلها بالجهاز
لفترة قصيرة فقط، مثل محركات الأقراص الوميضية USB. عندما يُدخل أحد المستخدمين
جهازًا محمولًا جديدًا، تعرض المنصة إشعارًا للسماح له بنسخ محتويات ذلك الجهاز أو
إدارتها.
في Android 6.0، يُعتبر أي جهاز غير مُعتمَد محمولًا. بما أنّه يتم توصيل مساحة التخزين المحمولة لفترة قصيرة فقط، تتجنب المنصة العمليات المكثفة، مثل فحص الوسائط. يجب أن تمر التطبيقات التابعة لجهات خارجية عبر إطار عمل الوصول إلى مساحة التخزين للتفاعل مع الملفات على مساحة التخزين المحمولة، ويتم بشكل صريح منع الوصول المباشر إليها لأسباب تتعلّق بالخصوصية والأمان.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]