יכולות התצוגה (כמו מצבי תצוגה וסוגי HDR נתמכים) יכולות להשתנות באופן דינמי במכשירים עם מסכים שמחוברים מבחוץ (עם HDMI או DisplayPort), כמו ממירים (STB) של Android TV ומכשירים שמועברים ישירות ללקוח (OTT). השינוי הזה יכול לנבוע מאותת חיבורי HDMI. למשל, כשהמשתמש עובר ממסך אחד לאחר או מאתחל את המכשיר ללא מסך מחובר. מערכת Android בגרסה 12 ואילך כוללת שינויים במסגרת כדי להתמודד עם יכולות של חיבור חם ותצוגה דינמית.
בדף הזה נסביר את אופן הטיפול בשקעים חשמליים במסך ובשינויים ביכולות התצוגה בהטמעת Composer HAL. בנוסף, נסביר איך לנהל את מאגר הנתונים הזמני המשויך ולמנוע מרוץ תהליכים במצבים האלה.
עדכון יכולות התצוגה
בקטע הזה מוסבר איך מערכת Android מטפלת בשינויים ביכולות התצוגה שהופעלו על ידי Composer HAL.
כדי שמערכת Android תוכל לטפל כראוי בשינויים ביכולות התצוגה, יצרן הציוד המקורי צריך להטמיע את Composer HAL כדי שהיא תשתמש ב-onHotplug(display, connection=CONNECTED)
כדי להודיע ל-framework על שינויים ביכולות התצוגה. לאחר ההטמעה, Android מטפל בשינויים ביכולות התצוגה באופן הבא:
- כשמזהים שינוי ביכולות התצוגה, ה-framework מקבל התראה לגבי
onHotplug(display, connection=CONNECTED)
. - עם קבלת ההתראה, מסגרת ה-framework משמיטה את מצב התצוגה שלה ויוצרת אותה מחדש עם היכולות החדשות מ-HAL באמצעות השיטות
getActiveConfig
,getDisplayConfigs
,getDisplayAttribute
,getColorModes
,getHdrCapabilities
ו-getDisplayCapabilities
. - אחרי שה-framework יוצר מצב תצוגה חדש, הוא שולח את הקריאה החוזרת (callback) של
onDisplayChanged
לאפליקציות שמאזינים לאירועים כאלה.
ה-framework מקצה מחדש את חוצי הגבולות לאירועי onHotplug(display, connection=CONNECTED)
הבאים. במאמר ניהול של מאגרי נתונים זמניים של לקוחות מוסבר איך לנהל בצורה נכונה את הזיכרון של מאגר הנתונים הזמני כדי למנוע כשלים במהלך ההקצאה של חוצץ פריימים חדש.
טיפול בתרחישים נפוצים של חיבור
בקטע הזה מוסבר איך לטפל כראוי בתרחישי חיבור שונים בהטמעות כאשר המסך הראשי מחובר ומנותק.
המסגרת של Android, שמיועדת למכשירים ניידים, לא כוללת תמיכה מובנית במסך ראשי מנותק. במקום זאת, במקרה שמסך ראשי מנותק באופן פיזי, ממשק HAL חייב להחליף את המסך הראשי ב-placeholder באינטראקציות עם המסגרת.
התרחישים הבאים יכולים להתרחש במכשירי STB ובמתאמי טלוויזיה עם מסכים מחוברים חיצוניים שאפשר לנתק. כדי להטמיע תמיכה בתרחישים האלה, תוכלו להיעזר במידע שמפורט בטבלה הבאה:
תרחיש | שימוש |
---|---|
אין מסך מחובר בזמן ההפעלה |
|
המסך הראשי מחובר פיזית |
|
המסך הראשי מנותק פיזית |
|
שיקולים בנוגע לחיבור ללא HDMI
מערכת Android TV תומכת רק ברזולוציות הבאות:
- 720x1280
- 1,080 x 1,920
- 2,160 x 3,840
- 4,320 x 7,680
כשמתאם STB או טלוויזיה מנסה להציג רזולוציה שלא נתמכת, למשל 480i בחיבור CVBS, מוצגת הודעת שגיאה למשתמש.
אם למתאם הטלוויזיה או ל-STB יש חיבור HDMI וגם חיבור HDMI, חיבור ה-HDMI הוא המסך הראשי והחיבור שאינו HDMI לא פעיל. לכן, אם חיבור ה-HDMI מנותק בזמן שהחיבור ללא HDMI עדיין מחובר, האירוע נשלח ל-SurfaceFlinger והיכולות של המסך שהוא לא HDMI צריכות להשתקף דרך getDisplayAttribute
וממשקי API אחרים של iComposerClient
(כמו getHdrCapabilities
).
שימוש במזהי config רציפים כדי למנוע מרוץ תהליכים
מרוץ תהליכים יכול להתרחש אם Composer HAL מעדכן את הגדרות התצוגה הנתמכות במקביל ל-framework של קריאה ל-setActiveConfig
או ל-setActiveConfigWithConstraints
.
הפתרון הוא להטמיע את Composer HAL כדי להשתמש במזהים רציפים ולמנוע את הבעיה הזו.
בקטע הזה מופיע תיאור של מרוץ המרוץ. בהמשך מפורט איך להטמיע את Composer HAL כדי להשתמש במזהים רציפים כדי למנוע מצבים כאלה.
כדאי להביא בחשבון את רצף האירועים הבא, שבו מזהים עוקבים חדשים לא מוקצים להגדרות התצוגה החדשות, וכתוצאה מכך מרוץ תהליכים:
מזהי התצורה הנתמכים של הגדרות התצוגה הם:
- id=1, 1080x1920 60 Hz
- id=2, 1,080x1,920 50 Hz
תוכנת ה-framework קוראת ל-
setActiveConfig(display, config=1)
.בו-זמנית, Composer HAL מעבד שינוי בהגדרות התצוגה ועדכן את המצב הפנימי שלו לקבוצה חדשה של הגדרות תצוגה, כפי שמוצג באופן הבא:
- id=1, 2,160x3840 60 Hz
- id=2, 2,160x3840 50 Hz
- id=3, 1,080x1,920 60 Hz
- id=4, 1,080x1,920 50 Hz
Composer HAL שולח אירוע
onHotplug
ל-framework כדי להודיע שקבוצת המצבים הנתמכים השתנתה.Composer HAL מקבל
setActiveConfig(display, config=1)
(משלב 2).לפי ה-HAL, פירוש הדבר הוא שה-framework ביקש שינוי הגדרה ל-2160x3840 60 Hz, למרות שבמציאות היה רצוי 1080x1920 60 Hz.
התהליך באמצעות הקצאות לא עוקבות של מזהים מסתיים כאן בפרשנות שגויה של שינוי ההגדרה הרצוי.
הגדרת Composer HAL לשימוש במזהים רציפים
כדי למנוע מרוץ תהליכים כאלה, ה-OEM (יצרן הציוד המקורי) חייב להטמיע את Composer HAL באופן הבא:
- כש-Composer HAL מעדכן את הגדרות התצוגה הנתמכות, הוא מקצה מזהים עוקבים חדשים להגדרות התצוגה החדשות.
- כשה-framework קורא ל-
setActiveConfig
או ל-setActiveConfigWithConstraints
עם מזהה config לא חוקי, Composer HAL מתעלם מהקריאה.
השלבים האלה נועדו למנוע מרוץ תהליכים כפי שמוצג בדיון הבא.
נבחן את רצף האירועים הבא, כאשר מזהים עוקבים חדשים מוקצים להגדרות התצוגה החדשות:
מזהי התצורה הנתמכים של הגדרות התצוגה הם:
- id=1, 1080x1920 60 Hz
- id=2, 1,080x1,920 50 Hz
תוכנת ה-framework קוראת ל-
setActiveConfig(display, config=1)
.כשהמערכת מעבדת שינוי בהגדרות תצוגה, הקבוצה הבאה של מזהי config מוקצית החל מהמספר השלם הבא שלא נמצא בשימוש, באופן הבא:
id=3, 2,160x3840 60 Hz
id=4, 2,160x3840 50 Hz
id=5, 1,080x1,920 60 Hz
id=6, 1,080x1,920 50 Hz
Composer HAL שולח אירוע
onHotplug
ל-framework כדי להודיע שקבוצת המצבים הנתמכים השתנתה.HAL של ה-Composer מקבל
setActiveConfig(display, config=1)
(משלב 2).Composer HAL מתעלם מהקריאה כי המזהה כבר לא חוקי.
ה-framework מקבל ומעבד את האירוע
onHotplug
משלב 4. הוא שולח קריאה ל-Composer HAL באמצעות הפונקציותgetDisplayConfigs
ו-getDisplayAttribute
. באמצעות הפונקציות האלה, ה-framework מזהה את המזהה החדש (5) של הרזולוציה וקצב הרענון הרצויים של 1080x1920 ו-60 Hz.ה-framework שולח אירוע
setActiveConfig
נוסף עם המזהה המעודכן 5.Composer HAL מקבל
setActiveConfig(display, config=5)
משלב 5.ה-HAL מפרש נכון שה-framework ביקש שינוי הגדרה ל-1080x1920 60 Hz.
כפי שמוצג בדוגמה למעלה, התהליך באמצעות הקצאות של מזהים עוקבים מבטיח שתנאי המרוץ נמנעים ושהשינוי הנכון בהגדרות התצוגה מתעדכן.