[GUIDE] The Noob's Guide to A/B Partitions and Other OP6 Idiosyncrasies

Search This thread

iElvis

Senior Member
May 24, 2012
5,021
2,836
Modville
If you've just arrived on the phone modding scene, or are coming from another phone that uses traditional approaches to flashing, you've likely come across people talking about the "A/B partitions." If you don't have any experience with this arrangement, it can be intimidating, because it fundamentally changes a lot of things related to flashing and updates.

What is a Partition?

Let's start with the basics. A partition is a discrete, contiguous, but non-overlapping section within the phone's storage where data is stored. There are partitions for bootloaders, various firmware, user data, OS files, and so on. For the most part, these files live in their own partitions, and you can wipe, format, and edit them without affecting files on other partitions.

There are 72 different partitions on the OP6. If you've worked with partitions on previous phones, you're probably thinking, "That's a lot," and it is. But there's a reason why there are so many: Many of them are duplicated, and that brings us to A/B partitions. Google moved to A/B partitioning for a specific reason: It allows for what are known as "seamless" updates. The following is from Google's explainer for devs, but it's fairly straightforward:

A/B system updates use two sets of partitions referred to as slots (normally slot A and slot B). The system runs from the current slot while the partitions in the unused slot are not accessed by the running system during normal operation. This approach makes updates fault resistant by keeping the unused slot as a fallback: If an error occurs during or immediately after an update, the system can rollback to the old slot and continue to have a working system. To achieve this goal, no partition used by the current slot should be updated as part of the OTA update (including partitions for which there is only one copy).

Each slot has a bootable attribute that states whether the slot contains a correct system from which the device can boot. The current slot is bootable when the system is running, but the other slot may have an old (still correct) version of the system, a newer version, or invalid data. Regardless of what the current slot is, there is one slot that is the active slot (the one the bootloader will boot form on the next boot) or the preferred slot.

Each slot also has a successful attribute set by the user space, which is relevant only if the slot is also bootable. A successful slot should be able to boot, run, and update itself. A bootable slot that was not marked as successful (after several attempts were made to boot from it) should be marked as unbootable by the bootloader, including changing the active slot to another bootable slot (normally to the slot running immediately before the attempt to boot into the new, active one).

What does all this mean? Well, one thing (the main thing, really) that it allows you to do is take an OTA while you are booted up and using your phone. (Even if you're rooted? Yes, but more on that in a moment.) The system update engine will download and install the update to the inactive slot in the background, then ask you to reboot. When you reboot, you'll be fully updated without the need to boot to bootloader and wait for it to install. This approach makes updating a lot safer: If the update breaks something, the system won't boot to that slot. It will return to the old slot and let you know the update failed. The days of having an OTA bork your phone out of the blue are mostly over. That's good!

But What About My Data?

Though there are two versions of many partitions (boot_a, boot_b, system_a, system_b, and so on) there's only one userdata partition. So your data isn't affected by the update.

You may need to log back into certain apps as if using them for the first time, but your data and settings will all still be where they were before the OTA.

What A/B Means for Rooting

The wrinkles, however, start coming when you unlock and root your phone. To understand why, we need to talk about something called the kernel. The kernel is a key part of any computer operating system. It is the tool that applications use to talk to the hardware and vice versa, and it governs how the CPU operates, how memory is used, and on smartphones how things like the screen, radio, speakers, and so on function. Without the kernel, or with a broken kernel, applications have no way to function. If you've heard the term "kernel panic," it's a situation in which the kernel stops the system either because of a hardware fault or a software problem that's taken the system into a state that the kernel can't get it out of.

Non-A/B Android phones actually had two kernel images. One lived in the recovery partition, while the other lived in the boot partition. This allowed the phone to boot into recovery and make major changes to the rest of the system. But the A/B approach gets rid of the separate recovery partition and integrates it into the boot partition. Why? Probably because on stock phones, the recovery is only used for system updates, and with the A/B arrangement, it's no longer necessary to have a separate dedicated recovery since updates happen directly to the inactive partition.

This creates a challenge for phone modding, however. Without a separate recovery partition, the stock recovery has to be replaced with a custom recovery, inside the boot partition where the kernel lives. But on Android, you cannot modify partitions through fastboot – you can only flash over them. So installing a custom recovery like twrp for the first time requires you to fastboot boot into twrp from your computer, then flash an installer once you are booted. .

There's another problem: Rooting via magisk makes modifications to the boot sector. So does flashing xposed or (obviously) a custom kernel. With recovery and these other custom mods now all living together in the same partition, it is possible for one of them to overwrite files used by another mod. This is why you may need to reflash magisk after updating a custom kernel or custom recovery, and why not doing so can result in a bootloop. You've overwritten files magisks uses for root, so your phone can no longer boot (this isn't the case with all mods; many are now coded to avoid this problem).

Updates on a Rooted OP6 with A/B Partitions

If you've been following along so far, you're probably now seeing another issue: Isn't a seamless update going to overwrite all of my mods? The answer is yes, it will (more accurately, it won't copy them over to the new slot). If you're cringing now, have faith. This isn't as big a deal as it sounds, and it's actually a good thing once you see how it all works.

Here's what happens when your OP6 gets an update notification. The update engine detects root and downloads the full update instead of the incremental update. This is very important and you should not try to frustrate or block it from doing so (unless you want to update manually via twrp, see below). Taking the incremental update on a rooted phone could result in a brick, or more likely, an unbootable slot. Like it says in that Google quote above, the updater installs the new version in the inactive slot. The key thing here is that it installs a fresh, fully stock version. Your data gets pulled over, but none of your mods go with it. To get them back, you have to install them all again. There are various ways of doing this, and this isn't the place to repeat the guides that are already posted on how. Just understand that you have to do it to keep root, twrp, and your other mods.

It works more or less the same way if you download the full update manually and flash in twrp. You'll get a fully stock installation on the other slot, and you'll boot into it unrooted unless you reinstall your mods first. You also should note that this makes for an easy way to go back to stock if that's what you want, and I recommend keeping a zip of the stock OS on your phone just in case you need to do it.

Note that you can manually switch the active slot in twrp, but I don't recommend doing so until you know what you're doing. After a couple of updates and flashes, what remains on the inactive slot is not necessarily going to be bootable, or it may boot with things like wifi broken. And if you've never updated at all, there may be nothing on the inactive slot, which means your phone will reboot into the void of a black screen. (But don't worry – there's a tool to fix this here.)

Here are a couple of guides that I recommend for further reading on the specifics:

[RECOVERY] HOW TO INSTALL OFFICIAL TWRP & MAGISK OOS 5.1.5 to 5.1.8
[OFFICIAL] OxygenOS 5.1.8 OTA for the OnePlus 6

If all this seems like some extra work, it is. But remember it ensures you're getting a clean and fully functional updated system. Once you get the hang of doing it this way, you'll appreciate the advantages.

Some Other Things to Be Aware of

In addition to the other changes, the cache partition has been removed. It now resides in the data partition and is no longer used for anything related to updates. One result is that wiping cache in twrp no longer does anything. If you want to clear cached data go into Settings>Storage & memory, then tap Cached data at the bottom and then tap OK.

Otherwise, you don't need to worry much about it. (Why did Google do this? Apparently to save space that was taken up by having to duplicate many other partitions. They also halved the system partitions by playing some clever games with app odexing, but that's beyond the scope of this guide – the only user effect is a slower first boot after factory reset.)

That's Cool! I Want to Know More!

This article on the XDA portal covers everything you could possibly want to know about A/B partitions and what they do.

Good luck and happy modding.

(Note: Devs and experienced users are encouraged to submit corrections if any of this is a bit off.)
Thanks to @jisoo for a guide in the Pixel forums I adapted some of this from.
 
Last edited:

hithere4x

Member
Sep 17, 2009
13
11
Jeddah
Man that's something
Any way Thank you
I was lazy to search and read about the whole thing , but you help to provide what I need to know .

Sent from my ONEPLUS A6003 using Tapatalk
 

iElvis

Senior Member
May 24, 2012
5,021
2,836
Modville
Nice write up. I did have a question though. If I flash the full stock rom in TWRP does it automatically flash to the non-active partition? I've had a couple of unexpected issues when flashing.

Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.
 

texasaggie1

Senior Member
Aug 10, 2004
740
247
OnePlus 7 Pro
OnePlus 8 Pro
Ah ok. I just ended up flashing the stock ROM twice, once to each partition. Then I ran the Twrp installer. Then I flashed magisk twice, once to each partition and that fixed my issues


Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.
 

RusherDude

Senior Member
Aug 24, 2012
2,013
614
Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.

Awesome writeup!!! this needs an sticky big time.

One question, why does TWRP flash stuff on current slot but full roms on the other slot (and changes slot then?). It is because it replicates the Update Engine protocol or something with entire stock roms only?

PS: I wish there was a more detailed version after the initial setup, like when **** happens and slots get disabled by the bootloader and such. I wonder if when an slot is disabled you can twrp enable/change into it or only flashing stock image works? There's a lot of stuff like this, like what happens if you manage to make both slots unusable (even if bootloader partition works, fastboot wouldn't be reachable right? :S).

This seems like just a hell of an environtment to control compared to the simple old partition scheme.. yeah, here you can have 2 systems set up incase something breaks, great, but you do not control the boot process, the bootloader does, and this is not good for us. Something that affects both slots at the same time like TWRP can go wrong (for example a bugged release of TWRP) and derp you both systems and let you without an unusable phone without even fasboot?... yeah qualcomm protocol but come on..

You'd add on the guide that you can disable seamless updates on developer options. This is very important!! I think that the manual OTA flashing is the way to go if we want to not get into ****..

And you're right, this is ultra intimidating, I've never ever had any problems rooting and such my first android phone.. it was an easy read explaining that bootloader->kernel->system->user, 1) unlock 2) twrp 3) flash root and mods and do nandroids... and if something goes wrong, if you never touched the bootloader partition you could always go into fastboot and fix, or into TWRP and fix even if system bootloops. Here if system bootlops you can't even use TWRP or fastboot on that slot???? wtf... super intimidating.

You added most of the good stuff on the first post.. how about a new section "the bad side" or something like that with all the stuff im saying and more bad stuff that I don't even know yet? :p You will evade most people getting onto those situations and post here asking about that stuff.

Thanks!
 
Last edited:
  • Like
Reactions: speed&vodka

iElvis

Senior Member
May 24, 2012
5,021
2,836
Modville
One question, why does TWRP flash stuff on current slot but full roms on the other slot (and changes slot then?). It is because it replicates the Update Engine protocol or something with entire stock roms only?

I assume because it's coded to flash to both slots. The stock rom updates are set up to use Google's A/B approach, which sets out a specific process for flashing updates.

PS: I wish there was a more detailed version after the initial setup, like when **** happens and slots get disabled by the bootloader and such. I wonder if when an slot is disabled you can twrp enable/change into it or only flashing stock image works? There's a lot of stuff like this, like what happens if you manage to make both slots unusable (even if bootloader partition works, fastboot wouldn't be reachable right? :S).

The A/B info page I linked explains exactly what happens:

  1. The current slot (or "source slot") is marked as successful (if not already marked) with markBootSuccessful().

    The unused slot (or "target slot") is marked as unbootable by calling the function setSlotAsUnbootable(). The current slot is always marked as successful at the beginning of the update to prevent the bootloader from falling back to the unused slot, which will soon have invalid data. If the system has reached the point where it can start applying an update, the current slot is marked as successful even if other major components are broken (such as the UI in a crash loop) as it is possible to push new software to fix these problems.

    The update payload is an opaque blob with the instructions to update to the new version. The update payload consists of the following:
    • Metadata. A relatively small portion of the update payload, the metadata contains a list of operations to produce and verify the new version on the target slot. For example, an operation could decompress a certain blob and write it to specific blocks in a target partition, or read from a source partition, apply a binary patch, and write to certain blocks in a target partition.
    • Extra data. As the bulk of the update payload, the extra data associated with the operations consists of the compressed blob or binary patch in these examples.
  2. The payload metadata is downloaded.
  3. For each operation defined in the metadata, in order, the associated data (if any) is downloaded to memory, the operation is applied, and the associated memory is discarded.
  4. The whole partitions are re-read and verified against the expected hash.
  5. The post-install step (if any) is run. In the case of an error during the execution of any step, the update fails and is re-attempted with possibly a different payload. If all the steps so far have succeeded, the update succeeds and the last step is executed.
  6. The unused slot is marked as active by calling setActiveBootSlot(). Marking the unused slot as active doesn't mean it will finish booting. The bootloader (or system itself) can switch the active slot back if it doesn't read a successful state.
  7. Post-installation (described below) involves running a program from the "new update" version while still running in the old version. If defined in the OTA package, this step is mandatory and the program must return with exit code 0; otherwise, the update fails.
  8. After the system successfully boots far enough into the new slot and finishes the post-reboot checks, the now current slot (formerly the "target slot") is marked as successful by calling markBootSuccessful().

You can see there are multiple stages here, and if the bootloader can't even load, that slot won't be marked as active.

There's an even more detailed version here: https://source.android.com/devices/tech/ota/ab/ab_implement

As I understand it, twrp can change active slots, but if the slot has been marked unbootable (because it's not bootable), then it probably has to fixed with a clean reflash.

Unless the slot is completely empty, you should still be able to get to bootloader. Obviously, if the bootloaders are corrupted on both slots, you have a brick, but you can do that on non-A/B phones too.

This seems like just a hell of an environtment to control compared to the simple old partition scheme.. yeah, here you can have 2 systems set up incase something breaks, great, but you do not control the boot process, the bootloader does, and this is not good for us. Something that affects both slots at the same time like TWRP can go wrong (for example a bugged release of TWRP) and derp you both systems and let you without an unusable phone without even fasboot?... yeah qualcomm protocol but come on.

I'm not sure the situation is that dire. A bad release of twrp could bork a non-A/B phone the same way? Here you've got two slots instead of one.

You'd add on the guide that you can disable seamless updates on developer options. This is very important!! I think that the manual OTA flashing is the way to go if we want to not get into ****..

I'm not seeing an option to disable A/B updates anywhere.

And you're right, this is ultra intimidating, I've never ever had any problems rooting and such my first android phone.. it was an easy read explaining that bootloader->kernel->system->user, 1) unlock 2) twrp 3) flash root and mods and do nandroids... and if something goes wrong, if you never touched the bootloader partition you could always go into fastboot and fix, or into TWRP and fix even if system bootloops. Here if system bootlops you can't even use TWRP or fastboot on that slot???? wtf... super intimidating.

I don't think this is true. If you're simply in a system bootloop, you can still get into bootloader.
 
  • Like
Reactions: RusherDude

RusherDude

Senior Member
Aug 24, 2012
2,013
614
Thanks :)

The A/B info page I linked explains exactly what happens:



You can see there are multiple stages here, and if the bootloader can't even load, that slot won't be marked as active.

There's an even more detailed version here: https://source.android.com/devices/tech/ota/ab/ab_implement

As I understand it, twrp can change active slots, but if the slot has been marked unbootable (because it's not bootable), then it probably has to fixed with a clean reflash.

Unless the slot is completely empty, you should still be able to get to bootloader. Obviously, if the bootloaders are corrupted on both slots, you have a brick, but you can do that on non-A/B phones too.

I'm not sure the situation is that dire. A bad release of twrp could bork a non-A/B phone the same way? Here you've got two slots instead of one.

I don't think this is true. If you're simply in a system bootloop, you can still get into bootloader.

All this is related to the same doubt. On the flow on the page you linked, it tries to boot, if it fails N times it sets the slot as unbootable and changes to the other. You cannot just change to the previous slot and enter fasboot there since the bootloader won't boot that already unbootable boot. It is considered unbootable even if its a system issue with bootloader/kernel working.. or I'm getting that wrong? On a normal partitions phone, you won't ever get locked to enter fasboot because system won't boot, here it will happen per the flow diagram on the site...

I'm not seeing an option to disable A/B updates anywhere.

Not A/B updates, but automatic updates. I don't have the phone, but I've been told in this sub that there's an option to disable automatic updates there.
 
Last edited:

iElvis

Senior Member
May 24, 2012
5,021
2,836
Modville
All this is related to the same doubt. On the flow on the page you linked, it tries to boot, if it fails N times it sets the slot as unbootable and changes to the other. You cannot just change to the previous slot and enter fasboot there since the bootloader won't boot that already unbootable boot. It is considered unbootable even if its a system issue with bootloader/kernel working.. or I'm getting that wrong? On a normal partitions phone, you won't ever get locked to enter fasboot because system won't boot, here it will happen per the flow diagram on the site...

I think I see what you may be missing here. One slot being unbootable doesn't lock you out of fastboot. You can get into fastboot on the other slot, where you can flash anything you want to either slot. So you're not locked out of it if it fails to boot, you just can't boot up on that slot and the system will boot on the other slot.

Not A/B updates, but automatic updates. I don't have the phone, but I've been told in this sub that there's an option to disable automatic updates there.

Ah, yes, you can indeed disable automatic upgrades. You can also just download the OTA and not reboot, which I've done several times. Download, stop the process, reboot to recovery before the slot switches over.
 
  • Like
Reactions: RusherDude

RusherDude

Senior Member
Aug 24, 2012
2,013
614
I think I see what you may be missing here. One slot being unbootable doesn't lock you out of fastboot. You can get into fastboot on the other slot, where you can flash anything you want to either slot. So you're not locked out of it if it fails to boot, you just can't boot up on that slot and the system will boot on the other slot.

In that scenario, yes you could reflash from slot B, but if you manage to then also bootloop on slot B, you end up with 2 slots with bootloader & kernel partitions working properly, system not booting and unable to enter fastboot or twrp on any of those? My doubt here is if bootloader/fastboot is "always there" even if you derp on both slots or not. If there isn't and you're reduced to qualcomm protocol having 2 correct aboot/fastboot partitions it is the most idiotic measure I have seen done by Google in a long time.


Ah, yes, you can indeed disable automatic upgrades. You can also just download the OTA and not reboot, which I've done several times. Download, stop the process, reboot to recovery before the slot switches over.

I'm interested in that. Which process do you kill? And after rebooting to recovery, you just reboot normal and the slot change and such is ignored and system ignores the download ota and such? or from now on you can't reboot normally again?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 225
    If you've just arrived on the phone modding scene, or are coming from another phone that uses traditional approaches to flashing, you've likely come across people talking about the "A/B partitions." If you don't have any experience with this arrangement, it can be intimidating, because it fundamentally changes a lot of things related to flashing and updates.

    What is a Partition?

    Let's start with the basics. A partition is a discrete, contiguous, but non-overlapping section within the phone's storage where data is stored. There are partitions for bootloaders, various firmware, user data, OS files, and so on. For the most part, these files live in their own partitions, and you can wipe, format, and edit them without affecting files on other partitions.

    There are 72 different partitions on the OP6. If you've worked with partitions on previous phones, you're probably thinking, "That's a lot," and it is. But there's a reason why there are so many: Many of them are duplicated, and that brings us to A/B partitions. Google moved to A/B partitioning for a specific reason: It allows for what are known as "seamless" updates. The following is from Google's explainer for devs, but it's fairly straightforward:

    A/B system updates use two sets of partitions referred to as slots (normally slot A and slot B). The system runs from the current slot while the partitions in the unused slot are not accessed by the running system during normal operation. This approach makes updates fault resistant by keeping the unused slot as a fallback: If an error occurs during or immediately after an update, the system can rollback to the old slot and continue to have a working system. To achieve this goal, no partition used by the current slot should be updated as part of the OTA update (including partitions for which there is only one copy).

    Each slot has a bootable attribute that states whether the slot contains a correct system from which the device can boot. The current slot is bootable when the system is running, but the other slot may have an old (still correct) version of the system, a newer version, or invalid data. Regardless of what the current slot is, there is one slot that is the active slot (the one the bootloader will boot form on the next boot) or the preferred slot.

    Each slot also has a successful attribute set by the user space, which is relevant only if the slot is also bootable. A successful slot should be able to boot, run, and update itself. A bootable slot that was not marked as successful (after several attempts were made to boot from it) should be marked as unbootable by the bootloader, including changing the active slot to another bootable slot (normally to the slot running immediately before the attempt to boot into the new, active one).

    What does all this mean? Well, one thing (the main thing, really) that it allows you to do is take an OTA while you are booted up and using your phone. (Even if you're rooted? Yes, but more on that in a moment.) The system update engine will download and install the update to the inactive slot in the background, then ask you to reboot. When you reboot, you'll be fully updated without the need to boot to bootloader and wait for it to install. This approach makes updating a lot safer: If the update breaks something, the system won't boot to that slot. It will return to the old slot and let you know the update failed. The days of having an OTA bork your phone out of the blue are mostly over. That's good!

    But What About My Data?

    Though there are two versions of many partitions (boot_a, boot_b, system_a, system_b, and so on) there's only one userdata partition. So your data isn't affected by the update.

    You may need to log back into certain apps as if using them for the first time, but your data and settings will all still be where they were before the OTA.

    What A/B Means for Rooting

    The wrinkles, however, start coming when you unlock and root your phone. To understand why, we need to talk about something called the kernel. The kernel is a key part of any computer operating system. It is the tool that applications use to talk to the hardware and vice versa, and it governs how the CPU operates, how memory is used, and on smartphones how things like the screen, radio, speakers, and so on function. Without the kernel, or with a broken kernel, applications have no way to function. If you've heard the term "kernel panic," it's a situation in which the kernel stops the system either because of a hardware fault or a software problem that's taken the system into a state that the kernel can't get it out of.

    Non-A/B Android phones actually had two kernel images. One lived in the recovery partition, while the other lived in the boot partition. This allowed the phone to boot into recovery and make major changes to the rest of the system. But the A/B approach gets rid of the separate recovery partition and integrates it into the boot partition. Why? Probably because on stock phones, the recovery is only used for system updates, and with the A/B arrangement, it's no longer necessary to have a separate dedicated recovery since updates happen directly to the inactive partition.

    This creates a challenge for phone modding, however. Without a separate recovery partition, the stock recovery has to be replaced with a custom recovery, inside the boot partition where the kernel lives. But on Android, you cannot modify partitions through fastboot – you can only flash over them. So installing a custom recovery like twrp for the first time requires you to fastboot boot into twrp from your computer, then flash an installer once you are booted. .

    There's another problem: Rooting via magisk makes modifications to the boot sector. So does flashing xposed or (obviously) a custom kernel. With recovery and these other custom mods now all living together in the same partition, it is possible for one of them to overwrite files used by another mod. This is why you may need to reflash magisk after updating a custom kernel or custom recovery, and why not doing so can result in a bootloop. You've overwritten files magisks uses for root, so your phone can no longer boot (this isn't the case with all mods; many are now coded to avoid this problem).

    Updates on a Rooted OP6 with A/B Partitions

    If you've been following along so far, you're probably now seeing another issue: Isn't a seamless update going to overwrite all of my mods? The answer is yes, it will (more accurately, it won't copy them over to the new slot). If you're cringing now, have faith. This isn't as big a deal as it sounds, and it's actually a good thing once you see how it all works.

    Here's what happens when your OP6 gets an update notification. The update engine detects root and downloads the full update instead of the incremental update. This is very important and you should not try to frustrate or block it from doing so (unless you want to update manually via twrp, see below). Taking the incremental update on a rooted phone could result in a brick, or more likely, an unbootable slot. Like it says in that Google quote above, the updater installs the new version in the inactive slot. The key thing here is that it installs a fresh, fully stock version. Your data gets pulled over, but none of your mods go with it. To get them back, you have to install them all again. There are various ways of doing this, and this isn't the place to repeat the guides that are already posted on how. Just understand that you have to do it to keep root, twrp, and your other mods.

    It works more or less the same way if you download the full update manually and flash in twrp. You'll get a fully stock installation on the other slot, and you'll boot into it unrooted unless you reinstall your mods first. You also should note that this makes for an easy way to go back to stock if that's what you want, and I recommend keeping a zip of the stock OS on your phone just in case you need to do it.

    Note that you can manually switch the active slot in twrp, but I don't recommend doing so until you know what you're doing. After a couple of updates and flashes, what remains on the inactive slot is not necessarily going to be bootable, or it may boot with things like wifi broken. And if you've never updated at all, there may be nothing on the inactive slot, which means your phone will reboot into the void of a black screen. (But don't worry – there's a tool to fix this here.)

    Here are a couple of guides that I recommend for further reading on the specifics:

    [RECOVERY] HOW TO INSTALL OFFICIAL TWRP & MAGISK OOS 5.1.5 to 5.1.8
    [OFFICIAL] OxygenOS 5.1.8 OTA for the OnePlus 6

    If all this seems like some extra work, it is. But remember it ensures you're getting a clean and fully functional updated system. Once you get the hang of doing it this way, you'll appreciate the advantages.

    Some Other Things to Be Aware of

    In addition to the other changes, the cache partition has been removed. It now resides in the data partition and is no longer used for anything related to updates. One result is that wiping cache in twrp no longer does anything. If you want to clear cached data go into Settings>Storage & memory, then tap Cached data at the bottom and then tap OK.

    Otherwise, you don't need to worry much about it. (Why did Google do this? Apparently to save space that was taken up by having to duplicate many other partitions. They also halved the system partitions by playing some clever games with app odexing, but that's beyond the scope of this guide – the only user effect is a slower first boot after factory reset.)

    That's Cool! I Want to Know More!

    This article on the XDA portal covers everything you could possibly want to know about A/B partitions and what they do.

    Good luck and happy modding.

    (Note: Devs and experienced users are encouraged to submit corrections if any of this is a bit off.)
    Thanks to @jisoo for a guide in the Pixel forums I adapted some of this from.
    7
    Nice write up. I did have a question though. If I flash the full stock rom in TWRP does it automatically flash to the non-active partition? I've had a couple of unexpected issues when flashing.

    Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.
    6
    I have OxygenOs 5.1.9, Twrp and root Magisk.
    What would be the step by step process to update to 5.1.11 keeping Twrp and root, without losing my data? Could you do everything from Twrp, without the need of a computer?

    You're going to lose root by updating - no way to avoid that. But getting it back is easy, and yes you can do it all on your phone provided you have all the necessary files in your internal storage before starting. I've done it myself several times:

    -Download the full 5.1.11 update package, twrp installer zip (not the img), magisk, and whatever rom/kernel you want to use to your phone. Check MD5s to be sure all is in order.
    -Reboot to recovery
    -Flash OOS update
    -Do NOT reboot. Instead, immediately flash twrp installer
    -Reboot to recovery (not system)
    -Flash magisk
    -Flash rom/kernel
    -Reboot
    4
    Very informative and I'd even recommend this read for users who already know a bit about the partitions!
    4
    I'm having a little trouble wrapping my head around this. So is there no separate recovery partition, because updates are done by switching to the other slot by the bootloader, and not the recovery, as was done previously?
    What I do not understand is that once the update files are downloaded by the system, isn't it the recovery that is swapping the files in the other inactive slot? I just don't properly get the need to eliminate the partition, since it's still functioning.

    The update engine handles the updates. Otherwise, recovery is doing the same thing, just from the boot partition. Google was trying to save some space that was taken up by duplicating other partitions for the A/B arrangement.

    2. Will flashing a custom recovery, then, in that case, also need to be flashed along with the boot, kernel, etc. and everything else in that partition?

    No. (Well, theoretically, yes, you could do this, but there's no reason to.) You just need to boot recovery from fastboot, then you can flash recovery only once you're in recovery.

    Either someone comes up with a REALLY simple way to root this device or just take it as it is............
    So I think I am getting a bit too old to do all these things to a perfect phone or I am just tired of getting through all these rooting/Magisk/TWRP methods.)

    I mean this as nicely and respectfully as I can manage, but it's really only a nightmare if you're not willing to re-learn how to do this. There are a couple of extra steps, and things need to be done in a certain order, but that's really it.

    90% of the problems I've seen with this phone have been the result of people blundering forward without reading the guides because they think they already know what to do and don't need to read any of the instructions. If you follow the guides, you'll be fine.

    I've been doing this stuff for a long time too, and there was a learning curve with this phone, but now that I'm used to it, it's not that big a deal. And I do really like the ability to take OTAs and get back to stock easily no matter how borked things get.