[Xiaomi Mi A2 / 6X Guides, News, & Discussion] ricardohnn:
About the setprop, even after the reboot isn't returning the prop, so that's why i am not sure if it is actually keeping it after twrp boot.

About the AB partition... well...

it's more or less like this...

let's say some simple partition scheme....

Preloader

Boot

System

Vendor

ODM

Data

So the phone will probably have many boot images type... like the usual boot.img or recovery.img (before treble) etc.

The boot.img will have the kernel image bla bla bla... since this is a google update, i believe that the AB partition procedures starts here (meaning all the relevant code of checking whether is A or B)

Google wanted to make things faster for the OEM (Samsung, LG etc) so they wanted to separate their ****s from google's one.

So (if things didn't change) you will have the following partitions now (actually i am not sure if they kept the system AB, but i believe so, since it seems to be working in other phones like that :p)

BootA

BootB

SystemA

SystemB

VendorA

VendorB

OEMA

OEMB

Data

So let's say google wants to update some security patches, from kernel til android, it will have to update boot and system. So in a OTA (changes if it is a google phone or a branded phone) before treble, it would update like... download the image containing boot and system into cache partition or data partition (depending the OTA size), after the download the update manager apk would set as a update booting and reboot your phone. Once booted, the phone would copy the partitions to the correct place (not being detailed) and rereboot. After the rereboot, if everything went normal, it would delete the downloaded image from your data/cache partition.

Now it's different like... instead of sending the update to the data partition and copying. It has a flag to set whether you are in A or B partition.

If you are (for eg.) in A partition, it will download the OTA to the B partition. (consider that in an untouched phone, A and B would have identical copies). So after downloading it, the flag is set to the B partition and reboot the phone. When booting, this time, it will not follow the A booting flow, like...

Before the update booting process would be

BootA

SystemA

VendorA

ODMA

Data

After the update the boot process will be

BootB

SystemB

VendorB

ODMB

Data

But i didn't update the vendor or ODM... why not keep in A? Because it's too hard to manage it.

So if anything fails in this update, it can easily go back into A booting process (which means you have a backup of your old boot).

Since system is too big, i am not sure if the system AB exists (it would just take up too much space... but anyway...).

It is also not a way to prevent bootloop, it is related to update. If an update fails (say, the image is corrupted or has no signature etc) the boot will change back, but if the update is "correct" it will boot as it should, even if the image is bad.

So again... when we do the fastboot boot boot.img, we are copying this boot into some cache or data to boot up, instead of our original boot. When we reboot, it will use the original boot. So, is there a difference from using twrp flashed and booted?

I know that fastboot boot will trigger different booting process (meaning signatures verifying etc) but don't think that it will not mount a partition or something...

Well... anyway... so after the reboot, when you setprop in TWRP, the getprop returned the prop correctly? I recall something about getprop not returning the prop but camera2 was enabled anyway with the setprop... well... can you just confirm one thing for me?

The steps you used was... fastboot flash patchboot and then reboot into twrp and then reboot back to usual partition.

You didn't do fastboot boot patched boot -> twrp -> reboot

Right?

---------- Post added at 09:44 AM ---------- Previous post was at 09:42 AM ----------

Oh didn't see this one. OK...

Damn... hmm... strange... well thanks anyway...

---------- Post added at 09:50 AM ---------- Previous post was at 09:44 AM ----------

Oh by the way, i saw one part

"But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images. "

I think this is wrong (at least if TWRP team didn't change stuff), but all images are bootable images... (by all images i mean... boot.img recovery.img Flashing.img).

I once thought that they used a common kernel image, but in fact, all the booting process image has the kernel image copied (literally) to prevent brick. So even with a corrupted boot img, you still can boot into recovery or into download mode.

So that's why TWRP must have a kernel.