פריסת מחיצה

באנדרואיד 10, מערכת קבצי השורש אינה כלולה עוד ב- ramdisk.img ובמקום זאת מתמזגת לתוך system.img (כלומר, system.img נוצר תמיד כאילו הוגדר BOARD_BUILD_SYSTEM_ROOT_IMAGE ). מכשירים המופעלים עם אנדרואיד 10:

  • השתמש בפריסת מחיצת מערכת כבסיס (נאכפת באופן אוטומטי על ידי ה-build ללא אפשרויות לשנות את ההתנהגות).
  • חייב להשתמש ב-ramdisk, אשר נדרש עבור dm-linear.
  • יש להגדיר את BOARD_BUILD_SYSTEM_ROOT_IMAGE ל- false . הגדרה זו משמשת רק כדי להבדיל בין התקנים המשתמשים ב-ramdisk לבין התקנים שאינם משתמשים ב-ramdisk (ובמקום זאת לטעון system.img ישירות).

המשמעות של תצורת מערכת כבסיס שונה בין אנדרואיד 9 לאנדרואיד 10. בתצורת מערכת כבסיס של Android 9, BOARD_BUILD_SYSTEM_ROOT_IMAGE מוגדר כ- true , מה שמאלץ את ה-build למזג את מערכת קבצי השורש לתוך system.img ואז mount system.img כמערכת קבצי השורש (rootfs). תצורה זו היא חובה עבור מכשירים המופעלים עם אנדרואיד 9 אך היא אופציונלית עבור מכשירים המשדרגים לאנדרואיד 9 ועבור מכשירים המריצים גרסאות נמוכות יותר של אנדרואיד. בתצורת מערכת כבסיס של Android 10, ה-build תמיד ממזג את $TARGET_SYSTEM_OUT ו- $TARGET_ROOT_OUT לתוך system.img ; תצורה זו היא התנהגות ברירת המחדל עבור כל המכשירים המריצים אנדרואיד 10.

אנדרואיד 10 מבצעת שינויים נוספים כדי לתמוך במחיצות דינמיות , מערכת לחלוקת מחיצות למרחב משתמש המאפשרת עדכוני אויר (OTA) ליצור, לשנות גודל או להרוס מחיצות. כחלק משינוי זה, ליבת לינוקס כבר לא יכולה להעלות את מחיצת המערכת הלוגית במכשירים המריצים אנדרואיד 10, כך שהפעולה הזו מטופלת על ידי השלב הראשון ב-it.

הסעיפים הבאים מתארים את דרישות המערכת כשורש עבור OTAs למערכת בלבד, מספקים הנחיות לגבי עדכון התקנים לשימוש במערכת כשורש (כולל שינויים בפריסת מחיצה ודרישות ליבת dm-verity). לפרטים על שינויים ב-ramdisk, ראה מחיצות Ramdisk .

לגבי OTAs למערכת בלבד

OTAs למערכת בלבד, המאפשרות לגרסאות אנדרואיד לעדכן את system.img ו- product.img מבלי לשנות מחיצות אחרות, דורשות פריסת מחיצת מערכת כבסיס. כל המכשירים המריצים אנדרואיד 10 חייבים להשתמש בפריסת מחיצת מערכת כבסיס כדי לאפשר OTAs למערכת בלבד.

  • התקני A/B, המרכיבים את מחיצת system כ-rootfs, כבר משתמשים במערכת כ-root ואינם דורשים שינויים כדי לתמוך ב-OTAs של המערכת.
  • התקנים שאינם A/B, אשר מעלים את מחיצת system ב- /system , חייבים להיות מעודכנים כדי להשתמש בפריסת מחיצת מערכת כבסיס לתמיכה ב-OTAs של המערכת.

לפרטים על התקני A/B ולא A/B, ראה עדכוני מערכת A/B (חלקים) .

שימוש בשכבת-על של ספק

שכבת-על של ספק מאפשרת לך לשכב שינויים במחיצת vendor בזמן אתחול המכשיר. שכבת-על של ספק היא קבוצה של מודולי ספק במחיצת product שמקבלים שכבת-על על מחיצת vendor כאשר המכשיר מאתחל, מחליף ומוסיף למודולים הקיימים.

כאשר המכשיר מאתחל, תהליך init משלים את השלב הראשון וקורא את מאפייני ברירת המחדל. לאחר מכן הוא מחפש /product/vendor_overlay/<target_vendor_version> ומעלה כל ספריית משנה בספריית מחיצות vendor המתאימה לה, אם מתקיימים התנאים הבאים:

  • /vendor/<overlay_dir> קיים.
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> יש את אותו הקשר קובץ כמו /vendor/<overlay_dir> .
  • init מותר לעלות בהקשר הקובץ של /vendor/<overlay_dir> .

הטמעת שכבת-על של ספקים

התקן קבצי שכבת-על של ספק ב- /product/vendor_overlay/<target_vendor_version> . קבצים אלה מכסים את מחיצת vendor בעת אתחול המכשיר, מחליפים קבצים בעלי אותו שם ומוסיפים קבצים חדשים כלשהם. שכבת-על של ספק לא יכולה להסיר קבצים ממחיצת vendor .

קובצי שכבת-על של ספק חייבים להיות בעלי הקשר קובץ זהה לקובצי היעד שהם מחליפים במחיצת vendor . כברירת מחדל, הקבצים בספריית /product/vendor_overlay/<target_vendor_version> הם בעלי הקשר vendor_file . אם יש חוסר התאמה בהקשר של קבצים בין קבצי שכבת-על של הספק לבין הקבצים שהם מחליפים, ציין זאת ב-sepolicy הספציפית למכשיר. הקשר הקובץ מוגדר ברמת הספרייה. אם הקשר הקובץ של ספריית שכבת-על של ספק אינו תואם את ספריית היעד, והקשר הקובץ הנכון לא צוין במדיניות ה-se-policy הספציפית למכשיר, ספריית שכבת-על של ספק אינה מכוסה על ספריית היעד.

כדי להשתמש בשכבת-על של הספק, על הליבה להפעיל OverlayFS על-ידי הגדרת CONFIG_OVERLAY_FS=y . כמו כן, יש למזג את הליבה מהקרנל הנפוץ 4.4 ואילך, או לתקן אותו באמצעות "overlayfs: override_creds=off option bypass creator_cred" .

דוגמה ליישום שכבת-על של ספק

הליך זה מדגים הטמעת שכבת-על של ספק המכסה את הספריות /vendor/lib/* , /vendor/etc/* ו- /vendor/app/* .

  1. הוסף קבצי ספקים שנבנו מראש device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/ :

    device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

  2. התקן את קבצי הספקים המובנים מראש ל- product/vendor_overlay ב- device/google/device/device.mk :

    PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

  3. הגדר הקשרים של קבצים אם לקבצי המחיצה vendor היעד יש הקשרים אחרים מאשר vendor_file . מכיוון ש- /vendor/lib/* משתמש בהקשר vendor_file , הדוגמה הזו לא כוללת את הספרייה הזו.

    הוסף את הדברים הבאים ל- device/google/device-sepolicy/private/file_contexts :

    /(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0

  4. אפשר לתהליך init להעלות את שכבת-העל של הספק בהקשרי קובץ שאינם vendor_file . מכיוון שלתהליך ה- init כבר יש הרשאה לעלות בהקשר vendor_file , דוגמה זו אינה מגדירה את המדיניות עבור vendor_file .

    הוסף את הדברים הבאים ל- device/google/device-sepolicy/public/init.te :

    allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;

אימות שכבת-על של ספק

כדי לאמת את תצורת שכבת העל של הספק, הוסף קבצים ב- /product/vendor_overlay/<target_vendor_version>/<overlay_dir> ובדוק אם הקבצים מכוסים על הקבצים ב- /vendor/<overlay_dir> .

עבור בניית userdebug , יש מודול בדיקה עבור Atest :

$ atest -v fs_mgr_vendor_overlay_test

עדכון למערכת כשורש

כדי לעדכן התקנים שאינם A/B ​​לשימוש במערכת כשורש, עליך לעדכן את ערכת המחיצות עבור boot.img ו- system.img , להגדיר dm-verity ולהסיר כל תלות באתחול בתיקיות השורש הספציפיות למכשיר.

עדכון מחיצות

שלא כמו התקני A/B המשמשים מחדש /boot כמחיצת השחזור , התקנים שאינם A/B ​​חייבים לשמור את מחיצת /recovery בנפרד מכיוון שאין להם את מחיצת ה-fallback חריץ (לדוגמה, מ- boot_a ל- boot_b ). אם /recovery מוסר ממכשיר שאינו A/B ונעשה דומה לסכימת A/B, מצב השחזור עלול להישבר במהלך עדכון כושל למחיצת /boot . מסיבה זו, המחיצה /recovery חייבת להיות מחיצה נפרדת מ- /boot עבור מכשירים שאינם A/B, מה שמרמז שתמונת השחזור תמשיך להתעדכן באופן דחוי (כלומר, כמו במכשירים המריצים אנדרואיד 8.1.0 ומטה).

הטבלה הבאה מפרטת את ההבדלים במחיצות התמונה עבור מכשירים שאינם A/B ​​לפני ואחרי Android 9.

תמונה Ramdisk (לפני 9) מערכת כשורש (אחרי 9)
boot.img מכיל קרנל ו- ramdisk.img : 
ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...
 מכיל גרעין אתחול רגיל בלבד.
recovery.img מכיל ליבת שחזור ו- ramdisk.img התאוששות.
system.img מכיל את הדברים הבאים: 
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
 מכיל את התוכן הממוזג של system.img ו- ramdisk.img המקורי: 
system.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/
      - bin/
      - etc/
      - vendor -> /vendor
      - ...
    - vendor/ (mount point)
    - odm/ (mount point)
    ...

המחיצות עצמן אינן משתנות; גם ramdisk וגם system-as-root משתמשים בסכימת המחיצות הבאה:

  • /boot
  • /system
  • /system
  • /recovery
  • /vendor וכו'.

הגדרת dm-verity

ב-system-as-root, על הליבה לעלות system.img תחת / (נקודת הרכבה) עם dm-verity . AOSP תומך ביישומי dm-verity הבאים עבור system.img .

vboot 1.0

עבור vboot 1.0 , על הליבה לנתח מטא נתונים ספציפיים לאנדרואיד ב- /system , ולאחר מכן להמיר לפרמטרים dm-verity כדי להגדיר את dm-verity (דורש תיקוני ליבה אלה ). הדוגמה הבאה מציגה הגדרות הקשורות ל-dm-verity עבור system-as-root בשורת הפקודה של ליבה:

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

vboot 2.0

עבור vboot 2.0 ( AVB ), טוען האתחול חייב לשלב את external/avb/libavb , אשר מנתח את מתאר ה-hashtree עבור /system , ממיר אותו ל- dm-verity params , ולבסוף מעביר את הפרמטרים לקרנל דרך שורת הפקודה של הליבה. (מתארי Hashtree של /system עשויים להיות ב- /vbmeta או ב- /system עצמה.)

vboot 2.0 דורש את תיקוני הקרנל הבאים:

הדוגמה הבאה מציגה הגדרות הקשורות ל-dm-verity עבור system-as-root בשורת הפקודה של ליבה:

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

שימוש בתיקיות שורש ספציפיות למכשיר

עם system-as-root, לאחר שתמונת המערכת הגנרית (GSI) מהבהבת במכשיר (ולפני הפעלת בדיקות הספק Test Suite ), כל תיקיות שורש ספציפיות למכשיר שנוספו עם BOARD_ROOT_EXTRA_FOLDERS נעלמו מכיוון שכל התוכן של ספריית השורש הוחלף על ידי מערכת כבסיס GSI. ההסרה של תיקיות אלו עלולה לגרום למכשיר להיות בלתי ניתן לאתחול אם קיימת תלות בתיקיות השורש הספציפיות למכשיר (לדוגמה, הן משמשות כנקודות הרכבה).

כדי למנוע בעיה זו, אל תשתמש BOARD_ROOT_EXTRA_FOLDERS כדי להוסיף תיקיות שורש ספציפיות למכשיר. אם אתה צריך לציין נקודות הרכבה ספציפיות למכשיר, השתמש ב- /mnt/vendor/<mount point> (נוספה ברשימות השינויים האלה). ניתן לציין את נקודות ההרכבה הספציפיות לספק ישירות הן בעץ מכשירי fstab (עבור שלב ראשון) והן בקובץ /vendor/etc/fstab.{ro.hardware} ללא הגדרה נוספת (כפי ש- fs_mgr יוצר אותם תחת /mnt/vendor/* באופן אוטומטי).