ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
สถานะของอุปกรณ์
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
สถานะอุปกรณ์จะระบุระดับความอิสระในการแฟลชซอฟต์แวร์ลงในอุปกรณ์และระบุว่ามีการบังคับใช้การยืนยันหรือไม่ สถานะของอุปกรณ์คือ LOCKED และ
UNLOCKED อุปกรณ์ LOCKED ป้องกันไม่ให้คุณแฟลชซอฟต์แวร์ใหม่ลงในอุปกรณ์ ส่วนอุปกรณ์ UNLOCKED อนุญาตให้แก้ไข
เมื่ออุปกรณ์เปิดเครื่อง โปรแกรมโหลดบูตจะตรวจสอบก่อนว่าอุปกรณ์เป็นLOCKEDหรือUNLOCKED หากอุปกรณ์มีสถานะUNLOCKED โปรแกรมโหลดบูตจะแสดงคำเตือนให้ผู้ใช้เห็น แล้วดำเนินการบูตต่อแม้ว่าระบบปฏิบัติการที่โหลดมาจะไม่ได้ลงนามโดยรูทของความน่าเชื่อถือก็ตาม
หากอุปกรณ์เป็น LOCKED บูตโหลดเดอร์จะดำเนินการตามขั้นตอนในการยืนยันการบูตเพื่อยืนยันซอฟต์แวร์ของอุปกรณ์ อุปกรณ์ LOCKED จะบูตเฉพาะในกรณีที่ระบบปฏิบัติการที่โหลดลงได้รับการลงนามอย่างถูกต้องโดยรูทของความน่าเชื่อถือ โปรดดูรายละเอียดเพิ่มเติมที่หัวข้อขั้นตอนการบูต
เปลี่ยนสถานะอุปกรณ์
หากต้องการเปลี่ยนสถานะของอุปกรณ์ ให้ใช้คำสั่ง fastboot flashing [unlock | lock] การเปลี่ยนสถานะทั้งหมดจะล้างพาร์ติชันข้อมูลและขอการยืนยันจากผู้ใช้ก่อนที่จะลบข้อมูลออก เพื่อปกป้องข้อมูลผู้ใช้
การเปลี่ยนจาก 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 UTC
[[["เข้าใจง่าย","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 UTC"],[],[],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```"]]
