גוגל עובדת על APEX: עדכון ספריות מערכת כמו הפצת לינוקס רגילה. צפוי ב-Android Q, APEX עשוי להיות הדבר הגדול ביותר מאז Project Treble.
יישום APEX הוא כנראה כאב הראש הגדול ביותר שגוגל התמודדה איתו מאז השקת Project Treble. מהו APEX, וכיצד הצגתו תשנה את אנדרואיד?
הרעיון מאחורי APEX כשלעצמו נפוץ למדי בהפצות יומיומיות של GNU/Linux: עדכוני חבילות המכוונים לחלקים ספציפיים של ערכת ספריית לינוקס. אבל זה משהו שגוגל מעולם לא ניסתה לעשות בהתחשב בכך שאנדרואיד השתמשה במחיצת RO (לקריאה בלבד) שבה כל ספריות המערכת מסגרות מאוחסנות לעומת מחיצות RW (קריאה-כתיבה) הרגילות המשמשות ברוב ההפצות של לינוקס, מה שהופך את תהליך השדרוג הסטנדרטי לא מתאים.
ספריות הן קוד הידור מראש שניתן להשתמש בו בתוכנות אחרות. ניתן להפוך את השיטות הנפוצות לספריות עבור אפליקציות אנדרואיד להתקשרותן, ולהקטין את גודל חבילות ה-APK מכיוון שלא יהיה צורך להטמיע מחדש את אותו קוד במספר אפליקציות. אתה יכול למצוא ספריות מערכת מותקנות מראש בספריות /system/lib ו-/system/lib64. ספריות מערכות אנדרואיד בדרך כלל אינן מתעדכנות בנפרד - במקום זאת, הן מתעדכנות כחלק משדרוגים של פלטפורמות אנדרואיד באמצעות עדכון OTA. מצד שני, ספריות בהפצות לינוקס עשויות להתעדכן בנפרד. עם הצגת APEX, ספריות מערכת באנדרואיד ניתנות לעדכון בנפרד כמו אפליקציות אנדרואיד. היתרון העיקרי של זה הוא שמפתחי אפליקציות יוכלו לנצל את היתרון של ספריות מעודכנות מבלי לחכות ל-OEM שישיק שדרוג מערכת מלא. בואו נצלול לפרטים טכניים יותר על איך APEX עובד.
כיצד APEX ישנה את האופן שבו ספריות מתעדכנות?
APEX היא מערכת אקולוגית שאילצה (או ליתר דיוק, מאלצת) את גוגל לשקול מחדש את האופן שבו אנדרואיד טוען את כל הספריות והקבצים ממחיצה לא סטנדרטית השונה מ-/system.
קודם כל, עלינו לציין את ההבדל בין ספרייה משותפת לספרייה סטטית. ספרייה משותפת היא ספרייה (בדרך כלל קובץ בשם libkind.so) שאינה כוללת את כל הקוד הדרוש להפעלה בעצמה, אלא היא "מקושרת" לספריות אחרות למעשה. מתן הקוד, בעוד שספרייה סטטית היא, כפי שאתה יכול לנחש, ספרייה שאינה תלויה בשום ספרייה אחרת והכול כלול באופן סטטי בתוך קוֹבֶץ.
אנדרואיד הגדירה באופן היסטורי את נתיב הספרייה (המכונה LD_LIBRARY_PATH בעולם לינוקס) עם קובץ בודד שנקרא ld.config.txt [0] כדי להגדיר את נתיבי החיפוש המותרים עבור הספריות המשותפות הדרושים לבינארי או אחר סִפְרִיָה. נתיבים אלה מקודדים בקשיחה בתצורה ואינם ניתנים להרחבה. פריסה זו, כולל מחיצת המערכת לקריאה בלבד, מובילה לספריות שאינן ניתנות לעדכון, אלא אם המשתמש מתקין עדכון OTA Android. גוגל תיקנה בעיה זו ואיפשרה להרחיב את נתיב החיפוש על ידי מתן אפשרות לחבילות ה-APEX הבודדות לספק ld.config.txt משלהן שכללו את נתיבי הספריות הנוספים (והמעודכנים) הכלולים בהן.
אמנם המהלך הזה פתר את אחת הבעיות העיקריות, אבל עדיין היו כמה בעיות רציניות שצריך להתגבר עליהן. קודם כל: יציבות ABI (ממשק בינארי יישומים). ספריות צריכות לייצא תמיד קבוצה יציבה של ממשקים כדי לאפשר לאפליקציות וספריות אחרות להמשיך לעבוד עם אותו פרוטוקול גם עם הספרייה המשודרגת. גוגל עובדת על כך באופן פעיל על ידי ניסיון ליצור ממשק C יציב בין ספריות APEXed.
אבל APEX אינו מוגבל לספריות ובינאריות בלבד. למעשה, הוא יכול להכיל קובצי תצורה, עדכוני אזור זמן וכמה מסגרות Java (הצפנות בזמן הכתיבה).
להלן מספר דוגמאות לחבילות APEX הנוכחיות המסופקות על ידי AOSP:
- com.android.runtime: ART וזמן ריצה ביוני (בינאריות וספריות)
- com.android.tzdata: נתוני אזור זמן ונתוני טיפול נמרץ (ספריות ונתוני תצורה)
- com.android.resolv: ספרייה המשמשת את Android כדי לפתור בקשות הקשורות לרשת (ספריות)
- com.android.conscrypt: ספק אבטחה של Java (מסגרת Java)
כיצד מותקנת ומבנה חבילת APEX?
חבילת APEX היא ארכיון zip פשוט (כמו APK) שניתן להתקין על ידי ה-ADB השימושי שלנו (בשלב זה בפיתוח) ובהמשך, על ידי המשתמש עצמו באמצעות מנהל חבילות (כמו Google Play או ידנית דרך חבילת אנדרואיד מתקין).
פריסת ה-ZIP היא כדלקמן:
בואו נצלול לתוך זה.
ה-apex_manifest.json מציין את שם החבילה והגרסה.
הקובץ apex_payload.img הוא תמונת מיקרו-מערכת קבצים (בפורמט EXT4).
הקבצים האחרים הם חלק מתהליך האימות המשמש להתקנת החבילה. בוא נראה.
הנוכחות של AndroidManifest.xml, גם אם הוא משמש בעיקר ביישומים, עוזר לנו להבין שרוב המימוש המשמש להתקנת APK סטנדרטית נעשה בשימוש חוזר אפילו עבור חבילות אלו. למעשה, רק התוסף נבדק כדי להבדיל ביניהם.
ה META-INF/ לספרייה יש את אישור החבילה ומשתמשת באותו מנגנון כמו חבילות APK רגילות. אז החבילות האלה מאומתים על ידי זוג מפתחות פרטיים/ציבוריים בזמן ריצה לפני שהמשתמש מורשה להתקין עדכון. אבל זה לא הספיק לגוגל, אז הם הוסיפו עוד 2 שכבות אבטחה. הם משתמשים ב-dm-verity כדי לבדוק את תקינות התמונה ובאימותי AVB (Android Verified Boot) כדי לוודא שהתמונה מגיעה ממקור מהימן. במקרה הגרוע ביותר, חבילת APEX תידחה.
אם כל שלבי האימות יצליחו, התמונה תסומן כתקינה ותחליף את גרסת המערכת באתחול הבא.
כיצד מותקנת תמונה בעת האתחול?
נתחיל בהסתכלות על ה-APEXs המותקנים כעת במכשיר שלי (אמולטור)
כפי שאתה יכול לראות, החבילות המותקנות מראש מאוחסנות ב- /system/apex/ וכולן נמצאות כעת בגרסה מספר 1. אבל מה קורה כאשר APEX מופעל? שוב נשתמש ב-com.android.tzdata כדוגמה.
בואו לאתחל את המכשיר וננתח את ה-logcat.
2 השורות הראשונות מספקות מספיק מידע כדי להבין את מקור החבילה והיכן היא עומדת להיות מותקן: /apex/, ספרייה חדשה שהוצגה באנדרואיד Q שתשמש לאחסון המופעלים חבילות.
לאחר שהחבילה אומתה בהצלחה עם AVB והמפתח הציבורי תואם, ה-APEX מותקן באמצעות התקן לולאה ל- /dev/block/loop0, מה שהופך את מערכת הקבצים EXT4 לנגישה למערכת. התקן לולאה הוא התקן פסאודו שהופך קובץ לנגיש כהתקן בלוק, מה שהופך את התוכן של אותו קובץ לנגיש כנקודת הרכבה.
בשלב זה, עדיין לא נעשה שימוש ב-APEX בגלל הסיומת @1 (שמציינת את גרסת החבילה). כדי ליידע סוף סוף את המערכת שהחבילה שלנו הופעלה בהצלחה, היא תותקן ב-Bind-mounted ל-/apex/com.android.tzdata, שם אנדרואיד מצפה באופן פעיל ש-tzdata יחיה. הרכבת חיבור מכסה ספריה או קובץ קיימים מתחת לנקודה אחרת. [1]
יישום APEX כלול כולו במאגר יחיד תחת AOSP. [2] ספריית apexd (APEX daemon) כוללת את הקוד שפועל באנדרואיד. בספריית apexer יש את הקוד המשמש את מערכת ה-build ליצירת חבילות APEX.
מה המטרה?
בשלב זה, כל מה שאני יכול לעשות הוא לשער. הניחוש הטוב ביותר שלי הוא שגוגל מנסה ליצור סט ליבה של חבילות APEX שניתן לעדכן על ידי גוגל כדי ליצור ליבת בסיס מאוחדת של אנדרואיד המשותפת בין ספקים, מה שהופך עדכוני "מערכת" לאפשריים בלבד, אך באמצעות חבילה אחת עדכונים.
האם כל המכשירים יתמכו ב-APEX?
לא. לדוגמה, apexd דורש ש-/data/apex יהיה זמין מיד לאחר האתחול כדי לעדכן את כל מודולי האנדרואיד. עם FDE (הצפנת דיסק מלא), /data/apex מוצפן עד לביטול נעילת המכשיר על ידי המשתמש, מה שהופך את APEX לחסר תועלת בעצם מכיוון שרק גרסאות ה-APEX של המערכת ייטענו בעת האתחול. חוץ מזה, כל המכשירים צריכים לתמוך ב-APEX, אבל הם צריכים כמה תיקוני ליבה (שרבים מהם תיקונים שגוגל מצאה בזמן משחק עם התקני לולאה). [3] [4]
מקורות [0], [1], [2], [3], [4]