שינויים בהתנהגות: כל האפליקציות

פלטפורמת Android 17 כוללת שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים רלוונטיים לכל האפליקציות כשהן פועלות ב-Android 17, בלי קשר ל-targetSdkVersion. אתם צריכים לבדוק את האפליקציה ולשנות אותה לפי הצורך כדי לתמוך בשינויים האלה, במקרים הרלוונטיים.

חשוב גם לעיין ברשימת השינויים בהתנהגות שמשפיעים רק על אפליקציות שמטרגטות ל-Android 17.

אבטחה

‫Android 17 כולל את השיפורים הבאים באבטחת המכשיר והאפליקציות.

תוכנית להוצאה משימוש של usesClearTraffic

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

חשוב לדעת שקבצי הגדרות של אבטחת רשת נתמכים רק ברמות API‏ 24 ומעלה. אם רמת ה-API המינימלית של האפליקציה נמוכה מ-24, צריך לבצע את שני השלבים הבאים:

  • הגדרת המאפיין usesCleartextTraffic לערך true
  • שימוש בקובץ תצורת רשת

אם רמת ה-API המינימלית של האפליקציה היא 24 ומעלה, אפשר להשתמש בקובץ הגדרות רשת ולא צריך להגדיר את usesCleartextTraffic.

הגבלת הרשאות URI משתמעות

נכון לעכשיו, אם אפליקציה מפעילה Intent עם URI שיש לו את הפעולה Send, SendMultiple או ImageCapture, המערכת מעניקה באופן אוטומטי לאפליקציית היעד הרשאות קריאה וכתיבה של ה-URI. אנחנו מתכננים לשנות את ההתנהגות הזו ב-Android 18. לכן מומלץ שאפליקציות יעניקו במפורש את הרשאות ה-URI הרלוונטיות במקום להסתמך על המערכת שתעניק אותן.

מגבלות על חנות מפתחות לכל אפליקציה

אפליקציות לא צריכות ליצור מספר גדול מדי של מפתחות ב-Android Keystore, כי זהו משאב משותף לכל האפליקציות במכשיר. החל מ-Android 17, המערכת אוכפת מגבלה על מספר המפתחות שאפליקציה יכולה להיות הבעלים שלהם. המגבלה היא 50,000 מפתחות לאפליקציות שאינן אפליקציות מערכת שמטרגטות ל-Android 17 ואילך, ו-200,000 מפתחות לכל שאר האפליקציות. לאפליקציות מערכת יש מגבלה של 200,000 מפתחות, ללא קשר לרמת ה-API שאליה הן מכוונות.

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

  • אפליקציות שמטרגטות ל-Android 17 ואילך: הפונקציה getNumericErrorCode() מחזירה את הערך החדש ERROR_TOO_MANY_KEYS.
  • כל האפליקציות האחרות: getNumericErrorCode() מחזירה ERROR_INCORRECT_USAGE.

חוויית המשתמש וממשק המשתמש של המערכת

‫Android 17 כוללת את השינויים הבאים, שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.

שחזור ברירת המחדל של חשיפת ה-IME אחרי סיבוב

החל מ-Android 17, כשמתבצע שינוי בהגדרות המכשיר (לדוגמה, באמצעות סיבוב), והאפליקציה לא מטפלת בשינוי הזה בעצמה, מצב החשיפה הקודם של ה-IME לא משוחזר.

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

  • מגדירים את המאפיין android:windowSoftInputMode לערך stateAlwaysVisible.
  • מבקשים את המקלדת הווירטואלית באופן פרוגרמטי ב-method onCreate() של הפעילות, או מוסיפים את method onConfigurationChanged().

קלט אנושי

‫Android 17 כוללת את השינויים הבאים שמשפיעים על האינטראקציה של אפליקציות עם מכשירי קלט אנושיים כמו מקלדות ומשטחי מגע.

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

החל מ-Android 17, אם אפליקציה מבקשת ללכוד את מצביע העכבר באמצעות View.requestPointerCapture() והמשתמש משתמש במשטח מגע, המערכת מזהה את תנועת המצביע ומחוות הגלילה מהמגעים של המשתמש ומדווחת עליהן לאפליקציה באותו אופן כמו תנועות של מצביע וגלגל העכבר מעכבר שנלכד. ברוב המקרים, זה מייתר את הצורך באפליקציות שתומכות בשימוש בעכבר כדי להוסיף לוגיקה מיוחדת לטיפול במשטחי מגע. פרטים נוספים זמינים במאמרי העזרה בנושא View.POINTER_CAPTURE_MODE_RELATIVE.

בעבר, המערכת לא ניסתה לזהות תנועות מלוח המגע, ובמקום זאת העבירה לאפליקציה את המיקומים המוחלטים של האצבעות בפורמט דומה לזה של מגעים במסך מגע. אם אפליקציה עדיין דורשת את הנתונים האלה, היא צריכה להפעיל את ה-method החדש View.requestPointerCapture(int) עם View.POINTER_CAPTURE_MODE_ABSOLUTE במקום זאת.

מדיה

‫Android 17 כוללת את השינויים הבאים בהתנהגות של מדיה.

הגברת האבטחה של אודיו ברקע

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

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

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