OS designers usually include a special fail-safe mode via which users can restore the system after a failure. The implementation, however, varies across devices: the method of pressing the reset button of your router for a while is not applicable on your PC.
Android, which is itself based on Linux kernel, also features a dedicated recovery mode. In retail devices, the recovery is based on the stock boot image (kernel) and is extensively used for installing system updates, doing factory resets and other low level tasks.
It is possible to modify the recovery environment to add extra features, such as backup/restore critical partitions (such as userdata or modem) and option to allow third party system updates (custom ROM). For further discussions, take a look at this article.
Well, this article is not about custom recoveries. Rather we are going to highlight a serious (and recurring) bug of stock recovery of Asus phones.
Before beginning, allow me to discuss a bit about system update mechanisms via recovery. In early days of Android, the incremental OTA update zips came with delta patches. These file based delta patches nothing but the differences between the old files and the updated ones.
With the release of Android 5.0 Lollipop, Google introduced block based OTA. Unlike file based delta patching, block based OTA mechanism also ensures integrity of the whole partition by taking care of more data (file metadata, dm-verity data, ext4 layout, etc.) .
Android 5.0 and later versions use block OTA updates to ensure that each device uses the exact same partition. Instead of comparing individual files and computing binary patches, block OTA handles the entire partition as one file and computes a single binary patch, ensuring the resultant partition contains exactly the intended bits. This allows the device system image to achieve the same state via fastboot or OTA.
(Source)
Newer versions of Android support payload based OTA via A/B partitioning. Although the compression technique is new, the underlying concept is still based on block based patching.
Non A/B devices (such as the Asus Zenfone lineup) are sticking with block OTA, which is much sensitive towards modifications. According to Google, an incremental OTA will fail even if no system file has been physically modified.
A system partition might be modified during an adb remount or as a result of malware. File OTA tolerates some changes to the partition, such as the addition of files that are not part of the source or target build. However, block OTA does not tolerate additions to the partition, so users will need to install a full OTA overwriting any system partition modifications) or flash a new system image to enable future OTAs.
The recovery maintains an internal list for checking the integrity of the base system. However, multiple Asus Zenfone Max Pro M1 users have noticed a borked system integrity from the recovery after installing the latest OTA update (WW-16.2017.1905.053).
PiunikaWeb readers should remember that Asus faced a couple of roadblocks while updating their Zenfone Max lineup to Android 9.0 Pie. In case of Zenfone Max Pro M1, the 053 build is the wider rollout of Pie along with May security patch.
Based on the user feedback, the stock recovery of the phone is now pointing 92 core system files as missing/mismatched after executing the root integrity test. The early adopters of the update, who manually flashed the full zip, are affected as well.
It fails even on .50
Lots of files missing on system\bin and etc ,What I guess is when they updated to pie, the stock recovery remained on the previous Oreo version ,so it’s database is not updated wrt the new files created on new os upgrade ,and the old ones deleted as a part of os upgrade ..
As for 92 files lost,92 new files are found.
(Source)
It is worth mentioning that the OS itself boots fine and passed SafetyNet and Play Store certifications. Thus the integrity violation must be a false positive originated from the recovery.
The same theory is getting attraction among the affected users in Asus support forum. Nevertheless, the glitch should affect the installation of the upcoming incremental OTA (although full zip could be flashed fine).
As a matter of fact, Asus did the same mistake in past with multiple phones. Take the example of Zenfone 3 Max Nougat update:
after nougat update, zc520tl runs slow and as i run the rood integrity check, it says 9 lost files, is this normal? or should i do something about it?
(Source)
Confused and frustrated Zenfone Max Pro M1 users are now manually reverting back to Android 8.1 Oreo to get rid of the bugs in the Pie update. Hopefully Asus will issue an official statement regarding the situation, paired with another bug fix update soon enough.
PiunikaWeb is a unique initiative that mainly focuses on investigative journalism. This means we do a lot of hard work to come up with news stories that are either ‘exclusive,’ ‘breaking,’ or ‘curated’ in nature. Perhaps that’s the reason our work has been picked by the likes of Forbes, Foxnews, Gizmodo, TechCrunch, Engadget, The Verge, Macrumors, and more. Do take a tour of our website to get a feel of our work. And if you like what we do, stay connected with us on Twitter (@PiunikaWeb) and other social media channels to receive timely updates on stories we publish.
Tags
Zenfone Max Pro M1
Kingshuk De
896 Posts
I came from a mixed background of Statistics and Computer Science. My research domains included embedded computer systems, mobile computing and delay tolerant networks in post-disaster scenarios. Apart from tinkering with gadgets or building hackintosh, I like to hop on various subreddits and forums like MyDigitalLife and XDA.
Next article View Article
