ניהול צריכת החשמל

כדי לתמוך בניהול צריכת חשמל ספציפי לרכב, מערכת Android מספקת CarPowerManagementServiceשירות וCarPowerManagerממשק.

מעברי מצב מופעלים על ידי יחידת הבקרה הראשית של הרכב (VMCU). כדי לתקשר עם VMCU, משלבי מערכות צריכים להטמיע כמה רכיבים. הגורמים שמבצעים את השילוב אחראים לשילוב עם שכבת ההפשטה של החומרה ברכב (VHAL) ועם הטמעת הליבה. האחריות של המפתחים היא גם להשבית את מקורות ההפעלה ולוודא שהכיבוי לא נדחה ללא הגבלת זמן.

הסברים על המונחים

במסמך הזה אנחנו משתמשים במונחים הבאים:

מעבד אפליקציות (AP)
חלק ממערכת על שבב (SoC).
חבילת תמיכה של הלוח (BSP)
שכבת התוכנה שמכילה קושחת אתחול ספציפית לחומרה ומנהלי התקנים שמאפשרים למערכת הפעלה מוטמעת לפעול בסביבת חומרה נתונה (לוח אם), שמשולבת במערכת ההפעלה המוטמעת.
CarPowerManager (CPM)
חשיפת API לאפליקציות כדי להירשם לשינויים במצב צריכת החשמל.
CarPowerManagementService (CPMS)
מתאם בין מעברי מצב ההפעלה, יוצר ממשק עם VHAL לשליטה במצב ההפעלה ומבצע את הקריאות הסופיות להשהיה ולכיבוי.
CarPowerPolicyDaemon ‏ (CPPD)
‫
Manages power policies and exposes AIDL interfaces for native processes to register power policy listeners.
קלט או פלט למטרה כללית (GPIO)
פין של אות דיגיטלי לשימוש כללי.
שיטת הפשטת חומרה (HAL)
שכבת תוכנה שכל המודולים ברמה גבוהה יותר חייבים ליצור איתה אינטראקציה כדי לגשת לפונקציונליות של החומרה.
מצב תנומה
נקרא גם השהיה לדיסק (S2D/S4). המערכת על שבב (SoC) עוברת למצב צריכת חשמל S4 (מצב שינה), ותוכן ה-RAM נכתב למדיה בלתי נדיפה (כמו זיכרון פלאש או דיסק), והמערכת כולה מושבתת.
מעבד מדיה (MP)
ראו מערכת על שבב (SoC).
מעגל משולב לניהול צריכת חשמל (PMIC)
שבב שמשמש לניהול דרישות ההספק של מערכת המארח.
מערכת על שבב (SoC)
מעבד ראשי שמריץ את AAOS, בדרך כלל מסופק על ידי יצרנים כמו Intel,‏ MediaTek,‏ Nvidia,‏ Qualcomm,‏ Renesas ו-Texas Instruments.
השעה
נקרא גם השהיה ל-RAM (S2R או STR). ה-SoC מועבר למצב צריכת חשמל S3 והמעבד מושבת, אבל ה-RAM ממשיך לפעול.
שכבת הפשטת חומרה לרכב (VHAL)
‫Android API שמשמש ליצירת ממשק עם רשת הרכב. שותף Tier 1 או יצרן ציוד מקורי (OEM) אחראי לכתיבת המודול הזה. הרשת של הרכב יכולה להשתמש בכל שכבה פיזית (כמו CAN,‏ LIN,‏ MOST ואתרנט). ה-VHAL מבצע הפשטה של רשת הרכב כדי לאפשר ל-AAOS ליצור אינטראקציה עם הרכב.
מעבד ממשק לרכב (VIP)
מידע על יחידת בקרת הרכב (MCU)
יחידת בקרה ראשית לרכב (VMCU)
המיקרו-בקר שמספק את הממשק בין רשת הרכב לבין ה-SoC. ה-SoC מתקשר עם ה-VMCU באמצעות אותות USB,‏ UART,‏ SPI ו-GPIO.

עיצוב המערכת

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

מכונת מצב הטעינה של הרכב

מערכת AAOS משתמשת במכונת מצבים כדי לייצג את מצב ההפעלה של ה-AP. מכונת המצבים מספקת את המצבים שמפורטים בהמשך:

מכונת מצב הטעינה של הרכב

איור 1. מכונת מצבים של מצב הטעינה של הרכב.

המעברים הנפוצים ביותר מודגשים בכחול. אלה המצבים והמעברים הנפוצים:

  • השהיה ל-RAM. הרכב ומערכת ה-SoC מושבתים. לא מופעל קוד. המתח נשמר בזיכרון ה-RAM של ה-SoC.
  • מחכים ל-VHAL. כשהנהג מבצע אינטראקציה עם הרכב, למשל פותח דלת, ה-VMCU מעביר חשמל ל-SoC. מערכת AAOS ממשיכה מ-Suspend-to-RAM ונכנסת למצב Wait for VHAL, שבו היא ממתינה לתיאום עם VHAL.
  • מופעלת ממשק VHAL אומר ל-AAOS לעבור למצב 'מופעל'. במצב הזה, מערכת AAOS פועלת באופן מלא ומתקשרת עם הנהג.
  • הכנות לפני הפסקת התמיכה כשהנהג מסיים לנהוג, ה-VHAL שולח את הערך SHUTDOWN_PREPARE ל-AAOS כדי להעביר אותו לשלב ההכנה לפני כיבוי. במצב הזה, מאזינים לשינויים במצב ההפעלה מקבלים STATE_PRE_SHUTDOWN_PREPARE. ההודעה הזו היא אזהרה מוקדמת על כך שהתהליך של סגירת החשבון מתחיל.
  • הכנה להפסקת התמיכה. כשכל מאזיני האירועים מסיימים או כשמגיעים לזמן הקצוב לתפוגה של Pre Shutdown Prepare, מערכת Android נכנסת לשלב הליבה של Shutdown Prepare, ומודיעה למאזיני האירועים באמצעות STATE_SHUTDOWN_PREPARE. התצוגה והאודיו מושבתים ומערכת AAOS לא מבצעת אינטראקציה עם הנהג. מערכת Android עדיין פועלת ויכולה לבצע פעולות ניקוי ועדכון, כמו הפעלת מצב מוסך.
  • מחכים לסיום של VHAL. בשלב הזה, מערכת AAOS מודיעה ל-VHAL שהיא מוכנה לכיבוי. ה-VMCU אמור להעביר את ה-SoC למצב שינה עמוקה ולהפסיק את אספקת החשמל למעבד האפליקציות. מערכת AAOS נמצאת במצב Suspend-to-RAM, למרות שלא מבוצע קוד.

מודולים לניהול צריכת החשמל

מערכת ניהול צריכת החשמל מורכבת מהמודולים הבאים:

שם המודול תיאור
CarPowerManager ‫Java או C++ API.
CarPowerManagementService מתאם בין מעברים של מצבי טעינה ומקצה את ניהול מדיניות הטעינה ל-CarPowerPolicyDaemon.
CarPowerPolicyDaemon מנהל את מדיניות צריכת החשמל ומתקשר עם לקוחות של מדיניות צריכת חשמל מקומית.
שכבת הפשטת חומרה לרכב ממשק ל-VMCU.
ליבה השעיה להטמעה של RAM או דיסק.

התכונה של שינה עמוקה או תרדמה (השעיה של Android ל-RAM או לדיסק) מוטמעת בקרנל. התכונה הזו מוצגת למרחב המשתמש כקובץ מיוחד שנמצא בכתובת /sys/power/state. כדי להשעות את AAOS, כותבים mem או disk בקובץ הזה.

ה-CPMS מתאם את מצב ההפעלה עם שירותים אחרים ועם HAL. ה-CPMS מטמיע את מכונת המצבים שמתוארת למעלה ושולח התראות לכל משתמש שצופה בו כשמתרחש מעבר בין מצבי ההפעלה. השירות הזה משתמש גם ב-VHAL כדי לשלוח הודעות לחומרה.

ה-CPPD הוא מקור המידע האמין לגבי מדיניות צריכת חשמל. הוא מנהל את מדיניות צריכת החשמל לאורך מחזור החיים של המכשיר, ומודיע ל-CPMS, ל-VHAL ולמאזינים מקומיים אחרים על שינויים במדיניות צריכת החשמל. ה-CPMS מעביר בקשות לשינוי מדיניות בנושא צריכת חשמל ל-CPPD.

מערכת CPMS מתקשרת עם VMCU באמצעות קריאה וכתיבה של מאפייני VHAL שקשורים למצב ההפעלה, כמו AP_POWER_STATE_REQ ו-AP_POWER_STATE_REPORT. אפליקציות יכולות להשתמש בממשק שמוגדר ב-CPM כדי לעקוב אחרי שינויים במצב ההפעלה. בנוסף, הממשק הזה מאפשר לאפליקציות לרשום מאזינים למדיניות צריכת החשמל. ה-API הזה של Java מסומן בהערות @SystemApi ו-@hide, ולכן הוא זמין רק לאפליקציות עם הרשאות. האיור הבא ממחיש את הקשר בין המודולים, האפליקציות והשירותים האלה:

תרשים עזר של רכיבי חשמל

איור 2. תרשים הפניה לרכיבי חשמל.

רצף הודעות

בקטע הקודם תיארנו את המודולים שמרכיבים את מערכת ניהול צריכת החשמל. בקטע הזה נשתמש בדוגמאות enter deep sleep ו-exit deep sleep כדי להסביר איך המודולים והאפליקציות מתקשרים:

כניסה לשינה עמוקה

רק ה-VMCU יכול להתחיל שינה עמוקה. אחרי שמפעילים את מצב השינה העמוקה, ה-VMCU שולח הודעה ל-CPMS דרך ה-VHAL. ה-CPMS משנה את המצב ל-SHUTDOWN PREPARE ומשדר את מעבר המצב הזה לכל האובייקטים שצופים בו (האפליקציות והשירותים שמנטרים את ה-CPMS) על ידי קריאה לשיטה onStateChanged() עם מזהה מצב חדש שסופק על ידי ה-CPM.

ה-CPM מתווך בין האפליקציות או השירותים לבין ה-CPMS. ה-method‏ onStateChanged() של האפליקציות או השירותים מופעל באופן סינכרוני ב-method‏ onStateChanged() של CPM. רוב האפליקציות והשירותים צריכים להשלים את ההכנה שלהם לפני שהם חוזרים מהשיחה הזו. לשירותים עם הרשאות מיוחדות מותר להמשיך בהכנות שלהם באופן אסינכרוני אחרי החזרה ל-PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER, POST_SUSPEND_ENTER. במקרה הזה, השירות עם ההרשאות אמור לקרוא ל-complete() באובייקט CompletablePowerStateChangeFuture שסופק כשההכנה שלו מסתיימת. שימו לב: אסור להשתמש בהכנה אסינכרונית עבור SHUTDOWN_PREPARE. לפני ש-DEEP_SLEEP_ENTRY נשלח אל VHAL, ‏ CPMS שולח מעת לעת בקשות לדחיית כיבוי אל VHAL.

כשכל אובייקטי ה-CPM מסיימים את ההכנות לכיבוי, ה-CPMS שולח AP_POWER_STATE_REPORT ל-VHAL, ואז ה-VHAL מודיע ל-VMCU שה-AP מוכן להשהיה. בנוסף, ה-CPMS קורא לשיטת ההשעיה שלו, שמשעה את הליבה.

האיור הבא מדגים את הרצף שמתואר למעלה:

כניסה לשינה עמוקה

איור 3. כניסה לשינה עמוקה.

ממשקי תכנות שסופקו על ידי CPM

בקטע הזה מתואר Java API ש-CPM מספק לאפליקציות ולשירותי מערכת. ממשק ה-API הזה מאפשר לתוכנת המערכת:

  • מעקב אחרי שינויים במצב ההפעלה בנקודת הגישה.
  • החלת מדיניות צריכת חשמל.

כדי להפעיל את ממשקי ה-API שסופקו על ידי CPM:

  1. כדי לקבל את מופע ה-CPM, צריך להפעיל את Car API.
  2. מבצעים קריאה למתודה המתאימה באובייקט שנוצר בשלב 1.

יצירת אובייקט CarPowerManager

כדי ליצור אובייקט CPM, צריך לבצע קריאה ל-method‏ getCarManager() של אובייקט Car. השיטה הזו היא חזית שמשמשת ליצירת אובייקטים של CPM. מציינים את android.car.Car.POWER_SERVICE כארגומנט כדי ליצור אובייקט של עלות לאלף חשיפות.

Car car = Car.createCar(this);
CarPowerManager powerManager =
  (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);

‫CarPowerStateListener וההרשמה

אפליקציות ושירותים של המערכת יכולים לקבל התראות על שינויים במצב ההפעלה באמצעות הטמעה של CarPowerManager.CarPowerStateListener. הממשק הזה מגדיר שיטה אחת, onStateChanged(), שהיא פונקציית קריאה חוזרת שמופעלת כשמצב ההפעלה של CPMS משתנה. בדוגמה הבאה מוגדרת מחלקה אנונימית חדשה שמטמיעה את הממשק:

private final CarPowerManager.CarPowerStateListener powerListener =
  new CarPowerManager.CarPowerStateListener () {
    @Override
     public void onStateChanged(int state) {
       Log.i(TAG, "onStateChanged() state = " + state);
     }
};

כדי להנחות את אובייקט המאזין הזה לעקוב אחרי מעבר בין מצבי הפעלה, יוצרים שרשור ביצוע חדש ורושמים את המאזין ואת השרשור הזה באובייקט CPM: 

executor = new ThreadPerTaskExecutor();
powerManager.setListener(powerListener, executor);

כשמצב ההפעלה משתנה, השיטה onStateChanged() של אובייקט ה-listener מופעלת עם ערך שמייצג את מצב ההפעלה החדש. הקשר בין הערך בפועל לבין מצב ההפעלה מוגדר ב-CarPowerManager ומוצג בטבלה הבאה:

שם תיאור
STATE_ON מזינים את מצב ההפעלה. המערכת פועלת באופן מלא.
STATE_SHUTDOWN_CANCELLED הכיבוי מבוטל ומצב ההפעלה חוזר למצב הרגיל.
STATE_SHUTDOWN_ENTER האפליקציות צריכות להתנקות ולהיות מוכנות לכיבוי.
STATE_POST_SHUTDOWN_ENTER ההכנות לכיבוי הסתיימו ו-VMCU מוכן לכיבוי. מזינים את מצב הכיבוי.
STATE_PRE_SHUTDOWN_PREPARE תהליך הסגירה נדרש, אבל מערכת CPMS עדיין לא התחילה את התהליך. התצוגה והאודיו עדיין פועלים
STATE_SHUTDOWN_PREPARE יכול להיות שמצב חנייה יפעל במהלך התקופה הזו.
STATE_SUSPEND_ENTER האפליקציות צפויות לבצע ניקוי ולהיות מוכנות להשהיה ל-RAM.
STATE_POST_SUSPEND_ENTER ההכנות להשהיה ל-RAM הושלמו ו-VMCU מוכן להשהיה ל-RAM. כניסה למצב השהיה.
STATE_SUSPEND_EXIT יציאה ממצב שינה או חזרה ממצב שינה שבוטל.
STATE_HIBERNATION_ENTER האפליקציות צריכות לנקות את עצמן ולהיות מוכנות למצב תנומה.
STATE_POST_HIBERNATION_ENTER ההכנות למצב שינה הושלמו, וה-VMCU מוכן למצב שינה. צריך להזין את מצב השינה.
STATE_HIBERNATION_EXIT יציאה ממצב שינה או המשך פעולה ממצב שינה שבוטל.
STATE_WAIT_FOR_VHAL המערכת מתחילה לפעול, אבל מחכה ליצור תקשורת עם VHAL לפני שהיא עוברת למצב ON.

ביטול הרישום של CarPowerStateListener

כדי לבטל את הרישום של כל אובייקטי המאזינים שנרשמו ל-CPM, צריך לבצע קריאה ל-method‏ clearListener:

powerManager.clearListener();

שילוב מערכות בהטמעה שלכם ב-Android

האינטגרטורים אחראים לדברים הבאים:

  • הטמעה של ממשק הליבה להשעיית Android.
  • הטמעת הפונקציות של VHAL כדי:
    • העברת ההפעלה של השהיה או כיבוי מהרכב אל Android.
    • שליחת ההודעה 'מוכן לכיבוי' מ-Android לרכב.
    • התחלת כיבוי או השעיה של Android דרך ממשק ליבת Linux.
  • מוודאים שכל מקורות ההתעוררות מושבתים כשהמכשיר במצב השהיה.
  • חשוב לוודא שהאפליקציות נסגרות מספיק מהר כדי לא לדחות את תהליך ההשבתה ללא הגבלת זמן.
  • מוודאים שחבילת ה-BSP מפעילה (או משביתה) את רכיבי המכשיר בהתאם למדיניות ניהול צריכת החשמל, כדי לא לחסום את ההשעיה או את מצב השינה.

ממשק ליבה: ‎/sys/power/state

מערכת AAOS מעבירה מכשיר למצב השהיה כששירות או אפליקציה כותבים mem בשביל השהיה ל-RAM או disk בשביל השהיה לדיסק בקובץ שנמצא ב-/sys/power/state. האינטגרטור צריך לספק פונקציה שעוקבת אחרי הקובץ הזה ומעבירה את Linux למצב השהיה. הפונקציה הזו עשויה לשלוח GPIO ל-VMCU כדי להודיע ל-VMCU שהמכשיר נסגר לחלוטין. האחריות של האינטגרטור היא גם להסיר את כל תנאי המירוץ בין VHAL לשליחת ההודעה הסופית ל-VMCU לבין המערכת שעוברת למצב השהיה או כיבוי.

האחריות של VHAL

ה-VHAL מספק ממשק בין רשת הרכב לבין Android. ‫VHAL:

  • העברת ההפעלה של השהיה או כיבוי מהמכונית אל Android.
  • ההודעה 'מוכן לכיבוי' נשלחת מ-Android לרכב.
  • הפקודה מתחילה את הכיבוי או ההשעיה של Android דרך ממשק ליבת ה-Linux.

כשמערכת ה-CPMS מודיעה ל-VHAL שהיא מוכנה לכיבוי, מערכת ה-VHAL שולחת את ההודעה shutdown ready (הכיבוי מוכן) ל-VMCU. בדרך כלל, ציוד היקפי על שבב כמו UART,‏ SPI ו-USB מעביר את ההודעה. אחרי שההודעה נשלחת, מערכת CPMS קוראת לפקודת הליבה כדי להשהות או להשבית את המכשיר. לפני כן, יכול להיות ש-VHAL או BSP יעבירו אות GPIO כדי להודיע ל-VMCU שאפשר להפסיק את אספקת החשמל למכשיר.

ממשק VHAL צריך לתמוך במאפיינים הבאים, ששולטים בניהול צריכת החשמל דרך VHAL:

שם תיאור
AP_POWER_STATE_REPORT מערכת Android מדווחת על מעברים בין מצבים ל-VMCU באמצעות המאפיין הזה, תוך שימוש בערכי enum של VehicleApPowerStateReport.
AP_POWER_STATE_REQ ה-VMCU משתמש במאפיין הזה כדי להנחות את Android לעבור למצבי הפעלה שונים, באמצעות ערכי enum של VehicleApPowerStateReq.

AP_POWER_STATE_REPORT

המאפיין הזה משמש לדיווח על מצב ניהול החשמל הנוכחי של Android. המאפיין הזה מכיל שני מספרים שלמים:

  • ‫int32Values[0]: ספירה (enum) של VehicleApPowerStateReport שמייצגת את המצב הנוכחי.
  • ‫int32Values[1]: משך הזמן באלפיות השנייה לדחייה, להשהיה או לכיבוי. המשמעות של הערך הזה תלויה בערך הראשון.

הערך הראשון יכול להיות אחד מהערכים הבאים. VehicleApPowerStateReport.aidl כולל תיאורים ספציפיים יותר, שמאוחסנים ב-hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle.

שם הערך תיאור הערך השני
WAIT_FOR_VHAL ה-AP מתחיל לפעול וצריך ליצור תקשורת עם ה-VHAL.
DEEP_SLEEP_ENTRY נקודת הגישה עוברת למצב שינה עמוקה. ה-VMCU צריך להפעיל מחדש את ה-AP אחרי הזמן שצוין בערך השני. חובה להגדיר
DEEP_SLEEP_EXIT ה-AP יוצא ממצב שינה עמוקה.
HIBERNATION_ENTRY נקודת הגישה עוברת למצב שינה. ה-VMCU צריך להפעיל מחדש את ה-AP אחרי הזמן שצוין בערך השני. חובה להגדיר
HIBERNATION_EXIT נקודת הגישה יוצאת ממצב שינה.
SHUTDOWN_POSTPONE מערכת Android לא מוכנה לכיבוי. ה-VMCU צריך להמתין את הזמן שצוין בערך השני לפני כיבוי ה-AP. יכול להיות שמערכת Android תבקש דחייה נוספת על ידי שליחת דוחות נוספים של SHUTDOWN_POSTPONE. חובה להגדיר
SHUTDOWN_PREPARE מערכת Android מתכוננת לכיבוי. חובה להגדיר
SHUTDOWN_START נקודת הגישה מוכנה לכיבוי. ה-VMCU צריך להפעיל מחדש את ה-AP אחרי הזמן שצוין בערך השני. (לא נדרשת תמיכה ב-VMCU כדי להשתמש בתכונה של הפעלה מתוזמנת). חובה להגדיר
SHUTDOWN_CANCELLED מערכת Android מפסיקה להתכונן לכיבוי ותמשיך למצב WAIT_FOR_VHAL.
מופעל מערכת Android פועלת כרגיל.

המצב יכול להיות מוגדר באופן אוטונומי או בתגובה לבקשה דרך VMCU.

AP_POWER_STATE_REQ

הנכס הזה נשלח על ידי VMCU כדי להעביר את Android למצב צריכת חשמל שונה, והוא מכיל שני מספרים שלמים:

  • ‫int32Values[0]: VehicleApPowerStateReq ערך enum שמייצג את המצב החדש שאליו רוצים לעבור.
  • ‫int32Values[1]: VehicleApPowerStateShutdownParam ערך enum. הערך הזה נשלח רק להודעת SHUTDOWN_PREPARE ומועבר ל-Android עם האפשרויות שהוא מכיל.

הערך השלם הראשון מייצג את המצב החדש שאליו מערכת Android אמורה לעבור. הסמנטיקה מוגדרת ב-VehicleApPowerStateReq.aidl ומפורטת בהמשך:

שם הערך תיאור
מופעל נקודת הגישה צריכה להתחיל לפעול באופן מלא.
SHUTDOWN_PREPARE נקודת הגישה צריכה להתכונן לכיבוי. הערך השני מציין אם לנקודת הגישה מותר לדחות את הכיבוי, ואם נקודת הגישה צריכה לצפות לכיבוי או להיכנס למצב שינה עמוקה.
CANCEL_SHUTDOWN נקודת הגישה אמורה להפסיק את ההכנה לכיבוי ולהתכונן להפעלה.
סיום נקודת הגישה תיסגר או תושהה.

‫VehicleApPowerStateShutdownParam מוגדר ב-VehicleApPowerStateShutdownParam.aidl. ה-enum הזה כולל את הרכיבים הבאים:

שם הערך תיאור
CAN_SLEEP ה-AP יכול להיכנס למצב שינה עמוקה במקום להיסגר לגמרי. מותר לדחות את התשלום.
CAN_HIBERNATE נקודת הגישה יכולה להיכנס למצב שינה במקום להיסגר לגמרי. מותר לדחות את התשלום.
SHUTDOWN_ONLY נקודת הגישה אמורה להיכבות. מותר לדחות את התשלום. אסור להשתמש בשינה עמוקה.
SLEEP_IMMEDIATELY יכול להיות שנקודת הגישה תעבור למצב שינה עמוקה, אבל היא חייבת לעבור למצב שינה או להיסגר באופן מיידי. אסור לדחות את התשלום.
HIBERNATE_IMMEDIATELY יכול להיות שנקודת הגישה תעבור למצב השהיה לדיסק, אבל היא חייבת להיכנס למצב שינה או להיכבות באופן מיידי. אסור לדחות את התשלום.
SHUTDOWN_IMMEDIATELY צריך לכבות את ה-AP באופן מיידי. אי אפשר לדחות את התשלום. אסור להשתמש בשינה עמוקה.

מקורות יציאה ממצב שינה

האינטגרטור צריך להשבית את מקורות ההתעוררות המתאימים כשהמכשיר נמצא במצב השעיה. מקורות נפוצים להוצאה ממצב שינה כוללים פעימות לב, מודם, Wi-Fi ו-Bluetooth. מקור ההתעוררות התקין היחיד צריך להיות הפרעה מ-VMCU כדי להעיר את ה-SoC. ההנחה היא ש-VMCU יכול להאזין למודם לאירועי התעוררות מרחוק (כמו הפעלת מנוע מרחוק). אם הפונקציונליות הזו מועברת ל-AP, צריך להוסיף עוד מקור להפעלת המודם.

אפליקציות

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

נספח

ספריות בעץ של קוד המקור

תוכן הארגון שלי
קוד שקשור ל-CarPowerManager. packages/services/Car/car-lib/src/android/car/hardware/power
CarPowerManagementService וכן הלאה. packages/services/Car/service/src/com/android/car/power
שירותים שפועלים עם VHAL, כמו VehicleHal ו-HAlClient. packages/services/Car/service/src/com/android/car/hal
ממשק VHAL והגדרות מאפיינים. hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle/
אפליקציה לדוגמה שתיתן לכם מושג לגבי CarPowerManager packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink

תרשים מחלקות

בתרשים המחלקות הזה מוצגים הממשקים והמחלקות של Java במערכת לניהול צריכת החשמל:

דיאגרמת מחלקת הספק

איור 4. תרשים דיאגרמת סיווג עוצמה.

קשר בין אובייקטים

באיור 5 מוצגים אובייקטים שיש להם הפניות לאובייקטים אחרים. קצה פירושו שאובייקט המקור מכיל הפניה לאובייקט היעד. לדוגמה, ל-VehicleHAL יש הפניה לאובייקט PropertyHalService.

דיאגרמת הפניה לאובייקט

איור 5. דיאגרמת הפניה לאובייקט.