מחיצת אתחול כללית

ב-Android 12, התמונה הגנרית של boot נקראת תמונת ליבה גנרית (GKI), מכיל את ה-ramdisk הכללי ואת הליבה של GKI.

במכשירים שמושקים עם Android 13, ramdisk יוסר מהתמונה של boot וימוקם בinit_boot נפרד. תמונה. השינוי הזה משאיר את תמונת boot עם רק ליבת GKI.

כדי לשדרג מכשירים שממשיכים להשתמש ב-Android 12 או גרסאות ליבה ישנות יותר, ה-RAMdisk הגנרי נותר באותו מקום אין דרישה לתמונה חדשה של init_boot.

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

במכשירים:

  • אין להשתמש במחיצת recovery ייעודית, כל ביטים של השחזור עוברים רדיסק כללי ל-Radisk של vendor_boot.

  • כדאי להשתמש במחיצה ייעודית של recovery, ללא שינוי ב-ramdisk של recovery. יש צורך כי ה-ramdisk recovery עומד בפני עצמו.

ארכיטקטורה

התרשימים הבאים ממחישים את הארכיטקטורה של מכשירים שפועלת בהם מערכת Android 12 ומעלה. למכשיר שמושק עם Android 13 יש תמונה אחת (init_boot) שמכילה את הרדיסק הגנרי. מכשירים שמשדרגים מ-Android 12 ל-Android 13 משתמשים באותה ארכיטקטורה שבה הם השתמשו Android 12.

השקה עם Android 13, ללא שחזור ייעודי

השקה/שדרוג של מכשיר, GKI, ללא שחזור ייעודי

איור 1. מכשירים שמושקים או משדרגים ל-Android 13, עם GKI, ללא שחזור ייעודי.

השקה עם Android 13, מכשיר ייעודי ושחזור A/B (ramdisk ייעודי)

השקה/שדרוג של מכשיר, GKI, שחזור A/B ושחזור A/B

איור 2. מכשירים שמושקים או משודרגים ל-Android 13, עם GKI, שחזור ייעודי ושחזור A/B.

אם במכשיר יש מחיצות recovery_a ו-recovery_b, צריך לעיין באיור הזה.

השקה עם Android 13, שחזור ייעודי ולא באמצעות A/B (ramdisk ייעודי)

השקה/שדרוג של מכשיר, GKI, שחזור ייעודי ולא מסוג A/B

איור 3. מכשירים שמושקים או משודרגים ל-Android 13, עם GKI, שחזור ייעודי וללא A/B.

צריך לעיין באיור הזה אם במכשיר יש מחיצה בשם recovery ללא הסיומת של משבצת הזמן.

השקה או שדרוג ל-Android 12, ללא שחזור ייעודי

השקה/שדרוג של מכשיר, GKI, ללא שחזור ייעודי

איור 4. מכשירים שמושקים או משדרגים ל-Android 12, עם GKI, ללא שחזור ייעודי.

השקה או שדרוג ל-Android 12, שחזור ייעודי ושחזור A/B (ramdisk ייעודי)

השקה/שדרוג של מכשיר, GKI, שחזור A/B ושחזור A/B

איור 5. מכשירים שמושקים או משודרגים ל-Android 12, עם GKI, תמיכה ייעודית ושחזור A/B.

אם במכשיר יש מחיצות recovery_a ו-recovery_b, צריך לעיין באיור הזה.

הפעלה או שדרוג ל-Android 12, שחזור ייעודי ולא מבוסס-A/B (רדיסק ייעודי)

השקה/שדרוג של מכשיר, GKI, שחזור ייעודי ולא מסוג A/B

איור 6. מכשירים שמושקים או משודרגים ל-Android 12, עם GKI, שחזור ייעודי וללא A/B.

צריך לעיין באיור הזה אם במכשיר יש מחיצה בשם recovery ללא הסיומת של משבצת הזמן.

שדרוג ל-Android 12, שחזור כהפעלה (שחזור כ-ramdisk)

השקה/שדרוג של מכשיר, ללא GKI, שחזור כאתחול

איור 7. מכשירים שמשדרגים ל-Android 12, ללא GKI, שחזור כהפעלה.

שדרוג ל-Android 12, שחזור ייעודי (ramdisk ייעודי)

השקה/שדרוג של מכשיר, ללא GKI, שחזור ייעודי

איור 8. מכשירים שמשדרגים ל-Android 12, ללא GKI, שחזור ייעודי.

תוכן של תמונות הפעלה

תמונות האתחול של Android כוללות את הפרטים הבאים.

  • נוספה תמונה אחת (init_boot) למכשירים עם Android 13

    • גרסת כותרת V4
    • תמונה גנרית של Ramdisk

  • תמונה גנרית אחת (boot)

    • גרסת כותרת V3 או גרסה 4
      • boot_signature להסמכת GKIboo.img (גרסה 4 בלבד). אישור GKI boot.img לא חתום להפעלה מאומתת. יצרני ציוד מקורי עדיין צריכים לחתום על boot.img המובנה מראש באמצעות מודל ספציפי למכשיר. AVB מקש.
      • cmdline כללי (GENERIC_KERNEL_CMDLINE)
      • ליבת GKI
    • תמונה גנרית של Ramdisk
      • כלול רק ב-boot תמונות מ-Android 12 ומוקדם יותר

  • תמונת vendor_boot (לפרטים, ראו אתחול ספק) מחיצות)

    • כותרת vendor_boot
      • cmdline ספציפי למכשיר (BOARD_KERNEL_CMDLINE)
    • תמונה של vendor_boot ramdisk
      • lib/modules
      • משאבי שחזור (אם אין שחזור ייעודי)
    • תמונה בפורמט dtb

  • תמונה בפורמט recovery

    • גרסת כותרת V2
      • cmdline ספציפי למכשיר לצורך שחזור, לפי הצורך
      • במחיצת שחזור שאינה A/B, תוכן הכותרת חייב להיות עצמאי; לראות תמונות שחזור. לדוגמה:
      • הפונקציה cmdline לא משורשרת ל-boot ול-vendor_boot cmdline.
      • הכותרת מציינת DTBO לשחזור, במקרה הצורך.
      • למחיצת שחזור A/B, אפשר לשרשר את התוכן או להסיק את התוכן מ-boot ו-vendor_boot. לדוגמה:
      • cmdline משורשר ל-boot ול-vendor_boot cmdline.
      • אפשר להסיק DTBO מהכותרת vendor_boot.
    • תמונה של recovery ramdisk
      • מקורות מידע לשחזור החשבון
      • עבור מחיצת שחזור שאינה A/B, התוכן של ה-ramdisk חייב להיות עצמאי; לראות תמונות שחזור. לדוגמה:
      • lib/modules חייב להכיל את כל מודולי הליבה הנדרשים להפעלה מצב שחזור
      • ramdisk השחזור חייב להכיל init.
      • עבור מחיצת שחזור A/B, רדיסק השחזור מופיע בתחילת מחיצת השחזור ראשי וvendor_boot, ולכן הוא לא צריך להיות בנפרד. לדוגמה:
      • lib/modules עשוי להכיל רק מודולים של ליבה נוספים שנדרשים כדי מצב התאוששות מאתחול מלבד מודולים של ליבה (kernel) ב-ramdisk של vendor_boot.
      • ייתכן שהקישור הסמלי ב-/init קיים, אבל הוא מכוסה על ידי הקובץ הבינארי /init מהשלב הראשון בקובץ האימג' של האתחול.

תוכן תמונה גנרי של Ramdisk

ה-ramdisk הגנרי מכיל את הרכיבים הבאים.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build אביזרים
  • ספריות ריקות לנקודות טעינה: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
  • first_stage_ramdisk/
    • ספריות ריקות כפולות לנקודות טעינה: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

שילוב קובץ האימג' של האתחול

יצירת דגלים קובעים את האופן שבו init_boot, boot, recovery ו-vendor_boot ליצירת תמונות. הערך של משתנה לוח בוליאני חייב להיות המחרוזת true או להיות ריקים (זו ברירת המחדל).

  • TARGET_NO_KERNEL המשתנה הזה מציין אם ה-build משתמש באתחול מובנה מראש תמונה. אם המשתנה הזה מוגדר לערך true, צריך להגדיר את BOARD_PREBUILT_BOOTIMAGE למיקום של קובץ האימג' של האתחול שנוצר מראש (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img)

  • BOARD_USES_RECOVERY_AS_BOOT המשתנה הזה מציין אם המכשיר משתמש את התמונה recovery בתור boot. כשמשתמשים ב-GKI, המשתנה הזה יש להעביר את המשאבים ריקים ואת משאבי השחזור אל vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE המשתנה הזה מציין שהלוח משתמש ג'קי. המשתנה הזה לא משפיע על מערכות יחסים או PRODUCT_PACKAGES

    זהו מתג GKI ברמת הלוח; כל המשתנים הבאים מוגבל על ידי המשתנה הזה.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT המשתנה הזה קובע אם משאבי השחזור של ramdisk מבוססים על vendor_boot.

    • אם המדיניות מוגדרת לערך true, משאבי שחזור נוצרים רק ב-vendor-ramdisk/ והן לא מותאמות לrecovery/root/.

    • כשהם ריקים, משאבי השחזור נוצרים רק על ידי recovery/root/ והם לא שפותח עבור vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT המשתנה הזה קובע אם GSI מפתחות AVB משתלבים באופן אוטומטי ב-vendor_boot.

    • הערך שמוגדר לפרמטר הוא true, אם BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • מוגדר, מפתחות GSI AVB מיועדים $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb

      • לא מוגדרת, מפתחות GSI AVB מיועדים $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb

    • כשהערך ריק, אם BOARD_RECOVERY_AS_ROOT:

      • מוגדר, מפתחות GSI AVB מיועדים $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb

      • לא מוגדרת, מפתחות GSI AVB מיועדים $ANDROID_PRODUCT_OUT/ramdisk/avb

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE המשתנה הזה קובע אם התמונה recovery מכילה ליבה (kernel) או לא. מכשירים שמופעלים עם Android 12 ושימוש במחיצת recovery A/B חייבים להגדיר את הפעולה הזו ל-true. מכשירים שמושקים עם Android 12 ואם נעשה שימוש בפורמט שאינו A/B, יש להגדיר את המשתנה הזה ל-false כדי לשמור את תמונת השחזור עצמאי.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES המשתנה הזה קובע אם הקובץ $OUT/boot*.img מועתק אל IMAGES/ בקובצי היעד.

    • על aosp_arm64 להגדיר את המשתנה הזה ל-true.

    • במכשירים אחרים צריך להשאיר את המשתנה הזה ריק.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE המשתנה הזה קובע אם העמודה init_boot.img נוצרת ומגדירה את הגודל. כאשר מוגדר, ה-Rramdisk הגנרי נוסף אל init_boot.img במקום אל boot.img ומחייב BOARD_AVB_INIT_BOOT* משתנים להגדרה vbmeta משורשרות.

שילובים מותרים

רכיב או משתנה שדרוג המכשיר ללא מחיצת שחזור שדרוג המכשיר עם מחיצת שחזור הפעלת המכשיר ללא מחיצת שחזור הפעלת המכשיר עם מחיצה לשחזור A/B הפעלת המכשיר עם מחיצת שחזור ללא חיבור A/B aosp_arm64
מכיל את boot כן כן כן כן כן כן
מכיל init_boot (Android 13) לא לא כן כן כן כן
מכיל את vendor_boot אופציונלי אופציונלי כן כן כן לא
מכיל את recovery לא כן לא כן כן לא
BOARD_USES_RECOVERY_AS_BOOT true ריק ריק ריק ריק ריק
BOARD_USES_GENERIC_KERNEL_IMAGE ריק ריק true true true true
PRODUCT_BUILD_RECOVERY_IMAGE ריק true או ריק ריק true או ריק true או ריק ריק
BOARD_RECOVERYIMAGE_PARTITION_SIZE ריק > 0 ריק > 0 > 0 ריק
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT ריק ריק true ריק ריק ריק
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT ריק ריק true true true ריק
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE ריק ריק ריק true ריק ריק
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES ריק ריק ריק ריק ריק true

ניתן להגדיר מכשירים עם מחיצת recovery ייעודית PRODUCT_BUILD_RECOVERY_IMAGE עד true או ריק. במכשירים האלה, אם BOARD_RECOVERYIMAGE_PARTITION_SIZE מוגדר, נוצרת תמונה של recovery.

הפעלת vbmeta בשרשרת להפעלה

צריך להפעיל vbmeta משורשרת לתמונות boot ו-init_boot. יש לפרט הבאים:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

לדוגמה, אפשר להיעזר ב שינוי.

מערכת ברמה הבסיסית (root)

התכונה 'מערכת בתור הבסיס' לא נתמכת במכשירים שמשתמשים ב-GKI. במצב מופעל מכשירים כאלה, BOARD_BUILD_SYSTEM_ROOT_IMAGE חייב להיות ריק. מערכת ברמה הבסיסית (root) אינה נתמכת גם במכשירים המשתמשים במחיצות דינמיות.

הגדרות מוצר

מכשירים שמשתמשים ב-ramdisk הכללי חייבים להתקין רשימה של קבצים מותר להתקין ב-ramdisk. כדי לעשות זאת, צריך לציין את הקוד הבא: device.mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

הקובץ generic_ramdisk.mk גם מונע בטעות מלצרות קבצים מסוגים אחרים להתקין קבצים אחרים ל-ramdisk (להעביר קבצים כאלה אל vendor_ramdisk במקום זאת).

הגדרת מכשירים

הוראות ההגדרה משתנות בהתאם למכשיר שמופעל עם Android 13, ואנחנו משדרגים ל-Android 12 ונשיק אותו עם Android 12. ההגדרות של Android 13 דומות לאופן שבו הן היו ב-Android 12

  • מכשירים שמשדרגים ל-Android 12:

    • אפשר לשמור על הערך של BOARD_USES_RECOVERY_AS_BOOT. אם הוא עושה זאת, הם משתמשים בהגדרות מדור קודם, ומשתני build חדשים חייבים להיות ריקים. אם קיים מכשירים:

      • מגדירים את BOARD_USES_RECOVERY_AS_BOOT לערך true. הארכיטקטורה היא מוצגת באיור 3.

      • צריך להגדיר את BOARD_USES_RECOVERY_AS_BOOT כריק, הארכיטקטורה מוצגת כמו שהיא איור 4.

    • אפשר להגדיר את BOARD_USES_RECOVERY_AS_BOOT כריק. אם הם עושים זאת, הם משתמשים לתצורות חדשות. אם מכשירים כאלה:

      • אין להשתמש במחיצה ייעודית של recovery, הארכיטקטורה מוצגת כפי שהיא מוצגת באיור 1 והאפשרות להגדרת המכשיר היא אפשרות 1.

      • משתמשים במחיצה ייעודית של recovery, הארכיטקטורה מוצגת כמו איור 2א או איור 2ב והגדרת המכשיר היא אפשרות 2א או אפשרות 2ב.

  • במכשירים עם Android 12 צריך להגדיר BOARD_USES_RECOVERY_AS_BOOT כדי לרוקן את קובצי ההגדרות האישיות ולהשתמש בהם. אם קיים מכשירים:

מכיוון ש-aosp_arm64 יוצר רק GKI (ולא vendor_boot או שחזור), אינו יעד מלא. למידע על aosp_arm64הגדרות build, תוכלו לעיין במאמר בנושא generic_arm64.

אפשרות 1: ללא מחיצת שחזור ייעודית

מכשירים ללא מחיצת recovery מכילים את התמונה הכללית של boot במקטע מחיצה boot. ה-ramdisk של vendor_boot מכיל את כל משאבי השחזור, כולל lib/modules (עם מודולים של ליבה (kernel) של ספק). במכשירים כאלה, הגדרות מוצר עוברות בירושה מ- generic_ramdisk.mk.

הגדרת ערכי board

מגדירים את הערכים הבאים:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

שרת ה-ramdisk vendor_boot יכול להכיל קישור סימבולי של /init עד /system/bin/init, ו-init_second_stage.recovery בשעה /system/bin/init. אבל, מכיוון ורדיסק גנרי משורשר אחרי הרדיסק vendor_boot, /init הקישור הסימבולי מוחלף. כשהמכשיר מתחיל באתחול, הקוד הבינארי של /system/bin/init נדרש כדי לתמוך באתחול בשלב שני. תוכן העניינים של vendor_boot + נתיבים גנריים הם ככה:

  • /init (מ-Ramdisk גנרי, שנבנה מ-init_first_stage)
  • /system/bin/init (מ-vendor_ramdisk, נוצר מ init_second_stage.recovery)

העברת קובצי fstab

יש להעביר את כל fstab הקבצים שהותקנו ל-ramdisk הגנרי אל vendor_ramdisk. לדוגמה, אפשר להיעזר ב שינוי.

התקנת מודולים

אפשר להתקין מודולים ספציפיים למכשיר כדי vendor_ramdisk (דילוג אם אין לכם מודולים ספציפיים למכשיר להתקנה).

  • משתמשים בווריאנט vendor_ramdisk של המודול כשהמודול מתקין /first_stage_ramdisk. המודול הזה אמור להיות זמין אחרי init עובר שורש ל-/first_stage_ramdisk אבל לפני init עובר שורש /system. למידע נוסף, עיינו בקטע סיכומי ביקורת (checksums) של מטא-נתונים דחיסת נתוני A/B וירטואליים.

  • משתמשים בווריאנט recovery של המודול כשהמודול מותקן ב-/. המודול הזה צריך להיות זמין לפני ש-init יעבור לרמה הבסיסית (root) /first_stage_ramdisk. לפרטים על התקנת מודולים ב-/, ראו ראשית מסוף השלב.

מסוף השלב הראשון

כי המסוף של השלב הראשון מתחיל לפני ש-init מועבר לרמה הבסיסית (root) /first_stage_ramdisk, עליך להתקין את גרסת recovery של המודולים. כברירת מחדל, שתי הווריאציות של המודול מותקנות על build/make/target/product/base_vendor.mk, כך שאם המכשיר יוצר קובץ בירושה מהקובץ הזה אין צורך להתקין באופן מפורש את הווריאציה recovery.

כדי להתקין באופן מפורש את המודולים לשחזור, השתמשו בהוראות הבאות.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

כך ניתן להבטיח שההתקנה של linker, sh ו-toybox ב $ANDROID_PRODUCT_OUT/recovery/root/system/bin, ולאחר מכן מותקן /system/bin במסגרת vendor_ramdisk.

כדי להוסיף מודולים שנדרשים למסוף השלב הראשון (לדוגמה, adbd), משתמשים ב במעקב.

PRODUCT_PACKAGES += adbd.recovery

הדבר מבטיח שהמודולים שצוינו יותקנו $ANDROID_PRODUCT_OUT/recovery/root/system/bin, ולאחר מכן מותקן /system/bin במסגרת vendor_ramdisk.

סיכום ביקורת (checksum) של מטא-נתונים

כדי לתמוך במטא-נתונים בדיקת סיכום (checksums) במהלך הטעינה בשלב הראשון, מכשירים שלא תומכים ב-GKI מתקינים את הרדיסק של המודולים הבאים. כדי להוסיף תמיכה ב-GKI, צריך להעביר את המודולים אל $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

לדוגמה, אפשר להיעזר ב רשימת שינויים.

דחיסת נתונים מסוג A/B וירטואלי

כדי לתמוך בדחיסת A/B וירטואלית, צריך להתקין את snapuserd כאן: vendor_ramdisk. המכשיר אמור לקבל בירושה virtual_ab_ota/compression.mk שמתקין את הווריאנט vendor_ramdisk של snapuserd.

שינויים בתהליך האתחול

תהליך האתחול לצורך שחזור או ל-Android לא משתנה, עם החריג הבא:

  • Ramdisk build.prop עובר אל /second_stage_resources כך שיש שלב שני. הפונקציה init יכולה לקרוא את חותמת הזמן של ה-build של האתחול.

מכיוון שמשאבים עוברים מ-ramdisk כללי ל-Radisk של vendor_boot, התוצאה היא שרשור שרשורי הרדיסקים הכלליים ל-ramdisk של vendor_boot לא משתנה.

הגדרת e2fsck

קובצי ה-Makefile במכשיר יכולים לרשת מ:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk אם המכשיר תומך בצפייה וירטואלית A/B אבל לא דחיסה.

  • virtual_ab_ota/compression.mk אם המכשיר תומך ב-A/B וירטואלי דחיסה.

פרטי ההתקנה של קובצי cookie של המוצר $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck בשעה סביבת זמן הריצה, השלב הראשון init עובר לרמה /first_stage_ramdisk ואז מבצעת את /system/bin/e2fsck.

אפשרות 2א: מחיצה ייעודית לשחזור חשבון A/B

שימוש באפשרות הזו במכשירים עם מחיצות recovery A/B. כלומר, במכשיר יש recovery_a ו-recovery_b partition. מכשירים כאלה כוללים מכשירי A/B ומכשירי A/B וירטואליים שבהם ניתן לעדכן את מחיצת השחזור, באמצעות את התצורה הבאה:

AB_OTA_PARTITIONS += recovery

ה-ramdisk של vendor_boot מכיל את הביטים של הספק של ה-ramdisk והספק מודולי הליבה, כולל:

  • קובצי fstab ספציפיים למכשיר

  • lib/modules (כולל מודולים של ליבה (kernel) של ספק)

ה-ramdisk recovery מכיל את כל משאבי השחזור. במכשירים כאלה, הגדרות מוצר עוברות בירושה מ- generic_ramdisk.mk.

הגדרת ערכי board

מגדירים את הערכים הבאים למכשירים עם מחיצת recovery A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

שרת ה-RAM של recovery יכול להכיל קישור סימבולי של /init -> /system/bin/init, וגם init_second_stage.recovery ב/system/bin/init. אבל מכיוון שהאתחול ה-ramdisk משורשר אחרי הרדיסק recovery, הקישור הסימבולי של /init הוא הוחלף. כשהמכשיר עובר למצב שחזור, /system/bin/init הקוד הבינארי נדרש כדי לתמוך באתחול בשלב שני.

כשהמכשיר יבצע אתחול אל recovery, התוכן של recovery + vendor_boot + דרכי הגעה גנריות הם:

  • /init (מ-ramdisk, שנבנה מ-init_first_stage)
  • /system/bin/init (מ-Radisk recovery, שנבנה מ init_second_stage.recovery, ובוצעה מ-/init)

כאשר מתבצעת אתחול של המכשיר ל-Android, התוכן של vendor_boot + גנרי הערכים האלה הם:

  • /init (מ-Ramdisk גנרי, שנבנה מ-init_first_stage)

העברת קובצי fstab

יש להעביר את כל fstab הקבצים שהותקנו ל-ramdisk הגנרי אל vendor_ramdisk. לדוגמה, אפשר להיעזר ב שינוי.

התקנת מודולים

לחלופין, אפשר להתקין ב-vendor_ramdisk מודולים ספציפיים למכשיר (לדלג על אם אין לכם מודולים ספציפיים למכשיר להתקנה). Init לא עובר לרמה הבסיסית (root). הווריאנט vendor_ramdisk של המודולים מותקן הרמה הבסיסית (root) של vendor_ramdisk. לדוגמאות של התקנת מודולים vendor_ramdisk, ראו מסוף שלב ראשון, מטא-נתונים סיכומי ביקורת (checksums) ו-Virtual A/B דחיסת נתונים.

מסוף השלב הראשון

כדי להתקין את הווריאנט vendor_ramdisk של המודולים, צריך להשתמש בגרסאות הבאות:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

כך ניתן להבטיח שההתקנה של linker, sh ו-toybox ב $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, ולאחר מכן מותקן /system/bin במסגרת vendor_ramdisk.

כדי להוסיף מודולים שנדרשים למסוף השלב הראשון (לדוגמה, adbd), מפעילים הווריאנט vendor_ramdisk של המודולים האלה על ידי העלאת תיקונים רלוונטיים ב-AOSP, ואז משתמשים בפקודה הבאה:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

הדבר מבטיח שהמודולים שצוינו יותקנו $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin אם נפח האחסון (Radisk) vendor_boot נטען במצב שחזור, המודול זמין גם ב-recovery. אם ramdisk של vendor_boot לא נטען במצב שחזור. המכשיר יכול באופן אופציונלי. להתקין גם את adbd.recovery.

סיכום ביקורת (checksum) של מטא-נתונים

כדי לתמוך במטא-נתונים בדיקת סיכום (checksums) במהלך הטעינה בשלב הראשון, מכשירים שלא תומכים ב-GKI מתקינים את הרדיסק של המודולים הבאים. כדי להוסיף תמיכה ב-GKI, צריך להעביר את המודולים אל $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

לדוגמה, אפשר להיעזר ב רשימת שינויים.

דחיסת נתונים מסוג A/B וירטואלי

כדי לתמוך בדחיסת A/B וירטואלית, צריך להתקין את snapuserd כאן: vendor_ramdisk. המכשיר אמור לקבל בירושה virtual_ab_ota/compression.mk שמתקין את הווריאנט vendor_ramdisk של snapuserd.

שינויים בתהליך האתחול

במהלך הפעלה ל-Android, תהליך ההפעלה לא משתנה. הלחצן vendor_boot + אמצעים גנריים דומים לתהליך האתחול הקיים, חוץ מהבדל אחד: fstab נטען מ-vendor_boot. מכיוון ש-system/bin/recovery לא קיים, first_stage_init מטפל בה כהפעלה רגילה.

תהליך ההפעלה משתנה במהלך האתחול במצב שחזור. מקש השחזור + vendor_boot + ramdisk גנרי דומה לתהליך השחזור הקיים, אבל הליבה נטענת מהתמונה boot במקום מהתמונה recovery. תהליך ההפעלה של מצב שחזור הוא בהמשך.

  1. תוכנת האתחול מופעלת ולאחר מכן מבצעת את הפעולות הבאות:

    1. דוחפת שחזור + vendor_boot + ramdisk גנרי ל-/. (אם ה-OEM (יצרן הציוד המקורי) משכפלת מודולים של ליבה לרדיסק שחזור על ידי הוספתם BOARD_RECOVERY_KERNEL_MODULES), המאפיין vendor_boot הוא אופציונלי.)
    2. מריצה את הליבה מהמחיצה boot.

  2. הליבה טוענת את ramdisk ל-/ ולאחר מכן מבצעת את /init מה-ramdisk הגנרי.

  3. השלב הראשון מתחיל ואז מבצע את הפעולות הבאות:

    1. הגדרה של IsRecoveryMode() == true ו-ForceNormalBoot() == false.
    2. טעינת מודולים של ליבה (kernel) של ספק מ-/lib/modules.
    3. מתקשרת אל DoFirstStageMount() אבל מדלגת על הטעינה כי IsRecoveryMode() == true. (במכשיר אין רפליקציות של RAM (כי /) עדיין אותו הדבר), אבל למעשה קורא ל-SetInitAvbVersionInRecovery()).
    4. התחלת שלב שני מ-/system/bin/init מ-ramdisk של recovery.

הגדרת e2fsck

קובצי ה-Makefile במכשיר יכולים לרשת מ:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk אם המכשיר תומך בצפייה וירטואלית A/B אבל לא דחיסה.

  • virtual_ab_ota/compression.mk אם המכשיר תומך ב-A/B וירטואלי דחיסה.

פרטי ההתקנה של קובצי cookie של המוצר $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck בשעה זמן הריצה, השלב הראשון init יריץ את /system/bin/e2fsck.

אפשרות 2ב: מחיצת שחזור ייעודית ולא מסוג A/B

יש להשתמש באפשרות הזו במכשירים עם מחיצת recovery שאינה A/B. כלומר, במכשיר יש מחיצה בשם recovery ללא סיומת של משבצת. מכשירים כאלה כוללים:

  • מכשירים שהם לא מסוג A/B;
  • מכשירי A/B ומכשירי A/B וירטואליים שבהם מחיצת השחזור לא שייכת שאפשר לעדכן. (זה חריג).

ה-ramdisk של vendor_boot מכיל את הביטים של הספק של ה-ramdisk והספק מודולי הליבה, כולל:

  • קובצי fstab ספציפיים למכשיר
  • lib/modules (כולל מודולים של ליבה (kernel) של ספק)

התמונה recovery צריכה להיות בפני עצמה. היא חייבת להכיל כל המשאבים הדרושים לאתחול מצב השחזור, כולל:

  • תמונת הליבה
  • התמונה של DTBO
  • מודולים של ליבה ב-lib/modules
  • הפעלה בשלב ראשון כקישור סימבולי /init -> /system/bin/init
  • אתחול בינארי בשלב שני /system/bin/init
  • קובצי fstab ספציפיים למכשיר
  • כל שאר משאבי השחזור, כולל הקובץ הבינארי של recovery

במכשירים כאלה, תצורת המוצר יורשת. מ-generic_ramdisk.mk.

הגדרת ערכי board

צריך להגדיר את הערכים הבאים למכשירים שהם לא מסוג A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

שרת ה-RAM של recovery חייב להכיל קישור סימבולי של /init -> /system/bin/init, וגם init_second_stage.recovery ב/system/bin/init. כשהמכשיר באתחול במצב השחזור, הקובץ הבינארי /system/bin/init נדרש כדי לתמוך שלב ראשון ושלב שני.

כשהמכשיר יבצע אתחול ב-recovery, התוכן של ramdisk עם recovery הוא ככה:

  • /init -> /system/bin/init (מ-Radisk recovery)
  • /system/bin/init (מ-Radisk recovery, שנבנה מ init_second_stage.recovery, ובוצעה מ-/init)

כאשר מתבצעת אתחול של המכשיר ל-Android, התוכן של vendor_boot + גנרי הערכים האלה הם:

  • /init (מ-ramdisk, שנבנה מ-init_first_stage)

העברת קובצי fstab

יש להעביר את כל fstab הקבצים שהותקנו ל-ramdisk הגנרי אל vendor_ramdisk ו-recovery ramdisk. לדוגמה, אפשר להיעזר ב שינוי.

התקנת מודולים

אפשר להתקין מודולים ספציפיים למכשיר ב-vendor_ramdisk וגם recovery ramdisk (דילוג אם אין לכם מודולים ספציפיים למכשיר להתקנה). init לא עובר לרמה הבסיסית (root). הווריאנט vendor_ramdisk של המודולים מותקן הרמה הבסיסית (root) של vendor_ramdisk. הווריאנט recovery של המודולים מותקן הרמה הבסיסית (root) של ramdisk recovery. לדוגמאות של התקנת מודולים ramdisk vendor_ramdisk ו-recovery, שבת מסוף שלב ראשון ומטא-נתונים בדיקת סיכום ביקורת (checksums).

מסוף השלב הראשון

כדי להתקין את הווריאנט vendor_ramdisk של המודולים, צריך להשתמש בגרסאות הבאות:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

כך ניתן להבטיח שההתקנה של linker, sh ו-toybox ב $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, ולאחר מכן מותקן /system/bin במסגרת vendor_ramdisk.

כדי להוסיף מודולים שנדרשים למסוף השלב הראשון (לדוגמה, adbd), מפעילים הווריאנט vendor_ramdisk של המודולים האלה על ידי העלאת תיקונים רלוונטיים ב-AOSP, ואז משתמשים בפקודה הבאה:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

הדבר מבטיח שהמודולים שצוינו יותקנו $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin

כדי להתקין את הווריאנט recovery של המודולים, צריך להחליף את vendor_ramdisk ב- recovery:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

סיכום ביקורת (checksum) של מטא-נתונים

כדי לתמוך במטא-נתונים בדיקת סיכום (checksums) במהלך הטעינה בשלב הראשון, מכשירים שלא תומכים ב-GKI מתקינים את הרדיסק של המודולים הבאים. כדי להוסיף תמיכה ב-GKI, צריך להעביר את המודולים אל $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

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

שינויים בתהליך האתחול

במהלך הפעלה ל-Android, תהליך ההפעלה לא משתנה. הלחצן vendor_boot + אמצעים גנריים דומים לתהליך האתחול הקיים, חוץ מהבדל אחד: fstab נטען מ-vendor_boot. מכיוון ש-system/bin/recovery לא קיים, first_stage_init מטפל בה כהפעלה רגילה.

בתהליך האתחול במצב שחזור (recovery), תהליך ההפעלה לא משתנה. תהליך השחזור ramdisk נטען באותו אופן כמו תהליך השחזור הקיים. הליבה נטענת מהתמונה recovery. כך יתבצע תהליך האתחול של מצב השחזור.

  1. תוכנת האתחול מופעלת ולאחר מכן מבצעת את הפעולות הבאות:

    1. דוחפת RAMdisk לשחזור אל /.
    2. מריצה את הליבה מהמחיצה recovery.

  2. הליבה טוענת את ramdisk ל-/ ולאחר מכן מבצעת את /init, שהוא קישור סימבולי אל /system/bin/init מ-Radisk recovery.

  3. השלב הראשון מתחיל ואז מבצע את הפעולות הבאות:

    1. הגדרה של IsRecoveryMode() == true ו-ForceNormalBoot() == false.
    2. טעינת מודולים של ליבה (kernel) של ספק מ-/lib/modules.
    3. מתקשרת אל DoFirstStageMount() אבל מדלגת על הטעינה כי IsRecoveryMode() == true. (במכשיר אין רפליקציות של RAM (כי /) עדיין אותו הדבר), אבל למעשה קורא ל-SetInitAvbVersionInRecovery()).
    4. התחלת שלב שני מ-/system/bin/init מ-ramdisk של recovery.

חותמות זמן של קובצי הפעלה

הקוד הבא הוא דוגמה לקובץ חותמת זמן של תמונה boot:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • בזמן ה-build, קובץ system/etc/ramdisk/build.prop מתווסף לקובץ הגנרי Ramdisk. הקובץ הזה מכיל חותמת זמן של פרטי ה-build.

  • בזמן הריצה, שלב ראשון init עותקים מה-ramdisk ל-tmpfs לפני שחרור של RAMdisk, שלב init יכול לקרוא קובץ זה כדי להגדיר מאפייני חותמת זמן של תמונה boot.