הפחתה תרמית

באמצעות מסגרת 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, למעבד וליציאת ה-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 ואילך) בממשק ה-callback של לקוחות HAL תרמיים, כמו שירות התרמי של המסגרת. לדוגמה, RegisterIThermalChangedCallback ו-UnregisterIThermalChangedCallback כדי לרשום או לבטל רישום אירועים שהרמה שלהם השתנתה. אם חומרת הבעיה התרמית של חיישן מסוים השתנתה, notifyThrottling שולח קריאה חוזרת (callback) של אירוע של הגבלת קצב העברת נתונים תרמי למאזינים של אירועים תרמיים.

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

מידע נוסף זמין במאמר הטמעת הפניה.

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

שירות תרמי

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

באמצעות ממשקי ה-callback, אפשר לאחזר את המצב התרמי הנוכחי של המכשיר כערך שלם בטווח שבין 0x00000000 (ללא הגבלת קצב) ל-0x00000006 (כיבוי המכשיר). רק לשירות מערכת מהימן, כמו Android API או 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) וגם שיטות סקירה (polling) כדי לאפשר לאפליקציות לקבל התראות על רמות החומרה של הטמפרטורה באמצעות קודי סטטוס שמוגדרים בכיתה PowerManager. השיטות הן:

• getCurrentThermalStatus() מחזירה את הסטטוס התרמי הנוכחי של המכשיר כמספר שלם, אלא אם המכשיר עובר צמצום עוצמה.
• addThermalStatusListener() הוספת מאזין.
• removeThermalStatusListener() מסירה מאזין שנוסף בעבר.

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

קודי הסטטוס התרמי מתרגמים לרמות ספציפיות של הגבלת קצב העברת הנתונים, שאפשר להשתמש בהן כדי לאסוף נתונים ולעצב חוויית משתמש אופטימלית. לדוגמה, אפליקציות עשויות לקבל סטטוס 0x00000000 (THERMAL_STATUS_NONE), שעשוי להשתנות מאוחר יותר ל-0x00000001 (THERMAL_STATUS_LIGHT). סימון המצב 0x00000000 בתור t0, ואז מדידת הזמן שחלף מהסטטוס THERMAL_STATUS_NONE לסטטוס THERMAL_STATUS_LIGHT בתור t1 מאפשרת ליצרני המכשירים לתכנן ולבדוק אסטרטגיות לצמצום סיכונים בתרחישי שימוש ספציפיים. בטבלה הבאה מפורטות הצעות לשימוש בקוד הסטטוס התרמי:

קוד סטטוס תרמי	תיאור והצעות לשימוש
‫THERMAL_STATUS_NONE ‏(0x00000000)	ללא ויסות נתונים. אפשר להשתמש בסטטוס הזה כדי להטמיע פעולות הגנה, כמו זיהוי תחילת פרק הזמן (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 כדי לדמות שינויים בטמפרטורה.