RIL Refactoring

אנדרואיד 7.0 שינתה את שכבת ממשק הרדיו (RIL) באמצעות סט של תכונות לשיפור הפונקציונליות של RIL. נדרשים שינויים בקוד השותף כדי ליישם את התכונות הללו, שהן אופציונליות אך מעודדות. שינויי Refactoring הם תואמים לאחור, כך שיישומים קודמים של התכונות Refactored ממשיכות לעבוד.

Refactoring RIL כולל את השיפורים הבאים:

  • קודי שגיאה של RIL. מאפשר קודי שגיאה ספציפיים בנוסף לקוד GENERIC_FAILURE הקיים. זה מסייע בפתרון תקלות על ידי מתן מידע ספציפי יותר על הגורם לשגיאות.
  • ניהול גרסאות RIL. מספק מידע גרסה מדויק יותר וקל יותר לתצורה.
  • תקשורת RIL באמצעות wakelocks. משפר את ביצועי הסוללה של המכשיר.

אתה יכול ליישם כל אחד או את כל השיפורים לעיל. לפרטים נוספים, עיין בהערות קוד על גירסאות RIL ב- https://android.googlesource.com/platform/hardware/ril/+/main/include/telephony/ril.h .

הטמעת קודי שגיאה משופרים של RIL

כמעט כל קריאות בקשת RIL יכולות להחזיר את קוד השגיאה GENERIC_FAILURE בתגובה לשגיאה. זוהי בעיה עם כל התגובות המבוקשות המוחזרות על ידי יצרני ה-OEM, מה שעלול להקשות על ניפוי באגים מדוח הבאגים אם אותו קוד שגיאה GENERIC_FAILURE מוחזר על ידי קריאות RIL מסיבות שונות. יכול לקחת זמן רב עד שהספקים אפילו לזהות איזה חלק מהקוד היה יכול להחזיר קוד GENERIC_FAILURE .

ב-Android 7.x ומעלה, יצרני OEM יכולים להחזיר ערך קוד שגיאה ברור המשויך לכל שגיאה אחרת שמסווגת כעת כ- GENERIC_FAILURE . יצרני OEM שאינם רוצים לחשוף בפומבי את קודי השגיאה המותאמים אישית שלהם יכולים להחזיר שגיאות כקבוצה נפרדת של מספרים שלמים (כגון 1 עד x) הממופות כ- OEM_ERROR_1 ל- OEM_ERROR_X . על הספקים לוודא שכל קוד שגיאה מוסווה כזה החזיר מפות לסיבה ייחודית של שגיאה בקוד. שימוש בקודי שגיאה ספציפיים יכול להאיץ את ניפוי הבאגים של RIL בכל פעם שגיאות כלליות מוחזרות על ידי ה-OEM, מכיוון שלעתים קרובות יכול לקחת יותר מדי זמן לזהות את הסיבה המדויקת לקוד שגיאה GENERIC_FAILURE (ולפעמים אי אפשר להבין).

בנוסף, ril.h מוסיף קודי שגיאה נוספים עבור ה-enums RIL_LastCallFailCause ו- RIL_DataCallFailCause כך שקוד הספק יכול להימנע מהחזרת שגיאות כלליות כגון CALL_FAIL_ERROR_UNSPECIFIED ו- PDP_FAIL_ERROR_UNSPECIFIED .

אימות קודי שגיאה משופרים של RIL

לאחר הוספת קודי שגיאה חדשים להחלפת קוד GENERIC_FAILURE , ודא שקודי השגיאה החדשים מוחזרים על ידי קריאת RIL במקום GENERIC_FAILURE .

הטמעת גירסאות RIL משופרות

גירסת RIL במהדורות אנדרואיד ישנות יותר הייתה בעייתית: הגרסה עצמה לא הייתה מדוייקת, מנגנון הדיווח על גרסת RIL לא היה ברור (מה שגרם לחלק מהספקים לדווח על גרסה שגויה), והפתרון לעקיפת הגרסה להערכת הגרסה הייתה מועדת לאי דיוק.

באנדרואיד 7.x ומעלה, ril.h מתעד את כל ערכי גרסת ה-RIL, מתאר את גרסת ה-RIL המתאימה ומפרט את כל השינויים עבור אותה גרסה. בעת ביצוע שינויים התואמים לגרסת RIL, על הספקים לעדכן את הגרסה שלהם בקוד ולהחזיר גרסה זו ב- RIL_REGISTER .

אימות גירסאות RIL משופרות

ודא שגרסת RIL התואמת לקוד RIL שלך מוחזרת במהלך RIL_REGISTER (ולא ה- RIL_VERSION שהוגדר ב- ril.h ).

הטמעת תקשורת RIL באמצעות wakelocks

בתקשורת RIL נעשה שימוש ב-Wakelocks מתוזמן בצורה לא מדויקת, המשפיעה לרעה על ביצועי הסוללה. ב-Android 7.x ומעלה, אתה יכול לשפר את הביצועים על ידי סיווג בקשות RIL ועדכון קוד לטיפול ב-Wakelocks באופן שונה עבור סוגי בקשות שונים.

סיווג בקשות RIL

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

  • סינכרוני . בקשות שלא לוקח זמן רב להגיב בחזרה. לדוגמה, RIL_REQUEST_GET_SIM_STATUS .
  • אסינכרוני . בקשות שלוקח זמן רב להגיב בחזרה. לדוגמה, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS .

בקשות RIL מבוקשות אסינכרוניות יכולות לקחת זמן רב. לאחר קבלת ack מקוד הספק, RIL Java משחררת את wakelock, מה שעלול לגרום למעבד היישום לעבור ממצב המתנה למצב השעיה. כאשר התגובה זמינה מקוד הספק, RIL Java (מעבד היישומים) רוכש מחדש את ה-Wakelock, מעבד את התגובה ואז חוזר למצב סרק. מעבר כזה ממצב סרק להשהיה לסרק יכול לצרוך הרבה חשמל.

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

תרחישי תקשורת RIL

התרשימים הבאים ממחישים תרחישי תקשורת נפוצים של RIL ומספקים פתרונות לשינוי קוד לטיפול בבקשות RIL מבוקשות ובלתי רצויות.

הערה: לפרטי הטמעה על פונקציות המשמשות בתרשימים הבאים, עיין בשיטות acquireWakeLock() , decrementWakeLock() ו- clearWakeLock( ) ב- ril.cpp .

תרחיש: בקשת RIL ותגובה אסינכרונית מבוקשת

בתרחיש זה, אם התגובה המבוקשת של RIL צפויה להימשך זמן רב (כלומר תגובה ל- RIL_REQUEST_GET_AVAILABLE_NETWORKS ), ה-Wakelock מוחזק במשך זמן רב בצד מעבד היישומים. בעיות במודם עלולות לגרום גם להמתנה ארוכה.

איור 1. RIL ביקש תגובה אסינכרונית.

פתרון 1: המודם מחזיק את ה-Wakelock עבור בקשת RIL והתגובה האסינכרונית.

איור 2. Wakelock מוחזק על ידי מודם.
  1. בקשת RIL נשלחת והמודם רוכש wakelock כדי לעבד בקשה זו.
  2. מודם שולח אישור שגורם לצד Java להפחית את מונה ה-Wakelock ולשחרר אותו כאשר ערך המונה הוא 0.

    הערה: משך הזמן הקצוב של wakelock עבור רצף הבקשה-ack יהיה קטן יותר ממשך הזמן הקצוב של זמן הקצוב הנוכחי מכיוון שה-ack אמור להתקבל די מהר.

  3. לאחר עיבוד הבקשה, המודם שולח פסיקה לקוד הספק שרוכש wakelock ושולח תגובה אל ril.cpp, אשר בתורו רוכש wakelock ושולח תגובה לצד Java.
  4. כאשר התגובה מגיעה לצד Java, wakelock נרכש ותגובה מוחזרת למתקשר.
  5. לאחר עיבוד התגובה על ידי כל המודולים, האישור נשלח (באמצעות socket) בחזרה אל ril.cpp , ולאחר מכן משחרר את ה-wakelock שנרכש בשלב 3.

פתרון 2: המודם לא מחזיק את ה-Wakelock והתגובה מהירה (בקשה ותגובה של RIL סינכרוניים). ההתנהגות הסינכרונית לעומת האסינכרונית מקודד קשה עבור פקודת RIL ספציפית ומוכרע על בסיס שיחה אחר שיחה.

איור 3. Wakelock לא מוחזק על ידי מודם.
  1. בקשת RIL נשלחת על ידי קריאה ל- acquireWakeLock() בצד Java.
  2. קוד הספק אינו צריך לרכוש wakelock והוא יכול לעבד את הבקשה ולהגיב במהירות.
  3. כאשר התגובה מתקבלת על ידי הצד של Java, נקרא decrementWakeLock() , אשר מקטין את מונה ה-wakelock ומשחרר את ה-Wakelock אם ערך המונה הוא 0.

תרחיש: תגובה לא רצויה של RIL

בתרחיש זה, לתגובות בלתי רצויות של RIL יש דגל מסוג wakelock ב- המציין אם יש צורך לרכוש wakelock עבור תגובת הספק. אם הדגל מוגדר, מוגדר wakelock מתוזמן והתגובה נשלחת דרך שקע לצד Java. כאשר הטיימר יפוג, ה-Wikelock משתחרר. ה-Wakelock המתוזמן עשוי להיות ארוך מדי או קצר מדי עבור תגובות בלתי רצויות של RIL שונות.

איור 4. תגובה לא רצויה של RIL.

פתרון: אישור נשלח מקוד ה-Java לצד המקורי ( ril.cpp ) במקום להחזיק wakelock מתוזמן בצד המקורי תוך שליחת תגובה לא רצויה.

איור 5. שימוש ב-ack במקום wakelock מתוזמן.

אימות ווייקלוקים שעוצבו מחדש

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