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

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

Android 16 (רמת API 36) כולל את השינויים הבאים, שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.

הסרת האפשרות לביטול ההסכמה לתצוגה מקצה לקצה

ב-Android 15 נאכפת תצוגה מקצה לקצה לאפליקציות שמטרגטות ל-Android 15 (רמת API 35), אבל אפשר לבטל את ההסכמה לכך באפליקציה על ידי הגדרת R.attr#windowOptOutEdgeToEdgeEnforcement לערך true. באפליקציות שמטרגטות את Android 16 (רמת API 36), ה-R.attr#windowOptOutEdgeToEdgeEnforcement הוצא משימוש והושבת, ולא ניתן לבטל את ההסכמה להצגה מקצה לקצה.

• אם האפליקציה שלכם מטרגטת ל-Android 16 (רמת API 36) ופועלת במכשיר Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement תמשיך לפעול.
• אם האפליקציה מטרגטת ל-Android 16 (רמת API 36) ופועלת במכשיר Android 16, האפשרות R.attr#windowOptOutEdgeToEdgeEnforcement מושבתת.

כדי לבדוק את האפליקציה ב-Android 16 Beta 3, צריך לוודא שהיא תומכת במסך מלא ולהסיר כל שימוש ב-R.attr#windowOptOutEdgeToEdgeEnforcement כדי שהיא תתמוך במסך מלא גם במכשיר עם Android 15. כדי לתמוך בתצוגה מקצה לקצה, תוכלו לעיין בהנחיות לכתיבה ולתצוגות.

כדי להשתמש בתכונה 'חזרה חזותית', צריך לבצע העברה או לבטל את ההסכמה

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs. or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

ממשקי ה-API של גופנים אלגנטיים הוצאו משימוש ומושבתים

באפליקציות שמטרגטות ל-Android 15 (רמת API 35), המאפיין elegantTextHeight TextView מוגדר כברירת מחדל לערך true, כך שהגופן הקומפקטי מוחלף בגופן שקל יותר לקרוא אותו. אפשר לשנות את ההגדרה הזו על ידי הגדרת המאפיין elegantTextHeight לערך false.

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

התנהגות של

התנהגות של

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

Android 16 (רמת API 36) כולל את השינויים הבאים, שמשנה או מרחיבים יכולות ליבה שונות של מערכת Android.

אופטימיזציה של תזמון עבודה בתעריף קבוע

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

כשמטרגטים ל-Android 16, פעולה אחת שהוחמצה של scheduleAtFixedRate תושלם באופן מיידי כשהאפליקציה תחזור למחזור חיים תקין. שינוי ההתנהגות הזה צפוי לשפר את ביצועי האפליקציה. כדאי לבדוק את ההתנהגות הזו באפליקציה כדי לראות אם היא מושפעת. אפשר גם לבדוק באמצעות מסגרת התאימות לאפליקציות ולהפעיל את הדגל STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat.

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

Android 16 (רמת API 36) כולל את השינויים הבאים באפליקציות כשהן מוצגות במכשירים עם מסך גדול.

פריסות דינמיות

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

התעלמות מהגבלות על כיוון, שינוי גודל ויחס גובה-רוחב

באפליקציות שמטרגטות ל-Android 16 (רמת API 36), מערכת Android 16 כוללת שינויים באופן שבו היא מנהלת את ההגבלות על הכיוון, שינוי הגודל ויחס הגובה-רוחב. במסכים עם רוחב קטן ביותר של 600dp ומעלה, ההגבלות האלה כבר לא חלות. בנוסף, האפליקציות ממלאות את כל חלון התצוגה, ללא קשר ליחס הגובה-רוחב או לכיוון המועדף על המשתמש, ולא נעשה שימוש בפורמט pillarbox.

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

אפשר גם לבדוק את ההתנהגות הזו באמצעות מסגרת התאימות לאפליקציות ולהפעיל את הדגל UNIVERSAL_RESIZABLE_BY_DEFAULT compat.

שינויי תוכנה נפוצים שעלולים לגרום לכשלים

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

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

פרטי ההטמעה

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

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

המערכת מתעלמת מהערכים הבאים של screenOrientation,‏ setRequestedOrientation() ו-getRequestedOrientation():

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

לגבי שינוי הגודל של התצוגה, ל-android:resizeableActivity="false", ל-android:minAspectRatio ול-android:maxAspectRatio אין השפעה.

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

חריגים

ההגבלות על הכיוון, על שינוי הגודל ועל יחס הגובה-רוחב ב-Android 16 לא חלות במצבים הבאים:

• משחקים (על סמך הדגל android:appCategory)
• משתמשים שמביעים הסכמה מפורשת להתנהגות ברירת המחדל של האפליקציה בהגדרות יחס הגובה-רוחב של המכשיר
• מסכים שקטנים מ-sw600dp

ביטול ההסכמה באופן זמני

כדי לבטל את ההסכמה לפעילות ספציפית, מגדירים את מאפיין המניפסט PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

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

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

בריאות וכושר

Android 16 (רמת API 36) כולל את השינויים הבאים שקשורים לנתוני בריאות וכושר.

הרשאות לבריאות ולכושר

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions are transitioning to the granular permissions under android.permissions.health also used by Health Connect. Any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND now requires the corresponding android.permissions.health permission. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Wear Health Services
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from Wear ProtoLayout
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should now request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

קישוריות

Android 16 (רמת API 36) כולל את השינויים הבאים ב-Bluetooth stack כדי לשפר את הקישוריות עם ציוד היקפי.

כוונות חדשות לטיפול באובדן של אג"ח ובשינויים בהצפנה

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

If your app currently uses custom mechanisms for bond loss handling, migrate to the new intent ACTION_KEY_MISSING to detect and manage bond loss events. We recommend your app guide the user to confirm the remote device is in range before initiating device forgetting and re-pairing.

Moreover, if a device disconnects after ACTION_KEY_MISSING intent is received, your app should be mindful about reconnecting to the device as that device may no longer be bonded with the system.

אבטחה

Android 16 (רמת API 36) כולל את שינויי האבטחה הבאים.

נעילת גרסה של MediaStore

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

כוונות בטוחות יותר

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

פרטיות

Android 16 (רמת API 36) כולל את השינויים הבאים בנושא פרטיות.

הרשאת רשת מקומית

כל אפליקציה עם ההרשאה INTERNET יכולה לגשת למכשירים ברשת LAN. כך קל לאפליקציות להתחבר למכשירים מקומיים, אבל יש לכך גם השלכות על הפרטיות, כמו יצירת טביעת אצבע של המשתמש ושימוש כשרתי proxy למיקום.

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

תוכנית השקה

השינוי הזה יופעל בין שתי גרסאות, 25Q2 ו-TBD, בהתאמה. חשוב מאוד שמפתחים יפעלו לפי ההנחיות האלה עד סוף הרבעון השני של 2025 וישתפו משוב, כי ההגנות האלה ייאכפו במהדורה מאוחרת יותר של Android. בנוסף, הם יצטרכו לעדכן תרחישי שימוש שמסתמכים על גישה מקומית משתמעת לרשת לפי ההנחיות הבאות, ולהתכונן לדחייה של המשתמשים ולביטול ההרשאה החדשה.

השפעה

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

אפליקציות יושפעו אם הן יגשו לרשת המקומית של המשתמש באמצעות:

• שימוש ישיר או שימוש בספרייה בסוקטים גולמיים בכתובות רשת מקומיות (למשל, פרוטוקול mDNS או פרוטוקול זיהוי השירותים SSDP)
• שימוש ב-classes ברמת המסגרת שמקבלות גישה לרשת המקומית (למשל NsdManager)

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

ההגבלות האלה מיושמות עמוק בתוך סטאק הרשתות, ולכן הן חלות על כל ממשקי ה-API של הרשתות. הרשימה הזו כוללת שקעים שנוצרו בקוד מקומי או מנוהל, ספריות רשת כמו Cronet ו-OkHttp וכל ממשקי ה-API שמוטמעים מעליהם. כדי לנסות לפתור שירותים ברשת המקומית (כלומר שירותים עם הסיומת ‎.local), נדרשת הרשאה לרשת המקומית.

חריגים לכללים שלמעלה:

• אם שרת ה-DNS של המכשיר נמצא ברשת מקומית, תעבורת הנתונים אליו או ממנו (ביציאה 53) לא דורשת הרשאת גישה לרשת המקומית.
• אפליקציות שמשתמשות ב-Output Switcher בתור הבורר שלהן באפליקציה לא יצטרכו הרשאות רשת מקומית (הוראות נוספות יפורסמו ברבעון 4 של שנת 2025).

הנחיות למפתחים (הסכמה מראש)

כדי להביע הסכמה להגבלות ברשת המקומית:

1. מבצעים איפוס (flash) של המכשיר לגרסה 25Q2 Beta 3 ואילך.
2. מתקינים את האפליקציה שרוצים לבדוק.

3. משנים את מצב הדגל Appcompat ב-adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. הפעלה מחדש של המכשיר

עכשיו הגישה של האפליקציה לרשת המקומית מוגבלת, וכל ניסיון לגשת לרשת המקומית יוביל לשגיאות שקשורות ליצירת שקעים. אם אתם משתמשים בממשקי API שמבצעים פעולות ברשת המקומית מחוץ לתהליך האפליקציה (למשל: NsdManager), הם לא יושפעו במהלך שלב ההסכמה.

כדי לשחזר את הגישה, צריך להעניק לאפליקציה הרשאה ל-NEARBY_WIFI_DEVICES.

1. מוודאים שהאפליקציה מצהירה על ההרשאה NEARBY_WIFI_DEVICES במניפסט שלה.
2. עוברים אל הגדרות > אפליקציות > [שם האפליקציה] > הרשאות > מכשירים בקרבת מקום > מתן הרשאה.

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

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

משתמשים בפקודה הבאה כדי להשבית את הדגל App-Compat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

שגיאות

שגיאות שנובעות מהמגבלות האלה יוחזרו ליציאה הקוראת בכל פעם שהיא מפעילה את send או וריאנט של send לכתובת רשת מקומית.

דוגמאות לשגיאות:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

הגדרה של רשת מקומית

ברשת מקומית בפרויקט הזה הכוונה לרשת IP שמשתמשת בממשק רשת עם יכולת שידור, כמו Wi-Fi או Ethernet, אבל לא כוללת חיבורים סלולריים (WWAN) או חיבורי VPN.

הרשתות הבאות נחשבות לרשתות מקומיות:

IPv4:

• 169.254.0.0/16 // Link Local
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• מקומי לקישור
• נתיבים שמחוברים ישירות
• רשתות קטנות כמו Thread
• רשתות משנה מרובות (TBD)

בנוסף, גם כתובות ה-multicast‏ (224.0.0.0/4, ‏ ff00::/8) וגם כתובת ה-broadcast של IPv4‏ (255.255.255.255) מסווגות ככתובות של רשתות מקומיות.

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

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