I would recommend users interesting in flashing the GSI to first read the Understand all about the GSI guide especially the section on what a GSI cannot do.
The install guide is a bit cryptic at the moment. This was on purpose to keep the GSI out of the reach of users who are not experts in installing and flashing ROM’s
Summary : If you have a device which is
Not supported by /e/ as of today
Treble project compatible device
then try out the GSI and share your feedback.
To understand what these terms means read the guide given above.
OTA OS Upgrade
Device we are testing on S9 / S9+ Will add more devices later
Sideload option tested and found to work perfectly. This is an alternate method for cases where the OTA does not work due to network issues.
One round of OTA testing completed successfully yesterday.
OTA testing from my side should happen today.
This is how the screen will look when the OS OTA download appears…
In this case I am on Oreo and the build I see is a Q build. Check the size of the build it is 1.6 Gb as the firmware is also included in this build. Testing in progress…will update
12 May Update The OTA OS upgrade testing from /e/ Oreo to /e/ Q on the S9 was successful. Will share details of the steps in the documentation we will release for this. As it was a sideload there was no data loss. To be honest it was a test device and all I had were the default apps with a couple of ID’s . All the same the data as retained across the upgrade.
Work will start on adapting for more devices soon.
Any testers available We would like to have a few users willing to test the S9 upgrade. Anyone interested ? You should have the /e/ OS oreo build on your S9 and ideally it should be a test device. Let me know in case you would like to help test the OTA upgrade for the S9.
Check out this post with more details
Android R
We are starting the customization of the source code for Android R soon. No ETA’s as yet but it took about 2-3 months for the Q customization which gives a rough idea about the time lines… New device additions
Starting from week 21 we will be adding a set of devices to the supported list. I will share the device names as we reach the ETA’s . The best part in these devices is we have dedicated ROM Maintainers for them.
Regarding the S9 update, in case the OTA is not as simple as planned, where can I find more info on the sideload option? Would it wipe the phone or does it also function as an update?
As mentioned in the initial post I did not find any data loss after the sideload. I did not do any wipe or format it was a direct TWRP sideload using the adb commands. You can also do a sideload through the TWRP screen >> Advanced >> ADB sideload and on the PC you run the adb sideload commands.
We will share a document on how to upgrade you can follow that when it comes out.
It seems like Google abandoned it’s naming scheme since “Android 10”. So no more “Sweets” nor letters at all. From Android 10 on it’s just “Android 11” and it’s follow-up “Android 12”. You should get used to that too
Although this would bring up some altered naming for the /e/-OS releases too.
Why? What if the e foundation just decides to stick with letters for marking Android versions, because they can?
Would phones running /e/ spontaneously combust ?
LineageOS do their own numbering. LineageOS 18 is Android 11. Seems to work nonetheless.
How about just restarting with “A”?
I estimate it will be a few years until that could lead to confusion, and then somebody smart would say “Haha! That letter could actually be confused with this older Android version we had in Stone Age!” and we would all smile about it for a moment and just get on with it .
Would work until Z, then they have to start with something like “AA” or so. Like mentioned above, Z+1 would also be possible, either way it’s just annoying.
It’s just a pain. I need to look up the corresponding Android version every time when seeing LineageOS versions. This is also just annoying.
Seems to be equally smart like Microsoft calling their Windows 10 follow up Windows 95 …
/e/OS{version}-{basedAndroidVersion}-{timestamp}-{branch}-{deviceCode} would hurt no one and everything is just there without the need to gather additional information.
I would actually support that.
You just made it sound at first like Google’s change of mind concerning letters and sweets should somehow force /e/ to make a change in the current /e/ version string, a necessity to follow Google I don’t quite see that strongly. And then I just gave a pragmatic example how to deal with going beyond the letter Z, I don’t pretend it would be awesomely clever, it just wouldn’t break anything either.
Somebody in Redmond is taking notes just now for when they need more ideas on how to annoy all the non-paying Windows users away to Linux to concentrate on what they really make money with nowadays .
.
.