It’s exciting for me since it would mean my TeraCube TeraCube_One TR1907Q ruby would be on a newer base OS than 10/Q like it is currently with the OEM image.
Be nice to have it match my TeraCube 2e emerald and zirconia, and my wife’s Google Pixel 5 redfin.
Hello,
absolutely not.
First, if you came from a previous release, it would be better starting again from a clean device, unless provided for by the builder or team, see ota.
It is always a major upgrade.
So, eventually, from s to t, doing backups, erasing the current version and only then clean flashing the newer release.
Regarding your question, flashing t over s jumping a clean installation, could get you issues.
Second, the recovery is just a part of the os, clearly important, but it is not the os itself.
I clean flashed and i am running t without e recovery, i use twrp, and my device just runs fine.
In short, it is not a recovery speech, it is the way you installed your rom that is essential.
We have a flash-party this Saturday: if /e/ 1.16 was not released (or if recovery binaries for 1.15 were not available) on Friday, we’ll need to know which workaround we can have.
For example, which recovery to use for /e/ 1.15 for starlte (Android R): https://images.ecloud.global/stable/starlte/
I am sorry, but this is getting really frustrating… Delay after delay… At this point it might be better, to just don’t give ETA’s at all… Why not fix the builds with missing recovery files first, then work on 1.16?
My device has been pretty much unused because I did not set it up yet because I wanted to go with eOS but don’t want to have to install everything again. So I decided I wait for the release. But weeks go by and the release is still not available.
I know that this is free software but still, you are clearly creating expectations of which, a large number cannot be fulfilled or only with very large delays.
Please don’t take this as me trying to be rude or offensive, I am just disappointed in how things are going so far…
I’m all for this.
Let’s be realistic and transparent regarding the challenges of software development and in case of inquiries just give all ETAs truthfully as “when it’s ready”.
The task @Manoj has, of keeping us informed of what’s happenning on the development side, is a thankless one. I think he’s doing a good job of giving us frequent, timely updates, even if the updates aren’t always what we want to hear. I prefer this, as opposed to no updates from the devs.
I see a lot of posts from users frustrated with the week-long delay in the release of v1.16. Imagine the disappointment on our side. Here was a task we had thought was in the final stages, we had initiated the releases. I had put out the ETAs, and we all went to sleep, peacefully. The next morning, when we checked the build servers, we see multiple issues spread across devices. Builds failing due to multiple reasons. When you have about 200+ device builds, we do expect a few to fail - 10 to 15. We now are working on restarting the builds across Q, R, S, T. The one-week delay forces us to push back our other tasks planned, but that was necessary to deliver a stable build. We now plan on starting the release from 24th Oct.
Hi @mossroy I believe you are aware that we have held back v1.16 and will be releasing it by next week. This would be too late for your flash-party. The last starlte build with a synced recovery was v1.14 on R
The suggestion from the team is, if you are planning on flashing the starlte use the command line method instead of the Easy Installer and use the v1.14 R build + recovery. User devices will get OTA updated to v1.16 and above when it is released.
@mossroy, https://openandroidinstaller.org/ supports starlte and does support the use of “local files”. It is thus possible to prepare (and test) needed files in advance.
@mossroy I created the issue, using Win. Are you on the same OS on your flash-party? At a local Repair-Cafe, I also help people with flashing /e and Odin/Win has lowered the barrier for many, to get started.
Thanks @Manoj : at least we have an official recommendation, even if the situation is clearly not ideal for us.
starlte device was just an example. For now, we don’t have this device to be flashed on Saturday, but we’ll have a dreamlte, for which the problem is the same: https://images.ecloud.global/stable/dreamlte/
Ok for the procedure: use manual steps instead of EasyInstaller, and install 1.14 instead of 1.15
@make-nz@aibd : we use linux laptops for the flash-party (but can run Windows 11 in a Virtualbox VM if necessary). We’re quite comfortable with adb/fastboot etc.
But when EasyInstaller is available for the device (and works), we prefer to use it, as it can convince the end-users to try by themselves afterwards.
We can not test in advance, as we don’t have the devices: each attendant of the flash-party will bring his own device on D-day