What is the problem with using dev builds?
From what I know there is no real problem being on dev builds rather than stable. They are built from the same code. dev builds can even be better than stable because, as user-debug builds they allow rooted debugging, which allows more flexibility in backing up your device.
A large number of users have always used dev builds, with no obvious problems
There are no OTA upgrades for dev builds, that’s the pain in the ass. With a Q stable build I would have been automatically upgraded to R (OTA 1.4Q to 1.5R), but with my Q dev build I am now in an dead end, Q updates are no longer provided and I have to manually upgrade to R, which means total data loss and starting with my phone from the scratch again. That won’t happen to S dev very soon (but eventually will), but could come up with R dev in a year or so.
What I don’t really understand is, why the Q dev build wasn’t OTA updated to a Q stable build at any time whatsoever. That would save users from running in this annoying dead end. What’s the reason for that? Is it technically not possible?
That would be nice indeed.
I would also propose that the documentation is complemented, pointing out that you can’t switch (or get switched by updates) from a certain dev build to its stable counterpart and that OTA upgrades are not available for dev builds (unless there are plans to offer them in the future).
That would perhaps save some people from this dead end. Well, at least those who mindfully read the documentation^o^ Over my journey with /e/, I had my learning by doing (and undoing) moments, too, I have to admit, and here is another one…
In several posts in the issue tracker developers say that for dev builds there will be no OTA upgrade. I don’t understand that either.
But there is a way to upgrade the dev build without data loss: You can flash the R-dev package with adb sideload and keep data.
I did that but I am having some trouble with several apps, but mostly with root access. So if your phone is not rooted the upgrade may work smoother.
It does not mean total data loss. I have updated from Android 7 / Nougat builds right up to Android 13 / S and have never lost data.
It’s quite straightforward:
You can back up EITHER
More information on both methods here
Do you mean with “dirty flash” adb sideload? An /e/ developer recommended that procedure. I read that flashing the upgrade e.g. from TWRP is not recommended, especially not on A/B devices.
Yes, that would be nice to know! And while explicating, could you also give your opinion on a “dirty flash” from a dev build to a stable build? Do you see any complications? I liked learning to do nerdy stuff when starting with /e/OS, but now I am old and just want to stay stable, easy and comfortable, enjoying OTA upgrades in the future^o^
That looks pretty interesting, something I have longed for quite a time. I will give it a try tomorrow.
No. TWRP and adb sideload are both methods of flashing a ROM. None of my devices are A/B, so TWRP just works for me. From what I’ve read, I believe adb sideload is the best way to flash A/B device but I don’t know for sure.
“Dirty flash” means flashing the new ROM over your existing data, using either method. This is what the 'Updater" app does with updates (and upgrades), so that your installed apps and user data are not affected.
“Clean flashing” involves getting rid of your existing installed apps and user data - either by wiping of formatting - before flashing the ROM. After a clean flash you do have to set your phone up again from scratch, either by hand, or by restoring a backup.
Sorry but I can’t - none of my devices have stable builds. And I wouldn’t install them if they were available because, from what I have read, there is no rooted debugging, so TWRP is the only functional way of making a restorable backup.
I use TWRP backup for backing up my current phone, but I need/use Android Backup and Restore Tools project for migrating between devices, because restoring a TWRP Backup
ABRT handles both those situtaions admirably. The only things it doesn’t restore is account data for apps like Mail (which allows you to export settings from your old phone and import them to the new one) and Account Manager. TWRP does that better.
For upgrading via adb sideload data is kept, so restoring not necessary.
I don’t think that a data restore with TWRP will work after an upgrade. TWRP restores the whole data partition, that includes system data that will have changed through the upgrade.
For app and app data backup and restore in case it is necessary I use the 3C App Manager which is also included in the 3C-Toolbox (both from Play Store). For app data backup the phone must be rooted, of course.
It may be necessary if the upgrade (i.e. moving to a higher Android version) requires the data partition to be formatted, which has happened to me before now. In that case you will have to restore the data
It has worked for me several times on different devices, though sometimes I have needed to format the data partition before flashing . I don’t know of any system data that is placed on the data partition. Do you have any examples?
Not if you use TWRP or ABRT, though ABRT requires rooted debugging (which is why I wouldn’t use a stable build). But now I’m repeating myself so I’ll stop 
You had to format the data partition and then you restored the previous data partition and it worked. That’s amazing but I believe you.
No, I don’t have significant examples. I just see some data in the /data/ folder that does not relate to apps and may be modified during the setup completion after the upgrade. But maybe I am wrong
And yes, in the last posts we talk about upgrades to another Android version, not just updating to the next release.
May formatting the data partition have become necessary for the dirty flash only? /e/OS provides OTA packages, adb sideload should do the same as an OTA upgrade. And those usually don’t cause data loss, not even when upgrading to another Android version. At least not with stock ROMs.
Anyway, backing up data for whatever problem is necessary anyway.
Thank you for sharing your experience.
Hello,
I have successfully installed e-1.6-s-20221201239247-dev-miatoll on my redmi 9 note pro but incoming, outcoming calls and sms are not working. internet is fine.
someone can help me please?
Regain your privacy! Adopt /e/ the unGoogled mobile OS and online services
in logs I see:
12-20 19:14:37.764 1655 1870 W BroadcastQueue: Appop Denial: receiving Intent { act=android.intent.action.SERVICE_STATE flg=0x1000010 (has extras) } to ProcessRecord{b1c95f5 3252:com.android.phone/1001} (pid=3252, uid=1001) excludes appop android:fine_location due to sender android (uid 1001)
Dear dev-team! Since the last update to A11 (R) 1.6 I suffer total random reboots and shutdowns. 1.3 - 1. 4 and 1.5 worked perfectly.
I noticed that ‘random’ often is while charging with my (original) OnePlus car-charger and more ever whe te battery is “fuller” then when it is “emptier”. I never charge over 80 percent but the behaviour is for less with a battery under 50 percent.
Although I do not see a “connecting”… There might be. Also sometimes double tapping a key (to shutdown screen) leads to a switch off or reboot instead of turning of the screen.
I have no idea how to make logs, but if you tell me how, I’d love to help.
My device ia rooted with Magisk and LSPosed installed (although that was the case too in 1.3, 1.4 and 1.5).
Thanks
I edit my post Dec 13. I realize that the original post does not ask the version of 1.6r or s, so for clarification it was 1.6s that caused the crash.
OnePlus 7 pro
guacamole
Rooted with Magisk
Was: Android R 1.5
Is: Android R 1.6
Good that /e/ at last has android 12, but the question is do we have to wait just as long on 7/e/ with Android 13