به‌طور پیش‌فرض، اکثر دستگاه‌های Android با راه‌انداز سیستم قفل‌شده عرضه می‌شوند، به این معنی که کاربران نمی‌توانند راه‌انداز سیستم یا افرازهای دستگاه را فلاش کنند. درصورت نیاز، شما (و کاربران دستگاهی که «گزینه‌های توسعه‌دهندگان» را فعال کرده‌اند) می‌توانید قفل راه‌انداز سیستم را باز کنید تا تصاویر جدید را فلش کنید.
رفتن به راه‌انداز سیستم
برای صدور فرمان‌های fastboot، باید در حالت bootloader باشید. یکی از راه‌های انجام این کار ارسال فرمان adb adb reboot bootloader است. برخی‌از تلفن‌ها
همچنین به شما امکان می‌دهند با فشار دادن ترکیبی از کلیدها
(معمولاً کلید کاهش صدا) درحین راه‌اندازی دستگاه، آن را در حالت bootloader بازراه‌اندازی کنید.
باز کردن قفل راه‌انداز سیستم
وقتی در حالت bootloader هستید، برای باز کردن قفل bootloader و فعال کردن پارتیشن‌ها برای
بازفلش شدن، فرمان fastboot flashing unlock را در دستگاه اجرا کنید. پس‌از
تنظیم، حالت باز کردن قفل در بازراه‌اندازی‌ها حفظ می‌شود.
دستگاه‌ها باید فرمان fastboot flashing unlock را رد کنند، مگراینکه
get_unlock_ability روی 1 تنظیم شده باشد. اگر روی 0 تنظیم شود، کاربر باید به صفحه اصلی راه‌اندازی کند، منو تنظیمات > سیستم > گزینه‌های توسعه‌دهندگان را باز کند و گزینه باز کردن قفل سازنده اصلی محصول را فعال کند (که get_unlock_ability را روی 1 تنظیم می‌کند). پس‌از تنظیم، این حالت در بازراه‌اندازی‌ها و بازنشانی‌های کارخانه‌ای داده‌ها حفظ می‌شود.
وقتی فرمان fastboot flashing unlock ارسال می‌شود، دستگاه باید به کاربران پیام‌واره‌ای نشان دهد
و به آن‌ها هشدار دهد که ممکن است با تصاویر غیررسمی با مشکل مواجه شوند.
پس‌از اینکه کاربر هشدار را تأیید کرد، دستگاه باید برای جلوگیری از دسترسی غیرمجاز به داده‌ها، بازنشانی داده‌های کارخانه را انجام دهد. حتی اگر بارکننده نتواند دستگاه را به‌درستی قالب‌بندی کند، باید آن را بازنشانی کند. فقط پس‌از بازنشانی می‌توان پرچم ماندگار را تنظیم کرد تا دستگاه بتواند دوباره فلش شود.
همه RAM که قبلاً رونویسی نشده است باید درطول فرایند
fastboot flashing unlock بازنشانی شود. این اقدام از حملاتی که محتوای باقی‌مانده RAM را از راه‌اندازی قبلی می‌خوانند جلوگیری می‌کند. به‌همین ترتیب، دستگاه‌های قفل‌گشایی‌شده باید
«حافظه دسترسی تصادفی» را در هر بار راه‌اندازی پاک کنند (مگر اینکه این کار تأخیر غیرقابل‌قبولی ایجاد کند)، اما
باید ناحیه استفاده‌شده برای هسته
ramoops را دست‌نخورده باقی بگذارند.
قفل کردن راه‌انداز سیستم
برای قفل کردن bootloader و بازنشانی دستگاه، فرمان fastboot flashing lock را در دستگاه اجرا کنید. دستگاه‌های درنظر گرفته‌شده برای خرده‌فروشی باید در وضعیت قفل‌شده (با get_unlock_ability برگرداندن 0) ارسال شوند تا مطمئن شویم مهاجمان نمی‌توانند با نصب سیستم یا تصویر راه‌اندازی جدید، دستگاه را به‌خطر بیندازند.
تنظیم ویژگی‌های قفل و باز کردن قفل
دارایی ro.oem_unlock_supported باید در زمان ساخت براساس اینکه آیا دستگاه از باز کردن قفل فلاش پشتیبانی می‌کند یا نه تنظیم شود.
- اگر دستگاه از باز کردن قفل با چشمک زدن پشتیبانی می‌کند،
ro.oem_unlock_supportedرا روی1تنظیم کنید. - اگر دستگاه از قفل‌گشایی با چشمک زدن پشتیبانی نمی‌کند،
ro.oem_unlock_supportedرا روی0تنظیم کنید.
اگر دستگاه از قفل‌گشایی با چشمک زدن پشتیبانی می‌کند، bootloader باید وضعیت قفل را با تنظیم متغیر خط فرمان هسته
androidboot.flash.locked روی 1 درصورت قفل بودن یا روی 0 درصورت قفل نبودن نشان دهد. این متغیر
باید در bootconfig به‌جای خط فرمان هسته در Android 12 تنظیم شود.
برای دستگاه‌هایی که از dm-verity پشتیبانی می‌کنند،
از ro.boot.verifiedbootstate برای تنظیم مقدار ro.boot.flash.locked روی
0 استفاده کنید؛ این کار قفل bootloader را درصورتی‌که وضعیت راه‌اندازی درستی‌سنجی‌شده نارنجی باشد باز می‌کند.
محافظت از بخش‌های مهم
دستگاه‌ها باید از قفل کردن و باز کردن قفل بخش‌های حیاتی پشتیبانی کنند، که به‌عنوان هر چیزی که برای راه‌اندازی دستگاه در bootloader لازم است تعریف می‌شود. چنین بخش‌هایی ممکن است شامل فیوزها، پارتیشن‌های مجازی برای هاب حسگر، بوت‌لودر مرحله اول، و غیره باشد. برای قفل کردن بخش‌های حیاتی، باید از مکانیزمی استفاده کنید که از تغییر عمدی هر بخش حیاتی توسط کدی (هسته، روگرفت بازیابی، کد OTA، و غیره) که در دستگاه درحال اجرا است جلوگیری کند. اگر دستگاه در وضعیت قفل بحرانی باشد، OTA نباید بتواند بخش‌های بحرانی را به‌روز کند.
انتقال از حالت قفل به حالت قفل‌بازشده باید مستلزم تعامل فیزیکی با دستگاه باشد. این تعامل شبیه به اثرات اجرای فرمان fastboot flashing unlock است اما کاربر باید دکمه فیزیکی روی دستگاه را فشار دهد. دستگاه‌ها نباید اجازه دهند که به‌طور برنامه‌نویسی‌شده
از lock_critical به unlock_critical بدون تعامل فیزیکی
منتقل شوند، و دستگاه‌ها نباید در حالت unlock_critical عرضه شوند.