[OnePlus 6 & 6T Cross Device Development] Terminator.J:
Heya!

Okay, let's see...

*cracks knuckles*

Without losing data? Sure, just don't format userdata.

Without switching to dynamic partitions? Nope, that's required... but it doesn't require you to wipe data.

That's literally it; you just ... don't wipe data. If you're using Google Apps, this can get messy. If not, well, it's *probably* fine.

There are some things you probably want to do first while booted into Android 13, before rebooting to recovery or bootloader to start the retrofit dynamic partitions conversion:

- Deleting multiple users & work profiles & such

- A little spring cleaning of various settings stores

- Removing any installed updates to system apps

- Resetting runtime permissions

1. Deleting mutliple users & work profiles is just what it sounds like. I think those are all in Settings > System; turn off multiple users & guest user, delete all their data, whatever. Work profiles can be a little more hairy; you have to check & see if you have any device administrator apps like Island or Shelter (or an actual work profile), and disable or uninstall those for now.

2. Settings spring cleaning (copying some relevant bits from a note I have in the TG group):

Make sure you have turned on the "Allow rooted debugging" toggle in Developer options, plug the phone in to USB, and restart adbd in root mode on the computer with `adb root`, then open an adb shell as normal with `adb shell`, and you should have a superuser (#) prompt.

Do `pm list package | grep settings` and `pm list package | grep Settings` and copy the output into a text file or something.

You're looking for packages that DON'T have "auto_generated_rro" or "overlay" in the packagename. The actual top-level settings stores, like `com.android.providers.settings` or `org.lineageos.lineagesettings` are the ones you're after; don't need to redo the commands for their children as well.

For each one of those, do `pm clear <packagename>`.

While we're at it, let's tidy up any leftover cruft that might've accumulated in SystemUI data due to ill-advised UI mods (or ill-advised framework modifications by the ROM devs 😅 ). Do `pm list package | grep systemui` and `pm list package | grep SystemUI` to get a list of candidate packagenames, and do `pm clear <packagename>` for those as well.

3. Removing updates to installed system apps (usually if Google Play Services updates itself, but just in case) isn't a bad idea, since that system app might not EXIST after updating. This one's easy; while you still have that root adb shell open, do `pm uninstall-system-updates`.

4. Resetting runtime permissions will force Android to treat the next boot as an upgrade and recompute permissions for ALL installed packages, even ones that have mysteriously suddenly appeared in /system/priv-app/ that weren't there before. It's like forcing a first-boot without having to format userdata, magical!

Do `find /data/misc_de -name 'runtime-permissions.xml' | xargs sed -i -E 's/fingerprint="[^"]+"/fingerprint="dummy-value-force-upgrade-path"/'`, and finally, do `reboot bootloader` to restart the phone into OEM bootloader for fastboot commands.

-- optional, if you had Google Apps or microG installed --

At this point, if you had Google Apps or some kind of microG insstalled, you should actually enter recovery & re-flash the current crDroid 9.x ROM zip, then boot into system WITHOUT RE-FLASHING GAPPS OR MICROG (yes, I know; that's the opposite of all the advice ever. this is uncharted territory here). Get that superuser prompt again with `adb root` followed by `adb shell`, then run the `find /data/misc_de -name 'runtime-permissions.xml' | xargs sed -i -E 's/fingerprint="[^"]+"/fingerprint="dummy-value-force-upgrade-path"/'` command a second time, and `reboot bootloader` again.

-- /optional --

Now go ahead with the dynamic partition conversion & first-time installation guide in the github gist as linked.

Just... skip the step for formatting data.

Not a supported configuration by any stretch of the imagination, but... hey, maybe it'll be great!

Boy that's been a thing.

Two primary options I'd recommend trying:

1. SwiftBackup, which still has an in-app purchase "pro feature unlock" ability via Google Play Store. HOWEVER; they have embraced the "no Google required" approach, and it's now POSSIBLE to manually run an app, messaging, and wifi backup, without using an account (i.e. no Google login required & no pro features available), to internal storage, and you deal with copying that to a computer, and then restoring it again after a wipe.

They have instructions for how to do all this and run it in "no Google login required mode for manual backup & restore" on the website. It's reasonably fast & works okay.

I used that when I migrated my stuff to Android 14 for a clean flash.

I actually had some issues with a couple MMS conversations, but then I have a morbidly obese SMS/MMS database that is probably corrupt as hell, having spent years backing up & restoring it via TitaniumBackup. Largely it all worked great; and I applaud the SwiftApps team making it possible to use it for free, and without even needing Google... worth considering the pro purchase if you value the quality-of-life features like cloud backup destinations & scheduled automatic backups, just as a "thank you".

2. NeoBackup (formerly OABX), is kind of the FOSS version of the above. It's the evolution of the OpenAndroidBackupX project, brought under the umbrella of the "NeoApps" open-source project (along with NeoLauncher, formerly known as "OmegaLauncher" back during the early days of "wtf is going on at Lawnchair?!"). It has a very similar feature set & limitations; you can back up apps & app data, call log database, the messaging database, and you can back up the wifi access point database.

With both apps, in order to RESTORE messages, you have to actually set those apps as the default messaging app before starting the restore. Don't forget to change it back to your actual SMS app after restoration has completed. And a reboot after restoring system data (call logs & message database) is a good idea.

Due to changes in Android 12+, neither app is able to restore the wifi access point database. I know SwiftBackup will let you load your existing backup, and then look up the old wifi network passwords to copy/paste. Cumbersome, but better than nothing. Blame Google.

You can also certainly TRY using Seedvault as well, if you wanna take multiple backups, and see if it works to restore from that first.

Of course, again, this is all uncharted territory and nothing guaranteed to work out exactly right.

But I'd hate to make you lose your streak of 3 major android version updates without formatting, and you have certainly expressed that you know what you're getting into.

May the odds be ever in your favor.