对于要启动的 Android 版本中包含的所有可执行代码和数据，启动时验证均要求在使用前以加密形式对其进行验证，其中包括内核（从 boot 分区加载）、设备树（从 dtbo 分区加载）、system 分区和 vendor 分区等。
对于 boot 和 dtbo 这类仅读取一次的小分区，通常是通过将整个内容加载到内存中，然后计算其哈希值来进行验证。接下来，系统会将计算出的哈希值与预期哈希值进行比较。如果值不一致，则 Android 将无法加载。如需了解详情，请参阅启动流程。
内存装不下的较大分区（如文件系统）可能会使用哈希树；在这种情况下，验证流程会在将数据加载到内存的过程中持续进行。对于这种情况，系统会在运行时计算哈希树的根哈希值，并将其与预期根哈希值进行比较。Android 包含用于验证较大分区的 dm-verity 驱动程序。如果在某个时刻计算出的根哈希值与预期根哈希值不一致，系统便不会使用相应数据，而且 Android 会出现错误。如需了解详情，请参阅 dm-verity 损坏。
预期哈希值通常存储在每个经过验证的分区的末尾或开头、专用分区中，或同时存储在以上两个位置。最重要的是，这些哈希值已由信任根以直接或间接的方式签名。举个例子，AVB 实现就支持这两种方式；如需了解详情，请参阅 Android 启动时验证。
回滚保护
即使更新流程完全安全，攻击者仍可能会利用非永久性 Android 内核漏洞来手动安装更易受攻击的旧版 Android 系统，重新启动进入易受攻击的版本，然后通过该 Android 版本来安装永久性漏洞。在这种情况下，攻击者可通过这种漏洞永久拥有相应设备，并可以执行任何操作（包括停用更新）。
防范这类攻击的保护措施称为“回滚保护”。“回滚保护”通常通过以下方式实现：使用防篡改的存储空间来记录最新的 Android 版本，并在 Android 版本低于记录的版本时拒绝启动 Android。系统通常会针对每个分区来跟踪版本。
如需详细了解 AVB 处理回滚保护的方式，请参阅 AVB README。
处理验证错误
验证在启动时（例如，如果在 boot 分区上计算出的哈希值与预期哈希值不一致）或运行时（例如，如果 dm-verity 在 system 分区上遇到验证错误）都可能会失败。如果验证在启动时失败，设备则无法启动，而且最终用户需要执行相关步骤才能恢复设备使用。
如果验证在运行时失败，恢复流程就会更复杂一些。如果设备使用的是 dm-verity，则应在 restart 模式下进行配置。在 restart 模式下，如果遇到验证错误，设备会立即重启，并设置特定标记以表明错误原因。引导加载程序应该会注意到该标记，并将 dm-verity 切换为使用 I/O 错误 (eio) 模式并保持该模式，直到安装新的更新为止。
在 eio 模式下启动时，设备会显示错误屏幕，以通知用户系统已检测到损坏，而且设备可能无法正常使用。该屏幕会持续显示，直到用户将其关闭为止。在 eio 模式下，如果遇到验证错误，dm-verity 驱动程序不会重启设备，而是会返回 EIO 错误，并且相应的应用需要处理该错误。
这样做的目的是，让系统更新程序能够正常运行（以便安装不含损坏错误的新操作系统），或者让用户能够从设备上获取尽可能多的数据。安装新的操作系统后，引导加载程序会注意到新安装的操作系统，并切换回 restart 模式。