Android 11 AMA: ללא צילומי מסך גלילה, השקות אפליקציות מהירות יותר, ועוד

אתמול פרסמה גוגל אנדרואיד 11 בטא 2, מביאים את ה-SDK הסופי, ה-NDK, המשטחים הפונים לאפליקציה, התנהגויות פלטפורמה והגבלות על ממשקים שאינם SDK למפתחים. היום, גוגל עונה על שאלות הקשורות לאנדרואיד 11 בקהילת /r/AndroidDev של Reddit לאחר הצגת שאלות בשבוע שעבר. הנה תקציר של כל מה שלמדנו מה-AMA של גוגל (Ask Me Anything).

אחת התכונות הצפויות ביותר של אנדרואיד 11 לא תהיה זמינה כאשר מערכת ההפעלה יוצא מבטא ב-8 בספטמבר: גלילה של צילומי מסך. בהתחלה מתוכנן להשקה באנדרואיד 11, גוגל אישרה כעת שהתכונה "לא עשתה את החתך עבור R." Android 11 Developer Preview 1 ו לכל מהדורות הבאות של DP ו-Beta יש כפתור מציין מיקום לצילום מסך גלילה שיכול להיות עלה באופן ידני עם פקודת מפתח נסתרת, אבל הקשה על הכפתור פשוט מציגה הודעת טוסט המציינת שהתכונה "לא מיושמת".

קיווינו שהפיצ'ר יעשה את דרכו לבטא או אפילו רק למהדורה היציבה, אבל נראה שזה פשוט לא יקרה.

ברור שהחדשות האלה ירגיזו חלק מהמשתמשים. אחרי הכל, יצרני OEM רבים מחזיקים בתכונה זו בתוכנה משלהם במשך שנים, אז מה לוקח לגוגל כל כך הרבה זמן להוסיף אותה לטלפונים של Pixel? כפי שהסביר דן סנדלר מצוות מערכת ממשק המשתמש של גוגל, הבעיה היא שגוגל רוצה לעשות את זה נכון. כמה יישומי צילומי מסך גלילה בחוץ פשוט מחקים גלילה ואז מחברים יחד מספר צילומי מסך כשהמסך זז. אם אי פעם עסקתם באוטומציה של ממשק משתמש באנדרואיד, תדע שזה לא תמיד עובד מאז, כפי שמר סנדלר מזכיר, אפליקציות יכולים להשתמש ב"RecyclerView בתקן ביצה או שהטמיעו מנוע גלילה מואץ OpenGL משלהם." מאז שגוגל מתכננת ליישם תכונה זו לא רק עבור טלפונים חכמים של Pixel אלא עבור כל המערכת האקולוגית של אנדרואיד כחלק מ-AOSP, הם צריכים לוודא זה יעבוד את כל אפליקציות ולא רק "אפליקציה אחת או שתיים שנבחרו ביד במכשיר מסוים".

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

דרישת CDD חדשה ליידע את המשתמשים על הגבלות רקע

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

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

יש כמה דברים לקחת מהתגובה הזו. ראשית, גוגל רוצה שיצרני OEM יהיו שקופים יותר עם המשתמשים לגבי מגבלות האפליקציות ברקע שהם מיישמים. בדקתי את מסמך הגדרת התאימות של Android 11 (שלא יצא לאור) ומצאתי את התוספת המוצעת הבאה לסעיף 3.5 - תאימות התנהגותית של API:

אם יישומי מכשירים מיישמים מנגנון קנייני להגבלת יישומים והמנגנון הזה מגביל יותר מאשר דלי המתנה "נדיר" ב-AOSP, הם:

[C-1-5] חייבים ליידע את המשתמשים אם הגבלות אפליקציה מוחלות על אפליקציה באופן אוטומטי. (חדש) אין לספק מידע כזה לפני 24 שעות לפני החלת הגבלות כאלה.

(הערה) עצירה בכוח נחשבת למגבילה יותר מ"נדיר" וחייבת לעמוד בכל הדרישות לפי 3.5.1, כולל 3.5.1/C-1-5 החדש

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

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

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

גיבויים משופרים של מכשיר למכשיר

בחודש שעבר, ראינו שינוי בתיעוד של אנדרואיד 11 רמז על תמיכה בגיבוי נתונים מקומיים טובים יותר. באנדרואיד 11, המערכת תתעלם מהתכונה allowBackup Manifest עבור כל אפליקציה שמכוונת לרמת API 30 כאשר המשתמש יוזם העברה "מכשיר למכשיר" של קבצי אפליקציה. גוגלר אליוט סטוק אומר שתכונה זו נועדה להקל בהרבה על יצרני טלפונים לבנות כלי העברת מכשיר למכשיר" כגון "מוצר Smart Switch המצוין של סמסונג" לעזור "להבטיח העברת אפליקציות בצורה אמינה יותר בין מכשירים מנקודת מבט של משתמש." למרבה הצער, זה לא חל על גיבויים מבוססי ענן, מכיוון שגוגל רוצה "לתת למפתחי תוכנה שליטה על מה קורה עם נתוני האפליקציה שלהם." ככזה, אנדרואיד 11 עדיין תכבד את התכונה allowBackup עבור כל גיבוי ושחזור מבוסס ענן, כמו דרך Google Drive המובנה של שירות Google Play גיבוי. לבסוף, גוגל מכירה בכך שתקרת הגיבוי של 25MB לאפליקציה עשויה שלא להספיק עבור מפתחים מסוימים, ולכן הם בוחנים דרכים לפתור זאת. עם זאת, גיבויים מקומיים למחשב אינם בבחינה, וגוגל חוזרת על תוכניתם לעשות זאת ביטול גיבוי adb במהדורה עתידית של אנדרואיד.

מפתחים מוזמנים ליישם שיטות העברת נתונים ללא חיכוך. ה ספריית Block Store החדשה, שהיא חלק מספריית שירותי הזהות של Google, נועדה להקל על הכניסה לאפליקציות ששוחזרו מהענן במכשירים חדשים, אבל זה תלוי במפתחים לבחור אם הם רוצים ליישם זאת או לא סִפְרִיָה.

מהירויות הפעלה מהירות יותר של אפליקציה עם תהליך קריאה קדימה (IORap)

גוגל תמיד מתנסה בדרכים לשיפור הביצועים באנדרואיד. אחת התכונות המעט ידועות שהוסיפו באנדרואיד 10 נקראת מאגר התהליכים הבלתי מיוחדים (USAP). תכונה זו מבטלת את התפצלות ה-Zygote במהלך תהליך ההפעלה של האפליקציה, וחוסכת כ-5 אלפיות השנייה במהירויות ההפעלה הממוצעות של האפליקציה במכשיר Pixel 2. התכונה כרגע מושבת כברירת מחדל ב-AOSP, וגוגל מסבירה שהשימוש הנוסף בזיכרון שלו עדיין טעון בדיקה. אבל מה שמעניין יותר הוא תכונה חדשה שמגיעה לאנדרואיד 11 בשם I/O Read Ahead Process (IORap). לפי גוגל, תכונה זו תוביל ל"סטארט-אפים קרים מהירים ביותר מ-5% עם מקרי גיבור שיגיעו ל-20% מהר יותר." תכונה זו "ישאוף מראש פריטי יישומים (כמו קוד ומשאבים) במהלך תהליך האתחול" כדי להגביר את השקת האפליקציה מהירויות.

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

שינויים באחסון בהיקף של אנדרואיד 11 - מדוע הגישה ל/הורדות מוגבלת?

אפליקציות המכוונות ל-Android 11 ומשתמשות בכוונה ACTION_OPEN_DOCUMENT_TREE לבקש גישה לספריות ספציפיות במכשיר החיצוני אחסון לא יוכל עוד לבקש ממשתמשים גישה לספריית הבסיס של האחסון החיצוני (/data/media/{user}), הורד ספרייה (/data/media{user}/Download), או כל אחת מספריות הנתונים הספציפיות לאפליקציה באחסון החיצוני (/Android/data או /Android/obb). מדוע הגישה לספריית ההורדות מוגבלת? לפי גוגל Roxanna Aliabadi, זה בגלל שתיקיית ההורדות "היא בסיכון הגבוה ביותר להחזיק מידע פרטי." כדוגמה, משתמשים שמורידים את המס שלהם החזרות או דפי בנק לא צריכים לדאוג לגבי האפשרות שאפליקציות ינצלו לרעה את גישת הקריאה הרציפה שלהן ל- מַדרִיך. גוגל אומרת שלבוחר המסמכים יהיה "טקסט מעודכן...כדי לציין שאנדרואיד הגבילה תיקיות מסוימות כדי להיבחר." זה מקווה להפחית את הבלבול לגבי הסיבה שהם לא יכולים להעניק לאפליקציות גישה לספריות מסוימות יותר.

למידע נוסף על השינויים הקרובים במדיניות האחסון וההפעל בהיקף, עיין במאמר זה.

נושאים שונים

• עמדת גוגל בנושא השתרשות/מודדינג
  • ג'ף ביילי מצוות AOSP של גוגל חוזר על עמדת החברה לגבי תמיכה בבחירה. גוגל "תמשיך להבטיח ששינוי/השרשה של קו מכשירי ה-Pixel אפשרי", אך גם "תתמוך בבחירה של יצרני OEM לא להתיר את המכשירים שלהם להיות מושרשים." יתר על כן, גוגל נותנת למפתחי תוכנה את הבחירה "לא לאפשר לתוכנה שלהם לפעול במכשירים מושרשים", בהתייחס לשינויים האחרונים ב זיהוי חבלה בתוכנה של ה-API של SafetyNet Attestation.
• מה קרה ל"פתוח והגדר כברירת מחדל"?
  • אנדרואיד 10 תוצרת זה קצת מעצבן להגדיר אפליקציה כמטפל ברירת המחדל עבור קישורים ספציפיים, שלדברי גוגל נעשה כדי להגן על משתמשים מפני "אפליקציות נצלניות". גוגל נסוגה על שינוי זה לאחר חשיבה מחודשת, תוך ביצוע "מספר שינויים מאחורי הקלעים" כדי להגן על המשתמש.
• משתמש ב-Vulkan Graphics API לעיבוד ממשק המשתמש?
  • גוגל מתכננת בסופו של דבר להשתמש את Vulkan Graphics API לעיבוד ממשק המשתמש, מה שיניב כמה שיפורים בביצועים. זה עדיין בהערכה, אבל לחברה לא היו פרטים לחלוק.
• חסר CallScreeningService במכשירים רבים
  • אפליקציות אנדרואיד יכולות ליישם את ממשק API של CallScreeningService ליירט שיחות נכנסות ויוצאות חדשות, מה שמאפשר להם לזהות את המתקשר ולקבל או לדחות את השיחה. למרות שזהו ממשק API מתועד רשמית, יש כנראה יצרני OEM רבים שאינם מיישמים אותו כראוי, לפי המפתח /u/_zeromod_. גוגל מאשר שה-API הזה מאומת על ידי Suite Test Compatibility (CTS), חבילת בדיקה אוטומטית שכל המכשירים חייבים לעבור כדי להיחשב תואמי אנדרואיד. מכל סיבה שהיא, ה-API הזה מחזיר לאפס כאשר קוראים למכשירים של יצרני OEM כמו Huawei, Vivo, Xiaomi או סמסונג, כך שסביר להניח שיש ליצרני OEM אלה באג בתוכנה שלהם.
• אין תוכניות למסגרת תוסף אודיו
  • מפתח שאל את גוגל אם הם מתכננים ליישם מסגרת תוסף שמע כמו יחידות האודיו של אפל, אבל התשובה הוא שלא סביר שזה יקרה בעתיד הקרוב.

אתה יכול לקרוא את כל התשובות מצוות ההנדסה של אנדרואיד כאן. הצוות מדבר קצת על Java, Kotlin, מערכת הבנייה של אנדרואיד, ה-API של CameraX ונושאים נוספים בכמה הערות. יש גם כמה הערות לגבי Wear OS, Android TV ו-Android Auto, אבל גוגל בעיקר חוזרת העבודה הקיימת שלהם על הפלטפורמות הללו ואומרת למפתחים להישאר מעודכנים למידע נוסף במהלך "אנדרואיד מעבר לטלפונים"שבוע שמתחיל ב-10 באוגוסט.