Install instructions prefer writing partitions to sideloading

in https://doc.e.foundation/devices/FP3/install the guide advertises writing the partitions individually after unzip - but when I flashed the first time, the dev 0.9/0.10 dev image builds didn’t have the individual partition images present in the zip, but a payload.bin - the 0.11 dev has the partition images again and is in line with the Documentation.

The payload seems OTA compatible as it carries all necessary meta information, while individual partition can be tinker friendly. With sideloading, there needed to be less commands issued. But needed some understanding of booting into TWRP. All in all, sideloading still seems more straight forward for a first flash.

So I’m curious - what are the pro/cons of one method over the other - do people individually flash the system or vendor partitions when debugging, and this is the reason they are distributed individually in dev images?

Would you be able to point me to docs that explain the difference in build instructions resulting in differing build artefacts?

@Manoj, as you did update the docs at https://gitlab.e.foundation/e/documentation/user/-/commit/95228827a606aa6079982c7817d6697c53f16b00 recently, I think you are able to sort me out.

Thank you!

I read https://doc.e.foundation/how-tos/build-e and looked into the docker build mechanism - I finally found some reference to the otacert metadata in the android build Makefile.

I’d also love to read an explanation for the question you pose…
In the meantime, if you want the individual partitions you can unpack them from the payload.bin found in the zip archive: http://newandroidbook.com/tools/imjtool.html did the trick for me.

NB: something that haven’t found stated clearly anywhere is that if you have an A/B system the sideload loads into the “other” partition, which makes sense, but may not be what you expect if you are trying to keep a working system in one partition and load test stuff into the other. E.g., if you boot partition A’s recovery and then sideload you will overwrite the B system/vendor/product partitions and the recovery will reboot into B. (So if you have a running system in A don’t load the boot/recovery boot.img into B, boot into that and then sideload 'cause you will overwrite your working system.)
(Edit: Whoops, I didn’t see that this thread is in the fairphone category, I don’t know whether the fairphone is A/B or not so it may not apply to this specific phone.)

yes, FP3 is A/B partitioned as Android9 device. Good question on slot usage by adb sideload or fastboot

https://source.android.com/devices/tech/ota/ab/ab_implement?hl=en

By default, fastboot flashes the current slot on an A/B device. If the update package also contains images for the other, non-current slot, fastboot flashes those images as well.

The fairphone lineage instructions that do suggest the adb sideload procedure notes, that the currently inactive slot is used.

https://forum.fairphone.com/t/rom-unofficial-lineageos-16-0-for-fp3/59849

The LineageOS packages can be flashed with TWRP from k4y0z. TWRP flashes it to the currently inactive slots and activates it afterwards.

So it seems fastboot: current slot, adb sideload: inactive slot

That matches my observations!