Develop Reference

Is it possible to run containers on android devices?

I’m a mobile developer and recently adept at using containers with docker. I’m developing a container architecture for my graduate project. One of the modules of this architecture would need to be run on an android device. But I could not find information on how to run a container on an android device. It could be something simple like an alpine image with python.
Can anyone tell me if there is a possibility to run a container on an android device with docker, or even kubernetes?

In 2021, the answer is definitely yes.
Here is a tutorial on that topic, which shows you how to run docker directly on Android, without VMs nor chroot. Note that you do need to root your phone and build a custom kernel though.
If you only want a quick look of docker running on android without getting your hands dirty, check out this comment on GitHub.

It is possible to use it for running docker on an android device using an application like termux or userland to install a qemu package.
The best way is to use alpine linux terminal, an android app available on github.
This alpine term app has a QEMU to run like alpine ISO. All things are automated
and this works with x86_64 kernel on any android.
Some android phones have a KVM kernel so this device can run faster alpine term
Also my friends made a video on a YouTube channel to run docker on any android phone without root.

I must note that I am not an expert in Android development. But I researched on this topic, and #Emile's answer is the easiest and closest you can get - as it seems.
You can actually run Fedora (and not only) image on top of the Termux and then launch Python inside. This is obviously not a docker, but might be helpful.You can find more info here.
In addition, I've found this topic on Quora which is a similar question:
Think about it: Docker abstracts the OS and that is all. The Android
OS is quite a different kernel than linux distributions, even though
it is linux. It might be tricky to get applications meant for a linux
distribution to run on Android/Docker.
One of the main reasons to use docker is that it can provide
self-contained packages of applications which do not affect the rest
of the system. The Android applications, packaged as .apk files are
just that.
Other than that I was able to find this topic on StackOverflow which does not really resolve the issue. As the issue might be related to AUFS and some Kernel features needed by LXT which are not present in Android - now some of them is from what I remember.
Also there is a claim that it is possible on docker forum and weibo (use translation to English), but there is only a screenshot provided by user and no details on how to do it, besides "it took a lot of effort" statement. So it would seam that this is still a not well known part, or maybe someone will be able to actually provide more complementary information - maybe try on Docker forum or GitHub.

We open the Android container, which can run the docker container on the Android operating system. Not only can run Docker containers, but also other containers, such as podman. In addition, we have also enabled the container to support checkpoint and restore functions, and support the migration of containers across architectures and operating systems. See https://github.com/CGCL-codes/Android-Container for details.

Some people think it's impossible but it isn't you can run a full ubuntu on your phone by this android app https://play.google.com/store/apps/details?id=com.termux
You can even install gui envrioment and connect over vnc everything is supported in this so also docker or website hosting and so on
(Make sure you follow al install steps in the app https://play.google.com/store/apps/details?id=studio.com.techriz.andronix to install linuxes like arch or ubuntu fedora or more you have to install these it doesn't work by just opening termux)
YOU DON'T HAVE TO ROOT TO USE THIS METHOD

Android source generic product/device type differences

In the AOSP tree are basically 3 generic device types.
List is base path: PRODUCT_DEVICE, PRODUCT_NAME
device/generic/<arch>: <arch>, mini_<arch>
device/generic/qemu: generic_<arch>, qemu_<arch>
device/generic/mini-emulator-<arch>: mini-emulator-<arch>, mini_emulator_<arch>
What are the differences between and uses for mini_, qemu_ and mini_emulator_?
Edit:
After googling a bit I didn't find a detailed explanation, but this blog post pointed out, that there are three more 'products' which are neither specific devices nor generic products: full, aosp and sdk. What do these do exactly?
Edit 2:
Looking into envsetup.sh from different ROMs (aosp, cyanogenmod, aospa) it seems to be possible, to set TARGET_PRODUCT to something like aosp_<arch> or full_<arch>. Is this an alias to one of mini_, qemu_ or mini_emulator_ or does this something else?

So after digging through the android build system a bit more I think I got it now:
The following TARGET_PRODUCTs are allowed:
aosp_ is just an alias for full_. It accepts all architectures (arm, x86, mips, arm64, x86_64 and mips64) and is also used for devices (e.g. aosp_flounder)
full_ is, if no device is specified via aosp_, a full featured build for the emulator. It includes core_. (full without _arch deaults to arm)
sdk_ is just an alias for sdk_phone_. (sdk without _arch defaults to armv7)
sdk_phone_ builds the Android SDK for the specific architecture. It includes core_ too
generic_ is the basic Android platform not specialized for any board. It can build for arm (default if nothing specified), x86 and mips. I don't think this can boot on a device or an emulator.
core_ is the basic configuration for all communication-oriented android devices like phones and tablets.
mini_ somehow extends core_. It seems to be a emulator build using only the basic configuration instead of the full featured build. But I'm not sure with this one.
mini_emulator_ combine mini_ with goldfish and QEMU related files. It seems to be some basic emulator build too.
qemu_ is an absolutely minimal android build for qemu (not the android emulator). It just has the stuff necessary to boot and some command line utilities/libraries and adb.

Deploying Qt Application on Android is really slow?

As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?

Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.

(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.

Building Autotools for Android

Perhaps some of you are aware that there is an Android port of GCC 4.7.
I've tested it and it works perfectly, however when 'make' and 'configure' are out of the picture, it is rather useless.
What would it take to port Autotools, including make and configure to Android itself?
If you are wondering who in the world would develop on a phone, you are forgetting that some tablets run Android, though I myself have a phone.

make require nothing, but C library and shell; configure is actually shell script, produced by autoconf, which in turn depends on awk, m4 and diffutils. The hardest part is using autoconf and make with Android built-in shell, which is said to lack lot of functionality. Fortunately Android ports of bash already exist.
The most problematic part with porting GNU programming stack to Android is undocumented file hierarchy (device vendors tend to modify it on every whim) and severely lacking Bionic library. There is number of projects, trying to work around this issues (such as http://sourceforge.net/projects/droidoverlay/, for example), but generally this area is still to be explored.

Developing native C applications android without the NDK?

OK this is a strange one:
Is there a way someone can develop native C applications or libraries for Android without using the Android NDK?
What was happening before the NDK was released?
(It's not there for too long, I think it was released only one or two years ago).

Apparently, you can -- a friend of mine is a real Android guru and he managed to build a GCC-based native toolchain entirely by hand. He also fixed some missing parts in Android's libc. The main idea is the following: GCC has builtin support for the arm-elf-linux target, so with an appropriate build script, you can configure it to build for Android. However, you have to root the phone to run the resulting binaries. One even cooler thing is that because GCC is a self-hosting compiler, with the arm-linux-elf toolchain, you can recompile GCC once again and have the toolchain on the phone itself.

Before the NDK was released, the only officially supported way of developing Android applications was to use the Android SDK and writing your applications in Java.
As others have mentioned, it's possible to cross-compile some applications as completely stand-alone and run them on a rooted phone. The downsides of this should be obvious: very few people will be able to run your application (they also need to be root, plus you won't be able to get your application up on the Play store); and you might even run into compatibility problems yourself across different devices e.g. if you rely on dynamic linking against various libraries (which you might need to do in order to keep the size of the binary down).
TL;DR: it's possible, but severly limited, and not recommended.

You can compile your C code with an Android-compatible toolchain (such as CodeSourcery) and run it on a non-rooted phone, from its command line (for example through an SSH connection like SSHDroid).