Android Q开关AVB remount分区,导致OTA升级super分区resize fail

  1. 问题平台:Android Q,无AB update,开启dynamic partition,机器专门做OTA升级压测,同一个OTA包在多个机器上升级,仅这台机器升级失败,其他机器升级没问题,且这台机器能正常开机和操作。
  2. 看OTA升级的log,异常为扩展system分区失败导致
[liblp]Partition vendor will resize from 0 bytes to 217198592 bytes
[liblp]Not enough free space to expand partition: system
Failed to resize partition system to size 1719984128.
script aborted: assert failed: update_dynamic_partitions(package_extract_file("dynamic_partitions_op_list"))
E:Error in @/cache/recovery/block.map (status 7)
  1. 对比正常的log,分区大小是合法的,问题也就进一步证明与机器关联
[liblp]Partition vendor will resize from 0 bytes to 217198592 bytes
[liblp]Partition system will resize from 0 bytes to 1719984128 bytes
[liblp]Updated logical partition table at slot 0 on device /dev/block/by-name/super
  1. 在异常和正常的机器上执行lpdump,确认异常的机器多了一个scratch分区
------------------------
  Name: scratch
  Group: default
  Attributes: none
  Extents:
    0 .. 559463 linear super 3639448
------------------------
  1. 从Google信息看,adb remount时,就会创建这样的一个分区,
    https://source.android.google.cn/devices/tech/ota/dynamic_partitions/implement?hl=zh-cn#adb-remount

  2. 通过如下代码可以确认OTA不会删除scratch分区(属于default group),继而导致异常
    default分区的特殊处理

  3. 综上,操作上要复现问题,就是关avb,并adb remount_all之后操作system或vendor分区,填足够多的数据,然后在未关闭AVB的情况,直接进行OTA升级,就能够复现问题。

  4. 恢复的方法也就是如下,操作完毕之后,重新使能AVB就可。
    adb disable-verity -> adb remount(创建scratch分区用于存放文件)
    -> adb enable-verity(删除scratch分区,恢复系统镜像)

  5. 附上正常异常的lpdump命令执行结果

异常的
Metadata version: 10.0
Metadata size: 516 bytes
Metadata max size: 65536 bytes
Metadata slot count: 2
Partition table:
------------------------
  Name: scratch
  Group: default
  Attributes: none
  Extents:
    0 .. 559463 linear super 3639448
------------------------
  Name: vendor
  Group: group_oem
  Attributes: readonly
  Extents:
    0 .. 424215 linear super 2048
------------------------
  Name: system
  Group: group_oem
  Attributes: readonly
  Extents:
    0 .. 3185727 linear super 426264
------------------------
Block device table:
------------------------
  Partition name: super
  First sector: 2048
  Size: 2150629376 bytes
  Flags: none
------------------------
Group table:
------------------------
  Name: default
  Maximum size: 0 bytes
  Flags: none
------------------------
  Name: group_oem
  Maximum size: 2146435072 bytes
  Flags: none
------------------------

正常的
/cache # lpdump                                                         
Metadata version: 10.0
Metadata size: 440 bytes
Metadata max size: 65536 bytes
Metadata slot count: 2
Partition table:
------------------------
  Name: system
  Group: group_oem
  Attributes: readonly
  Extents:
    0 .. 3185727 linear super 2048
------------------------
  Name: vendor
  Group: group_oem
  Attributes: readonly
  Extents:
    0 .. 424215 linear super 3188736
------------------------
Block device table:
------------------------
  Partition name: super
  First sector: 2048
  Size: 2150629376 bytes
  Flags: none
------------------------
Group table:
------------------------
  Name: default
  Maximum size: 0 bytes
  Flags: none
------------------------
  Name: group_oem
  Maximum size: 2146435072 bytes
  Flags: none
------------------------
  • 2
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Android AVB (Android Verified Boot) 是安卓系统中的一种安全功能,目的是确保用户设备上的操作系统和应用程序未被篡改。它使用了基于密钥的验证方法,以验证设备上的固件和启动程序的完整性和可靠性。 Android AVB的工作原理是,在设备启动时,固件和启动程序会被验证。首先,设备会检查固件和启动程序的数字签名,以确保它们是由受信任的开发者签名的。如果签名验证通过,则设备会继续启动,否则会发出警告或者拒绝启动。 除了验证签名外,Android AVB还会检查系统分区的哈希值是否与预期的哈希值匹配。这些哈希值是在设备正常运行时生成的,并被记录在一个被称为AVB表的数据结构中。如果发现系统分区的哈希值与预期的哈希值不匹配,设备将中断启动并显示一条警告信息。 通过使用Android AVB,设备能够有效防止来自未经授权的来源的操作系统和启动程序的篡改。这增加了设备的安全性,使用户能够放心使用设备,而不担心潜在的恶意软件或未经授权的更改。 总之,Android AVB是安卓系统中的一种安全功能,它通过验证数字签名和哈希值来确保设备上的操作系统和启动程序的完整性。它帮助防止未经授权的篡改,提高了设备的安全性。 ### 回答2: Android AVBAndroid Verified Boot)是安卓系统中的一种验证引导机制,它通过在设备启动过程中验证系统的完整性,防止未经授权的修改及恶意软件损害系统安全。以下是关于Android AVB的一些要点。 首先,Android AVB使用数字签名验证系统引导映像的完整性。在设备启动时,引导加载程序(Bootloader)会验证引导映像的签名,只有通过数字证书签名的映像才能被加载,这样可以确保系统引导过程没有受到非法篡改。 其次,Android AVB启用分区级别的验证,每个分区的映像都需要通过数字签名进行验证。这使得系统分区、供应商分区和OEM分区等可以被独立验证,并且可以防止未经授权修改。 另外,Android AVB还使用了完整性元数据(Integrity Metadata)来确保系统分区的数据安全。完整性元数据存储了每个分区的哈希值和签名信息,设备启动时会加载并验证这些元数据,以确保分区的数据没有被篡改。 最后,Android AVB还可以在设备上使用强制加密(Force Encryption)来确保用户数据的密钥只能被正确验证的引导映像解锁。这可以防止未经授权的访问或修改用户数据。 总的来说,Android AVB通过数字签名、分区级别的验证以及完整性元数据等机制,确保了安卓设备系统引导过程的完整性和安全性,并且防止了未经授权的修改和恶意软件的攻击。 ### 回答3: Android AVB是指Android Verified Boot的缩写,是一种用于验证和保护Android设备的引导过程的安全机制。它的目标是检测和阻止未经授权的软件从设备的启动过程中加载和运行。 Android Verified Boot通过使用数字签名和哈希算法来验证引导镜像的完整性和真实性。在设备启动的过程中,它会使用设备制造商预装的公钥来验证引导镜像的数字签名是否有效,并且只有当验证通过时才会加载和运行系统。这样可以防止未经授权的软件或者恶意代码被插入到引导过程中,提高了设备的安全性。 此外,Android AVB还可以更容易地检测到设备的Root状态和未经授权的修改。通过保护系统分区和检测分区是否已被修改,它可以提供更可靠的保护机制,防止未经授权的软件或者恶意代码对设备进行篡改。这可以帮助用户避免安全漏洞和数据泄露。 总之,Android AVB是一种用于验证和保护设备启动过程的安全机制,通过验证引导镜像的完整性和真实性,检测设备的Root状态和分区是否被修改,提高了Android设备的安全性。这有助于保护用户的个人数据和设备免受恶意软件和未经授权的修改的威胁。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值