Storage

סמל HAL של אחסון חיצוני ב-Android

מערכת Android התפתחה עם הזמן כדי לתמוך במגוון רחב של תכונות וסוגים של מכשירי אחסון. כל הגרסאות של Android תומכות במכשירים עם אחסון מסורתי, כולל אחסון נייד ואחסון אמולציה. אחסון נייד יכול לקבל מדיה פיזית, כמו כרטיס SD או USB, שמיועד לאחסון קבצים ולהעברת נתונים זמנית. המדיה הפיזית עשויה להישאר במכשיר למשך זמן רב, אבל היא לא קשורה למכשיר וניתן להסיר אותה. כרטיסי SD זמינים כאחסון נייד מאז Android 1.0, ובגרסה 6.0 של Android נוספה תמיכה ב-USB. אחסון Emulated מתאפשר על ידי חשיפת חלק מהאחסון הפנימי באמצעות שכבת אמולציה, והוא זמין החל מ-Android 3.0.

החל מגרסה 6.0 של Android, מערכת Android תומכת ב אחסון מתאים, שמסופק על ידי מדיה פיזית, כמו כרטיס SD או USB, שמאובטח ומפורמט כך שיפעל כמו אחסון פנימי. באחסון שניתן להתאמה אפשר לאחסן את כל סוגי נתוני האפליקציה.

הרשאות

הגישה לאחסון חיצוני מוגנת על ידי הרשאות שונות ב-Android. החל מ-Android 1.0, הרשאת הכתיבה מוגנת באמצעות ההרשאה WRITE_EXTERNAL_STORAGE. החל מגרסה 4.1 של Android, הרשאת הקריאה מוגנת באמצעות ההרשאה READ_EXTERNAL_STORAGE.

החל מגרסה 4.4 של Android, הבעלים, הקבוצה והמצבים של קבצים במכשירי אחסון חיצוניים נוצרים על סמך מבנה הספריות. כך אפליקציות יכולות לנהל את הספריות הספציפיות לחבילה שלהן באחסון החיצוני בלי שתצטרכו להעניק להן את ההרשאה הרחבה WRITE_EXTERNAL_STORAGE. לדוגמה, לאפליקציה עם שם החבילה com.example.foo יש עכשיו גישה חופשית ל-Android/data/com.example.foo/ במכשירי אחסון חיצוני ללא הרשאות. ההרשאות המשולבות האלה מתקבלות על ידי אריזה של מכשירי אחסון גולמיים ב-daemon של FUSE.

החל מ-Android 10, אפליקציות שמטרגטות את Android 9 ונמוכות יותר באחסון מדור קודם, ויכולות להביע הסכמה לאחסון מבודד. אפליקציות שמטרגטות את Android 10 ומשתמשות כברירת מחדל באחסון מבודד יכולות לבטל את ההסכמה באופן זמני. כדי לשנות את מצב ברירת המחדל, משתמשים במאפיין המניפסט 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 14 מבוססת על הרשאות מדיה מפורטות, שמאפשרות למשתמשים להעניק גישה חלקית לספריית המדיה החזותית שלהם כשאפליקציות מבקשות הרשאות מדיה. מידע נוסף זמין במאמר הענקת גישה חלקית לתמונות ולסרטונים.

הרשאות זמן ריצה

ב-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() כדי להטמיע את התכונה הזו, נדרשת גרסה 3.8 של Linux לפחות, אבל התיקונים הועברו לאחור אל Linux 3.4. אפשר להשתמש בבדיקת ה-CTS של PermissionsHostTest כדי לאמת התנהגות נכונה של הליבה.