אחסון בהיקף ב-Android Q מאלץ מפתחים להשתמש ב-SAF, וזה מבאס

השינויים ב-Scoped Storage ב-Android Q הם כאב ראש להתמודד איתו, כי ל- Storage Access Framework יש כמה פגמים כרגע.

אנדרואיד Q משנה מהותית את אופן פעולת האחסון בטלפון שלך. בכל גרסה עד פאי, האחסון של אנדרואיד עבד כמו מחשב שולחני: אתה יכול להשתמש בכל אפליקציה שתרצה לקרוא או לכתוב כל קובץ (אם אתה מעניק לאפליקציה הרשאה לעשות זאת). עם Q, גוגל מציגה (ודורשת) "אחסון בהיקף," מה שגורם לאנדרואיד לעבוד יותר כמו אייפון, שבו האחסון מבודד לכל אפליקציה. אפליקציה יכולה לגשת רק לקבצים שלה, ואם היא מוסרת, כל הקבצים שלה נמחקים.

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

אפליקציות שצריכות גישה כללית למערכת קבצים, למשל. חבילת משרד, עורך תמונות או מנהל קבצים, יצטרכו כעת להשתמש ב-Android API שנקרא "מסגרת גישה לאחסון" (SAF), עבור כל פעולות הקבצים. SAF זמין מאז אנדרואיד 5.0 Lollipop, אך מפתחים נוטים לא להשתמש בו אלא אם כן נדרש, מכיוון שיש לו גרסה קשה וגרועה API מתועד, חווית משתמש גרועה, ביצועים גרועים ואמינות ירודה (בעיקר בצורה של יישום ספציפי לספק מכשיר נושאים). כתוצאה מהקושי במעבר ל-SAF, גוגל החליטה לאפשר אפליקציות שעדיין לא מעידות התמיכה ב-Android Q תעבוד כמו פעם, אבל זה ישתנה כאשר חנות Play מחייבת את כל האפליקציות לתמוך ב-Q שנה הבאה.

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

גוגל שיפרה לפחות את התהליך הזה Q בטא 3, מכיוון שבטאס קודמות לא אפשרו לאפליקציה אפילו להציע מיקום למשתמש לבחור, אשר דרש מהמשתמש לעשות לא מעט עבודה כדי למצוא בפועל את האחסון הראשי של המכשיר שלהם.

ביצועי קלט/פלט קבצים סובלים במידה מסוימת תחת SAF, אבל הבעיה הבולטת ביותר טמונה בקובץ פעולות ספרייה, שבהן היא איטית פי 25 עד 50 מהגישה הרגילה לקבצים האפשרית ב פַּאִי. במקרה של מנהלי קבצים, זה אומר שייקח יותר סדרי גודל לבצע חיפושים וחישובי שימוש באחסון. דוח באג עם אפליקציית הדגמה הוא זמין פה.

הפעלת בדיקה לדוגמה של SAFTest המציגה את הבדל הביצועים בין ה-API של I/O של קבצים קונבנציונליים עם SAF.

בעיית ביצועים גדולה עוד יותר היא שאפליקציות מסוימות יצטרכו להעתיק קבצים לאזור ה"אחסון בהיקף" המקומי שלהם לפני שהם יוכלו לעבוד איתן. זה יכול להיות בעייתי כאשר קבצים כאלה הם בגודל של מספר גיגה-בייט, למשל. במקרה של קבצי וידאו או ארכיונים דחוסים. אפליקציות אנדרואיד רבות מנצלות את המספר המדהים של ספריות Java בקוד פתוח בקהילת המפתחים, וספריות אלה דורשות בדרך כלל גישה ישירה למערכת הקבצים כדי לעבוד. הם אינם ספציפיים לאנדרואיד וידרשו כתיבה מחדש כדי לעבוד עם SAF. גרוע מכך, רבות מהספריות הפנימיות של אנדרואיד עצמו לא יעבדו עם זה, כמו מנהל החבילות או ה-zip API. לדוגמה, מנהל קבצים אפילו לא יוכל להציג את הסמל של קובץ APK (באמצעות ה-API הסטנדרטי של אנדרואיד) מבלי להעתיק תחילה את כל ה-APK לאזור האחסון שלו. דוח שגיאות.

עבור אנשים בעלי נטייה טכנית, כיום ניתן להשבית את "אחסון בהיקף" של Android Q על בסיס אפליקציה באמצעות ADB באמצעות פקודת appops. משתמשי שורש יכולים לבצע את הפקודות ישירות במכשיר שלהם ללא מחשב שולחני. פקודות כאלה מתוארות בתיעוד כתכונות מפתח ולכן ניתן להסירן בכל עת.

אפשר גישה כללית לאחסון עבור אפליקציה:

adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-name

השבת את הגישה הכללית לאחסון עבור אפליקציה:

adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-name

גוגל מציגה את יתרונות האבטחה והפרטיות של השינוי הזה, אבל מבחינה טכנית, אין שיפור. לאפליקציות הייתה יכולת לאחסן קבצים באופן פרטי מאז אנדרואיד 1.0, וכמעט כל האפליקציות עושות שימוש ביכולת זו. כאשר אתה מעניק לאפליקציה גישה לספריית הבסיס של האחסון שלך באמצעות SAF, היא יכולה לקרוא, לכתוב ולשלוח כל קובץ שהיא רוצה למפתח המרושע שלו בדיוק באותו האופן שהוא יכול היה כשהענקת לאפליקציה גישה לאחסון ב-Pie.

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

לא ידוע אילו יתרונות גוגל מקווה להשיג עם השינוי הזה. הסיבה המוצהרת הרשמית בתיעוד הבטא של Android Q היא "לתת למשתמשים יותר שליטה על הקבצים שלהם ולהגביל את הקבצים עִרבּוּביָה." אחסון בהיקף, במתכונתו הנוכחית, הוא מגבלה חדשה של מה שהמשתמש רשאי לעשות, לא הרחבה של לִשְׁלוֹט. הטענה של הפחתת העומס עשויה להיות תקפה במידה מסוימת, אבל רק בגלל שהשינוי מקטין את היכולת להשתמש בקבצים בכלל. ו"העומס" גדל כאשר אתה מחשיב את הבעיה של אפליקציות מסוימות צריכות כעת לשכפל קבצים כדי לעבוד איתן.

אם גוגל באמת מודאגת לתת למשתמשים שליטה רבה יותר על קבצים ובלאגן, עליהם לבנות א פתרון שמתייחס ישירות לכך, במקום מיתוג כוזב של עיצוב אנדרואיד Q הנוכחי ככזה הַשׁבָּחָה. התשובה הפשוטה ביותר תהיה לאפשר למשתמשים להחליט אם הם רוצים שלאפליקציה תהיה גישה מוגבלת או כללית למערכת הקבצים, באמצעות תיבת הדו-שיח של בקשת הרשאת אחסון קיימת. אם יש כאן דאגה מיוחדת למשתמשים שמקבלים החלטות גרועות כאן, זה בהחלט אפשרי להפוך את הדו-שיח הזה לבולט יותר ולדרוש אינטראקציה נוספת של המשתמש כדי לאשר אפליקציה במלואה גִישָׁה.

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


הערת העורך: זהו מאמר אורח שנכתב על ידי חבר בכיר ב-XDA tliebeck, הידוע בעיקר בזכות עבודתו על סייר קבצים FX. התוכן של מאמר זה משקף את דעתו וניתוחו שלו לגבי מגבלות האחסון בהיקף של אנדרואיד Q, עם קלט ועריכה מינימליים של מישאל רחמן, העורך הראשי של XDA-Developers. פנינו לגוגל כדי לשאול אותם על חלק מהחששות הללו, אך לא שמענו מהחברה עד מועד הפרסום.