So I think that you are trying to satisfy Q3, is that correct?
In which case if you see the vendor partition you satisfy Q3. (Many ROMs one can only do this with payload bin … other methods to check presence of vendor are satisfactory.)
However now that I see (apologies) that you plan official to community this will / should involve change of build keys so that is expected not “correct”. So I think it will be fresh install.
./payload-dumper-go -l ~/Downloads/Test/e-4.0-a16-20260610633938-community-FP4.zip
Please wait while extracting payload.bin from the archive.
2026/06/14 16:12:14 Failed to extract payload.bin from the archive.
I am about to upgrade my Samsung A52q, from version 3.0.4 (T - Android 13) to e-4.0-a15-20260612634536-community-a52q.
After reading the various links given above I have a pretty good idea of what I must do (upgrade firmware that I can find in LineageOS wiki and then local update), but I still have one question: there is also a new version of the recovery available for download. It is zip file with a recovery-e-4.0-xxxx.img file and a vbmeta-e-4.0-xxxx.img file. Is it required, or recommended, or optional, to flash these two files with Odin as explained in the general instructions before the local update ? Would that impact the data on the phone ?
Thanks. I finally did the update, it went very well for the firmware and /e/OS. I tried to update also the vbmeta and the recovery, but for a strange reason Odin was crashing. Since it was not mandory I gave up for these two and it works fine so far.
FP5: Update from 4.0 A15 community to 4.0 A16 community failed!
I went like in the guides.
I checked the payload.bin contents and it looked like it has all the proper firmware files in it (modem, for example).
I used the reovery and adb sideload method
All looked fine until the reboot
It went in one boot loop
Then some “Try again” screen (or factory reset)
Okay, I thought, “Hey, I have an A/B phone”. Let’s switch the slot and try the old OS. So I went with fastboot set_active b.
But after the fastboot reboot it ended up in a boot loop.
Any ideas on how to continue?
I am considering to boot into recovery and “apply update” the a15 4.0 update to downgrade…
The phone is dynamic partitions, so fastboot change of recovery might result in having to switch to fastbootd in order to continue. This then becomes something of an expert method.
The advantage of Local update is as said plus fail safe (hopefully).
Edit
… has the advantage that you change to a16 after others have tried
Maybe this will only work if the a16 flash was fully rejected.
Well, I now know that Local update is better (well, could be added to the guide in the first post, that this method is actually recommended. The “Universal” sounds much more promissing.)
I still would like to rescue my phone with its data, really. I am happy to perform some “expert things”, if needed.
Now you can read the two scripts to give you an understanding of the partition layout.
If you are forced to fastbootd you can better decide what goes where.
In deciding what next, loosely speaking, think of Recovery having access to the “partition map”. The a15 map may have (unknown to me) differences to the a16 map.
boot slot b (as switched above) did not work very well at all. I only end up in fastboot. From where I can try recovery, but that loops back to fastboot.
After switching back to a, I can enter recovery (and it shows “slot a”). It shows 4.0, but not whether it’s A15 or A16 (Or at least, I can’t find it easily in the UI?).
I went to “advanced” and “Enable ADB”.
then
$ adb shell
FP5:/ # type getprop
getprop is /system/bin/getprop
FP5:/ # getprop ro.build.version.release
16
So did the previous sideload actually update the recovery?! I haven’t seen the recovery in the payload.bin (not 100% sure)?
I wonder, whether I should try to sideload the e-a16.zip again?
There are not so many reports of a16 upgrade for me to be confident of an answer.
I guess at this point
you did not “Try again”? Edit, this is history, probably not of help for me to comment.
It is quite possible it did, but it would have probably done this during the sideload … not at the start. I guess at the start of the previous sideload the “a15 map” was in place.
It would be something of a gamble if the next sideload here could grab the a16 map and re-jig any necessary partitions.
Previously mentioned, my intuitive preferred option would have been if you found a stable a15 recovery and attempted to go back to that. Seems that door is closed (??)
