Thanks for sharing your thoughts and concerns @archje
As far as contributing to individual ROM developers is concerned - ultimately the devices get build on the build infrastructure. The testing is done by users on the testing team on the devices. Unlike Lineage the ROM Maintainers at /e/ do not fix the issues. It is the developers who fix the bugs. The maintainers build the ROM and share it on the server. Bugs if any when they come are assigned to the development team.
Getting more developers - we have a job openings page on the documentation site. Talented developers are always welcome. We even have a projects looking for contributions page. Some of the categories are open for more than a year!
We are also working on opening up the Gitlab so that users can fork and make the changes to the code which they can then merge in. This started with the easy-installer code being opened up. Users can make changes and check in the code.
There are some issues that still need to be resolved before we can say that the gitlab for community users process works smoothly.
You can always contribute or donate as per your level of comfort. You can check where the amount gets spent here.
Thanks for sharing your thoughts and concerns @archje
I have been participating in the project /e/ since August 2018 and will continue to do so. It is a beautiful project and very promising. Nevertheless I have the feeling that the project is dispersing and that, considering the small size of the team, it puts a stop to some developments.
While I think that supporting the fairphone project is a great idea and that multiplying the number of supported phones is a good idea, it avoid us from further developing some phones that are/were considered to be the main phones in development.
Indeed, at the beginning I owned a LeTv L2 which seemed to be one of the main supported phones… but today, this phone is abandoned. In the meantime I had to change my phone so I switched to an S7.For several months now, when a migration seemed imminent to oreo… no more news.
While it seems perfectly normal to me that the planning can’t be respected, I have the feeling that the project is dispersing and, in fact, some branches are left abandoned.
I believe that it could be interesting to maintain on a handful of well-identified phones a sustained development and especially to guarantee a continuity, on the long term, of the support of these phones and this in a priority way.
Why not indicate two or three telephones that will be considered a priority and stick to them?
I appreciate and support the project /e/, these observations are personal to me and are only intended to help this project continue.
The work accomplished over the last few months is considerable. Congratulations again!
(Sorry for my english )
Agree with you on all points. As I mentioned above we have some meetings this week to thrash these questions out. Will be updating what the decision is on this thread.
As Framasoft says : “La route est longue, mais la voie est libre”
hi Manoj, for the meetings, my 2cents:
i think it would be good if /e/ designed a few phones to be its flagship phones, and if it made sure that those phones were always up-to-date with the latest Android version as soon as possible. Perhaps consider here a few phones from each market, e.g. one high end phone, one mid price phone and one budget phone. To choose which phones, i would consult data on mobile phone popularity and choose the phones in those budget groups that are most often used.
Support for all other phones would be a plus, but not necessary and can be left to the community in case of time/money constraints at the /e/ team.
Would need to think well about security updates for already existing phone in the /e/ device list.
haha i love that quote
Following up on this, would it be a good idea to prioritise a build for GSI, since it would enable a lot of phones in 1 go…? Or does it bring problems of its own?
Thanks Manoj. Re GSI for project Treble phones, does anyone have any experience with developing GSI builds generally for these phones and flashing them? Does it work well, does it indeed greatly decrease the amount of work needed to develop a build for one of the treble supported phones?
Re most sold phones :
I also support all the raised points concerning the devices and the further developments.
It would be much better to focus on a well defined set of devices (low, medium, high range), keep them up to date (general updates/bugfixes and of course the important security updates) and running smoothly like e.g. @Rik pointed out.
It’s all about user experience. You’ll probably get more users which stay because they’re statisfied, promote /e/ and that may also bring you more people who contribute to the project.
Galaxy s5 mini would be good (4.5") HD screen, good quality, etc…
/e/ must support the specially sold products for a long time. These are the Samsung Galaxy S7, 8, 9 and now also the Fairphone 3.
The devices must always be up to date with the latest security standards. Privacy can ONLY be ensured on a secured device. And /e/ sells their product with the promise of privacy. Apart from that, the devices hardware must also be perfectly supported by /e/. If that works, then something else from the 92 devices can be tackled.
yes, I agree, but good to add a few others in my opinion:
- phones previously sold by /e/ (as suggested by you @Fairphoner)
- GSI for treble phones
- most-sold devices in Europe
- a really small device
I’m curious what the decision will be @Manoj!
All : Sharing the points and some of the possible solutions that got discussed this week by the /e/ team on the subject of Device support, upgrade and porting
- On the PinePhone porting, we may have to port it directly to Android 10 / LOS 17.1 This is because we found that there are issues in porting it to Pie.
- This may also require the porting of the /e/ Source code to Android 10 or LOS 17.1
- Porting more newly released devices to /e/ ROM
Handling the Supported device list
As you may be aware we have 93 devices on our supported list as of today. While having such a long list of devices sounds good on paper there is a need to understand that the quality of service provided is more important that just quantity of devices serviced.
With this in mind - we will be coming out with a list of devices that we will support.
For now lets classify the devices that will be in the list as
- A : Devices already on Pie - no change here they will continue getting support
- B : Devices to be upgraded - where upgrade is required from Oreo / Nougat to Pie
- C : Device to be dropped - devices with 0 download by users in the last couple of months or serious build issues. This will be determined by taking stock from Gitlab.
The decision to drop some devices is also based on the facts that their Vendors have stopped
supporting them. Which means:
- No vendor patches
- If currently on nougat then no security patches . Backporting of security patches is not a
long term solution
- No support for hardware parts in case of any damage
- Some have partition size issues which prevents building a ROM with the full compliment of /e/ apps . This also prevents us at the moment from building ROM’s for them as part of the dev builds.
That being said the source code for all devices will be available on the Gitlab and interested users can still download and build unofficial ROM’s for their devices.
Solutions being discussed / planned / implemented
We are trying to check if instead of regular builds we can have a GSI for such devices. Users can get the /e/ experience and use their old devices while they last.
Adding SE Linux enforcing, Device encryption and Bootloader locking as a part of the OS installation experience. Activity of integrating this has been taken up separately for time with a dedicated developer.
We will be having a few more rounds of discussion in the next week, before we finalize what would be the course of action to take. This will be updated to all users on this thread.
We welcome your feedback on these points. We will take them into considerations before we finalize our plans.
Hope to arrive at a decision and share the future device support, upgrade and porting plan of action by the end of next week on this thread.
All devices with /e/ OS Nougat/ Oreo that are still supported by LOS 16.0 or even LOS 17.1 are suitable candidates for a /e/ migration.
LineageOS build target list
LineageOS build target list
<build_type> <period ("N"ightly, "W"eekly, "M"onthly)>
beryllium userdebug lineage-17.1 N
cheryl userdebug lineage-17.1 N
chiron userdebug lineage-17.1 N
discovery userdebug lineage-17.1 N
enchilada userdebug lineage-17.1 N
fajita userdebug lineage-17.1 N
gts4lvwifi userdebug lineage-17.1 N
guacamole userdebug lineage-17.1 N
h830 userdebug lineage-17.1 N
h850 userdebug lineage-17.1 N
h910 userdebug lineage-17.1 N
h918 userdebug lineage-17.1 N
h990 userdebug lineage-17.1 N
I01WD userdebug lineage-17.1 N
jactivelte userdebug lineage-17.1 N
jflteatt userdebug lineage-17.1 N
jfltespr userdebug lineage-17.1 N
jfltevzw userdebug lineage-17.1 N
jfltexx userdebug lineage-17.1 N
jfvelte userdebug lineage-17.1 N
ls997 userdebug lineage-17.1 N
pioneer userdebug lineage-17.1 N
polaris userdebug lineage-17.1 N
rs988 userdebug lineage-17.1 N
sagit userdebug lineage-17.1 N
us996 userdebug lineage-17.1 N
vs995 userdebug lineage-17.1 N
z2_plus userdebug lineage-17.1 N
a3xelte userdebug lineage-16.0 W
a5xelte userdebug lineage-16.0 W
a5y17lte userdebug lineage-16.0 W
a7y17lte userdebug lineage-16.0 W
Amber userdebug lineage-16.0 W
bacon userdebug lineage-16.0 W
bardock userdebug lineage-16.0 W
bardockpro userdebug lineage-16.0 W
berkeley userdebug lineage-16.0 W
capricorn userdebug lineage-16.0 W
charlotte userdebug lineage-16.0 W
cheeseburger userdebug lineage-16.0 W
crackling userdebug lineage-16.0 W
d800 userdebug lineage-16.0 W
d801 userdebug lineage-16.0 W
d802 userdebug lineage-16.0 W
d803 userdebug lineage-16.0 W
d850 userdebug lineage-16.0 W
d851 userdebug lineage-16.0 W
d852 userdebug lineage-16.0 W
d855 userdebug lineage-16.0 W
dipper userdebug lineage-16.0 W
dumpling userdebug lineage-16.0 W
ether userdebug lineage-16.0 W
f1f userdebug lineage-16.0 W
f400 userdebug lineage-16.0 W
find7 userdebug lineage-16.0 W
FP2 userdebug lineage-16.0 W
gemini userdebug lineage-16.0 W
griffin userdebug lineage-16.0 W
gts210vewifi userdebug lineage-16.0 W
gts28vewifi userdebug lineage-16.0 W
ham userdebug lineage-16.0 W
hlte userdebug lineage-16.0 W
hltechn userdebug lineage-16.0 W
hltekor userdebug lineage-16.0 W
hltetmo userdebug lineage-16.0 W
jason userdebug lineage-16.0 W
kccat6 userdebug lineage-16.0 W
kipper userdebug lineage-16.0 W
kiwi userdebug lineage-16.0 W
klte userdebug lineage-16.0 W
klteactivexx userdebug lineage-16.0 W
kltechn userdebug lineage-16.0 W
kltechnduo userdebug lineage-16.0 W
klteduos userdebug lineage-16.0 W
kltedv userdebug lineage-16.0 W
kltekdi userdebug lineage-16.0 W
kltekor userdebug lineage-16.0 W
kuntao userdebug lineage-16.0 W
land userdebug lineage-16.0 W
lentislte userdebug lineage-16.0 W
lithium userdebug lineage-16.0 W
ls990 userdebug lineage-16.0 W
m8 userdebug lineage-16.0 W
m8d userdebug lineage-16.0 W
marlin userdebug lineage-16.0 W
mata userdebug lineage-16.0 W
mido userdebug lineage-16.0 W
nash userdebug lineage-16.0 W
natrium userdebug lineage-16.0 W
nx563j userdebug lineage-16.0 W
oneplus2 userdebug lineage-16.0 W
oneplus3 userdebug lineage-16.0 W
payton userdebug lineage-16.0 W
r5 userdebug lineage-16.0 W
r7sf userdebug lineage-16.0 W
r7plus userdebug lineage-16.0 W
river userdebug lineage-16.0 W
RMX1851 userdebug lineage-16.0 W
s2 userdebug lineage-16.0 W
s3ve3gds userdebug lineage-16.0 W
s3ve3gjv userdebug lineage-16.0 W
s3ve3gxx userdebug lineage-16.0 W
s5neolte userdebug lineage-16.0 W
sailfish userdebug lineage-16.0 W
santoni userdebug lineage-16.0 W
scorpio userdebug lineage-16.0 W
shamu userdebug lineage-16.0 W
tissot userdebug lineage-16.0 W
victara userdebug lineage-16.0 W
vs985 userdebug lineage-16.0 W
X00TD userdebug lineage-16.0 W
X01BD userdebug lineage-16.0 W
x2 userdebug lineage-16.0 W
YTX703F userdebug lineage-16.0 W
YTX703L userdebug lineage-16.0 W
z3 userdebug lineage-16.0 W
z3c userdebug lineage-16.0 W
zangya userdebug lineage-16.0 W
zangyapro userdebug lineage-16.0 W
zenfone3 userdebug lineage-16.0 W
zl1 userdebug lineage-16.0 W
For the Samsung Galaxy S6 / S6 Edge (e-0.9-n), Galaxy S7 / S7 Edge (e-0.9-n), and Galaxy /S9 / S9+ (e-0.9-o), well-functioning LOS 16. 0 and LOS 17.1 builds have been available for months. Accordingly, source code and local_manifests must be available.
Samsung Galaxy A3 (2016 Exynos) SM-A310F “a3xeltexx” also known as “a3xelte” with 4.7 inches Super AMOLED Display) it is a high-quality small-format smartphone. Please read more …
Our /e/ forum member @ Panta has also been showing us for months how well his migration to e-0.9-pie works for the LG G3 d855 (3 GB RAM, 32 GB internal storage). Also @ Chimpthepimphas proven that migration to e-pie is possible for the LG G5 h850 (4 GB RAM, 32 internal storage). For both LGs, LOS 17.1 ensures sustainability. The user-replaceable battery for the two robotic LGs indicates that the devices have a longer life than many others.
The Samsung Galaxy Note 3 LTE N9005 “hlte” (e-0.9-n) is well equipped for a migration with 3GB RAM. The hlte fan community has been enjoying the official LOS 16.0 builds as well as (unofficial) LOS 17.1 and other custom ROM builds for many months. The same goes for the Samsung Galaxy S4 - “jfltexx” GT-I9505 with LOS. 16.0 and LOS 17.1.
The principle of supply and demand of our market economy: is relatively simple - goods and services are only provided if someone is willing to buy them. Therefore it makes sense to list devices of this class.
Arguments for other devices for or against remaining in the /e/ list are desired by the /e/ team.
/e/ User - your statement is needed, please!
Hi @Manoj, and thanks for your feedback !
About “C” devices with 0 downloads : some may show this poor counter from /e/, but as /e/ only offer Oreo builds for them, some users prefer to download an unofficial Pie build.
Of course, I’m talking about devices with LOS Pie support, not devices stuck on Nougat because out-of-LOS-support.
Building for these devices is quite straight-forward and unofficial builds doesn’t show any specific problem so far.
Will /e/ Foundation continue the upgrade plan and offer an official Pie build for these devices ?
That’s not clear if they will be included in “B” devices …
BTW I think “C” category should be splited in 2
Hi Manoj, thanks for this. Regarding GSI, I thought this was only possible for treble phones, do I understand correctly that it is also possible for other phones?