בדף הזה מוסבר איך להפעיל את מסגרת האודיו ואת שכבת הפשטת החומרה (HAL) של האודיו (AHAL) כדי לנהל חיבורים סינכרוניים מבוססי-חיבור (SCO), תהליך שמזוהה כ-SCO מנוהל של אודיו (AMSCO).
ב-Android מגרסה 17 ומעלה, מסגרת האודיו של Android משתמשת בתכונת ניהול SCO כדי לנהל את הניתוב של SCO, שנוהל במקור על ידי מסגרת Bluetooth (BT). במהלך ההעברה הזו, סטטוס החיבור של SCO עובר ממצב בבעלות מסגרת BT לתוצאה במורד הזרם של פעילות הזרמת אודיו.
התכונה הזו מרכזת את הבעלות על ניתוב האודיו במסגרת האודיו, וכך מיישרת קו בין ההטמעה של שכבת ההפשטה של חומרת האודיו (HAL) עבור SCO לבין פרופילי BT אחרים, כמו Advanced Audio Distribution Profile (A2DP) ו-LE Audio. השינוי הזה מפשט את האינטראקציה בין ערימות הטלקום לבין ערימות ה-BT, ומאפשר ארכיטקטורה חזקה ומרכזית יותר של ניתוב אודיו.
סקירה כללית של הארכיטקטורה
ארכיטקטורת AMSCO מרכזת את ניהול החיבורים של SCO במסגרת האודיו של Android, שמבוססת על החלטות ניתוב של פעילות סטרימינג של אודיו. הארכיטקטורה הזו שונה מהמודל הקודם, שבו מחסנית ה-BT ניהלה את החיבורים. התפקידים של כל רכיב בארכיטקטורה הזו הם:
ה-AHAL מתחיל את סשן ה-SCO ומשעה אותו רק אם מתקיימים התנאים הבאים:
- סטרימינג פעיל מועבר למכשיר SCO.
- מצב האודיו מוגדר, ויש תיקון למכשיר SCO.
מסגרת האודיו מונעת ממכשיר A2DP להחיל תיקון בו-זמנית כשהקריטריונים הספציפיים האלה מתקיימים. מסגרת האודיו לא שולחת יותר שינויים בסטטוס SCO או השהיות A2DP אל AHAL.
מסגרת האודיו מטפלת בניהול SCO, כך שמערך ה-BT כבר לא קורא לאודיו של חיבור או ניתוק. במקרים של ניתוק או שגיאה מונעים של SCO, מחסנית ה-BT מודיעה למסגרת האודיו באמצעות AudioManager#onHfpAudioDisconnected.
תוכנית
לפני שמיישמים את השינוי המבני בניהול SCO, צריך להשתמש במידע שבקטע הזה כדי להעריך את דרישות התאימות והארכיטקטורה הבאות.
תאימות לדורות קודמים
כדי לאפשר למסגרת להמשיך לתמוך במכשירים שעשויים לקבל עדכוני מערכת הפעלה בלי לעדכן את קובצי ה-AHAL או את קובצי ה-BT AHAL שלהם, צריך להשתמש במאפיין מערכת כדי לציין שצריך להפעיל את ניהול ה-SCO החדש. הנתיב מדור קודם נשמר למשך עד שש שנים במקרים שבהם מאפיין המערכת מושבת או שגרסת HAL לא עדכנית.
הגדרת סשן HFP
ה-AHAL צריך להשתמש בסוג הסשן החדש של פרופיל הדיבורית (HFP) כדי להתחיל או להשהות את ההפעלה, בדומה לסוגים אחרים של סשנים ב-BT. בסופו של דבר, מצב הזרם מנוהל באמצעות IBluetoothAudioProviders שונים, שמפורטים ונבנים על ידי מחלקה Factory בהתאם לנתיבים הזמינים.
מערך ה-BT משתמש בנתיב של העברת עומס לחומרה כשהדבר אפשרי. ההעדפה לשימוש בקודקים במהלך המשא ומתן היא לפי הסדר הבא: קודק LC3 בחומרה עדיף על קודק LC3 בתוכנה, ואחריו קודק mSBC בחומרה, אחר כך קודק mSBC בתוכנה, ולבסוף קודק CVSD בחומרה עדיף על קודק CVSD בתוכנה.
בתרשימי הרצף הבאים מפורטות האינטראקציות בין AHAL לבין מחסנית ה-BT שנדרשות כדי לקבוע את מצב הזרם.
תהליך הורדת עומס מהחומרה
איור 1 מראה איך מחסנית AHAL ו-BT מתואמות כדי ליצור נתיב נתונים ישיר בחומרה לאודיו SCO:
איור 1. הליך הורדת העומס מהחומרה.
הליך של נתיב נתונים בתוכנה
איור 2 מציג את התהליך של טיפול בנתוני אודיו שדורשים עיבוד בתוכנת המערכת:
איור 2. הליך של נתיב נתונים בתוכנה.
תהליך משא ומתן מחדש על קודק
כששער האודיו (AG) מקבל פקודה חדשה של קודק זמין ל-BT (AT+BAC), שער האודיו מפעיל מחדש את תהליך המשא ומתן על הקודק. באיור 3 מוצג התהליך של משא ומתן מחדש על קודק:
איור 3. תהליך משא ומתן מחדש של קודק.
ההשפעה על HeadsetStateMachine
מכונת המצבים של האוזניות בשכבת Java (שמיוצגת על ידי המחלקה HeadsetStateMachine) נשארת ללא שינוי, למעט המצב AUDIO_CONNECTED, שמופעל על ידי אירועים של מחסנית מקורית.
בשכבת Java, המערכת לא מפעילה יותר את connectAudioNative או את disconnectAudioNative. במקום זאת, המערכת מגיבה לשינויים במצב חיבור האודיו מהמערך המקורי. השינויים האלה מופעלים על ידי הפקודות של AHAL בתאריך IBluetoothAudioProvider או IBluetoothAudioPort.
הטמעה
כדי לשלב את שינוי המבנה של ניהול SCO, צריך לעדכן את התקשורת בין מחסנית ה-BT לבין מסגרת האודיו.
כדי להטמיע את התכונה:
הודעה למסגרת האודיו על שינויים ב-BT הפעיל כדי לעזור בניהול נכון של הפעלה וסגירה של SCO במהלך חיבורים של מכשיר HFP, ולטפל בשינויים במכשיר הפעיל. משתמשים ב-
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo)כדי לספק את המידע הזה למסגרת האודיו.
איור 4. חיבור מכשיר HFP.
מסגרת האודיו משתמשת בקריאה חוזרת (callback) של
AudioManagerAudioDeviceCallback#onAudioDevicesAddedבמקום בשידורים מדור קודם כדי לציין את מצב מכשיר האודיו.מטמיעים שליטה בזרם AHAL באמצעות
setCommunicationDevice(AudioDeviceInfodevice)כנקודת הבקרה הראשית להפעלת חיבור SCO.אם הפונקציה
HfpTransport::StartRequestמחזירהBluetoothAudioCtrlAck::PENDING, AHAL צריך לנסות שוב את הבקשה כי מכונת המצבים של HFP לא נוצרה.
תרחישים לדוגמה
בקטעים הבאים מפורטים תהליכים אופייניים של חוויית משתמש הכרחית (CUJ).
תהליך שיחה בטלקום
השינוי ב-refactor של ניהול SCO הופך את phoneStateChanged לפונקציה חוסמת. השינוי הזה גורם ל-telecom להמתין עד שהביצוע של phoneStateChanged בתוך השיטה BluetoothInCallService.onCallAdded יסתיים לפני שהוא מפעיל את ה-API של מסגרת האודיו כדי להתחיל ליצור SCO.
איור 5. לענות לשיחה או להתחיל שיחה דרך טלקום.
תהליך העבודה של שיחות VoIP
מסגרת האודיו מתחילה את התהליך בקריאה לשיטה BluetoothHeadset.startScoUsingVirtualVoiceCall. אחרי שמערך ה-BT מספק תוצאה ל-framework של האודיו, ה-framework מורה ל-AHAL להפעיל את startStream. האיור הבא ממחיש את התהליך הזה:
איור 6. לענות לשיחה או להתחיל שיחה דרך VOIP.
זיהוי דיבור
גם לזיהוי קולי בהפעלה קולית (HF) וגם לזיהוי קולי שמתחיל ב-AG, מחסנית ה-BT צריכה לבקש מ-framework האודיו לפתוח SCO באמצעות AudioManager.setCommunicationDevice. האיור הבא ממחיש את זה:
איור 7. התחלת SCO של זיהוי דיבור.
חיבור אודיו
מערכת ה-BT יוזמת חיבור SCO על ידי שליחת בקשה למסגרת האודיו עם AudioManager.setCommunicationDevice(AudioDeviceInfo) במהלך זיהוי קולי. אם שיחה פעילה, ה-BT stack שולח בקשה ל-telecom stack במקום ל-BluetoothInCallService#requestBluetoothAudio.
התהליך הזה מוצג באיור הבא:
איור 8. חיבור אודיו.
אימות ובדיקה
כדי לוודא שהתכונה משולבת בצורה נכונה ועומדת בתקני האיכות, יצרני המכשירים צריכים להריץ את הבדיקות הבאות:
- CTS Verifier: אפשר להשתמש ב-CTS Verifier לבדיקה אינטראקטיבית של ניתוב אודיו במהלך שיחות.
- חבילת בדיקות של ספקים (VTS): אימות האינטראקציות של AHAL ו-BT AHAL באמצעות VTS.
דרישות
התכונה הזו כפופה לדרישות הבאות:
- AHAL: ההטמעה דורשת AHAL תואם שתומך בנתיב הניהול שעבר רפקטורינג של SCO.