2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
デバイスの状態
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
デバイスの状態は、ソフトウェアがデバイスにどの程度自由にフラッシュでき、検証を適用できるかを示します。デバイスの状態には LOCKED と UNLOCKED があります。LOCKED のデバイスでは新しいソフトウェアをデバイスにフラッシュできませんが、UNLOCKED のデバイスでは変更が可能です。
デバイスの電源がオンになると、ブートローダーはまずデバイスが LOCKED と UNLOCKED のどちらであるかを確認します。デバイスが UNLOCKED の場合、ブートローダーはユーザーに警告を表示します。その後、読み込まれた OS がルート オブ トラストにより署名されていなくても、起動を実行します。
デバイスが LOCKED の場合、ブートローダーはブートの検証の手順に従ってデバイスのソフトウェアを検証します。LOCKED デバイスは、読み込まれた OS がルート オブ トラストにより適切に署名されている場合のみ起動します。詳細については、起動フローをご覧ください。
デバイスの状態の変更
デバイスの状態を変更するには、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```"]]
