اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
حالة الجهاز
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تشير حالة الجهاز إلى مدى سهولة إعادة تحميل البرامج على الجهاز و
ما إذا كان يتم فرض عملية إثبات الملكية. حالات الجهاز هي LOCKED و
UNLOCKED. تمنع أجهزة LOCKED من إعادة تحميل برمجيًا
برامج جديدة على الجهاز، في حين تسمح أجهزة UNLOCKED بالتعديل.
عند تشغيل الجهاز، يتحقّق مشغّل الإقلاع أولاً مما إذا كان الجهاز
LOCKED أو UNLOCKED. إذا كان الجهاز
UNLOCKED، يعرض أداة تحميل البرامج الثابتة تحذيرًا للمستخدم ثم يتابع
عملية التمهيد حتى إذا لم يتم توقيع نظام التشغيل المحمَّل بواسطة جذر الثقة.
إذا كان الجهاز LOCKED، ينفِّذ برنامج الإقلاع الخطوات الواردة في التحقّق من التشغيل للتحقّق من برنامج الجهاز. لا يتم تشغيل أجهزة LOCKED إلا إذا كان
نظام التشغيل المحمَّل موقَّعًا بشكل صحيح من خلال جذر الثقة. لمزيد من التفاصيل، يُرجى الاطّلاع على
مسار التمهيد.
تغيير حالة الجهاز
لتغيير حالة جهاز، استخدِم
الأمر fastboot flashing [unlock | lock]. لحماية data
المستخدم، تؤدي جميع عمليات النقل إلى محو أقسام البيانات وطلب confirmation
المستخدم قبل حذف البيانات.
من المتوقّع أن يحدث الانتقال من UNLOCKED إلى LOCKED عندما
يشتري المستخدم جهاز تطوير مُستخدَمًا. نتيجةً لقفل الجهاز، يجب أن يثق العميل بأنّه في حالة أنشأتها الشركة المصنّعة للجهاز، ما دام لم يتم عرض أي تحذير. من المتوقّع أن يتم الانتقال من LOCKED إلى
UNLOCKED عندما يريد المطوّر إيقاف
التحقّق على الجهاز لأغراض التطوير.
جذر الثقة
جذر الثقة هو مفتاح التشفير المستخدَم لتوقيع نسخة Android
المخزّنة على الجهاز. لا يعرف سوى سازندِي
الأجهزة الجزء الخاص من جذر الثقة، ويتم استخدامه لتوقيع كل إصدار من Android مخصّص
للتوزيع. يتم تضمين الجزء العلني من جذر الثقة في الجهاز ويُخزَّن في مكان لا يمكن التلاعب به (عادةً ما يكون تخزينًا للقراءة فقط).
عند تحميل نظام التشغيل Android، يستخدم أداة تحميل التشغيل جذر الثقة للتحقّق من
الأصالة. لمزيد من التفاصيل حول هذه العملية، يُرجى الاطّلاع على مقالة التحقّق من التشغيل. قد تحتوي الأجهزة على
مشغّلات تحميل متعددة، وبالتالي قد يتم استخدام مفاتيح تشفير متعددة.
جذر ثقة يمكن للمستخدم ضبطه
يمكن للأجهزة السماح للمستخدم بشكل اختياري بضبط جذر الثقة (مثلاً، مفتاح عام). يمكن للأجهزة، وأجهزة Google Pixel على وجه التحديد، استخدام قاعدة ثقة
هذه التي يمكن للمستخدم ضبطها لميزة "التشغيل المتحقّق منه" بالإضافة إلى قاعدة ثقة
المضمّنة.
في حال تنفيذ جذر الثقة الذي يمكن للمستخدم ضبطه، يجب تنفيذه بطريقة تجعل:
- يجب تأكيد العملية بشكلٍ فعلي لضبط/محو جذر
الثقة الذي يمكن للمستخدم ضبطه.
- لا يمكن للمستخدم النهائي إلا ضبط جذر الثقة الذي يمكنه ضبطه. ولا يمكن
ضبطه في المصنع أو في أي مرحلة وسيطة قبل حصول المستخدم النهائي على
الجهاز.
- يتم تخزين جذر الثقة الذي يمكن للمستخدم ضبطه في مساحة تخزين تُثبت عدم التلاعب بها.
تعني ميزة التحقّق من التلاعب أنّه من الممكن رصد ما إذا كان نظام Android قد
تلاعب بالبيانات، على سبيل المثال، إذا تم استبدالها أو تغييرها.
- في حال ضبط موثوق به يمكن للمستخدم ضبطه، يجب أن يسمح الجهاز بتشغيل إصدار
من Android موقَّع باستخدام موثوق به مضمّن أو موثوق به يمكن للمستخدم ضبطه.
- في كل مرة يتم فيها تشغيل الجهاز باستخدام جذر الثقة الذي يمكن للمستخدم ضبطه، يجب إعلامه
بأنّ الجهاز يحمِّل إصدارًا مخصّصًا من Android. على سبيل المثال، الشاشات التحذيرية، يُرجى الاطّلاع على
LOCKED
الأجهزة التي تم ضبط مفاتيح مخصّصة لها.
من بين طرق تنفيذ ميزة "جذر الثقة" التي يمكن للمستخدم ضبطها، توفير مشاركة افتراضية
لا يمكن إعادة تحميلها أو محوها إلا عندما يكون الجهاز في حالة
UNLOCKED. تستخدم أجهزة Google Pixel 2 هذا النهج ويُطلق على القسم الافتراضي اسم avb_custom_key. تنسيق
البيانات في هذا القسم هو نتيجة الأمر
avbtool extract_public_key. في ما يلي مثال على كيفية ضبط
جذر الثقة الذي يمكن للمستخدم ضبطه:
avbtool extract_public_key --key key.pem --output pkmd.bin
fastboot flash avb_custom_key pkmd.bin
يمكن محو جذر الثقة الذي يمكن للمستخدم ضبطه من خلال إصدار:
fastboot erase avb_custom_key
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Device state\n\nThe device state indicates how freely software can be flashed to a device and\nwhether verification is enforced. Device states are `LOCKED` and\n`UNLOCKED`. `LOCKED` devices prevent you from flashing new\nsoftware to the device, whereas `UNLOCKED` devices allow\nmodification.\n\n\nWhen a device powers on, the bootloader first checks if a device is\n`LOCKED` or `UNLOCKED`. If a device is\n`UNLOCKED`, the bootloader shows the user a warning and then proceeds\nto boot even if the loaded OS isn't signed by the root of trust.\n\n\nIf the device is `LOCKED`, the bootloader goes through the steps in\n[Verifying Boot](/docs/security/features/verifiedboot/verified-boot) to verify\nthe device's software. `LOCKED` devices boot *only* if the\nloaded OS is properly signed by the root of trust. For more details, see\n[The boot flow](/docs/security/features/verifiedboot/boot-flow).\n\nChange device state\n-------------------\n\n\nTo [change a device's state](/docs/core/architecture/bootloader/locking_unlocking), use\nthe `fastboot flashing [unlock | lock]` command. To protect user\ndata, *all* state transitions wipe the data partitions and ask for user\nconfirmation before data is deleted.\n\n\nThe `UNLOCKED` to `LOCKED` transition is anticipated when\na user buys a used development device. As a result of locking the device, the\nuser should have confidence that it is in a state produced by the device\nmanufacturer, as long as there is no warning. The `LOCKED` to\n`UNLOCKED` transition is expected when a developer wishes to disable\nverification on the device for development purposes.\n\nRoot of trust\n-------------\n\n\n*Root of trust* is the cryptographic key used to sign the copy of Android\nstored on the device. The private part of the root of trust is known only to the\ndevice manufacturer and is used to sign every version of Android intended for\ndistribution. The public part of the root of trust is embedded in the device and\nis stored in a place so it can't be tampered with (typically read-only\nstorage).\n\n\nWhen it loads Android, the bootloader uses the root of trust to verify\nauthenticity. For more details on this process, see\n[Verifying Boot](/docs/security/features/verifiedboot/verified-boot). Devices may have\nmultiple boot loaders and as such multiple cryptographic keys may be in play.\n\n### User-settable root of trust\n\n\nDevices can optionally allow the user to configure the root of trust (for\nexample, a public key). Devices can, and Google Pixel devices do, use this\nuser-settable root of trust for Verified Boot in addition to the built-in\nroot of trust.\n\n\nIf user-settable root of trust is implemented, it should be done in a way such\nthat:\n\n- Physical confirmation is required to set/clear the user-settable root of trust.\n- The user-settable root of trust can only be set by the end user. It can't be set at the factory or any intermediate point before the end user gets the device.\n- The user-settable root of trust is stored in tamper-evident storage. *Tamper-evident* means that it's possible to detect if Android has tampered with the data, for example, if it has been overwritten or changed.\n- If a user-settable root of trust is set, the device should allow a version of Android signed with either the built-in root of trust or the user-settable root of trust to boot.\n- Every time the device boots using the user-settable root of trust, the user should be notified that the device is loading a custom version of Android. For example, warning screens, see [`LOCKED`\n devices with custom key set](/docs/security/features/verifiedboot/boot-flow#locked-devices-with-custom-key-set).\n\n\nOne way of implementing user-settable root of trust is to have a virtual\npartition that can only be flashed or cleared when the device is in the\n`UNLOCKED` state. The Google Pixel 2 devices use this approach and\nthe virtual partition is called `avb_custom_key`. The format of the\ndata in this partition is the output of the\n`avbtool extract_public_key` command. Here's an example of how to set\nthe user-settable root of trust: \n\n avbtool extract_public_key --key key.pem --output pkmd.bin\n fastboot flash avb_custom_key pkmd.bin\n\n\nThe user-settable root of trust can be cleared by issuing: \n\n```\nfastboot erase avb_custom_key\n```"]]
