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.