בדף הזה מוסבר איך להפעיל את מסגרת האודיו ואת שכבת הפשטת החומרה (HAL) של האודיו (AHAL) כדי לנהל חיבורים סינכרוניים מבוססי-חיבור (SCO), תהליך שמזוהה כ-SCO מנוהל של אודיו (AMSCO).
ב-Android מגרסה 17 ומעלה, מסגרת האודיו של Android משתמשת בתכונת ניהול SCO כדי לנהל את הניתוב של SCO, שנוהל במקור על ידי מסגרת Bluetooth (BT). במהלך ההעברה הזו, סטטוס החיבור של ה-SCO עובר ממצב בבעלות ה-framework של 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 צריכה לשלוח בקשה למסגרת האודיו לפתיחת 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.