בדומה לגרסאות קודמות, 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 ואילך, מופעלות כברירת מחדל האנימציות של מערכת הניווט התחזיתי אחורה (חזרה למסך הבית, מעבר בין משימות ומעבר בין פעילויות).
בנוסף, לא מתבצעת קריאה ל-onBackPressed ולא מתבצעת יותר שליחה של KeyEvent.KEYCODE_BACK.
אם האפליקציה שלכם מיירטת את אירוע החזרה ואתם עדיין לא עברתם לניווט חזוי אחורה, עדכנו את האפליקציה כדי להשתמש בממשקי API נתמכים של ניווט אחורה, או השביתו את התכונה באופן זמני על ידי הגדרת המאפיין android:enableOnBackInvokedCallback לערך false בתג <application> או <activity> של קובץ AndroidManifest.xml של האפליקציה.
הוצאה משימוש והשבתה של ממשקי API אלגנטיים לגופנים
以 Android 15(API 级别 35)为目标平台的应用默认将 elegantTextHeight
TextView 属性设置为 true,从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。
Android 16 弃用了 elegantTextHeight 属性,当您的应用以 Android 16 为目标平台后,系统会忽略该属性。由这些 API 控制的“界面字体”即将停用,因此您应调整所有布局,以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。
elegantTextHeight 属性设置为 false 替换默认值的应用,
elegantTextHeight 行为。elegantTextHeight 属性设置为 false 来替换默认值的应用,其 elegantTextHeight 行为。
פונקציונליות עיקרית
Android 16 (API ברמה 36) כוללת את השינויים הבאים, שמשנים או מרחיבים יכולות ליבה שונות של מערכת Android.
אופטימיזציה של תזמון פעולה בקצב קבוע
在以 Android 16 为目标平台之前,如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行,则当应用返回到有效的生命周期时,所有错过的执行会立即执行。
以 Android 16 为目标平台时,当应用返回到有效的生命周期时,系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为,检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。
גורמי צורה של מכשירים
Android 16 (API ברמה 36) כוללת את השינויים הבאים באפליקציות כשהן מוצגות במכשירים עם מסך גדול.
פריסות מותאמות
אפליקציות ל-Android פועלות עכשיו במגוון מכשירים (כמו טלפונים, טאבלטים, מכשירים מתקפלים, מחשבים, מכוניות וטלוויזיות) ובמצבי חלונות במסכים גדולים (כמו מסך מפוצל וחלונות במחשב). לכן, מפתחים צריכים ליצור אפליקציות ל-Android שמותאמות לכל גודל מסך וחלון, ללא קשר לכיוון המכשיר. פרדיגמות כמו הגבלת הכיוון והגבלת שינוי הגודל מגבילות מדי בעולם של היום, שבו משתמשים במספר מכשירים.
התעלמות מהגבלות על כיוון, שינוי גודל ויחס גובה-רוחב
באפליקציות שמטרגטות ל-Android 16 (רמת API 36), ההגבלות על כיוון, שינוי גודל ויחס גובה-רוחב לא חלות יותר על מסכים עם רוחב מינימלי של 600dp ומעלה. האפליקציות ממלאות את כל חלון התצוגה, ללא קשר ליחס הגובה-רוחב או להעדפת הכיוון של המשתמש, ולא נעשה שימוש ב-pillarboxing.
השינוי הזה מציג התנהגות חדשה של הפלטפורמה. מערכת Android עוברת למודל שבו האפליקציות צריכות להתאים את עצמן לכיוונים שונים, לגדלים שונים של מסכים וליחסי גובה-רוחב שונים. הגבלות כמו כיוון קבוע או שינוי גודל מוגבל מקשות על התאמת האפליקציה. התאמה של האפליקציה כדי לספק את חוויית המשתמש הטובה ביותר.
אפשר גם לבדוק את ההתנהגות הזו באמצעות מסגרת התאימות של האפליקציה והפעלת דגל התאימות UNIVERSAL_RESIZABLE_BY_DEFAULT.
שינויי תוכנה נפוצים שעלולים לגרום לכשלים
התעלמות מהגבלות על כיוון, שינוי גודל ויחס גובה-רוחב עלולה להשפיע על ממשק המשתמש של האפליקציה במכשירים מסוימים, במיוחד על רכיבים שנועדו לפריסות קטנות שמוגבלות לכיוון לאורך: לדוגמה, בעיות כמו פריסות מתוחות ואנימציות ורכיבים מחוץ למסך. הנחות לגבי יחס הגובה-רוחב או האוריינטציה עלולות לגרום לבעיות חזותיות באפליקציה. מידע נוסף על איך להימנע מבעיות כאלה ולשפר את ההתנהגות ההסתגלותית של האפליקציה
התרת סיבוב המכשיר גורמת ליצירה מחדש של יותר פעילויות, מה שעלול לגרום לאובדן מצב המשתמש אם הוא לא נשמר בצורה נכונה. במאמר שמירת מצבי ממשק המשתמש מוסבר איך לשמור נכון את מצב ממשק המשתמש.
פרטי ההטמעה
תכונות המניפסט וממשקי ה-API של זמן הריצה הבאים מוזנחים במכשירים עם מסך גדול במצב מסך מלא ובמצב חלונות מרובים:
screenOrientationresizableActivityminAspectRatiomaxAspectRatiosetRequestedOrientation()getRequestedOrientation()
המערכת מתעלמת מהערכים הבאים של screenOrientation, setRequestedOrientation() ו-getRequestedOrientation():
portraitreversePortraitsensorPortraituserPortraitlandscapereverseLandscapesensorLandscapeuserLandscape
לגבי שינוי הגודל של התצוגה, 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 权限使用 android.permissions.health 下更精细的权限,健康数据共享也使用这些权限。自 Android 16 起,凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API,现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型:
- 从 Wear OS 上的健康服务中获取
HEART_RATE_BPM - 来自 Android Sensor Manager 的
Sensor.TYPE_HEART_RATE - 在 Wear OS 上,
ProtoLayout中的heartRateAccuracy和heartRateBpm 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
对于以 Android 16 或更高版本为目标平台的应用,MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性,以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时,应用应已处理版本变更,并且在大多数情况下无需更改其当前行为,除非开发者尝试推断超出此 API 预期范围的其他信息。
כוונות בטוחות יותר
התכונה Safer Intents היא יוזמת אבטחה רב-שלבית שנועדה לשפר את האבטחה של מנגנון פתרון הכוונות ב-Android. המטרה היא להגן על אפליקציות מפני פעולות זדוניות על ידי הוספת בדיקות במהלך עיבוד הכוונות וסינון כוונות שלא עומדות בקריטריונים ספציפיים.
ב-Android 15 התכונה התמקדה באפליקציה השולחת, ועכשיו ב-Android 16, השליטה עוברת לאפליקציה המקבלת, ומאפשרת למפתחים להביע הסכמה לפתרון קפדני של כוונות באמצעות מניפסט האפליקציה שלהם.
אנחנו מטמיעים שני שינויים חשובים:
אובייקטים מסוג Intent מפורש חייבים להתאים למסנן ה-Intent של רכיב היעד: אם אובייקט Intent מכוון במפורש לרכיב מסוים, הוא צריך להתאים למסנן ה-Intent של הרכיב הזה.
אובייקטים מסוג Intent ללא פעולה לא יכולים להתאים למסנן Intent כלשהו: אובייקטים מסוג Intent שלא צוינה להם פעולה לא אמורים להיות מזוהים כמסנן Intent כלשהו.
השינויים האלה חלים רק כשמעורבות כמה אפליקציות, והם לא משפיעים על הטיפול ב-Intent באפליקציה אחת.
השפעה
התכונה היא אופציונלית, ולכן מפתחים צריכים להפעיל אותה באופן מפורש במניפסט האפליקציה כדי שהיא תיכנס לתוקף. כתוצאה מכך, ההשפעה של התכונה תוגבל לאפליקציות שהמפתחים שלהן:
- מכירים את התכונה 'כוונות בטוחות יותר' ואת היתרונות שלה.
- בוחרים באופן פעיל לשלב באפליקציות שלהם שיטות לטיפול בהצהרות כוונות בצורה מחמירה יותר.
הגישה הזו מאפשרת להפעיל את התכונה רק אם רוצים, וכך מצמצמת את הסיכון לשיבוש של אפליקציות קיימות שעשויות להסתמך על ההתנהגות הנוכחית של זיהוי כוונות, שהיא פחות מאובטחת.
יכול להיות שההשפעה הראשונית ב-Android 16 תהיה מוגבלת, אבל ליוזמת Safer Intents יש תוכנית להשפעה רחבה יותר בגרסאות עתידיות של Android. התוכנית היא שבסופו של דבר, התנהגות ברירת המחדל תהיה זיהוי כוונות מדויק.
התכונה Safer Intents (העברות Intent בטוחות יותר) יכולה לשפר באופן משמעותי את האבטחה של מערכת Android, כי היא מקשה על אפליקציות זדוניות לנצל פרצות במנגנון של פתרון Intent.
עם זאת, צריך לנהל את המעבר לביטול ההסכמה ולאכיפה המחייבת בזהירות כדי לטפל בבעיות תאימות אפשריות עם אפליקציות קיימות.
הטמעה
המפתחים צריכים להפעיל באופן מפורש התאמה מחמירה יותר של 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>
מידע נוסף על הדגלים הנתמכים:
| שם ההתרעה | תיאור |
|---|---|
| enforceIntentFilter | התנאי הזה מחייב התאמה מדויקת יותר של כוונות נכנסות |
| ללא | השבתה של כל כללי ההתאמה המיוחדים לכוונות נכנסות. כשמציינים כמה דגלים, ערכים סותרים נפתרים על ידי מתן עדיפות לדגל 'none' |
| allowNullAction | הכלל הזה מרחיב את כללי ההתאמה כדי לאפשר התאמה של כוונות ללא פעולה. הדגל הזה משמש בשילוב עם enforceIntentFilter כדי להשיג התנהגות ספציפית |
בדיקה וניפוי באגים
כשהאכיפה פעילה, האפליקציות אמורות לפעול בצורה תקינה אם המתקשר של הכוונה מילא את הכוונה בצורה תקינה.
עם זאת, כוונות חסומות יפעילו הודעות אזהרה ביומן כמו
"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:")
סינון של קריאות מערכת (syscall) ב-GPU
为了加固 Mali GPU 表面,在生产 build 中,已废弃或仅用于 GPU 开发的 Mali GPU IOCTL 已被屏蔽。此外,用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策,请参阅 SAC 更新。
此更改适用于使用 Mali GPU 的 Pixel 设备(Pixel 6-9)。Arm 已在其 r54p2 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。
此项变更不会影响受支持的图形 API(包括 Vulkan 和 OpenGL),预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。
测试
如果您看到类似如下所示的 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
如果您的应用需要使用被屏蔽的 IOCTL,请提交 bug 并将其分配给 android-partner-security@google.com。
常见问题解答
此政策变更是否适用于所有原始设备制造商 (OEM)? 此变更将采用选择启用模式,但任何想要使用此强化方法的 OEM 都可以使用。如需了解如何实现此变更,请参阅实现文档。
是否必须在 OEM 代码库中进行更改才能实现此功能,还是默认随新的 AOSP 版本提供? 平台级变更将默认随新的 AOSP 版本一起发布。如果供应商想要应用此变更,可以在其代码库中选择启用此变更。
SoC 是否负责使 IOCTL 列表保持最新状态?例如,如果我的设备使用 ARM Mali GPU,我是否需要就任何更改与 ARM 联系? 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。 例如,ARM 会在驱动程序更新时更新其已发布的 IOCTL 列表。 不过,OEM 应确保在 SEPolicy 中纳入这些更新,并根据需要将任何选定的自定义 IOCTL 添加到列表中。
此变更是否会自动应用于所有在售 Pixel 设备,还是需要用户执行操作来切换某些设置才能应用此变更? 此变更适用于所有使用 Mali GPU 的 Pixel 在售设备(Pixel 6-9)。用户无需采取任何行动即可应用此变更。
使用此政策会影响内核驱动程序的性能吗? 我们使用 GFXBench 在 Mali GPU 上测试了此政策,未发现 GPU 性能有任何可衡量的变化。
IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致? 是的,允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新,则必须更新 SEPolicy IOCTL 列表以保持一致。
ARM 已将 IOCTL 分类为“受限”/“检测”,但我们希望在生产用例中使用其中一些 IOCTL,并拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置来决定如何对其使用的 IOCTL 进行分类。ARM 的列表可用于帮助确定这些值,但每个 OEM/SoC 的使用情形可能有所不同。
פרטיות
Android 16 (API ברמה 36) כוללת את השינויים הבאים שקשורים לפרטיות.
הרשאה לגישה לרשת המקומית
כל אפליקציה שיש לה הרשאה INTERNET יכולה לגשת למכשירים ברשת המקומית.
כך קל לאפליקציות להתחבר למכשירים מקומיים, אבל יש לכך גם השלכות על הפרטיות, כמו יצירת טביעת אצבע של המשתמש ושימוש ב-proxy למיקום.
מטרת הפרויקט Local Network Protections (הגנות על הרשת המקומית) היא להגן על פרטיות המשתמש באמצעות הגבלת הגישה לרשת המקומית מאחורי הרשאת זמן ריצה חדשה.
תוכנית ההשקה
השינוי הזה יוטמע בין שתי גרסאות, 25Q2 ו-26Q2 בהתאמה. חשוב מאוד שהמפתחים יפעלו לפי ההנחיות האלה ב-25Q2 וישתפו משוב, כי אמצעי ההגנה האלה יאכפו בגרסת Android מאוחרת יותר. בנוסף, הם יצטרכו לעדכן תרחישים שתלויים בגישה מרומזת לרשת מקומית באמצעות ההנחיות הבאות, ולהתכונן לדחייה של ההרשאה החדשה על ידי המשתמשים ולביטול שלה.
השפעה
בשלב הנוכחי, ניוד מספרים הוא תכונה אופציונלית, כלומר היא תשפיע רק על האפליקציות שהביעו הסכמה לשימוש בה. המטרה של שלב ההצטרפות היא לאפשר למפתחי אפליקציות להבין אילו חלקים באפליקציה שלהם תלויים בגישה משתמעת לרשת המקומית, כדי שיוכלו להתכונן להגנה על ההרשאות בגרסה הבאה.
האפליקציות יושפעו אם הן ניגשות לרשת המקומית של המשתמש באמצעות:
- שימוש ישיר או שימוש בספרייה בשקעים גולמיים בכתובות של רשת מקומית (למשל, פרוטוקול גילוי שירותים mDNS או SSDP)
- שימוש במחלקות ברמת המסגרת שיש להן גישה לרשת המקומית (למשל, NsdManager)
כדי להעביר תנועה אל כתובת ברשת מקומית וממנה, נדרשת הרשאת גישה לרשת המקומית. בטבלה הבאה מפורטים כמה מקרים נפוצים:
| פעולה ברשת ברמה נמוכה באפליקציה | נדרשת הרשאת גישה לרשת המקומית |
|---|---|
| יצירת חיבור TCP יוצא | כן |
| אישור חיבורי TCP נכנסים | כן |
| שליחת שידור יחיד, שידור לקבוצה או שידור לכולם ב-UDP | כן |
| קבלת שידור יחיד, שידור מרובה או שידור לכל ברשת ב-UDP | כן |
ההגבלות האלה מוטמעות עמוק במערך של רכיבי הרשת, ולכן הן חלות על כל ממשקי ה-API של הרשת. הנתונים כוללים שקעים שנוצרו בקוד מקורי או בקוד מנוהל, ספריות רשת כמו Cronet ו-OkHttp, וכל ממשקי API שהוטמעו מעל אלה. כדי לפתור בעיות בשירותים ברשת המקומית (כלומר, שירותים עם הסיומת .local), צריך הרשאה לרשת המקומית.
חריגים לכללים שלמעלה:
- אם שרת ה-DNS של המכשיר נמצא ברשת מקומית, לא נדרשת הרשאת גישה לרשת המקומית כדי להעביר תנועה אל השרת או ממנו (בפורט 53).
- אפליקציות שמשתמשות בבוחר הפלט כבוחר בתוך האפליקציה לא יצטרכו הרשאות גישה לרשת המקומית (הנחיות נוספות יפורסמו ברבעון הרביעי של 2025).
הנחיות למפתחים (אופציונלי)
כדי להפעיל את ההגבלות על הגישה לרשת המקומית:
- מבצעים פלאשינג למכשיר לגרסה עם 25Q2 Beta 3 ואילך.
- מתקינים את האפליקציה שרוצים לבדוק.
מחליפים את מצב הדגל Appcompat ב-adb:
adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>הפעלה מחדש של המכשיר
עכשיו הגישה של האפליקציה לרשת המקומית מוגבלת, וכל ניסיון לגשת לרשת המקומית יוביל לשגיאות בשקע. אם אתם משתמשים בממשקי API שמבצעים פעולות ברשת המקומית מחוץ לתהליך של האפליקציה (לדוגמה: NsdManager), הם לא יושפעו במהלך שלב ההצטרפות.
כדי לשחזר את הגישה, צריך לתת לאפליקציה הרשאה ל-NEARBY_WIFI_DEVICES.
- מוודאים שהאפליקציה מצהירה על ההרשאה
NEARBY_WIFI_DEVICESבמניפסט שלה. - עוברים אל הגדרות > אפליקציות > [שם האפליקציה] > הרשאות > מכשירים בקרבת מקום > אישור.
עכשיו הגישה של האפליקציה לרשת המקומית אמורה לחזור, וכל התרחישים אמורים לפעול כמו לפני שהאפליקציה נכללה בהחרגה.
אחרי שהאכיפה של ההגנה על הרשת המקומית תתחיל, כך תושפע תנועת הרשת של האפליקציה.
| הרשאה | בקשה יוצאת ב-LAN | בקשה יוצאת/נכנסת לאינטרנט | בקשה נכנסת ב-LAN |
|---|---|---|---|
| הוענקה | Microsoft Works | Microsoft Works | Microsoft Works |
| לא הוענקה גישה | פספוסים | Microsoft Works | פספוסים |
כדי להשבית את הדגל 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:
- קישור מקומי
- מסלולים שמקושרים ישירות
- רשתות Stub כמו Thread
- Multiple-subnets (TBD)
בנוסף, גם כתובות מולטיקאסט (224.0.0.0/4, ff00::/8) וכתובת ה-IPv4 לשידור (255.255.255.255) מסווגות ככתובות של רשת מקומית.
תמונות בבעלות האפליקציה
当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时,如果用户选择限制对所选媒体的访问权限,则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项,这会撤消该应用对这些照片和视频的访问权限。