באמצעות מסגרת Android, יצרני מכשירים ומפתחי אפליקציות יכולים להשתמש בנתונים תרמיים כדי להבטיח חוויית משתמש עקבית (UX) אם המכשיר מתחיל להתחמם יתר על המידה. לדוגמה, כשמערכת עוברת עומס תרמי, משימות jobscheduler מווסתות ובמקרה הצורך מופעלת השבתה תרמית של המסגרת. אפליקציות שמקבלות התראות על לחץ תרמי דרך קריאה חוזרת רשומה בכיתה PowerManager יכולות לשנות את חוויית המשתמש בצורה חלקה.
Thermal HAL
בגרסאות Android 9 ומטה נעשה שימוש בממשק סקירה (polling) שמוגדר ב-Thermal HAL 1.0 כדי לקבל קריאות טמפרטורה. ה-HAL הזה איפשר ל-Android Framework וללקוחות מהימנים אחרים, כמו HAL של יצרן המכשיר, לקרוא את הטמפרטורה הנוכחית ואת ערכי הסף הספציפיים למדיניות המוצר של ניתוב התנועה וההשבתה לכל חיישן באמצעות אותו ממשק API.
ב-Android 10 הושק רכיב תרמי במסגרת Android וגרסה חדשה של HAL, Thermal HAL 2.0, שמציגה את הממשק למכשירי החומרה של מערכת המשנה התרמית בצורה מופשטת. ממשק החומרה כולל חיישני טמפרטורה ותרמוסטטים לעור, לסוללה, ל-GPU, למעבד (CPU) וליציאת USB. טמפרטורת העור של המכשיר היא המערכת החשובה ביותר למעקב כדי לשמור על טמפרטורת פני המכשיר בתוך המגבלות התרמו-פיזיות שצוינו.
בנוסף, Thermal HAL 2.0 מספק ללקוחות מרובים קריאות של חיישן תרמי ורמות חומרה משויכות כדי לציין לחץ תרמי. האיור הבא מציג שתי הודעות אזהרה מממשק המשתמש של מערכת Android. ההודעות האלה מוצגות כשממשק הקריאה החוזרת (callback) של IThermalEventListener לחיישנים USB_PORT ו-SKIN, בהתאמה, מגיע לרמת החומרה THERMAL_STATUS_EMERGENCY.
איור 1. אזהרות על התחממות יתר.
הטמפרטורות הנוכחיות של סוגי החיישנים התרמיים מאוחזרות דרך IThermal HAL. כל קריאה לפונקציה מחזירה ערך סטטוס של SUCCESS או FAILURE. אם הערך המוחזר הוא SUCCESS, התהליך ממשיך. אם הערך FAILURE מוחזר, הודעת שגיאה, שצריכה להיות קריאת לבני אדם, נשלחת אל status.debugMessage.
בנוסף להיות ממשק דגימה שמחזיר את הטמפרטורות הנוכחיות, אפשר להשתמש בקריאה חוזרת (callback) IThermalChangedCallback (HIDL, Android 10 עד 13) או
IThermalChangedCallback (AIDL, Android 14 ואילך)
עם ממשק הקריאה החוזרת של לקוחות תרמיים עם HAL, למשל השירות התרמי של framework. לדוגמה, RegisterIThermalChangedCallback ו-UnregisterIThermalChangedCallback כדי לרשום או לבטל רישום אירועים שהרמה שלהם השתנתה. אם החומרה התרמית של חיישן נתון השתנתה, notifyThrottling שולח קריאה חוזרת (callback) של אירוע ויסות תרמי למאזינים לאירועים תרמיים.
בנוסף למידע על חיישן התרמי, ב-getCurrentCoolingDevices מוצגת רשימה של מכשירי קירור עם הפחתת עומס. הסדר ברשימה הזו נשמר, גם אם מכשיר קירור עבר למצב אופליין. יצרני המכשירים יכולים להשתמש ברשימה כדי לאסוף מדדים של statsd.
מידע נוסף זמין במאמר הטמעת הפניה.
אפשר להוסיף תוספים משלכם, אבל לא כדאי להשבית את הפונקציה של הפחתת החום.
שירות תרמי
ב-Android מגרסה 10 ואילך, השירות התרמי במסגרת מספק מעקב קבוע באמצעות אותות ההפחתה השונים מ-Thermal HAL 2.0, ומספק ללקוחות משוב על חומרת הצמצום. הלקוחות האלה כוללים רכיבים פנימיים ואפליקציות ל-Android. השירות משתמש בשני ממשקי קריאה חוזרת של Binder, IThermalEventListener ו-IThermalStatusListener, שנחשפים כקריאות חוזרות. הקוד הראשון מיועד לשימוש פנימי של יצרני פלטפורמות ומכשירים, והקוד השני מיועד לאפליקציות ל-Android.
באמצעות ממשקי הקריאה החוזרת (callback), ניתן לאחזר את הסטטוס התרמי הנוכחי של המכשיר כערך מספר שלם שנע בין 0x00000000 (ללא ויסות נתונים) ל-0x00000006 (כיבוי המכשיר). רק שירות מערכת מהימן, כמו ממשק API ל-Android או ממשק ה-API של יצרן המכשיר, יכול לגשת למידע המפורט של החיישן התרמי ושל האירועים התרמיים. באיור הבא מוצג מודל של תהליך הפחתת החום ב-Android 10 ואילך:
איור 2. תהליך הפחתת החום ב-Android מגרסה 10 ואילך.
הנחיות ליצרן המכשיר
כדי לדווח על חיישן הטמפרטורה של המכשיר ועל סטטוס הצמצום של Android מגרסה 10 עד 13, יצרני המכשירים צריכים להטמיע את ההיבט של HIDL ב-Thermal HAL 2.0 (IThermal.hal).
כדי לדווח על חיישן הטמפרטורה של המכשיר ועל סטטוס הצמצום ב-Android 14, יצרני המכשירים צריכים להטמיע את ההיבט של AIDL ב-Thermal HAL 2.0 (IThermal.aidl).
כל דבר שגורם לבלימת הביצועים של המכשיר, כולל אילוצים של הסוללה, חייב להיות מדווח דרך ה-HAL התרמי. כדי לוודא שזה יקרה, צריך להוסיף את כל החיישנים שעשויים להצביע על צורך בצמצום (על סמך שינויים בסטטוס) ל-HAL התרמי, ולדווח על חומרת הפעולות לצמצום שבוצעו. ערך הטמפרטורה שמוחזר מקריאת חיישן לא חייב להיות הטמפרטורה בפועל, כל עוד הוא משקף במדויק את סף החומרה התואם. לדוגמה, אפשר להעביר ערכים מספריים שונים במקום ערכי הסף בפועל של הטמפרטורה, או להוסיף טווחי הגנה למפרטי הסף כדי לספק היסטירציה. עם זאת, מידת החומרה שתואם לערך הזה חייבת להתאים למה שנדרש באותו סף. לדוגמה, אפשר להחליט להחזיר את הערך 72°C כסף הטמפרטורה הקריטית, כשהטמפרטורה בפועל היא 65°C, והיא תואמת לרמת החומרה הקריטית שציינתם. רמת החומרה חייבת להיות מדויקת כדי לספק את הפונקציונליות הטובה ביותר של המסגרת התרמית.
מידע נוסף על רמות הסף במסגרת ועל האופן שבו הן תואמות לפעולות לצמצום ההשפעה זמין במאמר שימוש בקודים של סטטוס חום.
שימוש בממשקי API תרמיים
אפליקציות יכולות להוסיף ולהסיר מאזינים, ולגשת למידע על המצב התרמי באמצעות הכיתה PowerManager.
הממשק IThermal מספק את כל הפונקציונליות הנדרשת, כולל החזרת ערכי הסטטוס התרמי. ממשק ה-binder של Thermal עטוף בממשק OnThermalStatusChangedListener, שבו אפליקציות יכולות להשתמש כשהן רושמות או מסירות מאזינים לסטטוס התרמי.
ממשקי ה-API התרמיים של Android כוללים גם שיטות קריאה חוזרת (callback) וגם שיטות דגימה לאפליקציות לקבלת התראות לגבי רמות החומרה התרמית באמצעות קודי סטטוס, שמוגדרים במחלקה PowerManager. ה-methods הם:
- הפונקציה
getCurrentThermalStatus()מחזירה את הסטטוס התרמי הנוכחי של המכשיר כמספר שלם, אלא אם המכשיר עובר צמצום עוצמה. addThermalStatusListener()הוספת מאזין.removeThermalStatusListener()מסירה מאזין שנוסף בעבר.
שימוש בקודים של סטטוס תרמי
קודי הסטטוס התרמיים מתורגמים לרמות ספציפיות של ויסות נתונים, ואפשר להשתמש בהן לאיסוף נתונים ולתכנון חוויית משתמש אופטימלית. לדוגמה, אפליקציות עשויות לקבל את הסטטוס 0x00000000 (THERMAL_STATUS_NONE), שעשוי להשתנות בהמשך ל-0x00000001 (THERMAL_STATUS_LIGHT). סימון המצב 0x00000000 כ-t0, ומדידת הזמן שחלף מהסטטוס THERMAL_STATUS_NONE לסטטוס THERMAL_STATUS_LIGHT כ-t1, מאפשר ליצרני המכשירים לתכנן ולבדוק אסטרטגיות לצמצום הבעיה לתרחישים ספציפיים לדוגמה. בטבלה הבאה מפורטות הצעות לשימוש בקוד הסטטוס התרמי:
| קוד סטטוס תרמי | תיאור והצעות לשימוש |
|---|---|
THERMAL_STATUS_NONE (0x00000000) |
ללא ויסות נתונים (throttle). אפשר להשתמש בסטטוס הזה כדי להטמיע פעולות הגנה, כמו זיהוי תחילת התקופה (t0 עד t1) מ-THERMAL_STATUS_NONE (0) עד THERMAL_STATUS_LIGHT (1). |
THERMAL_STATUS_LIGHT (0x00000001) |
הגבלת קצב העברת נתונים קלה, חוויית המשתמש לא מושפעת. בשלב הזה צריך להשתמש בהפחתה עדינה של המכשיר. לדוגמה, לדלג על הגברת הביצועים או על שימוש בתדרים לא יעילים, אבל רק בליבות גדולות. |
THERMAL_STATUS_MODERATE (0x00000002) |
צמצום מתון של הקצב, חוויית המשתמש לא מושפעת באופן משמעותי. ההקלות התרמית משפיעה על הפעילויות בחזית, ולכן צריך להפחית את צריכת החשמל באפליקציות באופן מיידי. |
THERMAL_STATUS_SEVERE (0x00000003) |
צמצום משמעותי של הקצב. חוויית המשתמש מושפעת במידה רבה. בשלב הזה, הפחתת הטמפרטורה התרמית במכשיר אמורה להגביל את קיבולת המערכת. המצב הזה עלול לגרום לתופעות לוואי, כמו למשל רעידות במסך ורעידות אודיו. |
THERMAL_STATUS_CRITICAL (0x00000004) |
הפלטפורמה עשתה כל מה שאפשר כדי לצמצם את צריכת החשמל. תוכנת הפחתת החום במכשיר הגדירה את כל הרכיבים לפעול במלוא הקיבולת שלהם. |
THERMAL_STATUS_EMERGENCY (0x00000005) |
רכיבים מרכזיים בפלטפורמה מושבתים בגלל תנאים תרמיים, והפונקציונליות של המכשיר מוגבלת. קוד הסטטוס הזה מייצג את האזהרה האחרונה לפני כיבוי המכשיר. במצב כזה, פונקציות מסוימות, כמו המודם והנתונים הסלולריים, מושבתות לחלוטין. |
THERMAL_STATUS_SHUTDOWN (0x00000006) |
צריך לכבות את המכשיר באופן מיידי. בגלל חומרת השלב הזה, יכול להיות שאפליקציות לא יוכלו לקבל את ההתראה הזו. |
יצרני המכשירים חייבים לעבור את בדיקת VTS ל-HAL תרמי, והם יכולים להשתמש ב-emul_temp מהממשק kernel sysfs כדי לדמות שינויים בטמפרטורה.