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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אם אתם לא משתמשים בספריית 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) צריכים להיות מופעלים בזמן שהאפליקציה פועלת בחזית כדי להאריך פעולות שהמשתמש יזם. במקרים ספציפיים, מותר לאפליקציות להפעיל שירות שפועל בחזית בזמן שהאפליקציה פועלת ברקע. עם זאת, בדרך כלל לא ניתנות לשירותים האלה שפועלים בחזית יכולות While-In-Use (WIU).

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

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

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

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

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