I know this has been asked before, but from what I read there is no official NO.
IIUC, /e/ OS is based on LineageOS, which has a tutorial on building it for the emulator here.
Why wouldn’t something similar work for /e/ OS?
Those part one instructions would build /e/ fine.
If the emulator were installed, and run emulator it would be interesting to hear if it was successful or how / where it failed. @newts and @Markus say it does not work, I wonder why?
Sorry, to which part one instructions are you referring to?
One would probably specify a device which built just as the Lineage standard build. Part two I see as the emulator install, I would expect that to go fine, never tried.
Part three is introducing the build. No idea why that would fail, but lots of reasons why it might fail. One would have had to substitute in the /e/ repos in part one, so maybe this would interfere, idk. The emulator will be from a fairly standard AOSP base, I expect, so it might be debuggable, idk.
Yeah, ideally there would be a device name for the emulator, then specify it like:
-e "DEVICE_LIST=eos_sdk_phone_<arch>-eng"
when starting the docker build.
From the examples on lineageos4microg ci/cd I would say the process is pretty forward, as long as you can point the build system to the necessary sources. But I don’t know how much /e/ build system is diverging from lineageos4microg one.
Not much, it is a fork. The things added by /e/ repos are separate. They add some complexity, so if one wanted to test progressively one might try pure lineage4microg, if it works and MicroG does not prove a blocker, then add /e/ repos and try again.
I do not use docker and that tends to hide what you are doing if experimenting. I would use this method [HOWTO] build /e/ the (full) classic way (no docker, no scripts, just 'make') to do the test you are contemplating.
As I read further, I can confirm that the emulator bits from LineageOS are included in the /e/ build; if these bits are missing in other non Lineage derived custom ROMs the emulator proposal would not work for those custom ROMs, I guess.
I have to wonder what you expect from the emulator? It will not actually work, it might be useful for an App developer to test his App against the emulator to see it looks ok, but probably be limited in testing its functionality, idk.
Thanks! I think that makes more sense than the docker way indeed.
Cool! Just to make sure I understand correctly, you’ve built /e/ for a device (if so, which one?) and at the end the process output had also the emulator system images? One question that pops into my mind is that ideally the emulator images would be x86_64, whereas the device images are usually arm64.
Yes, just a limited functionality device to test apps, just like Google’s distribution. Nothing fancier for now.
You are well ahead of me on the detail, I was talking in general terms; like I see in /prebuilts/android-emulator/ (this is stuff ready to use, “stock” as it were)
darwin-x86_64
linux-x86_64
update_emulator.sh
and on the output side of things in /build/make/target/product/ (ready to be used by build instructions)
AndroidProducts.mk
aosp_arm64_ab.mk
aosp_arm64.mk
aosp_arm_ab.mk
aosp_arm.mk
aosp_base.mk
aosp_base_telephony.mk
aosp_x86_64_ab.mk
aosp_x86_64.mk
aosp_x86_ab.mk
aosp_x86_arm.mk
aosp_x86.mk
base.mk
base_system.mk
emulator.mk
emulator_vendor.mk
sdk_phone_arm64.mk
sdk_phone_armv7.mk
sdk_phone_x86_64.mk
sdk_phone_x86.mk
sdk_x86_64.mk
sdk_x86.mk
So this sort of demonstates the way that the bits are available in the /e/ build for a specified emulator to be built with the correct commands.
I have built for OnePlus One bacon and Samsung A3 a3xelte but there are no emulator images produced in these builds, as I never asked for one.
Thank you!
I managed to start the emulator images building on lineageos4microg, but I got stuck at this error:
FAILED: ninja: ‘external/chromium-webview/prebuilt/x86_64/webview.apk’, needed by ‘out/target/product/emulator_x86_64/obj/APPS/webview_intermediates/package.apk’, missing and no known rule to make it
Before going down another rabbit hole trying to fix this, I’ll try the /e/ build with the same settings.
This might be a git-lfs item – are you aware of this notice:
ROM Builders - Unofficial and Custom
- A new Docker image has been released
- Those building using traditional repo sync method refer android_prebuilts_prebuiltapks_lfs
- You will have to install git-lfs (sudo apt-get install git-lfs)
- After completing a repo sync, you will have to run repo forall -c ‘git lfs pull’
Quoting from Development Updates – I think I see a reference to Lineage4microg using the same.
Interestingly enough, eos docker build code contains references to env vars like IS_EMULATOR and BACKUP_EMULATOR.
Unfortunately following this tutorial to build eos (even without setting the above env vars) terminates with this error:
Missing "vendor/lineage", aborting
I’m still trying to go docker way in order to avoid installing all the dependencies needed on my main machine.
uh, can be misleading error message, gave it its own thread at 'Missing "vendor/lineage", aborting' - docker build error explained
check the repo command log, it most likely explains the reason
2 Likes
It looks from here as if you now have two rabbit holes pointing (loosely) to repo (sync) errors.
In my experience docker will carry on with a build without ensuring “repo sync complete”
Did you check if external/chromium-webview/prebuilt/x86_64/webview.apk exists in your build environment? Are you building in Q or R?
I find that external/chromium-webview/prebuilt/x86_64/webview.apk exists in Q – but also a fairly complicated external/chromium-webview/README which looks pertinent to your emulator.
1 Like
Thank you guys!
I have tried multiple versions, including R. But fist of all I have to admit that I’ve been lazy and trying to get an emulator image as “cheaply” as possible without going through the process of understanding what is happening, neither following on the errors too much. I just hoped I would get away with just trying a few build configurations randomly. I know this is quite wrong!
In any case, I did make some progress.
- I’ve built a docker image (tagged as
myeos) using this repo. - Ran this:
docker run \
-v "/srv/src/eos/e/src:/srv/src" \
-v "/srv/src/eos/e/zips:/srv/zips" \
-v "/srv/src/eos/e/logs:/srv/logs" \
-v "/srv/src/eos/e/ccache:/srv/ccache" \
-e "BRANCH_NAME=v1.4.1-r" \
-e "DEVICE=x86_64" \
-e "BACKUP_EMULATOR=true" \
-e "IS_EMULATOR=true" \
-e "USER_BUILD=false" \
-e "ENG_BUILD=false" \
-e "BUILD_ONLY_SYSTEMIMAGE=false" \
-e "REPO=https://gitlab.e.foundation/e/os/releases.git" \
myeos
- Copied the output files as specified in the lineageos tutorial.
- Made a new AVD with that image.
- Emulator starts up
But it hangs at the startup splash 
The animation works fine, but the system doesn’t go beyond this atm. As seen in the background, QEMU system is full on busy, but the boot doesn’t go any further than this.
I got /e/ OS working with Q 
Thanks @aidb for pointing that that branch potentially has everything needed to build an emu image.
1 Like
if you see the splash, there is logcat output to tell you more. You want to build a user image to get at debug I guess.
Also while branch_name env var can handle tags, better use the branch. Not relevant for your 1.4 tag just yet (build-community: return all release repo tags (!56) · Merge requests · e / os / docker-lineage-cicd · GitLab - or is it a branch? Not at a keyboard)
1 Like
Good point, I’ll check logcat output.
I thought it is best to stick to a tag to get reproducible (and hopefully stable) builds…
One thing that I don’t understand and appreciate clarification on is the /e/ OS docker image. I have build my own docker image from this repo because it had some emulator references. But the official /e/ OS docker image called
registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community
doesn’t seem to be built using that repo. This is confusing, at least to me!
First, congratulations for your emulator build! 
I agree with that.
Are you sure?
Going to:
can show:
Url is registry.gitlab.e.foundation/e/os/docker-lineage-cicd:community, seems pretty familiar to me 
NB : you can forget the :5000 thing, as registry is also available though HTTPS (443).
Thank you @smu44!
I believe I am confused because I thought that the CI/CD that published the docker community build image is using the master branch.
Sorry if I look silly now, but here’s what I did:
$ docker pull registry.gitlab.e.foundation/e/os/docker-lineage-cicd:community
$ docker run -it --entrypoint bash registry.gitlab.e.foundation/e/os/docker-lineage-cicd:community
$ root@5e642ef98714:/srv/src cat /root/build.sh | grep IS_EMULATOR
// returns nothing
whereas if I look at the file in the repo on master, the IS_EMULATOR var is there.