3.0 KiB
3.0 KiB
Phase 7F – Recovery inventory
Summary
This build has A/B update infrastructure and Android recovery coordination, but the exact user-accessible cold-boot recovery method is not proven. There is no separate recovery partition in the complete 63-partition inventory.
Device-specific evidence
| Item | Finding | Classification |
|---|---|---|
Separate recovery partition |
absent from full p1–p63 layout; fstab recovery line commented | disproved |
| A/B layout | static A/B, slot A active, slotselect; no super |
confirmed |
| Recovery-in-boot possibility | standard A/B design can place recovery ramdisk in boot | plausible, content not inspected |
recovery executable |
not present under /system/bin in normal boot |
confirmed absence at that path |
fastbootd / bootctl |
not present under /system/bin |
confirmed absence at that path |
| Recovery framework service | recovery and system_update services present |
confirmed |
| BCB helpers | uncrypt, setup-bcb, clear-bcb definitions in uncrypt.rc |
confirmed definitions |
| Recovery persist/refresh | AOSP init scripts and helpers present | confirmed |
| OTA cert store | /system/etc/security/otacerts.zip |
confirmed |
| Vendor recovery hook | vendor_flash_recovery.rc references /vendor/bin/install-recovery.sh |
definition confirmed; binary absent in mounted vendor |
| Factory image | A/B factory SquashFS, AVB/slotselect, not mounted normally |
confirmed partition/path; contents unknown |
| Factory service | /factory/bin/factory_service, oneshot, vold domain, /tmp/factory |
init definition only; runtime/entry unknown |
USB .upg updater |
Settings scans /upgrades/autorun*.upg |
confirmed normal-Android USB OTA path |
| Recovery sideload | no local evidence | unknown |
| ADB in recovery | no local evidence | unknown |
| Physical key combination | no local resource found | unknown |
| Emergency upgrade | no confirmed trigger/protocol | unknown |
| Public Fastboot/unlock | no evidence; device locked/green | unknown/unavailable in normal boot |
| UART | console=ttyMT0,115200n1; Android console is UID shell/domain shell; forbid_uart0=1 |
configuration confirmed, pins/access/root unknown |
What recovery can likely write
The A/B OTA partition list advertises boot,system,vbmeta,vendor,dtbo, linux_rootfs,factory,3rd,tzbp,pq,aq,adsp,tpv_misc,uboot,uboot_env,ubootB, uboot_envB,dolby,r20,r21,3dlut. This proves intended OTA coverage, not that a
user-accessible recovery shell can freely write them. The trusted UpdateEngine
path writes the inactive slot according to a signed payload.
Practical conclusion
- If normal Android and ADB boot, a bad updated-system APK may be removable via PackageManager's system-update rollback.
- If Android/ADB do not boot, neither a key-based recovery UI nor USB emergency restore has yet been device-proven. Do not perform a live system/framework patch on that assumption.
- An OEM full
autorun*.upgplus documented model-specific key/USB recovery procedure is required before high-risk deployment.