תקשורת ברקע

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

• איתור מכשיר
• חיבור למכשיר
• שמירה על החיבור למכשיר

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

בתרשים הבא מוצגת תצוגה פשוטה של ההנחיות שבדף הזה:

הערה: ההנחיות הכלליות לעבודה ברקע ב-Android חלות גם על עבודה שקשורה ל-Bluetooth.

איתור מכשיר

קודם כל, האפליקציה צריכה למצוא מכשיר להתחבר אליו. כדי למצוא מכשיר BLE, אפשר להשתמש באחד מממשקי ה-API הבאים:

• BluetoothLeScanner, כמו שמתואר במאמר חיפוש מכשירי BLE. (דוגמה)
• CompanionDeviceManager כמו שמתואר בקטע התאמת מכשירים נלווים. (דוגמה)

הערה: ל-API של CompanionDeviceManager יש מגבלות מסוימות (כמו סינון מוגבל וחוסר תמיכה בכתובות MAC מתחלפות שלא מקושרות) שיכול להיות שלא יענו על הצרכים שלכם, בהתאם להטמעה של הציוד ההיקפי. במכשירי BLE שמשתמשים בכתובות פרטיות ניתנות לפתרון (RPA) מסתובבות, צריך לקשר את המכשיר באמצעות השיטה BluetoothDevice.createBond() כדי שהמערכת תוכל לפתור כתובות מסתובבות בשיטה CompanionDeviceManager.startObservingDevicePresence().

ברקע

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

• ב-BluetoothLeScanner: צריך להפעיל את startScan() עם אובייקט PendingIntent במקום אובייקט ScanCallback כדי לקבל התראה כשמכשיר שתואם למסנן נסרק. (דוגמה)
• ב-CompanionDeviceManager: פועלים לפי ההנחיות במאמר Keep companion apps awake כדי להעיר את האפליקציה ולהשאיר אותה ערה בזמן שמכשיר ששויך בעבר נמצא בטווח. (דוגמה)

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

התחברות למכשיר

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

• תוצאת סריקה של BluetoothLeScanner, כמו שמתואר בקטע הקודם.
• רשימת המכשירים המקושרים שאוחזרה מ-BluetoothAdapter.getBondedDevices().
• המטמון של BluetoothAdapter, באמצעות BluetoothAdapter.getRemoteLeDevice().

אחרי שיוצרים מכונה של BluetoothDevice, אפשר להתחיל בקשת חיבור למכשיר המתאים באמצעות קריאה לאחת מהשיטות של connectGatt(). הערך הבוליאני שמעבירים אל autoConnect מגדיר באיזה משני מצבי החיבור הבאים לקוח ה-GATT משתמש:

• חיבור ישיר (autoconnect = false): ניסיון להתחבר ישירות לציוד ההיקפי, ואם הוא לא זמין, החיבור נכשל. אם החיבור מתנתק, לקוח ה-GATT לא מנסה להתחבר מחדש באופן אוטומטי.
• חיבור אוטומטי (autoconnect = true): ניסיון להתחבר באופן אוטומטי לציוד ההיקפי בכל פעם שהוא זמין. אם הציוד ההיקפי יזם את הניתוק או שהציוד ההיקפי מחוץ לטווח, לקוח ה-GATT ינסה להתחבר מחדש באופן אוטומטי כשהציוד ההיקפי יהיה זמין.

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

ברקע

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

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

• משתמשים ב-WorkManager כדי להתחבר למכשיר.
  • אפשר להגדיר PeriodicWorkRequest או OneTimeWorkRequest כדי לבצע פעולה מוגדרת, אבל יכול להיות שיחולו הגבלות על האפליקציה.
  • בנוסף, אתם יכולים ליהנות מתכונות של WorkManager כמו אילוצי עבודה, משימה דחופה, מדיניות ניסיון חוזר ועוד.
  • אם צריך להשאיר את החיבור פעיל כמה שיותר זמן כדי לבצע משימה, כמו סנכרון נתונים או דגימה מההתקנים ההיקפיים, צריך להפעיל שירות שפועל בחזית לפי ההנחיות שמפורטות במאמר תמיכה ב-workers שפועלים לאורך זמן. עם זאת, הגבלות הפעלה של שירותים שפועלים בחזית חלות החל מ-Android 12.
• הפעלת שירות שפועל בחזית מסוג connectedDevice.
  • אם צריך להשאיר את החיבור פעיל כמה שיותר זמן כדי לבצע משימה, כמו סנכרון נתונים או דגימה מההתקנים ההיקפיים, צריך להפעיל שירות שפועל בחזית לפי ההנחיות שמפורטות במאמר תמיכה ב-workers שפועלים לאורך זמן. עם זאת, החל מ-Android 12 חלות הגבלות הפעלה של שירותים שפועלים בחזית.
• קוראים ל-startScan() עם אובייקט PendingIntent כמו שמתואר בקטע חיפוש מכשיר כדי להעיר את התהליך כשהמכשיר נמצא. המכשיר ההיקפי צריך לשדר.
  • מומלץ להפעיל Worker ו-Job. המערכת עלולה לקטוע את התקשורת, ולכן היא תומכת רק בתקשורת קצרה.
  • בגרסאות קודמות ל-Android 12, אפשר להפעיל שירות שפועל בחזית ישירות מהאובייקט PendingIntent.
• כדי להפעיל את השירות מהרקע, משתמשים ב-CompanionDeviceService ובאחת מההרשאות REQUEST_COMPANION_RUN_IN_BACKGROUND או REQUEST_COMPANION_START_FOREGROUND_SERVICES_FROM_BACKGROUND.

איך נשארים מחוברים למכשיר

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

• בזמן המעבר בין אפליקציות.
• בזמן האזנה להתראות על ציוד היקפי.

בשני המקרים, האפשרויות הבאות זמינות:

• משתמשים ב-CompanionDeviceService עם ההרשאה REQUEST_COMPANION_RUN_IN_BACKGROUND וה-method‏ CompanionDeviceManager.startObservingDevicePresence().
• להפעיל שירות שפועל בחזית כשהאפליקציה פועלת בחזית (או במסגרת אחד מהפטורים) עם סוג השירות שפועל בחזית connectedDevice.

בזמן מעבר בין אפליקציות

חיפוש מכשיר, התחברות אליו והעברת נתונים הם תהליכים שדורשים זמן ומשאבים רבים. כדי למנוע ניתוקים וצורך לבצע את כל התהליך בכל פעם שהמשתמש עובר בין אפליקציות או מבצע משימות בו-זמנית, צריך לשמור על החיבור פעיל עד לסיום הפעולה. אפשר להשתמש בשירות שפועל בחזית מסוג connectedDevice או ב-companion device presence API.

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

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

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