שינויים בהתנהגות: אפליקציות שמטרגטות את Android מגרסה 17 ואילך

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

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

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

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

ווידג'ט של מגבלת הזיכרון

החל מ-Android 17, באפליקציות שמיועדות ל-Android 17 (רמת API 37) ומעלה, המערכת אוכפת מגבלת זיכרון מחמירה (1.5 * רוחב המסך * גובה המסך * 4) על השימוש המשולב בזיכרון של מפות סיביות וסמלים שנמצאים בחבילת RemoteViews. חריגה מהמגבלות האלה תגרום לשגיאה חמורה IllegalArgumentException ולסגירה של תהליך האפליקציה.

מידע נוסף זמין במאמר בנושא UpdateAppWidget.

פונקציונליות עיקרית

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

הטמעה חדשה של MessageQueue שלא דורשת נעילה

החל מ-Android 17, אפליקציות שמטרגטות את Android 17 (רמת API 37) או גרסה מתקדמת יותר מקבלות הטמעה חדשה ללא נעילה של android.os.MessageQueue. ההטמעה החדשה משפרת את הביצועים ו מפחיתה את מספר הפריימים החסרים, אבל היא עלולה לגרום לשיבוש בלקוחות שמשקפים MessageQueue שדות ושיטות פרטיים.

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

אי אפשר יותר לשנות שדות סופיים סטטיים

באפליקציות שפועלות ב-Android 17 ומעלה ומטרגטות ל-Android 17 (רמת API 37) ומעלה, אי אפשר לשנות שדות של static final. אם אפליקציה מנסה לשנות שדה static final באמצעות רפלקציה, היא תגרום ל-IllegalAccessException. ניסיון לשנות אחד מהשדות האלה באמצעות ממשקי JNI API (כמו SetStaticLongField()) יגרום לקריסת האפליקציה.

נגישות

ב-Android 17 בוצעו השינויים הבאים כדי לשפר את הנגישות.

תמיכה בנגישות של הקלדה במקלדת פיזית ב-IME מורכב

התכונה הזו כוללת ממשקי API חדשים של AccessibilityEvent ושל TextAttribute שמשפרים את קורא המסך הקולי לקלט בשפות CJKV. אפליקציות של CJKV IME יכולות עכשיו לסמן אם נבחר מועמד להמרת טקסט במהלך כתיבת טקסט. אפליקציות עם שדות עריכה יכולות לציין סוגים של שינויי טקסט כששולחים אירועי נגישות של שינוי טקסט. לדוגמה, אפליקציות יכולות לציין ששינוי בטקסט התרחש במהלך כתיבת הטקסט, או ששינוי בטקסט נבע מביצוע commit. כך שירותי נגישות כמו קוראי מסך יוכלו לספק משוב מדויק יותר על סמך אופי השינוי בטקסט.

אימוץ האפליקציה

• אפליקציות IME: כשמגדירים כתיבת טקסט בשדות עריכה, אפליקציות IME יכולות להשתמש ב-TextAttribute.Builder.setTextSuggestionSelected() כדי לציין אם נבחר מועמד ספציפי להמרה.

• אפליקציות עם עריכת שדות: אפליקציות שמנהלות InputConnection מותאם אישית יכולות לאחזר נתונים של מועמדים שנבחרו על ידי קריאה ל-TextAttribute.isTextSuggestionSelected(). אחרי כן, האפליקציות האלה צריכות להפעיל את הפונקציה AccessibilityEvent.setTextChangeTypes() כששולחים אירועים מסוג TYPE_VIEW_TEXT_CHANGED. באפליקציות שמטרגטות ל-Android 17 (רמת API 37) ומשתמשות ב-TextView הסטנדרטי, התכונה הזו מופעלת כברירת מחדל. (כלומר, TextView יטפל באחזור נתונים מ-IME ובהגדרת סוגי שינוי טקסט כששולחים אירועים לשירותי נגישות).

• שירותי נגישות: שירותי נגישות שמבצעים עיבוד של אירועי TYPE_VIEW_TEXT_CHANGED יכולים להפעיל את AccessibilityEvent.getTextChangeTypes() כדי לזהות את אופי השינוי ולהתאים את אסטרטגיות המשוב שלהם בהתאם.

פרטיות

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

ההגדרה ECH (הצפנת Client Hello) מופעלת

ב-Android 17 נוספה תמיכה בפלטפורמה בהצפנת ClientHello‏ (ECH), תוסף ל-TLS שמשפר את פרטיות המשתמשים על ידי הצפנת ה-Server Name Indication‏ (SNI) בתהליך הלחיצת יד של TLS. ההצפנה הזו עוזרת למנוע מצופים ברשת לזהות בקלות את הדומיין הספציפי שאליו האפליקציה מתחברת.

באפליקציות שמטרגטות ל-Android 17 (רמת API 37) ומעלה, נעשה שימוש ב-ECH לחיבורי TLS. ה-ECH פעיל רק אם ספריית הרשת שבה נעשה שימוש באפליקציה (לדוגמה, HttpEngine, ‏ WebView או OkHttp) כוללת תמיכה משולבת ב-ECH, וגם השרת המרוחק תומך בפרוטוקול ECH. אם אי אפשר להגיע להסכמה על ECH, הלקוח שולח תוסף ECH עם תוכן אקראי (מנגנון שנקרא ECH GREASE). מידע נוסף על אופן הפעולה של ECH GREASE זמין ב-RFC 9849.

כדי לאפשר לאפליקציות להתאים אישית את ההתנהגות הזו, ב-Android 17 נוסף רכיב <domainEncryption> חדש לקובץ תצורת אבטחת הרשת. מפתחים יכולים להשתמש בתג <domainEncryption> בתוך התגים <base-config> או <domain-config> כדי לבחור מצב ECH (לדוגמה, "enabled" או "disabled") באופן גלובלי או לכל דומיין.

מידע נוסף זמין במאמר בנושא הצפנה של הודעת Client Hello.

נדרשת הרשאה לגישה לרשת המקומית לאפליקציות שמטרגטות Android 17

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

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

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

הסתרת סיסמאות ממכשירים פיזיים

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

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

אם המשתמש משתמש במסך המגע של המכשיר, המערכת מחילה את ההגדרה החדשה show_passwords_touch.

הגנה על OTP בהודעות SMS רגילות

החל מ-Android 17, מערכת Android מרחיבה את ההגנה שלה על קודי OTP ב-SMS כך שתחול גם על הודעות SMS רגילות (הודעות SMS שמכילות קוד OTP ולא משתמשות בפורמטים WebOTP או SMS Retriever). ברוב האפליקציות שמטרגטות את Android 17 (רמת API 37) ומעלה, הודעות ה-SMS האלה לא זמינות עד שלוש שעות אחרי שהן מתקבלות. העיכוב הזה נועד למנוע גניבת קוד אימות חד-פעמי. במהלך העיכוב של שלוש השעות, השידור של SMS_RECEIVED_ACTION מושהה והשאילתות במסד הנתונים של ספק ה-SMS מסוננות. הודעת ה-SMS זמינה לאפליקציות האלה אחרי העיכוב.

אפליקציות מסוימות, כמו אפליקציית העוזר האישי ל-SMS שמוגדרת כברירת מחדל, אפליקציות נלוות למכשירים מקושרים וכו', מוחרגות מההשהיה הזו. כל האפליקציות שמסתמכות על קריאת הודעות SMS כדי לחלץ מהן קודים לאימות חד-פעמי צריכות לעבור לשימוש בממשקי ה-API של SMS Retriever או SMS User Consent כדי להבטיח שהפונקציונליות תמשיך לפעול.

אבטחה

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

אבטחת פעילות

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

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

• הגברת האבטחה של BAL ושיפור ההסכמה להצטרפות: אנחנו משפרים את ההגבלות על הפעלה של פעילות ברקע (BAL) על ידי הרחבת ההגנה ל-IntentSender. המפתחים צריכים להפסיק להשתמש בקבוע MODE_BACKGROUND_ACTIVITY_START_ALLOWED מדור קודם. במקום זאת, כדאי להשתמש באמצעי בקרה מפורטים כמו MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, שמגביל את הפעלת הפעילות לתרחישים שבהם האפליקציה המתקשרת גלויה, וכך מצמצם באופן משמעותי את שטח הפנים של המתקפה.
• כלים להטמעה: מפתחים צריכים להשתמש במצב קפדני ובבדיקות lint מעודכנות כדי לזהות דפוסים מדור קודם ולהבטיח מוכנות לדרישות עתידיות של SDK לטירגוט.

הפעלה של CT כברירת מחדל

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

‫DCL מקורי מאובטח יותר – C

אם האפליקציה מטרגטת ל-Android 17 (רמת API 37) או לגרסה מתקדמת יותר, ההגנה על טעינת קוד דינמית (DCL) בטוחה יותר, שהוצגה ב-Android 14 לקובצי DEX ו-JAR, חלה עכשיו גם על ספריות Native.

כל הקבצים המקוריים שנטענו באמצעות System.load() צריכים להיות מסומנים כקריאה בלבד. אחרת, המערכת תציג את השגיאה UnsatisfiedLinkError.

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

הגבלת שדות של פרטים אישיים מזהים בתצוגת הנתונים של CP2

באפליקציות שמיועדות ל-Android 17 (API ברמה Android 17 (API ברמה 37)) ומעלה, ניהול אנשי הקשר 2 (CP2) מגביל את הגישה לעמודות מסוימות שמכילות פרטים אישיים מזהים (PII) בתצוגת הנתונים. כשהשינוי הזה מופעל, העמודות האלה מוסרות מתצוגת הנתונים כדי לשפר את הפרטיות של המשתמשים. העמודות המוגבלות כוללות:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

אפליקציות שמשתמשות בעמודות האלה מ-ContactsContract.Data יכולות לחלץ אותן מ-ContactsContract.RawContacts במקום זאת, על ידי הצטרפות ל-RAW_CONTACT_ID.

אכיפה של בדיקות SQL מחמירות ב-CP2

באפליקציות שמיועדות ל-Android 17 (רמת API‏ Android 17 (רמת API 37)) ומעלה, ניהול אנשי הקשר 2‏ (CP2) אוכף אימות מחמיר של שאילתות SQL כשמנסים לגשת לטבלה ContactsContract.Data בלי ההרשאה READ_CONTACTS.

בעקבות השינוי הזה, אם לאפליקציה אין הרשאה לREAD_CONTACTS, האפשרויות StrictColumns וStrictGrammar מוגדרות כשמבצעים שאילתה בטבלת ContactsContract.Data. אם שאילתה משתמשת בתבנית שלא תואמת לאלה, היא תידחה ותגרום להפעלת חריגה.

תבונה

‫Android 17 כוללת את השינויים הבאים ב-System Intelligence.

הוצאה משימוש של setContentCaptureEnabled

התכונה 'לכידת תוכן' מופעלת כברירת מחדל במכשירים מסוימים כדי לאפשר לתכונות AI במכשיר לנתח את תוכן המסך וליצור חוויות חכמות.

החל מ-Android 17, שיטת ה-API‏ ContentCaptureManager.setContentCaptureEnabled(boolean) הוצאה משימוש. באפליקציות שמטרגטות ל-Android 17 (רמת API 37) ומעלה, קריאה ל-setContentCaptureEnabled(false) כבר לא משביתה את התכונה 'לכידת תוכן'.

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

כדי להשבית את התכונה 'לכידת תוכן', מגדירים את הדגל FLAG_SECURE בחלון, כמו בדוגמה הבאה:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

לפרטים נוספים, אפשר לעיין במסמכי התיעוד של WindowManager.LayoutParams.FLAG_SECURE.

מדיה

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

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

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

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

• לשירות שפועל בחזית צריכות להיות יכולות של הרשאת while-in-use (WIU).
• לאפליקציה צריכה להיות הרשאת משימה ברגע מדויק והיא צריכה להיות באינטראקציה עם זרמי אודיו של USAGE_ALARM.

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

גורמי צורה של מכשירים

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

שינויים ב-API של הפלטפורמה שגורמים להתעלמות מהגבלות על כיוון, שינוי גודל ויחס גובה-רוחב במסכים גדולים (sw>=600dp)

הוספנו שינויים ב-API של הפלטפורמה ב-Android 16 כדי להתעלם מההגבלות על כיוון, יחס גובה-רוחב ושינוי גודל במסכים גדולים (sw ‏ >= 600dp) באפליקציות שמטרגטות לרמת API 36 ומעלה. מפתחים יכולים להשבית את השינויים האלה ב-SDK 36, אבל האפשרות הזו לא תהיה זמינה יותר לאפליקציות שמיועדות ל-Android 17 (רמת API 37) ומעלה.

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

קישוריות

ב-Android 17 בוצע השינוי הבא כדי לשפר את העקביות ולהתאים להתנהגות הרגילה של שקעי RFCOMM ב-Bluetooth ב-Java InputStream.

התנהגות עקבית של read() ב-BluetoothSocket עבור RFCOMM

באפליקציות שמטרגטות ל-Android 17 (רמת API 37), השיטה read() של InputStream שמתקבל מ-BluetoothSocket מבוסס-RFCOMM מחזירה עכשיו -1 כשהשקע סגור או כשהחיבור נותק.

השינוי הזה הופך את ההתנהגות של שקע RFCOMM לעקבית עם שקעי LE CoC, ומתאים למסמכי התקן InputStream.read(), שבהם מצוין שהערך -1 מוחזר כשמגיעים לסוף הזרם.

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