crDroid was mentioned for ginkgoin another thread, but this seems to have changed as far as I can tell.
DivestOS seems to have at least hlte and oneplus3 (probably more, I just checked two random ones) listed as end of life but reported working with the last update 15 days ago. Not sure if that means they currently receive security updates or not.
Others here are probably more knowledgable – my point is, if someone somewhere is generously putting in the time and effort to maintain a port of their ROM for these devices, it would be good to find a process by which to share these efforts across various custom ROMs since a lot of perfectly good devices could be saved that way.
The decision to fork from LineageOS was taken from day one. LOS has the widest range of devices and has maintainers for most of them. To pick up separate OS for individual devices will break the uniformity of the OS and make it difficult to track. This would also require separate forks, dedicated maintainers and efforts which would be better utilized working on the one single /e/OS code base.
Of course, it is much easier to access existing LineageOS open source code than to design your own code. But this dependency on LineageOS harbors massive risks for its own business model. If LineageOS fails, as we remember from the incident in May 2020, everyone who builds their custom ROM distributions on it will lose an elementary foundation. Or LineageOS maintainers cease their activities from one day to the next, remember the very short existence of Nothing Phone (1). After LineageOS dropped the ‘Spacewar’, /e/ also immediately discontinued support.
Custom ROM distributions such as CalyxOS, GrapheneOS or other high-quality custom ROMs and GSIs based exclusively on pure AOSP are much more independent and therefore stand-alone.
It makes perfect sense to streamline the /e/ portfolio and focus on ROM quality rather than quantity. However, this will inevitably happen, as the Murena business model eats up human and financial resources.
Not really. All the LOS source is free, open and available. If the LineageOS project stopped, any project or organisation that depends on it could immediately start using their own fork.
Not really? All LOS source code is free, open and available, but if it is not developed further by the LineageOS Android distribution, then that follows:
I meant it does not really ‘harbor massive risks for (/e/`s) business model’. Please explain what ‘massive risks’ and how they it threaten /e/'s business model.
LineageOS itself depends on AOSP. Does that dependency harbor massive risks for either LineageOS or /e/?
Let me clarify, what I am suggesting is not to start forking a set of random custom ROMs for different devices.
As far as I can tell the main issue right now why these devices have to be discontinued is the lack of security patches. These are basically for code that is part of AOSP and thus shared by all custom ROMs.
If one project or person backports these patches to an older version of Android/AOSP, there is a very high chance these patches would work on any custom rom based directly or indirectly on AOSP, irrespective from the device. Thus the potential to maybe create a way by which just these patches could be shared among projects.
Similarly, when it comes to device support, my understanding is that things like device trees would not need to be maintained once for every custom ROM, but could be shared as well in a centralized repository.
Hence my suggestion to maybe find a way to create an infrastructure or process whereby custom ROM projects could pool their efforts in those areas.
Part of the appeal of custom ROMs (outside of privacy considerations) is that old existing devices that are still perfectly functional can continue to be used.
Keeping existing devices usable and saving energy that is usually consumed by constant background connections from ads and tracking are two major strong arguments in favor of using something like /e/ in a market where people are increasingly eco conscious.
Murena has three revenue streams: Device sales, donations, and services (/e/-cloud). I don’t know what the ratios are, but the latter two likely depend directly on the number of devices being supported.
One partial solution for having more ‘unsupported’ devices on /e/OS would be a GSI. The /e/OS GSI on T is in its final stages of development and testing. We should be able to release it soon.
This sounds very encouraging at first, because the information on this so far has been rather reserved and uncertain.
As with /e/OS-Q GSI, a /e/OS-T GSI will enable many devices to be degoogled, because current AOSP 13 GSIs without GApps are rare - apart from the continuously maintained Andy Yan Lineage GSIs - because most GSI builders concentrate on AOSP 14.
However, the current GSI A14 do not always work due to the Android 14 QPR2 / QPR3 issue created by Google, especially if the Linux kernel is older than version 4.19.
As soon as /e/os-t gsi is available, I will try to get a whole range of smartphones and tablets working with it. If the /e/OS-T GSI quality becomes as good as /e/OS-Q was, new ungoogled horizons will open up. We’ll see…
I wish I had enough skill in that area to do something like that myself … It just seems less than optimal that pretty much every custom ROM project is handling device support and security patches for themselves.
That sounds great, but my experiences with the /e/ GSI on olivelite were not very promising – but maybe I just got unlucky and GSI support is better on other devices.
A GSI is not a full-fledged version of the ROM. It gives you an idea how the /e/OS ROM would feel if installed on the device. We are also looking at implementing an interface with the GSI. When a user flashes the GSI, it will show the user what is working and what is not working on the device.
The best use for GSI is it will give a fresh lease of life for old phones which were discarded for lack of support. It will also let us test out newer devices which may eventually get on the supported list.
Depending on the hardware/firmware, I have had very good experiences on various smartphones/tablets with different GSI distributions including /e/OS-Q GSI, because all elementary applications work and are therefore also suitable as daily drivers. The most positive aspect, however, is that the data monster Google Mobile Services (GMS) is no longer on board.
I second @Xxpsilon statement, I also used GSI on a lot of different unsupported devices, from Samsung to Huawei and Xiaomi. I didn’t have many problems, occesional restarts on some but rarely (once a week) and it can definitely be used as daily driver. It’s very well done.
I’m very excited about GSI T, I will donate to murena once it’s out as a thank you and because it seems fair. I got so used to e/os/ that I can’t go back to ad-infested stock spyware. GSI T will expand e/os/ reach so much as it will become applicable to most of the newer devices.
