Week 42, 2023: Development and Testing Updates

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.

It’s still unclear to me. Without the T recovery, is a phone with the T build flashed (upgraded from S) in some kind of crippled or problematic state?

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.

I didn’t find yet the T version for the FP3. Will it be coming or are there issues?

And would you mind re-open this thread, please?

Thank you, Manoj!

Issue has been reopened as requested.

2 Likes

Thanks @Manoj

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/

Will 1.16 release also fix https://gitlab.e.foundation/e/backlog/-/issues/7225, that prevents us from using EasyInstaller ? (at least for the 2 devices mentioned in this gitlab ticket)

1 Like

Let me check with the team and get back.

1 Like

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…

Thanks for your work nonetheless!

2 Likes

Here are the extracted data necessary for a ‘clean install’ for the OnePlus 8T (kebab):
Android T e-1.15-t-20230917331436-dev-kebab.zip

fastboot flash dtbo dtbo.img
fastboot flash vbmeta vbmeta.img
fastboot flash recovery recovery.img
adb sideload copy-partitions-20220613-signed.zip

/e/ Install Instructions

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”.

2 Likes

v1.16

The device build release will be staggered over the next couple of days starting from 17 Oct up to 30 Oct.

Update 18 Oct: Release start date will be moved forward. Will update once I get a confirmation from the team

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.

17 Likes

Agree. This is dynamic and good transparency. They are moving timeliness as needed and we know immediately.

Frustrating? Sure, but less than not knowing at all.

7 Likes

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.

24 Likes

A hard, but correct call.

Thanks to you and the team.

1 Like

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.

3 Likes

@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.

1 Like

@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

Regarding https://openandroidinstaller.org/, we did not have the occasion to test it.
We might try it at the flash-party.