התכונה 'טריגר קולי' מאפשרת לאפליקציות להאזין לאירועים אקוסטיים מסוימים, כמו מילות הפעלה, בצורה חסכונית באנרגיה ושומרת על הפרטיות. דוגמאות לתרחישי שימוש בטריגרים של צלילים: Assistant ו'מה מושמע עכשיו'.
בדף הזה יש סקירה כללית של ארכיטקטורת Sound Trigger וממשק HAL (שכבת הפשטה של חומרה).
Sound Trigger stack
מערכת המשנה Sound Trigger בנויה בשכבות, כמו שמוצג באיור 1:
איור 1: מחסנית Sound Trigger
ברשימה הבאה מפורט כל אחד מהרכיבים שמוצגים באיור 1:
שכבת ה-HAL (בירוק) מכילה את הקוד הספציפי לספק שמיישם את הממשק Sound Trigger HAL (STHAL).
SoundTriggerMiddleware
(בצהוב) נמצא מעל ממשק HAL. היא מתקשרת עם HAL ואחראית לפונקציות כמו שיתוף HAL בין לקוחות שונים, רישום ביומן, אכיפת הרשאות וטיפול בתאימות לגרסאות ישנות יותר של HAL.המערכת
SoundTriggerService
(בכחול) נמצאת מעל תוכנת הביניים. הוא מאפשר שילוב עם תכונות אחרות של המערכת, כמו טלפוניה ואירועים שקשורים לסוללה. בנוסף, היא מנהלת מסד נתונים של מודלים של צלילים, שמסודרים לפי אינדקס עם מזהים ייחודיים.מעל שכבת
SoundTriggerService
, המערך (בחום) מטפל בתכונות ספציפיות ל-Assistant ובאפליקציות כלליות בנפרד.
התפקיד של מחסנית Sound Trigger הוא להעביר אירועים נפרדים שמייצגים אירועים אקוסטיים של טריגר. ברוב המקרים, מחסנית Sound Trigger לא מטפלת באודיו. כשמתקבלים אירועי ההפעלה, האפליקציות מקבלות גישה לזרם האודיו בפועל, שמתרחש סביב הזמן של האירועים, על ידי פתיחת אובייקט AudioRecord
דרך מסגרת האודיו. ממשקי ה-API של Sound Trigger HAL מספקים נקודת אחיזה עם האירוע שהופעל, שמשמשת עם Audio Framework. לכן, מכיוון ש-Sound Trigger HAL ו-Audio HAL מחוברים מתחת לפני השטח, הם בדרך כלל חולקים תהליך.
ממשק HAL של Sound Trigger
ממשק HAL של Sound Trigger (STHAL) הוא החלק הספציפי לספק של מחסנית Sound Trigger, והוא מטפל בזיהוי חומרה של מילות הפעלה וצלילים אחרים. STHAL מספק מנוע אחד או יותר, וכל אחד מהם מריץ אלגוריתם שונה שנועד לזהות סוג ספציפי של צלילים. כש-STHAL מזהה טריגר, הוא שולח אירוע למסגרת ואז מפסיק את הזיהוי.
הממשק של STHAL מפורט בקטע /hardware/interfaces/soundtrigger/
.
ממשק ISoundTriggerHw
תומך באפשרות להפעיל סשן זיהוי אחד או יותר בכל זמן נתון, ולהאזין לאירועים אקוסטיים.
קריאה ל-ISoundTriggerHw.getProperties()
מחזירה מבנה Properties
שמכיל תיאור של ההטמעה והיכולות.
התרשים הבא (איור 2) מסביר את התהליך הבסיסי של הגדרת סשן:
איור 2: דיאגרמת מצבים של STHAL
בשלבים הבאים מפורט כל סטטוס:
לקוח HAL טוען מודל באמצעות
loadSoundModel()
אוloadPhraseSoundModel()
. אובייקט המודל שסופק מציין באיזה אלגוריתם (מנוע) ספציפי לזיהוי הטמעה צריך להשתמש, וגם את הפרמטרים שרלוונטיים לאלגוריתם הזה. אם הפעולה מצליחה, השיטות האלה מחזירות נקודת אחיזה שמשמשת להפניה למודל הזה בקריאות הבאות.אחרי שהמודל נטען בהצלחה, לקוח ה-HAL קורא ל-
startRecognition()
כדי להתחיל בזיהוי. הזיהוי ממשיך לפעול ברקע עד שאחד מהאירועים הבאים מתרחש:- התקשרת אל
stopRecognition()
במודל הזה. - זוהה אירוע.
- הזיהוי מבוטל בגלל מגבלות משאבים, למשל, כשמתחיל תרחיש שימוש בעדיפות גבוהה יותר.
בשני המקרים האחרונים, אירוע זיהוי נשלח דרך ממשק הקריאה החוזרת (callback) שרשום על ידי לקוח HAL בזמן הטעינה. בכל המקרים, אחרי שאחד מהאירועים האלה מתרחש, הזיהוי מושבת ולא ניתן יותר להשתמש בקריאות חוזרות לזיהוי.
אפשר להפעיל מחדש את אותו מודל במועד מאוחר יותר, ולחזור על התהליך הזה כמה פעמים שצריך.
- התקשרת אל
לבסוף, מודל לא פעיל שכבר לא נחוץ מוסר על ידי לקוח HAL באמצעות
unloadModel()
.
טיפול בשגיאות HAL
כדי להבטיח התנהגות אמינה ועקבית בין יישומי מנהלי התקנים, ב-Android 11, כל קודי שגיאה שאינם מציינים הצלחה שמוחזרים מ-HAL נחשבים לשגיאות תכנות, והתיקון שלהן מחייב הפעלה מחדש של תהליך HAL. זו אסטרטגיית שחזור שמשתמשים בה כמוצא אחרון, וההנחה היא שמקרים כאלה לא יקרו במערכת שעובדת בצורה תקינה.