Just a few months ago, we released our Easy Installer, a ready to use solution that allows users to install /e/ OS on any supported device in a matter of minutes. The Easy Installer is perfect for a vast majority of users who care about their privacy but don’t have the technical skills to flash a smartphone, thus making /e/OS a viable option for many new users who were previously sidelined.
It’s a fully integrated software application, available for Linux and Windows and compatible currently with the Samsung Galaxy S6, S7, S7 Edge, S8, S9, and S9+.
With the Easy installer, our goal is to support as many phones as we can to offer the possibility of switching to /e/OS to as many users as possible.
And this is where we need your help! /e/OS is currently available on over 100 devices, but the e Foundation doesn’t have the resources to develop support to all of these all on our own.
We have made the development to support a new device in the Easy Installer as easy as possible thanks to its specific architecture.
In this context, Ingo , a community member, contacted us to offer his help in adding FP3 support to the Easy Installer. Thanks to his work, as of today, you can easily install /e/OS on your Fairphone 3 and Fairphone 3+ . We are very grateful for his time and dedication to this project.
We reached out to interview him in order to know more about him, his motivations and the work he put into the Easy Installer. You can read the exchange below.
Question: First of all thanks for taking the time out of your busy schedule to work on integrating the FP3 with the /e/ OS Easy Installer. Could you please present yourself and what you do?
Answer: My name is Ingo and I’m from Hamburg, Germany.
I started programming in the mid to late 1980s, when my parents bought me a pre-owned Commodore 128 D with lots of accessories, books and other material. Of course I was mainly playing C64 games, but as all you needed for programming was there immediately without installing additional tools, I started to experiment with both Basic and Assembler. Fortunately I had computer science lessons at school which were ultra-rare back then and partly still are today.
After school I decided to study physics and during my first 4 years at university I didn’t program at all. But starting with my diploma thesis I shifted to a more software-related focus which was needed for physics analysis anyway. So I ended up working in the software industry in 2005, which is what I still do today.
At my current company — a large German online shop — I’m mostly using Kotlin for back-end services and Typescript for web front-ends.
Q: What motivates you to be so active in both Fairphone and /e/’s communities?
A: Even before Fairphone I was part of other communities like the Hamburg Linux User Group. I guess, helping other people out with technology issues dates back to me maintaining my aunt’s VCR as a kid…
Specifically about Fairphone: I didn’t have a smartphone at all until I learned about the Fairphone 1. I had followed what was going on with mobile phones, anyway, because as a software developer I thought I may at some point have to learn about it for my job.
Around 2010, news about people working at Foxconn committing suicide because of the poor working conditions was spreading. And even before that I had read about suicides at Renault and Peugeot-Citroën. I find this rather unbearable. So when a German computer magazine wrote an article about the crowdfunding for the first Fairphone, I got interested and joined the crowdfunding. That’s what motivates me to choose Fairphone over other brands and help people with their devices.
And since somebody has to organize the local meetups that I like to attend, I figured I might as well do that, too. I’m part of the Hamburg “Fairphone Angel” program : volunteering to act as a local contact for people who need assistance but doing so in person rather than writing back and forth in chats or forums. I also handle the community Twitter account @WeAreFairphone and the corresponding account on Mastodon. I visit the Fairphone forum almost daily.
I think I first learned about /e/ when someone posted on the Fairphone forum that it now supported the FP2. But I only became really active in the /e/ community when the cooperation around the FP3 was announced. Questions about /e/ on FP3 came up so I registered at the /e/ forum in order to be able to answer/simply point to existing solutions. It seemed to me that on “both sides” there were misunderstandings about the other community, so I tried to moderate between them.
My motivation was to help people with their FP3, now with a de-googled OS that so many were asking for, even if I don’t intend to use it as a daily driver myself.
Keeping up the pace in two communities is rather demanding, so I mostly stick to the forum, plus developing and beta testing (if time permits).
Q: What made you want to contribute by integrating the FP3 to the /e/ OS Easy Installer?
A: As a Fairphone Angel I had installed other OSes on the FP2 for people who were not able to do it themselves or were afraid to do so.
When I saw that /e/ wanted to release an installer written in Java, I saw it as a chance to work on something I’m more familiar with than Electron/Javascript, the language used on the Ubuntu Touch installer I was contributing on. I know about Java back-end programming and I figured that front-end development with JavaFX wouldn’t be too different from C# WPF which I had done in a previous company.
Then there was the decision, should I first try to add FP2 support or FP3? I went for the FP3 because the cooperation between /e/ and Fairphone was rather fresh and I thought people would be more interested in the newer model.
So the first — technical — part of my motivation was to learn new technologies/improve on existing skills.
And the other part was to promote the Fairphone 3 in the sense that I know many people wanted to have a de-googled OS for their FP3. Making it easier to get /e/ on their FP3 for those not willing to spend an extra 30€ for the preinstalled /e/ just seemed right.
Q: What programming tools did you use for this development effort?
A: What I usually do when I want to work on someone’s code is to clone the source code repository, build the executable and see if it runs and how the software works.
In the case of the /e/ installer it was a bit more difficult, because I don’t own one of the initially supported phones. So I couldn’t play around and see how the important parts worked that did the actual flashing. Therefore my next step was to look around the code and understand how things are supposed to work.
I quickly came to a point where I wanted to step through the code at run time with the help of a debugger to actually see how things play together. At work I use the Integrated Development Environment (IDE) called IntelliJ IDEA so that was my natural choice of tools.
Other than that, tools were rather standard and were fixed by the /e/ devs: git for source code management and gradle as build tool. Which I’m quite familiar with in any case.
Q: What were the issues you faced in integrating the code into the /e/ GitLab?
A: The first was that I couldn’t just click the “Run” button in my IDE to execute the installer from source, which is what I had expected to work out of the box. I don’t remember what the exact errors were, but the reasons were not that hard to identify. There was a discussion on the /e/ forum how to best fix those issues and eventually the /e/ devs made the corresponding changes. This enabled us to start the actual work.
Andre — another volunteer working on adding new devices (LeEco 2/Max2) discovered the second problem, the one with the code names. The already supported models were “dreamlte” or “herolte” for example, but he wanted to add “le_s2_ww” and I, “FP3”. Those code names are used with a basic Java feature to automatically show instructional images depending on the currently connected device. But this Java feature normally is used to show different resources based on a language code and those codes must have a specific format. More or less by chance it worked for the initial seven devices because their code names had the right format. Andre came up with the idea to map the official device code names to internal codes that would then work.
Another bigger obstacle was when I wanted to build the executable and actually try to flash the FP3 with my own installer binary before giving it to someone else for testing. I didn’t have experience with the module system that was introduced in Java 9. It basically has to do with permissions which piece of code can call other pieces of code. It took me some time to get that permission configuration right.
After that it was mostly minor issues like having to add more binaries from the Google platform tools collection to the bundled installer executable because the initially supported devices did not wipe user data via fastboot and therefore didn’t need “mke2fs” for example
Q: Do you have any suggestions for the /e/ Development team and managers to make the process of code integration better?
A: When I started to work on the code, the documentation only contained one page that described how to build the bundled packages for Linux, windows and mac.
In addition there was the hint that one has to add configuration files in YAML format to describe the necessary steps for each device and which images to flash. Having just that plus code and existing configs to look at wasn’t a perfect starter.
Since then, there are more pages available, e.g. one explaining the format of the YAML files which is super helpful. But still the available documentation does not list and explain all things that need to be touched when adding a new device. I guess that could be my next “project”: provide documentation for what I think is missing.
A second problem I had when I started to work on the installer was the lack of a communication place to ask questions/exchange ideas with other developers and/or the /e/ devs.
As far as I know there is no development Telegram group and the forum wasn’t ideal either. In order to be able to focus on development questions and exchange of ideas I started a new topic, but general discussions hijacked the thread. So I would be in favor of having a closed space for developers that is invite-only. Or maybe more strict moderation of off-topic posts, i.e. moving them to the topic where they fit better.
Q: What do you think is required of people who want to add support for their device?
A: A rough overview of the steps one has to take is as follows
- fork the easy-installer repo in the /e/ GitLab and clone it to your computer
- create and edit two YAML configuration files for the device you want to add
- copy one line in Java code to add a new mapping for your device code name to internal codes
- check if you can re-use existing batch/shell scripts for the actual flashing steps or create new ones (bash/CMD)
- check if you can re-use existing instruction texts/images or create new ones
- run/test the code and package it to an executable, either in an IDE or with gradle on the command line
- find the root cause if your changes don’t work on first try
If that all sounds gibberish to you, you might not be up to it. But on the other hand I think it is not necessary to have a lot of Java knowledge for example. Maybe any programming language will do, but strongly-typed and object oriented should be a plus. Shell scripting is relevant as well. And of course it helps if you already know forking, branching and merge requests with either GitLab or GitHub.
Q: Any concluding comments?
A: The work was fun and I learned a few things here and there.
Thanks for giving me the opportunity to share my experience with the development process.
And the support/answers to my questions/code contributions on the way.
In conclusion, we would like to thank Ingo once more for his work on this project. We are very grateful to be supported by such a dedicated community.
You can read more about the Easy Installer in our documentation here.
If anyone should wish to contribute by adding the support of a new device to the Easy installer, don’t hesitate to reach out!
Regain your privacy! Adopt /e/ the unGoogled mobile OS and online services
. Nevertheless it was a pretty cool experience and with some small improvements everyone can do that who at least knows how the settings menu in android looks like.