החל מ-Android 17, מסגרת האודיו אוכפת הגבלות על אינטראקציות עם אודיו ברקע, כולל הפעלת אודיו, בקשות למיקוד אודיו וממשקי API של שינוי עוצמת הקול, כדי לוודא שהמשתמש יזום את השינויים האלה באופן מכוון.
אם מפתח אפליקציה רוצה לשלוט באודיו בלי פעילות גלויה, הוא צריך לוודא שהאפליקציה כוללת שירות חזיתי (שלא מסוג SHORT_SERVICE) שהופעל עם יכולות בזמן השימוש (WIU). לשירות שפועל בחזית יש יכולות WIU אם הוא מופעל בתגובה ל-MediaSessionEvent או בזמן שהאפליקציה גלויה למשתמש.
אם האפליקציה מנסה לקרוא לממשקי API של אודיו בזמן שהאפליקציה לא נמצאת במחזור חיים תקין, ממשקי ה-API של הפעלת האודיו ושינוי עוצמת הקול נכשלים בשקט בלי להציג חריגה או לספק הודעת שגיאה. ה-API של מיקוד האודיו נכשל עם קוד התוצאה AUDIOFOCUS_REQUEST_FAILED.
ההגבלות האלה נועדו לצמצם את המקרים של באגים לא מכוונים ברקע של אודיו. הנה כמה דוגמאות:
- אפליקציות שמפעילות אודיו בלי שירות בחזית עלולות להיות מוקפאות. כשהאפליקציה מופעלת מחדש, הפעלת האודיו מתחדשת באופן לא צפוי, לפעמים אחרי כמה שעות.
- אפליקציות שמפעילות אודיו בלי שירות בחזית נתקלו במגבלות שונות על ההפעלה, שגרמו לביצועים לא חלקים של האודיו.
- ההפעלה מנותקת ממחזור החיים של הפעילות, מה שעלול לגרום לדליפה של סשן הפעלה או של אירועי מיקוד, שממשיכים ללא אפשרות למשתמש להפסיק את ההפעלה.
אנחנו מעודדים מפתחים לבדוק את האפליקציות שלהם ולספק משוב על השינוי בהתנהגות אם יש תרחישי שימוש מכוונים באודיו שהושפעו לרעה. כדי לדווח על בעיות, אפשר להשתמש בכלי הזה למעקב אחרי בעיות תאימות של אפליקציות ב-Android 17.
זיהוי תרחישים לדוגמה לשימוש באודיו ברקע שמושפעים מהשינוי
צריך לבדוק את ההטמעה של הפעלת האודיו ולזהות אם האפליקציה אמורה לספק פונקציונליות של אינטראקציה עם אודיו ברקע גם בנסיבות מותנות.
אם האפליקציה מיועדת להפעיל אודיו או להשתמש בממשקי API של אודיו רק בזמן שהיא מציגה פעילות שגלויות למשתמש, כולל שימוש במצב 'תמונה בתוך תמונה' (PiP), השינויים האלה לא ישפיעו עליה.
אם האפליקציה שלכם מספקת פונקציונליות של VoIP, כולל אפליקציות לשיחות וידאו, היא כבר צריכה לעמוד בדרישות החדשות להפעלה (בדרך כלל באמצעות שימוש בממשקי ה-API המומלצים של טלקום) כדי להקליט אודיו בהצלחה, ולכן סביר להניח שהיא לא תושפע.
אם האפליקציה שלכם מיועדת להמשיך להפעיל אודיו כשהמסך כבוי או כשהמשתמש סגר את הפעילות באפליקציה (כמו באפליקציות של סטרימינג מוזיקה או באפליקציות של פודקאסטים), האפליקציה נחשבת ככזו שמספקת פונקציונליות של אודיו ברקע, והיא צריכה לעמוד בדרישות החדשות.
תרחישים שבהם סביר להניח שתהיה השפעה על האודיו ברקע
אם האפליקציה לא פועלת לפי המודל של המשך אינטראקציה עם אודיו שהתחילה כשהאפליקציה הייתה פתוחה, או בתגובה להפעלה מפורשת של המשתמש, סביר להניח שהפונקציונליות של האפליקציה תושבת בשקט.
לדוגמה, אם האפליקציה מפעילה שירות שפועל בחזית בתגובה ל-BOOT_COMPLETE ומנסה לבצע אינטראקציה עם אודיו, הפעולה תיחסם.
שיטות מומלצות לשימוש באודיו ברקע כדי לצמצם את ההשפעה
אפשר להשתמש ברכיב
MediaSessionServiceשל ספריית Jetpack media3 כדי לנהל את הפעלת האודיו ברקע.אם תעשו זאת, סביר להניח שהאפליקציה שלכם לא תושפע מההקשחה ברקע, כי הספרייה עוזרת לנהל את מחזור החיים של ההפעלה.
אם אתם לא משתמשים בספריית media3, תצטרכו להפעיל
mediaPlaybackFGS באופן ידני. תמיד מפעילים שירות שפועל בחזית כשהאפליקציה בחזית, אם יכול להיות שיושמע אודיו ברקע.לדוגמה, אם האפליקציה שלכם היא אפליקציה להזרמת וידאו שבדרך כלל פועלת רק בחזית, אבל יש בה אמצעי נוחות למשתמש להמשך ההפעלה כשהמסך כבוי, אז כשההפעלה מופעלת על ידי המשתמש, האפליקציה עדיין צריכה להפעיל שירות בחזית.
הפעולה הזו מבטיחה שהשירות שפועל בחזית יופעל עם יכולות WIU.
חשוב להשאיר את
mediaPlaybackFGS פעיל במהלך כשלים זמניים שנמשכים פחות מ-10 דקות.אם באפליקציה יש כשל זמני, כמו בעיה בחיץ (באפרינג) בגלל פעילות ברשת, או שיש הפרעה זמנית צפויה כמו
AUDIOFOCUS_LOSS_TRANSIENT, כוונת ההפעלה צריכה להימשך. לכן, חשוב שה-FGS שלכם יישאר פעיל.הפסקת השירות שפועל בחזית בסיום ההפעלה והפעלה מחדש רק אם המשתמש מפעיל מחדש את ההפעלה באופן מפורש.
במקרה של אות קבוע לסיום ההפעלה (לדוגמה, תוכן שהסתיים ללא הפעלה אוטומטית,
AUDIOFOCUS_LOSS, אירוע השהיה מ-UMO או אירוע של מקש מדיה) או כשל שלא ניתן לשחזר, האפליקציה צריכה להפסיק את האינטראקציה עם האודיו, להפסיק את שירות החזית ולסיים את סשן המדיה. כל הפעולות האלה תואמות לתפיסה של המשתמש לגבי סיום האינטראקציה הרצויה עם האודיו ברקע. אחרי שמבצעים את הפעולה הזו, לאפליקציה אין יותר יכולות של אינטראקציה עם אודיו ברקע.לאחר מכן, אם המשתמש מפעיל מחדש את ההפעלה באופן מפורש, למשל דרך ממשק המשתמש של האפליקציה או דרך לחצן ההפעלה של אובייקט המדיה האוניברסלי, הכוונה להפעיל את השמע צריכה לחזור, וכתוצאה מכך יופעל FGS חדש.
בודקים את התנהגות ההפעלה של האודיו באמצעות פקודות של adb shell.
בדיקת שינויים ב-Android מגרסה 16 ומגרסה 17
התכונה כבר מוטמעת ברמת 'אזהרה' מגרסה Android 16 ואילך. המשמעות היא שאפליקציות יכולות להשתמש ב-adb shell cmd audio
set-enable-hardening כדי לבדוק באופן ידני את האכיפה של חיזוק האודיו ברקע.
כדי להפעיל את האכיפה במכשירים עם Android 16, מריצים את הפקודה הבאה:
adb shell cmd audio set-enable-hardening 1
כדי להשבית את האכיפה במכשירים שפועלת בהם מערכת Android 17, מריצים את הפקודה הבאה:
adb shell cmd audio set-enable-hardening 0
מומלץ גם להשתמש ב-logcat או בפקודת adb adb dumpsys audio כדי לזהות אם האפליקציה נתקלה בכשלים שקטים בגלל אכיפה של חיזוק האודיו. אם כן, ביומן יופיע קטע שמתחיל ב-AudioHardening עם שם החבילה שלכם.
הסבר על FGS עם יכולת גישה בזמן שימוש
באופן כללי, שירותים שפועלים בחזית (FGS) צריכים להיות מופעלים בזמן שהאפליקציה פועלת בחזית כדי להאריך פעולות שהמשתמש יזם. במקרים ספציפיים מסוימים, מותר לאפליקציות להפעיל שירות שפועל בחזית בזמן שהאפליקציה פועלת ברקע. עם זאת, בדרך כלל לא ניתנות לשירותים האלה שפועלים בחזית יכולות While-In-Use (WIU).
ה-WIU פועל כשער אבטחה – הוא מונע מ-FGS שהופעל מהרקע לבצע התנהגויות רגישות מסוימות, במקרים שבהם המשתמש לא מודע לפעילות של האפליקציה. היא מונעת מהאפליקציה לגשת לנתונים רגישים כמו מיקום, מצלמה או מיקרופון, ומגרסה Android 17 ואילך היא גם חוסמת ממשקי API של אודיו שבדרך כלל דורשים הקשר גלוי של ממשק משתמש.
הנה קישור שימושי:
- שירות FGS רגיל: שירותים שהופעלו בזמן שהאפליקציה גלויה או שקיבלו יכולת הפעלה של פעילות ברקע מקבלים גישה ל-WIU.
- שירותים עם הפעלה ברקע (BFSL): רובם לא מעניקים גישה ל-WIU. החריגים העיקריים שמאפשרים WIU הם אינטראקציות שכוללות כוונה מפורשת של המשתמש, לדוגמה, קליקים על התראות, אינטראקציות עם ווידג'טים או אירועים של מקשי מדיה ממכשיר חיצוני.
- המערכת התחילה FGS: ל-FGS ניתנה גישת WIU, והיא התחילה להשתמש בהעברה של שרת המערכת (לדוגמה, באמצעות ספריית Telecom Jetpack).
מידע נוסף על הגבלות על הפעלה מהרקע של שירות שפועל בחזית
רשימה מלאה של ממשקי API של אודיו שהושפעו
פונקציית אודיו |
התוצאה |
ממשקי API שהושפעו |
הפעלת האודיו |
ההפעלה מושתקת אין חריגים, לא מתקבלת הודעת שגיאה מאף API |
(NDK) יכול להיות שגם ספריות מדיה בצד הלקוח שמנהלות את ההפעלה, כמו media3, Exoplayer ו-Oboe, יושפעו. |
בקשה להרשאת אודיו |
החזרות אין השפעה על הפעלת אודיו באפליקציות אחרות, לא הושג מיקוד |
|
ממשקי API של עוצמת הקול ומצב הצלצול |
אין השפעה על מצב הצלצול או עוצמת הקול (הקריאה לשיטה מתעלמת בשקט) אין חריגים, לא מתקבלת הודעת שגיאה מאף API |
|