Details of this proposal are in this issue in gitlab. It is based on discussions in this post in the forums, and this response to it
Please feel free to respond either in this thread, or in the gitlab issue
14 Likes
First thoughts
A first attempt at an /e/ Core ROM would be a custom build with
-
The following /e/ apps removed
- Apps
- Browser
- Calendar
- ESmsSync
- eDrive
- eSpeakTTS
- LibreOffice Viewer
- Magic Earth
- Message
- Notes
- OpenKeychain
- PDF Viewer
- Tasks
- Weather
-
/e/'s fork of MicroG replaced by the official upstream
-
Bliss Launcher (for iOS fans) and OpenLauncher (for fans of the traditional Android experience) both included. Users will be offered a choice during first time setup, and can switch using Settings | Apps⌠| Default apps. (That is assuming Bliss can work without the Weather app. I will check that by installing it from F-Droid on a device without the Weather app)
-
F-Droid and Privileged Extension, Aurora Store and Aurora Services included so users can install the apps of their choice
-
/e/'s Account Manager replaced by DAVx5 - a minimal build without that is essentially LineageOS for MicroG.
2 Likes
A âminimal /e/ buildâ is awaiting and discussed since this forum exist.
Proposing it as a manifest file and custom builds from the community is a good coherent thing.
For Official builds, the âcore conceptâ could be completed by a mandatory additional âmeta/e/packâ, that resolve the technical limitation of /system partition size.
During this second step install, system-apps have to be automatically installed, but the rest of the native-apps proposed by the e-team should be chosen or not by the user.
After that, user must have the ability to remove or replace the non-essentials apps.
3 Likes
@piero How about installing suggested native-apps as user app already with the update? There has to be some way to detect devices that are (up/down)grading (already have /e/) and skip this.
@petefoth I like your approach. However would switch app store would diverge too much from /e/ philosophy (bad choice of word I guess) and having multiple launchers unaligned with minimizing size of core set?
Good points. Iâm not going to try to answer them all now. Iâm working on a proof-of-concept, which Iâll share details of when I feel happy with it.
Briefly I aim to produce the following
- A âbare-bonesâ (âAdventurer Editionâ - thanks @aibd) build which allows a user complete choice for every app, with almost nothing pre-installed
- A âno-cloudâ build with the /e/ apps that donât need an eCloud account
- A âwith-cloudâ build which will fit in devices with very little space such as OnePlus One (bacon) which does not have space even for the
MINIMAL_APPS/e/ build, and has not had a working build sincev0.18
I have a good idea how to do the above, but Iâm not going to share very much detail, or discuss it much further until Iâve spent quite a bit more time on it. I do welcome ideas and suggestions, but I may ignore them to start with, until Iâve got something to show 
4 Likes
OK this is what I plan to work on for a while:
https://git.coop/phone-custom-roms/backlog/-/wikis/e/E-Editions
As mentioned above, comments are welcome, but may be ignored
2 Likes
Why is this extra stuff needed? Cant u use a branch for the minimum build, or the buildscripts already present in the docker build script? (pre-build.sh etcâŚ)
Because, as I mentioned in the linked pageâŚ
I already have the build environment set up
âŚwhich is what I use for making my custom builds.
The android_vendor_extendrom project eases the process of making ânon-standardâ builds based on e/OS. I use it alongside @steadfasterX 's android_vendor_e project which makes it easy to build /e/OS using the âtraditionalâ Android build tools.
This particular set of âextra stuffâ around the âtraditionalâ Android build tools is well documented, works for me, and I find it easier to work with than the âextra stuffâ that Docker and its associated scripts bring to the process.
I am sure it would be possible achieve what I in many different ways: I have chosen this way because it works for me 
Oh, ok. I donât see the easing, but that personal preference. âcore OSâ is planned a long time ago right? Why not work directly on the e-source in the form of a branch? maybe i miss the point?
I also build a custom âbareâ version of /e/ with no edrive, aps, weather etc. Only had a problem with notes or tasks, donât recall exactly, then the rom would not boot anymore.
Indeed. And nothing much has happened, because the /e/ Foundation has other priorities and will focus the efforts of their paid developers on the stuff that has - for them - higher priority. If anything is going to happen, then it will need to be done by someone from the volunteer /e/ community. It happens to be a question which has captured my interest. (It also happens to be in someways similar to an open source project with which I was loosely involved for a time in my paid employment, which looked at how to integrate open source and free software components into complete custom operating systems.)
Because neither the problem nor the solution is specific to /e/OS. In general terms the problem can be expressed as
How can I further customise an existing custom Android ROM, by removing some components of the original, and adding other components - either to be built from source, or to be included as âprebuiltsâ from other custom ROMs, git repos, or app repos such as F-Droid?
The good news is that the android_vendor_extendrom project has already solved this problem for me with /e/OS, in a way which I think is quite elegant I currently use it to make a custom build with some /e/OS components removed, others replaced by their upstream equivalents, and others included just because I like using them
I am pretty sure that android_vendor_extendrom also solves this problem for other LineageOS-based custom ROMs (LineageOS itself, LineageOS for Microg, maybe even iodĂŠ if they ever get round to opening their source).
So I will continue to work with android_vendor_extendrom because:
- I know it works;
- I know how to make it work (and I find it much easier than messing with Docker files or shell scripts)
- I have already submitted patches - and had them accepted by the owner - to make it do what I want / need it to do;
- it provides a generalised solution, not one specific to a particular custom ROM. (One of the âstretch goalsâ I have for this proof-of-concept is to produce an 'edition` of another custom ROM alongside the /e/OS âeditionsâ)
Thatâs useful to know - thanks. I remember when I first started working with /e/OS (and trying to build it), it was stated that it would not run without the Notes app. Thereâs definitely an experiment to be done to see if that is still the case
2 Likes
I have to say Iâd really appreciate an e/os version without anything. Just the bare minimum that the phone needs to run android. I want to be able to install exactly what I want without the os forcing me to use or root uninstall apps I donât need and I want to be able to choose whether or not I want to install microg.
1 Like
An interesting suggestion. Would be great to see some development around making default applications uninstallable. I remember we had put in some efforts around that concept during the initial days. Most of the default applications are interconnected in the code which made removing them difficult. Lack of resources had made us stop the work then. Maybe a joint effort from the users and development team can make that possible.
6 Likes
Iâm aware that certain default apps simply canât be removed if you want the phone to work but a lot of them can. I currently still have Contacts, Message, Telephone, Recorder, Clock, Camera, Gallery, and Files installed. As far as I know thatâs the bare minimum needed for the phone to work (even though you can replace some of these, a lot of apps still depend on the stock versions to work).
Thatâs how Lineage is delivered. After installing that you can just decide if you want to install microg, gapps or neither. My phone doesnât have Lineage yet but as things are right now Iâll probably change as soon as itâs available to regain the option to customize my phone exactly how I want (although Iâd stick with /e if there was such a bare minimum version).
1 Like
Ok, lets join forces I can share what I have done unto now: (this is the quick and dirty way, but useful I think)
The removal takes place in different places, in the manifest some stuff is removed. Trebuchet is included here because I remove Bliss (different spot) and there must be at least 1 launcher.
In pre-build.sh (which u donât use but that does not matter):
micro is replaced with the ânormalâ version from the website, I just replace the one already in the repo (with the same name, kind of a hack)
/srv/src/PIE/vendor/lineage/config/common.mk is replaced with this:
The icon pack is replaced because I want the nice /e/ icons. For example magic earth is installed, it will get the âmapsâ icon.
Then removal of apps in the pre-builds folder, because they still get build even if removed in common.mk (above) Donât know why that is.
Remove Email:
Then the removal of some evil Google code like 8.8.8.8:
And for private dns some changes (canât share because I use a private server for this)
pre-build.sh:
3 Likes
Thanks for the suggestion (and for the information youâve posted, which is very useful).
However, I am going to carry on with my original approach (using android_vendor_extendrom) because, if I get it right, it will allow people to build their chosen edition just by setting an environment variable (e.g. export E_EDITION='E_CORE'), with no need to tinker with manifests. Clearly you would choose to do this in a different way, but Iâll stick with my way for now
2 Likes
The approach does not matter, in the end code must be compiled. Anyway, I took a look at the Tasks app, the OS did not boot fully, hereâs the log:
And here the solution
Comment out or delete the code in DefaultPermissionGrantPolicy.java:
I now have:
Clock
Settings
Gallery
Phone
Very happy with it, feels so clean!
2 Likes
With v0.20-q the phone boots and runs fine without Tasks
there is a differencence in code:
The choice âsupportingâ 3 or 4 versions of Android makes it complicated. I still build pie for the FP3 because i know it works great, security patches still available.