Motorola One (xt1941-4) „deen“: How to build e/OS 0.22

Looking at the default launcher of /e/OS („Bliss“)

Preliminaries and Disclaimer

In this short note I will summarize the steps and ressources that took me to successfully building /e/OS 0.22 for Motorola One xt1941-4 („deen“). This build relies on device specific repos used for an unofficial LineageOS 17.1 port in June 2020, therefore, /e/OS is built on Android 10 here. All credits go to 100Daisy and Electimon for providing the device specific repos needed to build it. The LineageOS port is really a nice work, guys!

Since this is my very first custom ROM ever, and still >90% of the build process is black-box to me, please do not ask for any help in the building process. I actually do not know anything apart from what is written here…

DISCLAIMER: ALL INFORMATION HERE IS COLLECTED AT BEST EFFORT, BUT I DO NOT GUARANTEE THAT IT IS FREE FROM ERRORS, OR IN ANY WAY COMPLETE. ALL INFORMATION ON THIS PAGE MAY CHANGE AT ANYTIME WITHOUT FURTHER NOTICE. IF YOU USE ANY OF THIS INFORMATION, YOU WILL DO SO COMPLETELY ON YOUR OWN RISK. YOU MAY LOOSE YOUR DATA AND PROBABLY BRICK YOUR DEVICE, ESPECIALLY IF YOU DO NOT KNOW YET HOW TO BUILD OR INSTALL CUSTOM ROMS.

However, here is what I did:

Set up the building environment

First I had to set up a suitable build environment. This is what I used:

  • Microsoft Surface Book, 4 cores, 16 GB RAM
  • Ubuntu 20.4 LTS
  • 300 GB SSD partition
  • 8 GB swapfile

Then I followed some instructions to install the required packages and libraries. I do not remember, which one I actually used, but I suppose this will do:

https://wiki.lineageos.org/devices/FP3/build

Follow this guide up to the start of the section „Initialize the LineageOS source repository“. The instruction to setup the development environment is generic and virtually applies to all devices. You may go ahead there if you want to create LineageOS instead of /e/OS: Just skip the extraction of the vendor blobs, and use the local manifest.xml given below. Since I did not try this out, I can say no more about this.

Get the repos

You may also consider e’s own instructions at

https://gitlab.e.foundation/e/documentation/a-generic-guide-on-porting-eos/-/wikis/07:-Building-an-e-ROM-the-Repo-Sync-way

However, this is what I did:

Move to the root of your build_dir, then enter the command (in one line):

repo init -u https://gitlab.e.foundation/e/os/android.git -b refs/heads/v1-q

This will provide the most recent sources for e/OS on Android 10 / LineageOS 17.1. Next, you need to put the following device specific manifest.xml into the folder [build_dir]/.repo/local_manifests (create it if it is not there already):

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote name="device" fetch="https://github.com/" revision="refs/heads/lineage-17.1" />
  <remote name="kernel" fetch="https://github.com/" revision="refs/heads/android-10-release-qpks30.54-22-13" />
  <remote name="vendor" fetch="https://github.com/" revision="refs/heads/lineage-17.1" />
  <default revision="refs/heads/lineage-17.1"
           remote="github"
           sync-c="true"
           sync-j="4" />
  <project path="device/motorola/deen" remote="device" name="EdElling/device_motorola_deen" />
  <project path="kernel/motorola/deen" remote="kernel" name="EdElling/android_kernel_motorola_deen" />
  <project path="vendor/motorola/deen" remote="vendor" name="EdElling/vendor_motorola_deen" />
  <project path="system/qcom" remote="github" name="LineageOS/android_system_qcom" />
</manifest>

Sorry for the bad layout here, just copy/paste it in gedit and it should be fine.

Update 13.03.2021: I replaced the above manfest.xml with another version, that is hopefully more stable. Sorry for any inconvenience.

Again: All credits go to 100Daisy and Electimon for providing those repos! I just forked them in order to save them for the future.

Then you can actually sync the sources, using

repo sync --force-sync --no-clone-bundle

This will take a long time, probably several hours. If your internet connection should be disrupted, then just start this command again, sync will basically continue where it stopped.

Prepare the build

You may want to further consider the instructions linked above. However, this is how I proceeded:

source build/envsetup.sh

This will install a bunch of tools and commands for the build process.

For Linux noobs: Note that now all of this has to be done in the terminal session in which you actually will start the build. I switched to a text terminal (e.g. CTRL-ALT-F4) and even stopped the xwindows session („sudo service gdm stop“) from a second terminal after starting the build in order to save as much memory as possible.

Then use:

lunch

and select the device you want to build for. I chose lineage_deen_userdebug. It will build /e/OS nonetheless, due to the repos fetched before.

Then, you may want to set up compiler cache, which I strongly suggest. In case you have to restart the build from scratch (after e.g. doing „repo clean“) , you can save a considerable amount of time. Instead of 25G in line two, use as much memory as you can afford, but keep in mind that the complete build_dir will take approx 200 GB in the end, so you need to account for extra space for the compiler cache accordingly.

export USE_CCACHE=1
ccache -M 25G
export CCACHE_COMPRESS=1
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"

I used these commands, each in one line. The last parameter -Xmx4G sets the memory limit for Java processes. This was enough in my case, but if the build process dies due to java memory issues, the value could be raised to e.g. 6G.

Finally, I learned how to conduct something like a dry run of the build process. This will check for all the dependencies being fulfilled. Just enter:

m nothing

After some minutes it will say that the „build“ was successful, or will display errors because of missing files or libraries. If there are errors, they have to be tracked down and solved, before proceeding.

Building /e/OS

If you have come this far, it is time to start the actual build:

m -j4

The -j4 option tells the build system to use 4 processes in parallel. I probably could have done with 6, or leave it to the system to choose by just give -j as option. Quite late in the build process, there will be a heavy memory load caused by java processes. If there are several java processes each taking 4GB, a limit of -j4 seemed reasonable to me.

If there are errors, they will be displayed in the terminal, but you might as well look them up later in [build_dir]/out/error.log or other logfiles there.

If the build process is dying or killed by the kernel, you may search for the cause using e.g.

sudo journalctl -b -2 | grep -E -i -B100 'killed process'

Adapt the options of journalctl according to your situation. In my case, the swapfile (2 GB then) and RAM was complete used up, due to some other large service running in the background without me noticing it.

If the build was successfully finished (after many hours…), you will find the following files (among others) in [build_dir]/out/target/product/deen:

  • system.img
  • vendor.img
  • boot.img

Problems along the way

Basically I ran into two issues during the build process, apart from the memory being used up. I researched and solved those issues one by one, and each time continued the interrupted build process by just repeating „m -j4“. Probably, the measures can be also taken in advance, to hopefully achieve a clean build from the start, but I did not dig into this yet. I have no clue what the proper way would be to deal with this, so if anyone has an idea, I would like to know.

Update [build_dir]/frameworks/base/api/current.txt

The build process stopped with the following message:

Aborting: Found compatibility problems checking the public API against the API in /home/elling/e/frameworks/base/api/current.txt

Luckily, the message also suggested the solution:

You can update current.txt by executing the following command:
make api-stubs-docs-update-current-api

This I did and the problem was solved.

Update [build_dir]/build/core/tasks/check_boot_jars/package_whitelist.txt

Another error later on stated, that the package qcom.fmradio would not be in the whitelist to be allowed for the boot partition. So I just appended

###################################################
# qcom.fmradio
qcom\.fmradio
qcom\.fmradio\.*

to [build_dir]/build/core/tasks/check_boot_jars/package_whitelist.txt, and this error went away too.

Installing on device (incl. download links)

Of course the bootloader needs to be unlocked (find instructions on Motorola’s support pages).

Note, that I did not start installation from stock ROM, but from an earlier installation of the LineageOS 17.1 ROM. I don’t know if the procedure should be different starting from stock. The LineageOS install zip, however, basically only contained those three images as payload, so I guess it should work like this.

Update: Installing like this on another device with the latest stock rom worked all the same.

Reboot to bootloader, either using „adb reboot bootloader“ or Power + Vol down buttons.

I then flashed using the following fastboot commands:

fastboot -w
fastboot flash system system.img
fastboot flash boot boot.img
fastboot flash vendor vendor.img

Additionally, I flashed vbmeta.img, but I am not sure if this would be necessary, or if I messed things up with other devices. Any more info on vbmeta.img ist welcome!

You can find pictures and a list of what is working here. Pretty much everything is, until now I encountered problems only with the special /e/OS apps, but this is another story.

Get the img files

You may download the img files for testing purposes here. Use them at your own risk!

If you messed up your device

If installation fails and you messed up your device: Don’t panic! You should always be able to return to stock ROM. You can download it here.

If you run Linux, you must unzip the file, because the files are flashed using fastboot. This is not an OTA file that could be installed using TWRP! You will find a bash script flashfile.sh inside the unzipped folder. Just run this script (bash flashfile.sh) from the command line with your device connected.

If you use Windows, you may want to use Motorolas „Rescue and Smart Assistant“ tool to flash the stock rom.

Things left to do

Although the build seems to work really fine, thanks to the device tree repos from the LineageOS build, there are some things that should be improved.

First, the vendor files should be updated according to the latest stock ROM from autumn 2021.

Then, the next build probably should not be signed using the default public test keys, but by newly generated „real“ keys.

And since there are unofficial ROM’s out there with Android 11 for the Motorola One „deen“, it should be possible to produce a version of e/OS based on Android 11.

However, since my holidays are over, it will take some time until I can work this out. Maybe someone else can advance things further in the mean time?

17
0

3 Gedanken zu “Motorola One (xt1941-4) „deen“: How to build e/OS 0.22”

  1. Thanks for the excellent write up. I replied to your post on xda-developers with some information on how to extract the updated blobs. Perhaps we can cooperate to bring new life in this old and very nice device.

    0
    0
  2. On androidfilehost.com (see link above) there is also a version of e/OS 0.22 r (Android 11). The WebView Integration die not work well. However, if you install Google’s Android System WebView from e’s Apps, then it seems to work all right.

    0
    0

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.