ב-Android 7.0 בוצע רפקטורינג של שכבת ממשק הרדיו (RIL) באמצעות קבוצה של תכונות לשיפור הפונקציונליות של RIL. כדי להטמיע את התכונות האלה, שמומלץ להשתמש בהן אבל הן לא חובה, צריך לבצע שינויים בקוד של השותף. שינויים בשיפור הקוד תואמים לדורות קודמים, כך שהטמעות קודמות של התכונות שעברו שיפור ממשיכות לפעול.
השיפורים הבאים כלולים בשינוי המבנה של RIL:
- קודי שגיאה של RIL מאפשר קודי שגיאה ספציפיים
בנוסף לקוד
GENERIC_FAILUREהקיים. המידע הזה עוזר לפתור בעיות כי הוא מספק פרטים ספציפיים יותר על הגורם לשגיאות. - ניהול גרסאות של RIL. מספק מידע מדויק יותר על הגרסה וקל יותר להגדרה.
- תקשורת RIL באמצעות נעילות השכמה. משפר את ביצועי הסוללה של המכשיר.
אתם יכולים להטמיע את כל השיפורים שצוינו למעלה או רק חלק מהם. פרטים נוספים זמינים בהערות על קוד בנושא ניהול גרסאות של RIL ב-https://android.googlesource.com/platform/hardware/ril/+/android17-release/include/telephony/ril.h.
הטמעה של קודי שגיאה משופרים של RIL
כמעט כל הקריאות לבקשות RIL יכולות להחזיר את קוד השגיאה GENERIC_FAILURE בתגובה לשגיאה. זו בעיה שקיימת בכל התגובות שמתקבלות מהיצרנים, ולכן קשה לנפות באגים בדוח אם קוד השגיאה GENERIC_FAILURE מוחזר על ידי קריאות RIL מסיבות שונות. יכול להיות שיעבור זמן רב עד שהספקים יזהו איזה חלק בקוד יכול היה להחזיר קוד GENERIC_FAILURE.
ב-Android מגרסה 7.x ואילך, יצרני ציוד מקורי (OEM) יכולים להחזיר ערך קוד שגיאה נפרד
שמשויך לכל שגיאה שונה שמסווגת כרגע כ-GENERIC_FAILURE. יצרני ציוד מקורי שלא רוצים לחשוף לציבור את קודי השגיאה המותאמים אישית שלהם יכולים להחזיר שגיאות כקבוצה נפרדת של מספרים שלמים (למשל 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 בגרסאות ישנות של Android: הגרסה עצמה לא הייתה מדויקת, המנגנון לדיווח על גרסת RIL לא היה ברור (מה שגרם לספקים מסוימים לדווח על גרסה שגויה), והפתרון העקיף להערכת הגרסה היה מועד לטעויות.
ב-Android 7.x ואילך, ril.h מתעד את כל ערכי גרסת ה-RIL, מתאר את גרסת ה-RIL התואמת ומפרט את כל השינויים בגרסה הזו. כשמבצעים שינויים שמתאימים לגרסת RIL, הספקים צריכים לעדכן את הגרסה שלהם בקוד ולהחזיר את הגרסה הזו ב-RIL_REGISTER.
אימות של גרסאות משופרות של RIL
מוודאים שגרסת ה-RIL שתואמת לקוד ה-RIL מוחזרת במהלך RIL_REGISTER (ולא RIL_VERSION שמוגדר ב-ril.h).
הטמעה של תקשורת RIL באמצעות wakelocks
נעשה שימוש ב-wakelocks מתוזמנים בתקשורת RIL בצורה לא מדויקת, מה שמשפיע לרעה על ביצועי הסוללה. ב-Android 7.x ומעלה, אפשר לשפר את הביצועים על ידי סיווג של בקשות RIL ועדכון הקוד כדי לטפל ב-wakelocks באופן שונה עבור סוגים שונים של בקשות.
סיווג בקשות RIL
בקשות RIL יכולות להיות יזומות או לא יזומות. ספקים צריכים לסווג בקשות שהתקבלו כתוצאה מפנייה יזומה לאחת מהקטגוריות הבאות:
- synchronous. בקשות שלא דורשות זמן רב לתגובה. לדוגמה,
RIL_REQUEST_GET_SIM_STATUS. - asynchronous. בקשות שלוקח הרבה זמן לקבל עליהן תשובה. לדוגמה,
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
בקשות RIL אסינכרוניות שמתקבלות בתגובה לבקשה יכולות לקחת זמן רב. אחרי קבלת אישור מקוד הספק, RIL Java מבטל את חסימת מצב השינה, מה שעלול לגרום למעבד האפליקציה לעבור ממצב בלי פעילות למצב השהיה. כשהתגובה זמינה מקוד הספק, RIL Java (מעבד האפליקציות) מקבל מחדש את ה-wakelock, מעבד את התגובה ואז חוזר למצב המתנה. מעבר ממצב לא פעיל למצב השהיה וחזרה למצב לא פעיל עלול לצרוך הרבה חשמל.
אם זמן התגובה לא ארוך מספיק, עדיף להחזיק את ה-wakelock ולהישאר במצב בלי פעילות במשך כל הזמן שנדרש לתגובה, מאשר לעבור למצב השהיה על ידי שחרור ה-wakelock ולהוציא ממצב שינה כשהתגובה מגיעה. הספקים צריכים להשתמש במדידות צריכת חשמל ספציפיות לפלטפורמה כדי לקבוע את ערך הסף של הזמן T שבו צריכת החשמל במצב בלי פעילות למשך הזמן T גדולה יותר מצריכת החשמל במעבר ממצב בלי פעילות למצב השעיה וחזרה למצב בלי פעילות באותו משך זמן T. אם הזמן T ידוע, פקודות RIL שנמשכות יותר מהזמן T יכולות להיות מסווגות כאסינכרוניות, והפקודות הנותרות מסווגות כסינכרוניות.
תרחישי תקשורת של RIL
בתרשימים הבאים מוצגים תרחישי תקשורת נפוצים של RIL, ומוצעים פתרונות לשינוי הקוד כדי לטפל בבקשות RIL שמתקבלות בתגובה לבקשות שנשלחו ובבקשות שלא מתקבלות בתגובה לבקשות שנשלחו.
הערה: פרטי ההטמעה של הפונקציות שמופיעות בתרשימים הבאים מפורטים בשיטות acquireWakeLock(), decrementWakeLock() ו-clearWakeLock( ב-ril.cpp.
תרחיש: בקשת RIL ותגובה אסינכרונית שמתקבלת לאחר בקשה
בתרחיש הזה, אם התגובה המבוקשת של RIL צפויה להימשך זמן רב (כלומר, תגובה ל-RIL_REQUEST_GET_AVAILABLE_NETWORKS), ה-wakelock מוחזק למשך זמן רב בצד של מעבד האפליקציה. בעיות במודם יכולות גם לגרום להמתנה ארוכה.
פתרון 1: המודם מחזיק ב-wakelock עבור בקשת ה-RIL והתגובה האסינכרונית.
- בקשת RIL נשלחת והמודם מקבל נעילת השכמה כדי לעבד את הבקשה הזו.
- המודם שולח אישור שגורם לצד של Java להקטין את מונה ה-wakelock ולשחרר אותו כשערך המונה הוא 0.
הערה: משך הזמן הקצוב לתפוס את המעבד במצב פעיל ברצף של בקשת אישור יהיה קצר יותר ממשך הזמן הקצוב שמשמש כרגע, כי האישור אמור להתקבל די מהר.
- אחרי עיבוד הבקשה, המודם שולח הפרעה לקוד הספק שמקבל את ה-wakelock ושולח תגובה ל-ril.cpp, שבתורו מקבל את ה-wakelock ושולח תגובה לצד Java.
- כשהתגובה מגיעה לצד של Java, מתבצעת השגת נעילת השכמה ומוחזרת תגובה למתקשר.
- אחרי שכל המודולים מעבדים את התגובה, נשלח אישור (דרך socket) בחזרה אל
ril.cpp, ואז מתבצע שחרור של ה-wakelock שהושג בשלב 3.
פתרון 2: המודם לא מחזיק את ה-wakelock והתגובה מהירה (בקשת RIL ותגובה סינכרוניות). ההתנהגות הסינכרונית לעומת האסינכרונית מוצפנת בפקודת RIL ספציפית ונקבעת על בסיס שיחה אחר שיחה.
- בקשת RIL נשלחת על ידי קריאה ל-
acquireWakeLock()בצד Java. - קוד הספק לא צריך לקבל נעילת השכמה (wakelock), והוא יכול לעבד את הבקשה ולהגיב במהירות.
- כשמתקבלת התגובה בצד Java, מתבצעת קריאה לפונקציה
decrementWakeLock(), שמקטינה את מונה ה-wakelock ומשחררת את ה-wakelock אם ערך המונה הוא 0.
תרחיש: תגובה לא רצויה של RIL
בתרחיש הזה, לתגובות לא רצויות של RIL יש סימון מסוג wakelock ב- שמציין אם צריך להשיג wakelock לתגובת הספק. אם הדגל מוגדר, מוגדרת נעילת השכמה מתוזמנת והתגובה נשלחת דרך שקע לצד Java. כשהטיימר מסתיים, נעילת ההשכמה משתחררת. ה-wakelock עם הגבלת הזמן יכול להיות ארוך מדי או קצר מדי לתגובות שונות של RIL unsolicited.
הפתרון: קוד ה-Java שולח אישור לצד המקורי (ril.cpp) במקום להחזיק נעילת השכמה מתוזמנת בצד המקורי בזמן שליחת תגובה לא רצויה.
אימות של נעילות מעוררות שעוצבו מחדש
מוודאים ששיחות RIL מזוהות כסינכרוניות או אסינכרוניות. צריכת הסוללה יכולה להיות תלויה בחומרה או בפלטפורמה, ולכן ספקים צריכים לבצע בדיקות פנימיות כדי לגלות אם שימוש בסמנטיקה החדשה של חסימת מצב השינה עבור קריאות אסינכרוניות מוביל לחיסכון בצריכת הסוללה.