שינויים בהתנהגות: אפליקציות שמטרגטות ל-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, מוודאים שהאפליקציה תומכת בתצוגה מקצה לקצה ומסירים את השימוש ב-R.attr#windowOptOutEdgeToEdgeEnforcement כדי שהאפליקציה תתמוך בתצוגה מקצה לקצה גם במכשיר Android 15. הוראות לגבי תמיכה בתצוגה מקצה לקצה מופיעות במאמרים יצירת תצוגות ותצוגות.

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

对于以 Android 16（API 级别 36）或更高版本为目标平台且在 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

הוצאה משימוש והשבתה של ממשקי 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), ההגבלות על כיוון, שינוי גודל ויחס גובה-רוחב לא חלות יותר על מסכים עם רוחב מינימלי של 600dp ומעלה. האפליקציות ממלאות את חלון התצוגה, בלי קשר ליחס הגובה-רוחב או להעדפת הכיוון של המשתמש, ולא נעשה שימוש בבפורמט pillarbox.

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

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

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

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

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

פרטי ההטמעה

במכשירים עם מסך גדול במצב מסך מלא ובמצב ריבוי חלונות, המערכת מתעלמת ממאפייני המניפסט וממשקי ה-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 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) כוללת את השינויים הבאים שקשורים לנתוני בריאות וכושר.

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

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用， BODY_SENSORS 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• HEART_RATE_BPM Wear OS 上的健康服务
• Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
• heartRateAccuracy 和 heartRateBpm（来自 Wear OS 上的 ProtoLayout）
• FOREGROUND_SERVICE_TYPE_HEALTH ，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 如需在使用期间监测心率、血氧饱和度或体表温度： 请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 如需访问后台传感器，请请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与保护对 Health Connect（用于存储健康、 健身和保健数据的 Android 数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移为使用 READ_HEART_RATE 和其他精细权限的移动应用还必须 声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

קישוריות

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

כוונה חדשה לטיפול באובדן של קשרים ושינויים בהצפנה

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

אפליקציות שמטרגטות את Android 16 יכולות עכשיו:

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

התאמה להטמעות שונות של יצרני ציוד מקורי (OEM)

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

מומלץ להשתמש בהתנהגויות הבאות באפליקציות:

• אם המערכת משדרת את הכוונה ACTION_KEY_MISSING:

  המערכת תנתק את הקישור של ACL (Asynchronous Connection-Less), אבל פרטי הקישור של המכשיר יישמרו (כפי שמתואר כאן).

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

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

• אם הכוונה ACTION_KEY_MISSING לא משודרת:

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

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

דרך חדשה להסרת שיוך Bluetooth

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

אבטחה

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

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

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

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

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

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

אנחנו מטמיעים שני שינויים מרכזיים:

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

2. אובייקטים מסוג Intent ללא פעולה לא יכולים להתאים למסנן Intent כלשהו: אובייקטים מסוג Intent שלא צוינה להם פעולה לא אמורים להיות מזוהים כמסנן Intent כלשהו.

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

השפעה

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

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

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

יכול להיות שההשפעה הראשונית ב-Android 16 תהיה מוגבלת, אבל ליוזמת Safer Intents יש תוכנית להשפעה רחבה יותר בגרסאות עתידיות של Android. התוכנית היא שבסופו של דבר, התנהגות ברירת המחדל תהיה זיהוי כוונות מדויק.

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

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

הטמעה

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

<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>

מידע נוסף על הדגלים הנתמכים:

בדיקה וניפוי באגים

כשהאכיפה פעילה, האפליקציות אמורות לפעול בצורה תקינה אם האפליקציה שקוראת ל-Intent מילאה את ה-Intent בצורה תקינה. עם זאת, כוונות חסומות יפעילו הודעות אזהרה ביומן כמו "Intent does not match component's intent filter:" ו-"Access blocked:" עם התג "PackageManager." ההודעות האלה מצביעות על בעיה פוטנציאלית שעלולה להשפיע על האפליקציה ודורשת טיפול.

מסנן Logcat:

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

סינון של קריאות מערכת ל-GPU

כדי להקשיח את פני השטח של Mali GPU, ‏ Mali GPU IOCTLs שהוצאו משימוש או שמיועדים אך ורק לפיתוח GPU נחסמו בגרסאות ייצור. בנוסף, פקודות IOCTL שמשמשות ליצירת פרופיל של GPU הוגבלו לתהליך של מעטפת או לאפליקציות שאפשר לבצע בהן ניפוי באגים. פרטים נוספים על המדיניות ברמת הפלטפורמה זמינים בעדכון בנושא SAC.

השינוי הזה מתבצע במכשירי Pixel עם Mali GPU (מכשירי Pixel 6 עד Pixel 9). חברת Arm סיפקה סיווג רשמי של פקודות ה-IOCTL שלה בDocumentation/ioctl-categories.rst של גרסה r54p2. הרשימה הזו תמשיך להתעדכן בגרסאות עתידיות של מנהלי ההתקנים.

השינוי הזה לא משפיע על ממשקי API גרפיים נתמכים (כולל Vulkan ו-OpenGL), ולא צפוי להשפיע על מפתחים או על אפליקציות קיימות. לא תהיה השפעה על כלי פרופיל של GPU, כמו Streamline Performance Analyzer ו-Android GPU Inspector.

בדיקה

אם מופיעה לכם דחייה של SELinux שדומה לזו שמופיעה בהמשך, סביר להניח שהשינוי הזה השפיע על האפליקציה שלכם:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

אם האפליקציה שלכם צריכה להשתמש ב-IOCTLs חסומים, עליכם לדווח על באג ולהקצות אותו לכתובת android-partner-security@google.com.

שאלות נפוצות

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

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

3. האם מערכות SoC אחראיות לעדכון רשימת ה-IOCTL? לדוגמה, אם במכשיר שלי נעשה שימוש ב-GPU מסוג ARM Mali, האם אצטרך לפנות אל ARM כדי לבצע שינויים כלשהם? מערכות SoC נפרדות צריכות לעדכן את רשימות ה-IOCTL שלהן לכל מכשיר עם פרסום מנהל ההתקן. לדוגמה, ARM תעדכן את רשימת ה-IOCTL שפורסמה שלה אחרי עדכוני מנהלי התקנים. עם זאת, יצרני ציוד מקורי (OEM) צריכים לוודא שהם משלבים את העדכונים ב-SEPolicy שלהם, ומוסיפים לרשימות את כל פקודות ה-IOCTL המותאמות אישית שנבחרו, לפי הצורך.

4. האם השינוי הזה חל אוטומטית על כל מכשירי Pixel שזמינים למכירה, או שנדרשת פעולה של המשתמש כדי להפעיל משהו וליישם את השינוי? השינוי הזה חל על כל מכשירי Pixel שזמינים כרגע בשוק ומשתמשים במעבד גרפי Mali (מכשירי Pixel 6 עד Pixel 9). לא נדרשת פעולה מצד המשתמש כדי להחיל את השינוי הזה.

5. האם השימוש במדיניות הזו ישפיע על הביצועים של מנהל ההתקן של ליבת המערכת? המדיניות הזו נבדקה ב-GPU מסוג Mali באמצעות GFXBench, ולא נצפה שינוי מדיד בביצועי ה-GPU.

6. האם רשימת ה-IOCTL צריכה להיות תואמת לגרסאות הנוכחיות של מרחב המשתמש ושל מנהל ההתקן של ליבת המערכת? כן, צריך לסנכרן את רשימת ה-IOCTL המותרים עם ה-IOCTL שנתמכים על ידי מנהלי ההתקנים של מרחב המשתמש ושל ליבת מערכת ההפעלה. אם פקודות ה-IOCTL במרחב המשתמש או במנהל ההתקן של ליבת המערכת מעודכנות, צריך לעדכן את רשימת פקודות ה-IOCTL של SEPolicy כך שתתאים להן.

7. חברת ARM סיווגה את פקודות ה-IOCTL כ 'מוגבלות' או כ'אינסטרומנטציה', אבל אנחנו רוצים להשתמש בחלק מהן בתרחישי שימוש בייצור, ו/או לדחות אחרות. יצרני ציוד מקורי (OEM) ומערכות על שבב (SoC) אחראים להחליט איך לסווג את פקודות ה-IOCTL שבהן הם משתמשים, על סמך ההגדרה של ספריות Mali במרחב המשתמשים שלהם. אפשר להשתמש ברשימה של ARM כדי לקבל החלטות לגביהם, אבל יכול להיות שכל יצרן ציוד מקורי או SoC יצטרכו להשתמש בהם בצורה שונה.

פרטיות

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

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

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

מטרת הפרויקט Local Network Protections (הגנות על הרשת המקומית) היא להגן על פרטיות המשתמש באמצעות הגבלת הגישה לרשת המקומית מאחורי הרשאה בתחילת ההפעלה חדשה.

תוכנית ההפצה

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

השפעה

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

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

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

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

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

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

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

הנחיות למפתחים (הצטרפות)

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

1. מבצעים פלאשינג של המכשיר ל-build עם 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>

שגיאות

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

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

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:

• Link-local
• מסלולים עם חיבור ישיר
• רשתות Stub כמו Thread
• Multiple-subnets (TBD)

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

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

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