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

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

שכבת הפשטת חומרה (HAL) תרמית

ב-Android מגרסה 9 ומטה, נעשה שימוש בממשק polling שמוגדר ב-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 מספק את כל הפונקציונליות הנדרשת, כולל החזרת ערכי מצב הטמפרטורה. ממשק ה-IThermal binder עטוף כממשק OnThermalStatusChangedListener, שאפליקציות יכולות להשתמש בו כשרושמים או מסירים listeners של סטטוס תרמי.

לממשקי ה-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 כדי לדמות שינויים בטמפרטורה.