[HOWTO] Building /e/ ROMs - a Beginner's Guide

eOSWiki HOWTOs
1

I was asked in another thread

I started to pull together all the links - to these forums and elsewhere - that I have found useful. After a while, I decided to pull that information, and other stuff I have learned since I started trying to build ROMs. After a while, I decided to take all the notes I had made and convert them into “Beginner’s Guide”.

This is not intended to duplicate information from the Official /e/ OS How to Build the /e/ ROM? document.and the other information in the /e/ Documentation and in these forums. Instead my intention is to point at the ‘authoritative’ (and - with luck - up-to-date) sources of the information, and to provide ‘extra’ stuff based on my experience.

It is intended to be a starting point for people who - like me - want to make /e/ OS builds, but don’t have much (any) experience of building Android custom ROMs. It assumes a reasonable familiarity with working with computers, but tries to be accessible for those with only limited experience of building software, and of working with command line tools, remote machines etc.

The first version is incomplete (and badly needs editing), but I hope to keep adding to it when I have time, and as I find out more. I hope that it can be a useful resource for anyone wanting to start building ROMs.

The document can be found in my git.coop Wiki

Any feedback is very welcome: criticism, suggestions for changes / additions / deletions

Much of what I have learned has come from other /e/ ROM builders and users, to whom I am very grateful, including @Unknown, @Anonyme, @harvey186, @itsclarence, @steadfasterX, @Manoj, @Ingo_FP_Angel , @LEPT and others. Thank you all!

11 Likes
2

Looks like one has to register at git.coop in order to access the wiki. Is there a way to make it publicly accessible? Or mayber later once you feel it’s good enough for everyone to see?

3

Thanks for spotting that deliberate error :slight_smile:

I have moved the article to a public repo, and corrected the link (I think)

2 Likes
4

Hello Peter,
I would love to learn and actively contribute to the success of your project. But I fail at the very first step - registering with git.coop.

My email account is with tutanota com, a reputable, reliable and secure email provider. Nevertheless, git.coop claims:

1 error prohibited this user from being saved:
Email domain is not authorized for sign-up

How can I overcome this barrier?

2 Likes
5

Hi @SuzieQ

Thanks very much for your offer to help.

You should be able to view the Wiki page, the repository it is part of and the group containing this and other repositories without having to register or create an account. Please let me know if that isn’t possible.

git.coop is a Gitlab instance hosted by the Webarchitects Co-operative and it provides hosting for members of the co-operative. The error message you saw really means “Sorry! Accounts on this gitlab instance are only available to co-op members”, but it was written by a software engineer, not a writer :wink: So if you wanted or needed an account there you would have to join the co-op :slight_smile:

The way things are currently setup, the document is a Wiki page, rather than a normal file in the git repo, so only people with a git.coop account (i.e. co-op members) can edit it.

If you wanted to contribute to the document - and that would be great - then the easiest way is for me to change the document so it is a normal file within the git repo, rather than a Wiki.

Then you can either clone the repo on your local machine, or fork it in a public repo on github or gitlab, make your changes, then submit them as patches or pull requests.

If you’re happy to do that, then I’ll make the necessary changes, If it seems too fiddly, or too much hassle, then please feel free to just send emails, or forum messages or make comments in this thread.

Please let me know what works for you.

Pete

2 Likes
6

Hi Pete,
your explanations are great because clearly understandable. Thank you. It did ‘Ahh’ for me.

Please don’t make extra work and effort for yourself at the moment. I need to be able to see to what extent I can contribute something useful, because as a ROM builder I am at the beginning, 1st grade primary school, so to speak.

How and where can I ask questions without you having to change the wiki now?

My first question on your git coop instance would be: What would be your recommendation for a well-equipped private desktop workstation in my workspace? I was thinking of an AMD Ryzen XXXXX, 32GB RAM, SSD + HDD, etc… Internal line via stable fibre optic connection is already available.

Regards.

1 Like
7

@petefoth Sorry to bump this 3ad but, since you recommend to “build in the cloud”, it would be interesting to have a wizard-driven vnotebook like these (but, of course, device-agnostic):

Do you tink is possible ?

1 Like
8

I have no idea, and I’m not sure what the point would be. It is already possible to build locally or in the cloud, using either the official way using Docker or the unofficial android_vendor_e project. I don’t see any need for yet another method.

9

Well, even if we perfectly know that human intervention is always necessary, it would be interesting to have a wizard that allows users to build by just providing addresses of correct repositories…

…to get a concrete idea of what we mean, you can check SwinIR or RealESRGAN (super-resolution NN upscalers) colabs:

Hope that inspire.

1 Like
10

…as you can see from this discussion, even “skilled” users may encounter problems in building (with guides too): don’t you think that a wizard could help them more to reach their goal faster ?

2 Likes
11

No I don’t :slight_smile:

There are lots of resources to help people who want to make builds: 50+ results for “howto build” in these forums alone, plus all the information in forums and wikis about Lineage OS, Android AOSP, and lots more. Adding another resource would just provide more things to read.

And would you make a wizard for building with Docker? Or without Docker? The traditional way with only the standard AOSP tools ? The traditional way using the android_vendor_extendrom project? To build in the cloud or locally, or in a local VM. Or in Google colaboratory?

The way you want to build, and the resources you have available will be different for other prospective builders.

To be able to build, you need to

  • spend the time learning how to do it, why you might be better doing it one way or a different way.
  • read the guides that are available, and ask questions if you don’t understand.
  • try building an officially supported device first - using whatever method you fancy. It should just work. When it doesn’t, try and work out why, by asking others, by trying to figure it out yourself.

There is no easy way to do it, and the only “wizard” that will help will be wearing a pointy hat, waving a magic wand, and studying - or teaching - Software Engineering at Hogwarts :slight_smile:

3 Likes
12

…that’s why most (potential) users prefer to ask instead to build themself.

Thanks anyway for all explainations.

2 Likes
13

Mass doesn’t mean class. Less is more is not only a saying that has become a winged word and means for me not - minimalism, but concentration on the essentials.

… but the majority of those who have already learned it and know how it works give me the impression that it is easy - which it is not. It reminds me of my student days: luminaries of professors and lecturers with a knowledge like the Encyclopaedia Britannica were not able to convey their knowledge to me in a way that I could understand.

Right! That’s why I appreciate the /e/OS GSI images. They give me a relatively quick sense of achievement, even if it’s not always as easy as the majority of published guides suggest, depending on the device.

1 Like