מיטיגציה תרמית

בעזרת מסגרת Android, יצרני מכשירים ומפתחי אפליקציות יכולים להשתמש בנתונים תרמיים כדי לוודא שחוויית המשתמש (UX) תהיה עקבית אם המכשיר יתחיל להתחמם יתר על המידה. לדוגמה, כשמערכת עוברת עומס תרמי,jobscheduler המשימות מוגבלות, ואם צריך, מתבצע כיבוי תרמי של המסגרת. אפליקציות שמקבלות התראות על עומס חום דרך קריאה חוזרת (callback) רשומה במחלקה PowerManager יכולות להתאים את חוויית המשתמש שלהן בצורה חלקה.

Thermal HAL

ב-Android מגרסה 9 ומטה נעשה שימוש בממשק סקר שמוגדר ב-Thermal HAL 1.0 כדי לקבל קריאות טמפרטורה. ה-HAL הזה אפשר למסגרת Android וללקוחות מהימנים אחרים, כמו 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.

בנוסף להיותו ממשק תשאול שמחזיר את הטמפרטורות הנוכחיות, אפשר להשתמש בפונקציית הקריאה החוזרת IThermalChangedCallback (HIDL, ‏ Android 10 עד 13) או IThermalChangedCallback (AIDL, ‏ Android 14 ואילך) עם ממשק הקריאה החוזרת מלקוחות של thermal HAL, כמו שירות ה-thermal של המסגרת. לדוגמה, RegisterIThermalChangedCallback ו-UnregisterIThermalChangedCallback כדי לרשום או לבטל את הרישום של אירועים שבהם השתנתה חומרת הבעיה. אם חומרת הבעיה התרמית בחיישן מסוים השתנתה, notifyThrottling שולח קריאה חוזרת (callback) של אירוע ויסות תרמי למאזיני אירועים תרמיים.

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

מידע נוסף זמין במאמר בנושא הטמעה לדוגמה.

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

שירות תרמי

ב-Android מגרסה 10 ואילך, שירות הטמפרטורה ב-framework מספק מעקב קבוע באמצעות אותות המיתון השונים מ-Thermal HAL 2.0, ומעביר ללקוחות משוב על חומרת ההגבלה. הלקוחות האלה כוללים רכיבים פנימיים ואפליקציות ל-Android. השירות משתמש בשני ממשקי קריאה חוזרת של Binder, IThermalEventListener ו-IThermalStatusListener, שמוצגים כקריאות חוזרות. הראשון מיועד לשימוש פנימי בפלטפורמות ובמכשירי יצרנים, והשני מיועד לאפליקציות ל-Android.

אפשר לאחזר את המצב התרמי הנוכחי של המכשיר כמספר שלם בטווח שבין 0x00000000 (ללא הגבלת מהירות) לבין 0x00000006 (כיבוי המכשיר) באמצעות ממשקי הקריאה החוזרת. רק שירות מערכת מהימן, כמו Android API או API של יצרן המכשיר, יכול לגשת למידע המפורט של חיישן הטמפרטורה ולאירועים שקשורים לטמפרטורה. באיור הבא מוצג מודל של תהליך ההפחתה של העומס התרמי ב-Android 10 ואילך:

תרשים זרימת תהליך של הפחתת עומס חום ב-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 מספק את כל הפונקציונליות הנדרשת, כולל החזרת ערכי מצב הטמפרטורה. ממשק הכריכה התרמית עטוף כממשק OnThermalStatusChangedListener, שאפליקציות יכולות להשתמש בו כשרושמים או מסירים ממשקי listener של סטטוס תרמי.

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

שימוש בקודי סטטוס תרמי

קודי הסטטוס של הטמפרטורה מתורגמים לרמות ספציפיות של הגבלת קצב הבקשות, שאפשר להשתמש בהן לאיסוף נתונים ולתכנון חוויית משתמש אופטימלית. לדוגמה, אפליקציות עשויות לקבל סטטוס של 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 כדי לדמות שינויים בטמפרטורה.