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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לבדוק אם האפליקציה עומדת בדרישות במכשירים עם 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 של האודיו שהושפעו