חיזוק האבטחה של אודיו ברקע

החל מ-Android 17, מסגרת האודיו אוכפת הגבלות על אינטראקציות עם אודיו ברקע, כולל הפעלת אודיו, בקשות להרשאת אודיו וממשקי API של שינוי עוצמת הקול, כדי לוודא שהמשתמש יזום את השינויים האלה באופן מכוון.

כל האפליקציות שפועלות ב-Android 17 וכוללות אינטראקציות עם אודיו ברקע חייבות לכלול פעילות גלויה או להפעיל שירות בחזית שאינו מסוג SHORT_SERVICE. הכלל הזה רלוונטי גם אם האפליקציה מטרגטת רמת API‏ 37 וגם אם לא.

אם אפליקציה מטרגטת ל-Android 17 (רמת API 37), יש הגבלה נוספת. אם האפליקציה פועלת ברקע, היא צריכה להפעיל שירות שפועל בחזית עם יכולות while-in-use (בזמן השימוש). (לשירות בחזית המכשיר ניתנות יכולות WIU אם הוא מופעל בתגובה לפעולה שהמשתמש יזם או בזמן שהאפליקציה גלויה למשתמש). עם זאת, הדרישה ליכולות WIU לא חלה אם לאפליקציה ניתנה ההרשאה exact alarm, והיא מבצעת שינויים בזרמי אודיו עם המאפיין USAGE_ALARM.

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

למה אנחנו מבצעים את השינוי

ההגבלות האלה נועדו לצמצם את המקרים של באגים לא מכוונים ברקע של אודיו. הנה כמה דוגמאות:

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

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

זיהוי תרחישים לדוגמה לשימוש באודיו ברקע שהושפעו

צריך לבדוק את ההטמעה של הפעלת האודיו ולזהות אם האפליקציה אמורה לספק פונקציונליות של אינטראקציה עם אודיו ברקע גם בנסיבות מותנות.

אם האפליקציה מיועדת להפעיל אודיו או להשתמש בממשקי API של אודיו רק בזמן שהיא מציגה פעילות שגלויות למשתמש, כולל שימוש במצב 'תמונה בתוך תמונה' (PiP), השינויים האלה לא ישפיעו עליה.

אם האפליקציה שלכם מספקת פונקציונליות של VoIP, כולל אפליקציות לשיחות וידאו, היא כבר צריכה לעמוד בדרישות החדשות להפעלה (בדרך כלל באמצעות שימוש בממשקי ה-API המומלצים של טלקום) כדי להקליט אודיו בהצלחה, ולכן סביר להניח שהיא לא תושפע.

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

תרחישים של אודיו ברקע שסביר להניח שיושפעו

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

לדוגמה, אם האפליקציה מפעילה שירות שפועל בחזית בתגובה ל-BOOT_COMPLETE ומנסה לבצע אינטראקציה עם אודיו, הפעולה תיחסם.

שיטות מומלצות לשימוש באודיו ברקע כדי לצמצם את ההשפעה

• אפשר להשתמש ברכיב MediaSessionService של ספריית Jetpack‏ media3 כדי לנהל את הפעלת האודיו ברקע.

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

• אם אתם לא משתמשים בספריית media3, תצטרכו להפעיל mediaPlayback FGS באופן ידני. תמיד מפעילים שירות שפועל בחזית כשהאפליקציה בחזית, אם יכול להיות שיושמע אודיו ברקע.

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

  הפעולה הזו מבטיחה שהשירות שפועל בחזית יופעל עם יכולות WIU.

• חשוב להשאיר את mediaPlayback FGS פעיל במהלך כשלים זמניים שנמשכים פחות מ-10 דקות.

  אם באפליקציה יש כשל זמני, כמו בעיה בחיץ (באפרינג) בגלל פעילות ברשת, או שיש הפרעה זמנית צפויה כמו AUDIOFOCUS_LOSS_TRANSIENT, הפעולה של הפעלת התוכן צריכה להימשך. לכן, חשוב שה-FGS שלכם יישאר פעיל.

• הפסקת השירות שפועל בחזית בסיום ההפעלה והפעלה מחדש רק אם המשתמש מפעיל מחדש את ההפעלה באופן מפורש.

  במקרה של אות קבוע לסיום ההפעלה (לדוגמה, תוכן שהסתיים ללא הפעלה אוטומטית, AUDIOFOCUS_LOSS, אירוע השהיה מ-UMO או אירוע של מקש מדיה) או כשל שלא ניתן לשחזר, האפליקציה צריכה להפסיק את האינטראקציה עם האודיו, להפסיק את שירות שפועל בחזית ולסיים את סשן המדיה. כל הפעולות האלה תואמות לתפיסה של המשתמש לגבי סיום האינטראקציה הרצויה עם האודיו ברקע. אחרי שתעשו את זה, לאפליקציה שלכם לא יהיו יותר יכולות של אינטראקציה עם אודיו ברקע.

  לאחר מכן, אם המשתמש מפעיל מחדש את ההפעלה באופן מפורש, למשל דרך ממשק המשתמש של האפליקציה או דרך לחצן ההפעלה של Universal Media Object, הכוונה להתחיל הפעלת אודיו צריכה לחזור, וכתוצאה מכך יופעל FGS חדש.

• בודקים את התנהגות ההפעלה של האודיו באמצעות פקודות של adb shell.

בדיקת שינויים

כדי לבדוק את התאימות של האפליקציה באפליקציות שפועלות ב-Android 17 ואילך (החל מגרסת בטא 3), מריצים את פקודת ה-ADB הבאה:

adb shell cmd audio set-enable-hardening <enable|disable|throw>

לפקודה הזו יש את האפשרויות הבאות:

• ‫enable: הפעלה של כל ההגבלות על אבטחת האודיו בכל האפליקציות. הדרישה לשירותים בחזית של WIU חלה בין אם האפליקציה מטרגטת ל-Android 17 (רמת API 37) ובין אם לא. בנוסף, הדרישה נאכפת גם אם האפליקציה מבצעת שינויים בזרמי התראות ויש לה את הרשאת ההתראה המדויקת.

• ‫disable: השבתה של כל ההגבלות על אבטחת אודיו.

• ‫throw: מפעיל את כל ההגבלות על אבטחת האודיו לכל האפליקציות, כמו enable. בנוסף, הדגל הזה מאפשר להציג כשלים חמורים, ויוצר IllegalStateException לאינטראקציות של עוצמת הקול והמיקוד. במקרה של הפעלת אודיו, שיטת הכתיבה מחזירה באופן עקבי קוד שגיאה. האפליקציה קורסת במצבי הפעלה ללא כתיבות מפורשות.

אפשר להשתמש ב-adb dumpsys audio או ב-logcat כדי לזהות אם האפליקציה נתקלה בכשלים שקטים בגלל אכיפה של חיזוק האודיו. אם כן, תופיע רשומה עם הקידומת AudioHardening ושם החבילה שלכם. אם ההודעה מכילה את המחרוזת level: full, האפליקציה מפעילה שירות שפועל בחזית, אבל לשירות אין אפשרות לפעול בזמן השימוש באפליקציה. אם ההודעה מכילה level: partial, האפליקציה לא מפעילה שירות שפועל בחזית.

הסבר על FGS עם יכולת שימוש בזמן שהאפליקציה פועלת

באופן כללי, שירותים שפועלים בחזית (FGS) צריכים להיות מופעלים בזמן שהאפליקציה פועלת בחזית כדי להאריך פעולות שהמשתמש יזם. במקרים ספציפיים, מותר לאפליקציות להפעיל שירות שפועל בחזית בזמן שהאפליקציה פועלת ברקע. עם זאת, בדרך כלל לא ניתנות לשירותים האלה יכולות של 'בזמן השימוש' (WIU).

ה-WIU פועל כשער אבטחה – הוא מונע מ-FGS שהופעל מהרקע לבצע התנהגויות רגישות מסוימות, במקרים שבהם המשתמש לא מודע לפעילות של האפליקציה. היא מונעת מהאפליקציה לגשת למידע אישי רגיש כמו מיקום, מצלמה או מיקרופון, ומגרסה Android 17 ואילך היא גם חוסמת ממשקי API של אודיו שבדרך כלל דורשים הקשר גלוי של ממשק משתמש.

הנה קישור שימושי:

• שירות FGS רגיל: שירותים שמופעלים בזמן שהאפליקציה גלויה או שניתנה להם יכולת הפעלה של פעילות ברקע מקבלים גישה ל-WIU.
• שירותים שמופעלים ברקע (BFSL): רובם לא מעניקים גישה ל-WIU. החריגים העיקריים שמאפשרים WIU הם אינטראקציות שכוללות כוונה מפורשת של המשתמש, לדוגמה, קליקים על התראות, אינטראקציות עם ווידג'טים או אירועים של מקשי מדיה ממכשיר חיצוני.
• המערכת התחילה FGS: שירותי חזית מקבלים גישת WIU אם הם מופעלים על ידי הקצאת הרשאות של שרת המערכת (לדוגמה, מספריית Telecom Jetpack), או על ידי קישורי מערכת שמייצגים מצב חזית מורחב כדי לבצע פונקציונליות ייעודית (לדוגמה, עבור VoiceInteractionService).

מידע נוסף על הגבלות על הפעלה מהרקע של שירות שפועל בחזית

רשימה מלאה של ממשקי API של אודיו שהושפעו