ב-Android 7.0 בוצע רפקטורינג של שכבת ממשק הרדיו (RIL) באמצעות קבוצה של תכונות לשיפור הפונקציונליות של RIL. כדי להטמיע את התכונות האלה, שמומלצות אבל לא חובה, צריך לבצע שינויים בקוד של השותף. שינויים בשיטת ה-refactoring תואמים לדורות קודמים, ולכן יישומי העבר של התכונות שעברו refactoring ממשיכים לפעול.
השיפורים הבאים כלולים בשינוי המבנה של RIL:
- קודי שגיאה של RIL מאפשר קודי שגיאה ספציפיים
בנוסף לקוד
GENERIC_FAILUREהקיים. המידע הזה עוזר לפתור בעיות שגיאה כי הוא מספק פרטים ספציפיים יותר על הגורם לשגיאות. - ניהול גרסאות של RIL. מספק מידע מדויק יותר על הגרסה וקל יותר להגדרה.
- תקשורת RIL באמצעות נעילות השכמה. משפר את ביצועי הסוללה של המכשיר.
אתם יכולים להטמיע את כל השיפורים שצוינו למעלה או רק חלק מהם. פרטים נוספים זמינים בהערות על קוד בנושא ניהול גרסאות של RIL ב-https://android.googlesource.com/platform/hardware/ril/+/android16-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 בכל פעם שקודי שגיאה כלליים מוחזרים על ידי יצרן הציוד המקורי, כי לעיתים קרובות לוקח יותר מדי זמן לזהות את הסיבה המדויקת לקוד שגיאה GENERIC_FAILURE (ולפעמים אי אפשר לגלות אותה).
בנוסף, ril.h מוסיף קודי שגיאה נוספים לסוגי הנתונים המנויים 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. - אסינכרוני. בקשות שלוקח הרבה זמן לקבל עליהן תשובה. לדוגמה,
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
בקשות RIL אסינכרוניות שמתקבלות בתגובה לבקשה יכולות לקחת הרבה זמן. אחרי קבלת אישור מקוד הספק, RIL Java משחרר את ה-wakelock, מה שעלול לגרום למעבד האפליקציה לעבור ממצב המתנה למצב השהיה. כשהתגובה זמינה מקוד הספק, 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) עבור רצף בקשת האישור יהיה קצר יותר ממשך הזמן הקצוב שמשמש כרגע, כי האישור אמור להתקבל די מהר.
- אחרי עיבוד הבקשה, המודם שולח הפרעה לקוד הספק שמקבל את ה-wakelock ושולח תגובה ל-ril.cpp, שבתורו מקבל את ה-wakelock ושולח תגובה לצד Java.
- כשהתגובה מגיעה לצד של Java, מתבצעת השגת נעילת השהיה ומוחזרת תגובה למתקשר.
- אחרי שכל המודולים מעבדים את התגובה, נשלח אישור (דרך socket) בחזרה אל
ril.cpp, ואז מתבטל נעילת המכשיר שהופעלה בשלב 3.
פתרון 2: המודם לא מחזיק את ה-wakelock והתגובה מהירה (בקשת RIL ותגובה סינכרוניות). ההתנהגות הסינכרונית לעומת האסינכרונית מוצפנת בפקודת RIL ספציפית ונקבעת על בסיס שיחה אחר שיחה.
- בקשת RIL נשלחת על ידי קריאה ל-
acquireWakeLock()בצד Java. - קוד הספק לא צריך לקבל נעילת השכמה (wakelock) ויכול לעבד את הבקשה ולהגיב במהירות.
- כשמתקבלת התגובה בצד של Java, מתבצעת קריאה לפונקציה
decrementWakeLock(), שמקטינה את מונה ה-wakelock ומשחררת את ה-wakelock אם ערך המונה הוא 0.
תרחיש: תגובה לא רצויה של RIL
בתרחיש הזה, לתגובות לא רצויות של RIL יש סימון מסוג wakelock ב- שמציין אם צריך להשיג wakelock לתגובת הספק. אם הדגל מוגדר, מוגדרת נעילת השכמה מתוזמנת והתגובה נשלחת דרך שקע לצד Java. כשהטיימר מסתיים, נעילת ההשכמה משתחררת. יכול להיות שמשך הזמן של נעילת ההשכמה ארוך מדי או קצר מדי לתגובות שונות של RIL שלא נשלחו כבקשה.
הפתרון: קוד ה-Java שולח אישור לצד המקורי (ril.cpp) במקום להחזיק נעילת השכמה מתוזמנת בצד המקורי בזמן שליחת תגובה לא רצויה.
אימות של נעילות מעוררות ששופצו
מוודאים ששיחות RIL מזוהות כסינכרוניות או אסינכרוניות. צריכת הסוללה עשויה להיות תלויה בחומרה או בפלטפורמה, ולכן הספקים צריכים לבצע בדיקות פנימיות כדי לגלות אם שימוש בסמנטיקה החדשה של מניעת שינה עבור קריאות אסינכרוניות מוביל לחיסכון בסוללה.