ללא קוד מקור, איך מפתחים משיגים רכיבי חומרה כגון מצלמות הפועלות ב-ROMs מותאמים אישית? התשובה היא BLOB, סימן והרבה איתור באגים.
עם שחרורו של אנדרואיד אוראו ומכשירים רבים כגון Xiaomi Redmi Note 3, Google Nexus 5 ו אחרים מקבלים את זה באופן לא רשמי, זה כנראה הוגן לתהות מדוע אותן תכונות (בעיקר המצלמה) נוטות להישבר כאשר מפתחים מעבירים ROM מבוסס Android Open Source Project (AOSP). בטח ראיתם שרשורי פורום XDA של ROM עם רשימה ארוכה של תכונות שבורות למעלה. "מה עובד" ואחריו רשימה של תכונות עבודה, ואז למטה הסמל האייקוני "מה לא עובד? אתה תאמר לי!" הם שני פזמונים פופולריים בפורומים שלנו שהפכו למעשה למם במקומות כמו Reddit וטוויטר.
מדוע כל כך הרבה פונקציונליות נשברת בכל פעם שמפתח מנסה להעביר AOSP ROM למכשיר שלו? התשובה הבסיסית היא שמכיוון שהפונקציות משתנות בגרסאות שונות של אנדרואיד, מנהלי התקנים ישנים ארוזים כ-BLOBs לא יעבדו עם גרסאות חדשות יותר של אנדרואיד, או אפילו רק עם AOSP במלאי. כדי להתגבר על זה, מפתחים עושים שימוש במה שנקרא "שיים", אבל התהליך הכרוך הוא מסובך, זמן רב ולפעמים קשה מאוד לנפות באגים.
במאמר זה, נתאר כיצד פועלים shims, במיוחד בכל הקשור להפעלת המצלמה כראוי על ROMs מבוססי AOSP. אנו נשתמש ב- OnePlus 3T כדוגמה. שימו לב שהקושי הכרוך בהפעלת תכונות אלו הוא מאוד ספציפי למכשיר.
OnePlus 3T עם OxygenOS. למרות שטלפונים של OnePlus ידועים בידידותיות לפיתוח מותאם אישית שלהם, יש הרבה עבודה שמפתחים עושים מאחורי הקלעים כדי ליצור יציאות יציבות של AOSP.
מה זה שים או BLOB?
כדי אפילו להתחיל להבין חלק ממה שמפתחים עושים, ראשית עלינו להסביר כמה דברים. למרות שמערכת ההפעלה אנדרואיד היא קוד פתוח (יש סיבה שהיא נקראת Android Open Source Project), התוכנה (ללא הליבה) הנשלחת באלפי מכשירי אנדרואיד אינה. למפתחים אין גישה לקוד המקור של ניסיון של סמסונג, EMUI, OxygenOS, או כל אחד מהטעמים האחרים של צד שלישי של אנדרואיד.
כעת, למפתחים המעבירים מניות AOSP למכשיר שאינו של גוגל כנראה לא אכפת מקוד המקור של סקינים אלה של אנדרואיד מכיוון שהם לא יהיו. שינוי ובניית ROMs אלה. זה יהיה נכון, אם לא מסיבה אחת גדולה וגדולה: החלקים הדרושים כדי שהמצלמה תעבוד כמו שצריך, בעיקר ה מצלמה HAL (שכבת הפשטה של חומרה), הם גם מקור סגור.
הבעיה שיש לא רק את המצלמה HAL אלא גם את המקור הסגור של ה-ROM היא שמפתחים שעובדים על העברת AOSP למכשיר שלהם יהיו עובד עיוור. מקור סגור OEM ROM מסוגל להתממשק עם המצלמה HAL בסדר גמור כי OEM יש גישה למקור HAL המצלמה. המצלמה HAL היא מה שמאפשר ל-ROM "לדבר" עם חומרת המצלמה - בלעדיה, המצלמה לא תפעל. חשבו על המצלמה HAL בתור ההגה והדוושות של המכונית. ההגה/דוושות מאפשרים שליטה ברכיבים הפנימיים של הרכב על ידי מתן ממשק חיצוני לנהג (ה-ROM) לעשות שימוש ברכיבים הפנימיים.
ככל שחומרת המצלמה הופכת מורכבת יותר ויותר (ה הופעתן של מצלמות כפולות, למשל), גישה למקור ה-HAL של המצלמה תהפוך העברת ROM AOSP עם מצלמה פונקציונלית למאמץ הרבה יותר קל.
עם זאת, יצרני OEM אינם מספקים גישה למקור HAL של המצלמה מסיבות שונות. ראשית, אם אין להם את כל זכויות הבעלות על המצלמה HAL (כגון כאשר הם משלבים קניין רוחני מחברות אחרות), אז הם לא יכולים להפיץ את המקור. שנית, שחרור מקור ה-HAL של המצלמה עלול לסכן את הקניין הרוחני שלהם. לבסוף, חברות אינן מחויבות חוקית לספק קוד מקור זה (בניגוד לקוד המקור של הליבה שהן מחויב לשחרר במסגרת ה-GPL), ולכן אין להם תמריץ לשחרר אותו. אז ללא גישה למקור HAL של המצלמה, איך בדיוק מפתחים גורמים למצלמה לעבוד על AOSP ROMs? התשובה היא BLOB, shim, והרבה הרבה ניפוי באגים.
מכשיר כֶּתֶם (Binary Large OBject) מכיל קבצים בינאריים ארוזים מראש שהם צורת הידור של תוכנה. במקרה זה, מקור ה-HAL של המצלמה נערך על ידי ה-OEM ונשלח במכשירים כקבצים בינאריים. כשמפתחים מדברים על BLOB, הם מתייחסים לאותם קבצים בינאריים שנשלחים במכשירים חיים שהם מסוגלים לחלץ. עכשיו, לנושא "בלובי המצלמה" יש OnePlus שפגע זמן רב במשך חודשים רבים, אבל האמת היא שלמפתחים תמיד הייתה גישה ל-BLOB של המצלמה. ה קוד המקור של מצלמה HAL הוא כרטיס הזהב למפתחים כאן, אבל זה יהיה לעולם, לעולם לא ישוחרר בשל הסכנה המשפטית זה יכניס חברות כמו OnePlus.
לפיכך, מפתחים המעוניינים להכניס AOSP למכשיר נותרים רק עם BLOB של המצלמה HAL שלגביהם אין להם גישה לקוד המקור. לעתים רחוקות אם בכלל, מפתח יכול לקשר את קוד ה-AOSP ROM שלו עם המצלמה HAL BLOB ולצפות שהוא יעבוד, ולכן כדי לגשר על הפער בין השניים, מפתחים יוצרים מה שנקרא "פַּחִית.”
"שיים" זה "לתקוע (משהו) או למלא חלל". זה למעשה מה שמפתח עושה מתי כתיבת שים לב - הם מוסיפים קוד כדי לאפשר ל-BLOB להתממשק עם קוד המקור של AOSP שהם עובדים עם. שימס משמשים כדי לגרום ל-BLOB מכל הסוגים השונים לעבוד עם AOSP, אבל בדרך כלל, BLOB של המצלמה הוא זה שדורש הכי הרבה שיימינג. כפי שהזכרנו קודם, שיימינג נדרש לא רק להעברת גרסאות חדשות יותר של אנדרואיד למכשיר (כגון כל אותם ROMs לא רשמיים של אנדרואיד אוראו) אבל גם נחוצים בעת העברת AOSP של אותה גרסת אנדרואיד לזה התקן.
קריאה מומלצת: מחנות למדף: כניעה מעמיקה של מדוע מכשירי MSM8974 אינם נכללים בנוגט
ה-OnePlus 2, למשל, קיבל את שלו עדכון מערכת הפעלה רשמי רשמי אחרון בצורה של אנדרואיד 6.0 מרשמלו. למכשיר, לעומת זאת, יש למעשה ROM מבוססי AOSP פועלים במלואם מבוסס על אנדרואיד נוגט, וזה הודות לעבודה הקשה של המפתחים והשימים שלהם. אנחנו נפרט כמה דוגמאות של shims, אבל קודם, אנחנו צריכים לדבר על איך בדיוק shims עובד.
איך עובד שיימינג?
מכיוון שלמפתחים אין גישה למקור ה-HAL של המצלמה או ה-OEM ROM (ורק לקבצים הבינאריים המהודרים מראש), הם לא יכולים לדעת לאילו פונקציות מצפה ה-HAL של המצלמה. בגלל זה, לעתים קרובות יש חוסר התאמה בין שם הפונקציה שהמצלמה HAL מחפשת לבין השם האמיתי של הפונקציה בקוד ה-AOSP שאיתו המפתח עובד.
כדי לפתור בעיה זו, המפתח פשוט יוצר פונקציה חדשה המשתמשת באותו שם של פונקציה שהמצלמה HAL BLOB מצפה לה, אבל הפונקציה החדשה הזו פשוט מבצעת את מה שהמפתח רוצה זה ל. הפונקציה החדשה הזו שפועלת כמתווך בין ה-BLOB ל-AOSP היא ה-shim. התרחיש הספציפי הזה שבו ה-BLOB לא מצליח למצוא את הפונקציה שהוא מחפש הוא אחד התרחישים הנפוצים שבהם יש צורך ב-shim.
אולי הדברים יהיו קצת יותר הגיוניים עם דוגמה היפותטית הכוללת את ה-OnePlus 3T. ניצור דוגמה באמצעות OxygenOS ומצלמת OnePlus. אם נשתמש ב-BLOB של מצלמה שנלקחו מ-OxygenOS Nougat עבור ה-OnePlus 3T כדי לבנות ROM נוגט מבוסס AOSP, אנו עלולים להיתקל בבעיות. הסיבה לכך היא ש-BLOB של המצלמה (שהורכבו במקור על ידי ה-OEM) יוכלו להתייחס לכל הפונקציות הדרושות לה בתוך OxygenOS, אך מאז ייתכן ש- AOSP ROM מהידור לא מכיל את הפונקציות הללו או שהידור אותן תחת שם אחר (ובכך מוביל לחוסר התאמה בין סמלי הפונקציות), יהיה שְׁגִיאָה. ניתן לתקן זאת על ידי יצירת פונקציה חדשה בתוך ה-AOSP ROM בשם שה-BLOB מצפה לו - ה-shim שלנו.
סמלים בהקשר תכנות משמשים להתייחסות לפונקציות ספציפיות בקוד. סמלים נחוצים מכיוון שהמיקום של פונקציה יכול להשתנות בעת עריכת הקוד, וכך על מנת להימנע מקידוד קשיח הפניות לפונקציות, המהדר יוצר טבלת סמלים שפונקציות אחרות יכולות להשתמש בהן כדי להתייחס תמיד ימינה פוּנקצִיָה. כאשר אתה משנה את שם הפונקציה לפני הקומפילציה, הסמל שלה משתנה גם כן, כך שבעצם כל משתנה שה-OEM יוצר למקור HAL של המצלמה לפני ההידור ידרוש מהמפתחים ליצור חדש פַּחִית.
ההסבר שהצענו עד כה גורם לזה להישמע כאילו יצירת shims היא קלה. לשנות כמה שמות פונקציות פה ושם לא נשמע קשה מדי, נכון? לו רק זה היה כל כך קל. המציאות של shims כוללת יותר מסתם שינוי שמות של פונקציות. דיברנו עם המפתח המוכר של XDA Sultanxda שהצליח לספק לנו דוגמה לאחד ה-shims הקשים יותר שהוא עבד עליהם.
שיימינג - לא קל כמו שזה נשמע
למי שלא מכיר את ה-OnePlus 3T, המצלמה הקדמית הייתה שבורה בהתחלה ROMs מותאמים אישית מבוססי AOSP. מלכתחילה, ניסיון לצלם כל תמונה מעל 8MP יביא לכך מתרסק. בניסיונו לפתור סוגיה זו, עשה סולטנקסדה כמה shims כדי לאפשר למצלמה הקדמית של OnePlus 3T לפעול כהלכה.
Shim #1 - שינוי שם חבילת המצלמה
על מנת למנוע מהמצלמה הקדמית להתרסק בכל פעם שהמשתמש צילם תמונה מעל 8MP, Sultanxda אילץ את המצלמה HAL לזהות את כל המצלמות כמצלמת OnePlus. זה נעשה מכיוון ש-OnePlus החליטה להקדיש פונקציית עוזר ליישומים מסוימים (isOnePlusCamera, isFacebookCameraוכו') מסיבה כלשהי. Sultanxda תיקנה זאת על ידי שיימינג של המצלמה HAL כך שהיא מצביעה על פונקציה חדשה שתמיד מחזירה "נכון" כאילו המשתמש משתמש במצלמת OnePlus - גם כשלא.
Shim #2 - השבת QuadraCfa
עבור ה-shim הבא שלו, הוא היה צריך להשבית את QuadraCfa שהיא ככל הנראה טכנולוגיה קניינית של Qualcomm הקשורה למצלמה. אנחנו אומרים כנראה כי לא אני ולא Sultanxda בטוחים בדיוק מה זה QuadraCfa, אבל Sultanxda כן יודעת שהיא שברה את המצלמה הקדמית בכל פעם שהיא הופעלה.
הוא הבחין ש-QuadraCfa איכשהו יאפשר את עצמו, אבל הוא לא היה בטוח מדוע או איך היא עושה זאת. פתרון זה דרש שינוי די לא שגרתי מצידו. ב-shim קונבנציונלי, פונקציית shim, כאשר היא מורכבת, מספקת את הסמל החסר שה-BLOB מחפש. במקרה זה, ל-BLOB כבר היו הסמלים שהוא צריך - אלה שייצגו כנראה את הפונקציות שהחלו את QuadraCfa.
לפיכך, הוא היה צריך לעקוף את הסמלים המשמשים את המצלמה HAL ובעצם, לגרום להם להיות "חסרים" כך שֶׁלוֹ shims יספקו את אותם סמלים "חסרים". הדרך היחידה לעשות זאת היא באמצעות עריכת hex המצלמה HAL עצמה. עריכת Hex היא בעצם הסתכלות דרך חבורה של ג'יבריש לא מאורגן בצורה של נתונים בינאריים על מנת למצוא מחט בערימת השחת - או פונקציה או מחרוזת שאתה מחפש לערוך.
עריכת הקסדה של פונקציה היא הרבה יותר קשה מעריכת הקסדה של מחרוזת, אך למרבה המזל, Sultanxda הצליחה להימנע מהצורך לערוך בקשתית את הפונקציות מאחורי QuadraCfa על ידי במקום זאת עריכת hex שמות הסמלים כדי לבטל את הסמלים האלה.
Shim #3 - Bright Light Crash Fix
בשלב הבא, Sultanxda זיהה שצילום תמונה מהמצלמה הקדמית בתנאי תאורה בהירים יגרום למצלמה לקרוס. על מנת לשחזר את הבאג הזה במכשיר שלו, Sultanxda למעשה הפעיל את פונקציית הפנס של ה-OnePlus One שלו והאיר את האור מול המצלמה הקדמית של ה-OnePlus 3T על מנת לגרום לו לקרוס ולייצר יומנים שמישים! לאחר שגילה מהי הפונקציה שגורמת להתרסקות, הוא יצר תבנית שיניים כדי לאלץ את המכשיר להשתמש במצב תאורה חלשה כל הזמן עבור המצלמה הקדמית.
Shim #4 - תמונות מצלמה קדמית ברזולוציה נמוכה
לאחר תיקון התרסקות האור הבהיר עם ה-shim הקודם, Sultanxda גילתה באג נוסף שהופיע למעשה כתוצאה ישירה מאותו shim: תמונות מצלמה קדמיות ברזולוציה נמוכה. במקום לצלם תמונות ברזולוציה שביקשת המשתמש (למשל. 16MP), התמונה המתקבלת תצולם ב-4MP.
פתרון זה הצריך שהוא יסמן את הפונקציות handleSuperResolution ו isSuperResolution להחזיר תמיד true, אבל רק כאשר המצלמה הפונה הקדמית פעילה (כי אחרת, המצלמה תתרסק בעת צילום תמונות מהחיישן האחורי).
לקח נלמד - שיימינג יכול להיות קשה
Sultanxda מודה כי ה-shims שהוא היה צריך ליצור כדי לגרום למצלמה הקדמית של OnePlus 3T לפעול לא מייצגות את הדוגמה האופיינית שלך ל-shim. הוא די גאה ב-shim שלו לאור המורכבות שלו וההכרח הנדיר לערוך את ה-BLOB עצמו. אבל הדוגמה הזו רק מראה כמה קשה זה יכול להיות לגרום לחומרת המצלמה לעבוד על מכשירים מסוימים.
יהי רצון שההרפתקאות של המצלמה שלך יהיו פחות כואבות ממה ששלי היו. -סולטנקסדה
יומנים, יומנים ועוד יומנים. ללא דרך עקבית לשחזר קריסה וללא יומנים, למפתחים יש תקווה קטנה למצוא את מקור הבעיה. גם אם הם מוצאים מה גורם לבעיה, זה לא תמיד פתרון פשוט. כל התהליך של מציאת וריסוק הבאגים הללו יכול לקחת ימים או שבועות וזו הסיבה לכך שתיקון המצלמה ב-AOSP ROMs הוא אחת המשימות הקשות יותר.
אם למכשיר שלך יש AOSP ROM מועבר אליו עם חומרה מתפקדת במלואה, אני מקווה שתוכל להתחיל מעריך את המאבק שאולי עברו אותם מפתחים כדי להביא לך אותם מאפיינים. העריכו אותם על עבודתם, כי זה לא קל. זו עבודה רבה שהרוב המכריע של המשתמשים אפילו לא ישים לב אליה, מכיוון שמפתחים מוכשרים בפורומים שלנו דואגים לחלקים הבלתי נראים הרבים של אנדרואיד.
ברצוננו להודות במיוחד לסולטנקסדה על התרומות הרבות שהציע ביצירת מאמר זה.