Gitpod: [recovered issue #723]: Is there a prebuilt image which is suitable for android app development?

[jankeromnes]

_It seems that GitHub accidentally took down issue #723, but they kindly provided the missing content so that we could re-post it._

---

@dongfangxunlei at 2019-08-13T06:55:40Z:

android SDK/NDK is so large. Is there existing image containing it? android studio is better.

@svenefftinge at 2019-08-13T12:07:40Z:

We would have that, but ATM Gitpod doesn't support running emulators in the container.

@JesterOrNot at 2019-10-05T15:21:45Z:

I'll try and see if I can get something together

@JesterOrNot at 2019-10-05T15:28:27Z:

Here is the repo in case you're interested
https://github.com/JesterOrNot/Gitpod-Android

@jankeromnes at 2019-10-08T08:51:36Z:

@JesterOrNot Exciting! Thanks a lot for setting up this repository. Have you tried to build an Android app with it?

@JesterOrNot at 2019-10-08T13:01:46Z:

I am trying but I need help most good vscode extensions for android development require the installation of android studio and I can't figure out how to do that
EDIT: I finished installing it take a look!

@JesterOrNot at 2019-10-08T20:24:12Z:

For testing, I think a good starting place is https://github.com/jesterornot/termux-app

@JesterOrNot at 2019-10-08T22:10:19Z:

it works!!!!!!!!!!!!!!!

@JesterOrNot at 2019-10-08T22:27:45Z:

now all that's left is finding a way to automate the setup of android studio! does anyone have any ideas?

@jankeromnes at 2019-10-10T13:05:10Z:

@JesterOrNot Wow, that's amazing! Thanks a lot for getting it to work. 💯

Regarding automating the setup of Android Studio, I don't think they have a non-interactive setup (e.g. via a command line interface) so I think our best bet is to find where Android stores its configuration files, and then import or generate them programmatically in your Dockerfile.

For example, you could set up Android Studio manually, and then inspect what changes that did to the file system. Android Studio probably has a configuration directory that you can look into.

(Or, worst case, we could also run the Docker image locally, set up Android Studio, and then use Docker to inspect the file system layer changes with docker diff.)

@JesterOrNot at 2019-10-11T01:14:10Z:

Great idea!
I'll get to it!

@JesterOrNot at 2019-11-16T17:13:00Z:

@jankeromnes
upon further testing when I tried to start an android project this happened

@jankeromnes at 2019-11-18T10:57:27Z:

@JesterOrNot Amazing progress! Thanks a lot for blazing the trail here. 💯

From the error message, it seems that we can't install an x86-64 AVD, because it requires hardware acceleration (VT-X or SVM). After a quick research, it seems we can't enable that in Docker containers.

So I think our options here are:

1) Use a physical device for testing

I.e. develop your app in Gitpod, and test by flashing a real Android device connected to your laptop, either by:

• downloading a flashable image from Gitpod (with flashing tools included), or
• using something like https://github.com/inlets/inlets to connect Gitpod with your local Android device (but I'm not even sure whether this can work, given that inlets is for networks while Android flashing probably requires USB interaction)

or

4) Use an Android Virtual Device based on an ARM system image

If I understand this correctly, I think using an ARM-based AVD here will come with its own emulated ARM CPU. This means the emulated CPU can have all the required features, however it will be super slow (because 100% of the hardware will be emulated in software).

@JesterOrNot at 2019-11-19T02:56:56Z:

So @jankeromnes, what are our next steps?

[Kreyren]

@jankeromnes Can you make TLDR from this? It's unnecessarily long.

[Kreyren]

Seems to be relevant to https://github.com/gitpod-io/gitpod/issues/1265

[JesterOrNot]

@Kreyren Basically
Issue reporter: I want to develop android!
Sven: Not possible
Me: I'll take a stab take a look at https://github.com/JesterOrNot/Gitpod-Android
Me: I did it (sends a lot of screenshots with Android Studio installed)
Jan: Great job Sean
Me: Oh I need KVM
Jan: Hmm we could A: Use physical device via inlets, B: downloading a flashable image from Gitpod (with flashing tools included) C: Use An ARM-based Virtual device (it will be really slow)

[Kreyren]

@JesterOrNot thank you! ^-^

i think i understand the issue, but i don't know why is solution proposed in https://github.com/gitpod-io/gitpod/issues/1265#issuecomment-591711957 not an option?

[JesterOrNot]

Neither do I, Does it work?

[JesterOrNot]

@geropl if you have time can you take a look?

[Kreyren]

@JesterOrNot i believe that referenced sourcehut is a proof of it working well.

[JesterOrNot]

I know but what about _in gitpod_

[Kreyren]

@JesterOrNot looks like same usecase to me just different product provided

[JesterOrNot]

No, I mean do we have KVM/QUEMU running in a workspace?

[Kreyren]

@JesterOrNot Based on available info we don't since that would require sharing /dev/kvm to dockerd thus proposed to replace docker with vagrant which is based on available info more secure, more efficient on system resources and does not have these limitations and is compatible with current dockerfile configurations.

hardware used on gitpod based on the data that i was able to harvest from it supports KVM (root access is required to confirm).

[geropl]

@geropl if you have time can you take a look?

@JesterOrNot Thanks a ton for your investigation. The runtime change required to be able to (potentially) open up KVM is on our radar but not within short reach. It's more several months than weeks and we're not ready to commit to a timeline for it, yet.

@Kreyren Thank you for the suggestions. We're observing the space for some time now and indeed are favouring options that would make Gitpod feel more like a VM than a container.

[Kreyren]

@geropl The runtime change required to be able to (potentially) open up KVM is on our radar but not within short reach. It's more several months than weeks and we're not ready to commit to a timeline for it, yet.

Why that long? I see this being deployed under 12 hours with hardening.

Would be willing to provide the userland and kernel assuming hardware info and abstract provided.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ceefour]

Keep this alive

[ffeldhaus]

@geropl Several months have passed, do you have an update on the current status? Is there anything missing you need from the underlying infrastructure?