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

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

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

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

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

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

החל מ-Android 17, המערכת אוכפת מגבלת זיכרון מחמירה על עדכוני RemoteViews לאפליקציות שמטרגטות ל-Android 17 (רמת API‏ 37) ומעלה. כשאפליקציה מעבירה אובייקט RemoteViews אל AppWidgetManager.updateAppWidget,‏ system_server מחשב את הזיכרון הכולל שבשימוש של כל נתוני התמונות בכל כיוון וקטגוריית גודל במטען הייעודי (payload). אם הזיכרון הכולל חורג מהתקרה של המערכת (mMaxWidgetBitmapMemory), המערכת דוחה את העדכון ומחזירה את השגיאה IllegalArgumentException:

java.lang.IllegalArgumentException: RemoteViews for widget update exceeds maximum bitmap memory usage (used: XXXXX, max: YYYYY)

באפליקציות שמטרגטות לרמת API 36 או פחות, המערכת מתעדת את הפרת הזיכרון הזו כאזהרה (Slog.w) בלי להציג חריגה.

android skills add glance-appwidget-updates-and-memory

איך המערכת מחשבת את תקרת הזיכרון

המערכת מגדירה את תקציב הזיכרון של מפת הסיביות של הווידג'ט ל-6 * width * height בייטים (1.5 * 4 * width * height, שווה ערך ל-1.5 פעמים הגודל של מאגר נתונים (buffer) של ARGB_8888 במסך מלא) להגדרת התצוגה הפעילה. ברמת API‏ 37 ומעלה, החישוב הזה כולל את שני הדברים הבאים:

• אובייקטים מסוג Bitmap בזיכרון ו-Icon שמגובים במפת סיביות (Icon.TYPE_BITMAP ו-Icon.TYPE_ADAPTIVE_BITMAP) שמאוחסנים ב-RemoteViews.mBitmapCache (למשל קריאות ל-setImageViewBitmap, ל-Icon.createWithBitmap, ל-Icon.createWithAdaptiveBitmap או ל-Jetpack Glance ImageProvider(bitmap)). כל מופע ייחודי של Bitmap או של Icon שמגובה במפת סיביות ב-mBitmapCache נספר פעם אחת בכל היררכיית RemoteViews.
• תמונות שמגובות ב-URI‏ (Icon.createWithContentUri,‏ setImageViewUri או Glance ImageProvider(uri)) לא נכללות במגבלת הבייטים של RemoteViews IPC ב-system_server, אבל תהליך המארח של הווידג'ט מפענח את קובץ ה-content:// שאליו מפנים ברזולוציה מלאה לתוך ה-heap שלו. תמיד צריך לכתוב תמונה שעברה דגימת חסר ל-context.cacheDir לפני שחושפים אותה באמצעות URI של FileProvider.

שלבים לפתרון הבעיה

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

1. חישוב תקציב הזיכרון בזמן הריצה מ-WindowMetrics: ברמת API‏ 30 ומעלה, קוראים את גבולות החלון הפעיל מ-WindowManager.currentWindowMetrics.bounds במקום מ-resources.displayMetrics. במכשירים עם כמה רזולוציות ובמכשירים מתקפלים, יכול להיות ש-displayMetrics ידווח על מידות של מסך לא פעיל. העריכו את התקציב הכולל של תמונות הווידג'ט ב-6L * bounds.width() * bounds.height(), כמו בדוגמה הבאה:

   private const val FALLBACK_MAX_BYTES = 15_000_000L
   
   fun calculateWidgetMemoryCapBytes(context: Context): Long {
       if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
           val wm = context.getSystemService(WindowManager::class.java)
               ?: return FALLBACK_MAX_BYTES
           val bounds = wm.currentWindowMetrics.bounds
           return 6L * bounds.width().toLong() * bounds.height().toLong()
       }
       val dm = context.resources.displayMetrics
       return 6L * dm.widthPixels.toLong() * dm.heightPixels.toLong()
   }
   

2. צמצמו את דגימת התמונות למידות הניתנות לצפייה של הווידג'ט והשתמשו ב-RGB_565: פענחו מפות סיביות עם ערכי BitmapFactory.Options.inSampleSize בחזקת שתיים בגודל המקסימלי של הווידג'ט (maxWidthDp על maxHeightDp), והשתמשו ב-Bitmap.Config.RGB_565 (2 בייטים לכל פיקסל) במקום ב-ARGB_8888 (4 בייטים לכל פיקסל) לתמונות אטומות ולתמונות ממוזערות.

3. העברת פענוח מפת הסיביות אל מחוץ ל-provideContent ב-Jetpack Glance: כשמשתמשים ב-SizeMode.Responsive או ב-SizeMode.Exact, Glance מפעיל את פונקציית הלמבדה provideContent פעם אחת לכל קטגוריית גודל. מפענחים כל Bitmap משותף פעם אחת בתוך provideGlance לפני שקוראים ל-provideContent, כדי שכל קטגוריות הגודל יפנו לאותו מופע של Bitmap ב-RemoteViews.mBitmapCache.

4. כשמחליפים תמונות, משתמשים בקריאות מלאות של updateAppWidget: בהטמעות קלאסיות של AppWidgetProvider, נמנעים מקריאה ל-AppWidgetManager.partiallyUpdateAppWidget כדי להחליף תצוגות של Bitmap או Icon. עדכונים חלקיים ממזגים פעולות חדשות בעץ RemoteViews הקיים ב-system_server בלי להסיר פעולות של תמונות שנשמרו בעבר במטמון. במקום זאת, צריך ליצור פריסה מלאה של RemoteViews ולקרוא ל-updateAppWidget.

5. הגדרת פריסת ברירת מחדל לשגיאות: ב-Jetpack Glance, משנים את onCompositionError כדי להציג ברירת מחדל של RemoteViews ללא מפת סיביות אם העדכון נכשל.

כדי לבדוק את השימוש הנוכחי בזיכרון של מפת הסיביות (bitmap) שעבר סריאליזציה בווידג'ט במכשיר מחובר, מריצים את הפקודה הבאה:

adb shell dumpsys appwidget

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

‫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. ניסיון לשנות אחד מהשדות האלה באמצעות ממשקי API של JNI (כמו SetStaticLongField()) יגרום לקריסת האפליקציה.

נגישות

ב-Android 17 יש את השינויים הבאים שמשפרים את הנגישות.

תמיכה בנגישות בהקלדה מורכבת במקלדת פיזית של עורך שיטות קלט (IME)

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

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

• אפליקציות 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 (Encrypted Client Hello) מופעל

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

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

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

מידע נוסף זמין במסמכי התיעוד של Encrypted 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, ההגנה על סיסמאות חד-פעמיות ב-SMS ב-Android חלה גם על הודעות SMS רגילות (הודעות SMS שמכילות סיסמה חד-פעמית ולא משתמשות בפורמטים של WebOTP או SMS Retriever). ברוב האפליקציות שמטרגטות ל-Android 17 (רמת API‏ 37) ומעלה, הודעות ה-SMS האלה זמינות רק שלוש שעות אחרי שהן מתקבלות. העיכוב הזה נועד למנוע חטיפה של סיסמאות חד-פעמיות. במהלך העיכוב של שלוש השעות, השידור של SMS_RECEIVED_ACTION מושהה והשאילתות במסד הנתונים של ספק ה-SMS מסוננות. הודעת ה-SMS זמינה לאפליקציות האלה אחרי העיכוב.

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

‫Safer Native DCL—C

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

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

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

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

באפליקציות שמטרגטות את 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‏ 37) ומעלה, ניהול אנשי הקשר 2 (CP2) אוכף אימות קפדני של שאילתות SQL כשיש גישה לטבלה ContactsContract.Data בלי ההרשאה READ_CONTACTS.

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

תבונה

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

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

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

החל מ-Android 17, השיטה ContentCaptureManager.setContentCaptureEnabled(boolean) ב-API הוצאה משימוש. באפליקציות שמטרגטות ל-Android 17 (רמת API 37) ומעלה, קריאה ל-setContentCaptureEnabled(false) לא משביתה יותר את Content Capture.

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

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

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

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

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

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

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

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

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

קישוריות

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

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

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

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

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