اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
نظرة عامة على برنامج الإقلاع
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
برنامج الإقلاع هو صورة مملوكة للمورّد مسؤولة عن تشغيل
النواة على الجهاز. يحمي أداة تحميل البرامج حالة الجهاز، وهي مسؤولة عن بدء تشغيل بيئة التنفيذ الموثوقة (TEE) وربط جذر الثقة. يتحقّق مشغّل الإقلاع أيضًا من سلامة قسمَي boot وrecovery قبل نقل التنفيذ إلى النواة.
مثال على مسار برنامج الإقلاع
في ما يلي مثال على مسار أداة تحميل البرامج:
تحميل الذاكرة وإعدادها
عليك إثبات ملكية الجهاز وفقًا لخطوات التشغيل المتحقَّق منه.
تحقَّق من أقسام التمهيد، بما في ذلك boot وdtbo وinit_boot و
recovery، وفقًا لخطوات ميزة "التشغيل المتحقّق منه". كجزء من هذه الخطوة، تحقَّق من إصدار
عنوان صورة التمهيد
وحلِّل العنوان وفقًا لذلك.
في حال استخدام التحديثات A/B، حدِّد الشريحة الحالية لبدء التشغيل.
تحديد ما إذا كان يجب تشغيل وضع الاسترداد لمزيد من
المعلومات، يُرجى الاطّلاع على مقالة
إتاحة التحديثات عبر الهواء.
تحميل صور التشغيل، مثل boot.img وvendor_boot.img
init_boot.img وصور التشغيل الأخرى الخاصة بالمورّدين تحتوي صور التمهيد هذه
على صور kernel وramdisk.
تحميل النواة في الذاكرة كملف ثنائي مضغوط قابل للتنفيذ الذاتي
يزيل نواة النظام الضغط عن نفسها وتبدأ في التنفيذ في الذاكرة.
حمِّل أقراص RAM وقسم bootconfig في الذاكرة
لإنشاء initramfs.
ميزات إضافية متعلقة ببرنامج التمهيد
في ما يلي قائمة بالميزات الإضافية المرتبطة ببرنامج التمهيد التي يمكنك
تنفيذها:
تداخل شجرة الأجهزة (DTO)
تتيح الصورة المتراكبة لشجرة الجهاز لمسؤول التمهيد
إتاحة إعدادات الأجهزة المختلفة. يتم تجميع ملف DTO في ملف device
tree blob (DTB) الذي يستخدمه مشغّل الإقلاع.
توزيع عشوائي للعنوان الافتراضي لصورة النواة: يتيح أداة تحميل البرامج التمهيدية
تعشُّب العنوان الافتراضي الذي يتم تحميل صورة النواة عليه. لتحديد العنوان بشكل عشوائي، اضبط RANDOMIZE_BASE على true في إعدادات kernel.
يجب أن يقدّم برنامج الإقلاع عنصرًا عشوائيًا من خلال تمرير قيمة u64 عشوائية في ملف node
/chosen/kaslr-seed في شجرة الجهاز.
التشغيل المتحقّق منه: تتيح ميزة التشغيل المتحقّق منه
لمشغِّل الإقلاع التأكّد من أنّ جميع الرموز البرمجية التي يتم تنفيذها مصدرها موثوق به.
إعدادات التشغيل
تتوفّر إعدادات التمهيد
في الإصدار Android 12 والإصدارات الأحدث، وهي آلية لنقل
تفاصيل الضبط من الإصدار ومُشغِّل الإقلاع إلى نظام التشغيل.
قبل الإصدار 12 من Android، كان يتم استخدام مَعلمات سطر أوامر kernel التي تحتوي على البادئة
androidboot.
التحديثات عبر شبكة غير سلكية (OTA) يمكن لأجهزة Android في الميدان تلقّي تحديثات عبر شبكة غير سلكيّة (OTA) و
تثبيتها على النظام وبرامج التطبيقات و
قواعد المنطقة الزمنية. لهذه الميزة تأثيرات على تنفيذ bootloader. للحصول على معلومات عامة عن التحديثات عبر الهواء، يُرجى الاطّلاع على مقالة التحديثات عبر الهواء. للاطّلاع على تفاصيل تنفيذ التحديثات عبر الهواء الخاصة بوظيفة أداة تحميل البرامج الثابتة، يُرجى الاطّلاع على مقالة إتاحة التحديثات عبر الهواء.
ربط الإصدار:
تؤدي عملية ربط الإصدار إلى ربط
مفاتيح الأمان بنظام التشغيل ومستوى تصحيح الأمان. يضمن ربط الإصدار
أنّه لا يمكن للمهاجم الذي يكتشف ثغرة أمنية في إصدار قديم من
النظام أو برنامج TEE الرجوع بالجهاز إلى الإصدار المُعَدَّل
واستخدام المفاتيح التي تم إنشاؤها باستخدام الإصدار الأحدث. يجب أن يقدّم برنامج الإقلاع معلومات معيّنة
لتفعيل ربط الإصدار. لمزيد من المعلومات، يُرجى الاطّلاع على
معلومات الإصدار في سمات AVB.
سطر أوامر النواة
اربط سطر أوامر kernel من المواقع التالية:
سطر أوامر برنامج الإقلاع: مجموعة من المَعلمات الثابتة والديناميكية التي يحدّدها
برنامج الإقلاع
شجرة الأجهزة: من عقدة chosen/bootargs
defconfig: من CONFIG_CMDLINE
boot.img: من سطر الأوامر (للعيوب والحجم، يُرجى الرجوع إلى
system/core/mkbootimg/bootimg.h
اعتبارًا من Android 12، بالنسبة إلى مَعلمات androidboot.* التي
علينا تمريرها إلى مساحة المستخدم في Android، يمكننا استخدام
bootconfig بدلاً
من سطر أوامر kernel.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Bootloader overview\n\nA *bootloader* is a vendor-proprietary image responsible for bringing up the\nkernel on a device. The bootloader guards the device state and is responsible\nfor initializing the [Trusted Execution Environment (TEE)](/docs/security/features/trusty)\nand binding its root of trust. The bootloader also verifies the integrity of the\n`boot` and `recovery` partitions before moving execution to the kernel.\n\nExample bootloader flow\n-----------------------\n\nHere's an example bootloader flow:\n\n1. Load and initialize memory.\n\n2. Verify the device according to [Verified Boot flow](/docs/security/features/verifiedboot).\n\n3. Verify the boot partitions, including `boot`, `dtbo`, `init_boot`, and\n `recovery`, according to the Verified Boot flow. As part of this step, check the\n [boot image header](/docs/core/architecture/bootloader/boot-image-header)\n version and parse the header accordingly.\n\n4. If [A/B updates](/docs/core/ota/ab) are used, determine the current slot to\n boot.\n\n5. Determine if recovery mode should be booted. For more\n information, see\n [Supporting OTA Updates](/docs/core/architecture/bootloader/updating).\n\n6. Load the boot images, such as `boot.img`, `vendor_boot.img`,\n `init_boot.img`, and other proprietary vendor boot images. These boot images\n contain the kernel and ramdisk images.\n\n 1. Load the kernel into memory as a self-executable compressed\n binary. The kernel decompresses itself and starts executing into memory.\n\n 2. Load ramdisks and the bootconfig section into memory\n to create `initramfs`.\n\nAdditional bootloader-related features\n--------------------------------------\n\nFollowing is a list of additional bootloader-related features that you can\nimplement:\n\n- *Device tree overlay (DTO).*\n A [device tree overlay](/docs/core/architecture/dto) lets the bootloader to\n support different hardware configurations. A DTO is compiled into a *device\n tree blob (DTB)* which is used by the bootloader.\n\n- *Kernel image virtual address randomization.* The bootloader supports\n randomizing the virtual address at which the kernel image is loaded. To\n randomize the address, set `RANDOMIZE_BASE` to `true` in the kernel config.\n The bootloader must provide entropy by passing a random u64 value in the\n `/chosen/kaslr-seed` device tree node.\n\n- *Verified Boot.* [Verified Boot](/docs/security/features/verifiedboot) lets\n the bootloader to ensure all executed code comes from a trusted source.\n\n- *Boot config.*\n [Boot config](/docs/core/architecture/bootloader/implementing-bootconfig)\n is available in Android 12 and higher and is a mechanism for passing\n configuration details from the build and bootloader to the operating system.\n Prior to Android 12, kernel command-line parameters with the prefix of\n `androidboot` are used.\n\n- *Over-the-air (OTA) updates.* Android devices in the field can receive and\n install OTA updates to the system, app software, and\n time zone rules. This feature has implications on your bootloader\n implementation. For general information on OTA, see\n [OTA updates](/docs/core/ota). For bootloader-specific OTA implementation\n details, see\n [Supporting OTA updates](/docs/core/architecture/bootloader/updating).\n\n- *Version binding* .\n [Version binding](/docs/security/features/keystore/version-binding) binds\n security keys to the operating system and patch level version. Version binding\n ensures that an attacker who discovers a weakness in an old version of the\n system or the TEE software can't roll a device back to the vulnerable version\n and use keys created with the newer version. The bootloader must provide certain\n information to support version binding. For further information, see\n [Version information in AVB properties](/docs/core/architecture/bootloader/version-info-avb).\n\nKernel command line\n-------------------\n\nConcatenate the kernel command line from the following locations:\n\n- Bootloader command line: set of static and dynamic parameters determined by\n the bootloader\n\n- Device tree: from the `chosen/bootargs` node\n\n- `defconfig`: from `CONFIG_CMDLINE`\n\n- `boot.img`: from the command line (for offsets and sized, refer to\n [`system/core/mkbootimg/bootimg.h`](https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/android16-release/include/bootimg/bootimg.h)\n\nAs of Android 12, for `androidboot.*` parameters that\nwe need to pass to Android userspace, we can use\n[bootconfig](/docs/core/architecture/bootloader/implementing-bootconfig) instead\nof the kernel command line."]]
