2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
ブートローダーのロックとロック解除
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ほとんどの Android デバイスはデフォルトで、ブートローダーがロックされた状態で出荷されるため、ユーザーはブートローダーまたはデバイス パーティションをフラッシュできません。必要に応じて、（開発者向けオプションを有効にしているデバイス ユーザーは）ブートローダーをロック解除して、新しいイメージをフラッシュできます。
ブートローダーを開く
fastboot コマンドを発行するには、ブートローダー モードを開く必要があります。その方法の 1 つは、adb コマンド adb reboot bootloader を送信します。一部のスマートフォンでは、デバイスの起動中に特定のキーの組み合わせ（通常は音量小）を押すことで、ブートローダー モードで再起動することもできます。
ブートローダーのロックを解除する
ブートローダー モードを開いた後で、ブートローダーをロック解除してパーティションの再フラッシュを有効にするには、デバイスで fastboot flashing unlock コマンドを実行します。設定すると、再起動を行ってもロック解除モードが維持されます。
get_unlock_ability が 1 に設定されている場合を除き、fastboot flashing unlock コマンドはデバイスで拒否されます。0 に設定されている場合、ユーザーはホーム画面に移動し、[設定] > [システム] > [開発者向けオプション] メニューを開き、[OEM ロック解除] オプションを有効にする必要があります（これにより get_unlock_ability が 1 に設定されます）。設定すると、再起動やデータの初期化を行ってもモードが維持されます。
fastboot flashing unlock コマンドが送信されると、非公式のイメージによる問題が発生する可能性についての警告が表示されます。ユーザーが警告を確認した後、デバイスでは不正なデータアクセスを防ぐためにデータの初期化が行われます。ブートローダーは、デバイスを正しく再フォーマットできない場合でも、デバイスの初期化を行います。初期化を行った後にのみ、永続フラグを設定してデバイスの再フラッシュが可能になります。
まだ上書きされていない RAM はすべて fastboot flashing unlock プロセスで初期化されます。これにより、以前の起動から残りの RAM の内容を読み取る攻撃を防止できます。同様に、ロック解除されたデバイスでは、許容できない遅延が生じる場合を除き、毎回起動時に RAM を消去する必要があります。ただし、カーネルの ramoops に使用する領域は残す必要があります。
ブートローダーをロックする
ブートローダーをロックしてデバイスを初期化するには、デバイスで fastboot flashing lock コマンドを実行します。販売用のデバイスは、新しいシステムやブートイメージをインストールしようとする攻撃者によりデバイスが侵害されるのを確実に防ぐために、ロック状態（get_unlock_ability で 0 が返される）で出荷されています。
ロックとロック解除のプロパティを設定する
ro.oem_unlock_supported プロパティは、デバイスがロック解除のフラッシュに対応するかどうかに基づいてビルド時に設定する必要があります。
- デバイスがロック解除のフラッシュに対応する場合は、
ro.oem_unlock_supported を 1 に設定します。
- デバイスがロック解除のフラッシュに対応しない場合は、
ro.oem_unlock_supported を 0 に設定します。
デバイスがロック解除のフラッシュに対応している場合、ブートローダーはカーネル コマンドライン変数 androidboot.flash.locked を 1（ロックされている場合）、または 0（ロック解除されている場合）に設定することでロック状態を表します。この変数は、Android 12 のカーネル コマンドラインではなく、bootconfig で設定する必要があります。
dm-verity に対応しているデバイスの場合、ro.boot.verifiedbootstate を使用して ro.boot.flash.locked の値を 0 に設定します。これにより、確認付きブートの状態がオレンジであれば、ブートローダーがロック解除されます。
クリティカル セクションを保護する
デバイスは、クリティカル セクション（デバイスをブートローダーにブートするために必要なものとして定義）のロックとロック解除に対応している必要があります。このようなセクションとしては、ヒューズ、センサーハブの仮想パーティション、第 1 ステージのブートローダーなどが挙げられます。クリティカル セクションをロックするには、デバイスで実行されているコード（カーネル、リカバリ イメージ、OTA コードなど）がクリティカル セクションを意図的に変更できないようにするメカニズムを使用する必要があります。デバイスがロック クリティカル状態の場合、OTA はクリティカル セクションのアップデートに失敗します。
ロック状態からロック解除状態に移行するには、デバイスを物理的に操作する必要があります。この操作は、fastboot flashing unlock コマンドを実行した場合と似ていますが、ユーザーがデバイスの物理ボタンを押す必要があります。デバイスは、物理的な操作なしでプログラムによって lock critical から unlock critical に移行できないようにする必要があります。また、デバイスは出荷時に unlock critical 状態にしないでください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 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-03-26 UTC。"],[],[],null,["# Lock and unlock the bootloader\n\nBy default, most Android devices ship with a locked bootloader, meaning that\nusers can't flash the bootloader or device partitions. If needed, you (and\ndevice users with Developer options enabled) can unlock the bootloader to flash\nnew images.\n\nGet into the bootloader\n-----------------------\n\nTo issue `fastboot` commands, you must be in the bootloader mode. One\nway to do this is to send the adb command `adb reboot bootloader`. Some phones\nalso allow you to reboot into the bootloader by pressing a key combination\n(commonly volume down) while booting the device.\n\nUnlock the bootloader\n---------------------\n\nOnce in the bootloader mode, to unlock the bootloader and enable partitions to\nbe reflashed, run the `fastboot flashing unlock` command on the device. After\nsetting, the unlock mode persists across reboots.\n\nDevices should deny the `fastboot flashing unlock` command unless the\n`get_unlock_ability` is set to `1`. If set to `0`, the user needs to boot to the\nhome screen, open the *Settings \\\u003e System \\\u003e Developer options* menu\nand enable the **OEM unlocking** option (which sets the `get_unlock_ability`\nto `1`). After setting, this mode persists across reboots and factory data\nresets.\n\nWhen the `fastboot flashing unlock` command is sent, the device should prompt\nusers to warn them that they might encounter problems with unofficial images.\nAfter the user acknowledges the warning, the device should perform a factory\ndata reset to prevent unauthorized data access. The bootloader should reset the\ndevice even if it can't reformat it properly. Only after a reset can the\npersistent flag be set so that the device can be reflashed.\n\nAll RAM not already overwritten should be reset during the\n`fastboot flashing unlock` process. This measure prevents attacks that read\nleftover RAM contents from the previous boot. Similarly, unlocked devices should\nclear RAM at every boot (unless this creates an unacceptable delay), but\nshould leave the region used for the kernel's\n[`ramoops`](https://www.kernel.org/doc/html/v4.12/admin-guide/ramoops.html).\n\nLock the bootloader\n-------------------\n\nTo lock the bootloader and reset the device, run the `fastboot flashing lock`\ncommand on the device. Devices intended for retail should be shipped in the\nlocked state (with `get_unlock_ability` returning `0`) to ensure that attackers\ncan't compromise the device by installing a new system or boot image.\n\nSet lock and unlock properties\n------------------------------\n\nThe `ro.oem_unlock_supported` property should be set at build time based on\nwhether the device supports flashing unlock.\n\n- If the device supports flashing unlock, set `ro.oem_unlock_supported` to `1`.\n- If the device doesn't support flashing unlock, set `ro.oem_unlock_supported` to `0`.\n\nIf the device supports flashing unlock, then the bootloader should indicate the\nlock status by setting the kernel command line variable\n`androidboot.flash.locked` to `1` if locked or to `0` if unlocked. This variable\nmust be set in bootconfig instead of in the kernel command line in Android 12.\n\nFor devices that support [dm-verity](/docs/security/features/verifiedboot/dm-verity),\nuse `ro.boot.verifiedbootstate` to set the value of `ro.boot.flash.locked` to\n`0`; this unlocks the bootloader if the verified boot state is orange.\n\nProtect critical sections\n-------------------------\n\nDevices should support the locking and unlocking of critical sections, which are\ndefined as whatever is needed to boot the device into the bootloader. Such\nsections might include fuses, virtual partitions for a sensor hub, first-stage\nbootloader, and more. To lock critical sections, you must use a mechanism that\nprevents code (kernel, recovery image, OTA code, etc.) that is running on the\ndevice from deliberately modifying any critical section. OTAs should fail to\nupdate critical sections if the device is in lock critical state.\n\nTransitioning from locked to unlocked state should require a physical\ninteraction with the device. This interaction is similar to what the effects of\nrunning the `fastboot flashing unlock` command but requires the user to press\na physical button on the device. Devices shouldn't allow programmatically\ntransitioning from `lock critical` to `unlock critical` without physical\ninteraction, and devices shouldn't ship in the `unlock critical` state."]]
