自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
设备状态
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
设备状态指明了能够以多大的自由度将软件刷写到设备上，以及是否强制执行验证。设备状态为 LOCKED 和 UNLOCKED。状态为 LOCKED 的设备禁止您将新软件刷写到设备上，而状态为 UNLOCKED 的设备允许您进行修改。
当设备开机后，引导加载程序会先检查设备状态是 LOCKED 还是 UNLOCKED。如果设备状态为 UNLOCKED，引导加载程序会向用户显示警告，然后继续启动，即使加载的操作系统并非由信任根签名也是如此。
如果设备状态为 LOCKED，引导加载程序会完成验证启动中的步骤，以验证该设备的软件。只有加载的操作系统由信任根正确签名后，状态为 LOCKED 的设备才会启动。如需了解详情，请参阅启动流程。
更改设备状态
如需更改设备状态，请使用 fastboot flashing [unlock | lock] 命令。为了保护用户数据，只要设备状态发生了变化，都会先擦除 data 分区中的数据，并会在删除数据之前要求用户确认。
用户购买二手开发设备后，应将设备状态从 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 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-27。
[null,null,["最后更新时间 (UTC)：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```"]]
