באנדרואיד 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/*
.
הוסף קבצי ספקים שנבנו מראש
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
התקן את קבצי הספקים המובנים מראש ל-
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)
הגדר הקשרים של קבצים אם לקבצי המחיצה
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
אפשר לתהליך
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 דורש את תיקוני הקרנל הבאים:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- תיקוני קרנל 4.4 , תיקוני ליבה 4.9 וכו'.
הדוגמה הבאה מציגה הגדרות הקשורות ל-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/*
באופן אוטומטי).