שינויים בהתנהגות: אפליקציות שמטרגטות את 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 שלא דורשת נעילה

Beginning with Android 17, apps targeting Android 17 (API level 37) or higher receive a new lock-free implementation of android.os.MessageQueue. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

For more information, including mitigation strategies, see MessageQueue behavior change guidance.

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

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

נגישות

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

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

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

• IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

• Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

• Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

פרטיות

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

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

Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.

For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.

To allow apps to customize this behavior, Android 17 adds a new <domainEncryption> element to the Network Security Configuration file. Developers can use <domainEncryption> within <base-config> or <domain-config> tags to select an ECH mode (for example, "enabled" or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

נדרשת הרשאה לגישה לרשת המקומית לאפליקציות שמטרגטות 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 רגילות

Beginning with Android 17, Android is extending its SMS OTP protection to apply to standard SMS messages (SMS messages containing an OTP that do not use the WebOTP or SMS Retriever formats). For most apps targeting Android 17 (API level 37) or higher, these SMS messages do not become available until three hours after receipt. This delay is intended to help prevent OTP hijacking. During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

אבטחה

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

אבטחת פעילות

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

• BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
• Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

הפעלה של 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.