Translation(s): none

Debian install apps on Android

There are a number of free and non-free apps and scripts for Android that allow you to run a Debian chroot on an Android device.

Lil' Debi

Lil' Debi is a Debian GSoC supported project with a Debian member as a main developer that uses cdebootstrap to run the full install process on the Android device, then manage starting and stopping the chroot. It aims to provide a single Debian install in parallel with Android while touching the Android internals as little as possible. It provides a complete Debian install process and transparent boot integration. The app includes the debian-keyring.gpg so cdebootstrap fully verifies the packages it downloads from the beginning. It calls /etc/init.d/rc 2 on boot and /etc/init.d 0 on shutdown to provide boot integration.


DebianKit aims to provide a single Debian install directly in parallel with the existing Android install. This is possible since Android uses almost none of the standard UNIX paths, so Debian can just be copied directly onto the same file system. The one notable exception is that Android has a symlink to /system/etc at /etc, and there are a few files in /system/etc.


Manual installation in a chroot

This is an account of installing vanilla Debian in a chroot on Android.

This was tested on a Vodafone 845 (a re-branded HuaWei u8120 / Joy / Ascend).

Then, on a workstation (any architecture), insert the µSD card, and:

sudo debootstrap --arch=armhf --variant=minbase --foreign  wheezy  /media/PHONE\ CARD/debian

For machines without externally mountable/addressable storage, you can use the script detailed here to transfer the chroot whilst maintaining permissions etc. e.g.:

cd debian && tar czplf - . | /root/ /external_sd/unpackdebian

where /external_sd/unpackdebian contains a simple script such as:

mkdir /external_sd/local/debian && \
tar -C /external_sd/local/debian -xzf -

You will need to use --arch=armel if your phone is too old to support ARMv7.

If you have a local mirror, replace the URL above with your local mirror.

Then remove the µSD card and replace it in the phone, start SSHDroid (which provides chroot command). Then SSH to the phone, then:

export SDCARD=/sdcard
export ROOT=$SDCARD/debian
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH
export HOME=/root
mount -o remount,exec,dev,suid $SDCARD
for f in dev dev/pts proc sys ; do mount -o bind /$f $ROOT/$f ; done
chroot $ROOT /bin/bash -l
debootstrap/debootstrap --second-stage

Then build up the Debian system as you normally would a minimal installation.

Alternatively, to build the chroot in a single step (without the first stage / second stage split), you can use the qemu-debootstrap or vmdebootstrap tools.


Running Debian binaries outside the chroot

If you need to run binaries from inside the chroot outside the chroot, you can use

export SDCARD=/mnt/sdcard
export ROOT=$SDCARD/debian
export LD_LIBRARY_PATH=$ROOT/lib:$ROOT/lib/arm-linux-gnueabi:$ROOT/lib/arm-linux-gnueabihf:$ROOT/usr/lib:$ROOT/usr/lib/arm-linux-gnueabi:$ROOT/usr/lib/arm-linux-gnueabihf
cd $ROOT
./lib/ld-linux-*.so* bin/ls

Available memory

Android pre-loads applications (in some case that the user has never started) when there is free memory. This reduces the memory available to applications in a chroot.

It looks like the *_MEM properties in /init.rc along with the /sys/module/lowmemorykiller/parameters/minfree could help.

Zygote starts SystemServer and SystemServer restarts zygote, so simply killing one of them won't work. The Android-native way of getting rid of zygote and all that descends from it is to just use the 'stop' command (in a script or through a remote (root) shell), to restart the whole Android environment you'd use the 'start' command:

stop # to stop zygote
# now do whatever you want without Android getting in the way. Once you're ready just use:
start # to start zygote

The display is now blank and ready for SDL. The input devices only partly work with SDL on the 8120 (write your own code to read /dev/input/event*) but graphics work well.

Group privileges on Android

Android uses predefined groups to control permissions. You will likely have to add these groups within your virtualized Linux environment to grant permission for your user to do useful things. For example, if you want to access the /sdcard storage area on your device, you will need to add yourself to group 1015 aid_sdcard_rw.

Refer to the official AOSP source for the complete list of users and groups. Here is the list for Marshmallow.

AF_INET privileges

On Android, you will need to add at least one group 3003 aid_inet for those processes which require access to creating sockets (other security guarded systems particular to Android may need addressing for other applications, search for 3003 aid_inet on the web for more detail).

exim4 and mailman chroot on Android

As well as altering inet access, the Debian-exim user will have to be added to group 3003. Further, if you experience trouble in the exim mainlog for creating sockets during DNS, try dropping privileges by adding "deliver_drop_privilege=true" to the exim4.conf.template file. For mailman, the standard setup is required, as per the README.Debian file in /usr/share/doc. However the user list must also be added to the group 3003 to allow it to send mail.

Running GUI along side Android

You can also try running GUI apps and desktop environments along side Android. There are a number of X11 Server apps on the Google Play store that do a great job. One such X11 app is "XServer XSDL" which is free in the Google Play store.

An example of how to get this working. Start the chroot, start the X11 Server app, add "export DISPLAY=" to your running chroot, then start your app or desktop environment, at this point you should see it open in the X11 Server app. YMMV though, not all Android devices have the ram or cpu to run this.

Integrate the Debian boot process

Debian gives you a huge array of server software to install and run on your Android device in a chroot. It is possible to start and stop everything using the rc scripts that all daemons in Debian install. If you don't want the shutdown procedure to halt/power-off your phone, you need to remove some rc init scripts. This doesn't always work, so when you run stop in Debian, it might poweroff your phone. We got it working on Blandroid by running these commands in the debian shell (via ssh is probably the easiest):

 update-rc.d -f halt remove
 update-rc.d -f reboot remove

On ?CyanogenMod, we had to remove a lot more scripts to prevent it from shutting down, like sendsigs. But then /etc/init.d/rc 0 no longer shutdown all of the Debian services.

 update-rc.d -f halt remove
 update-rc.d -f reboot remove
 update-rc.d -f sendsigs remove
 update-rc.d -f umountfs remove
 update-rc.d -f umountroot remove

You probably want to remove all of the networking stuff from your Debian chroot and let Android handle it, otherwise you might have Debian and Android fighting over the network config. Also, you need to replace the Debian call to kill all processes, because it will also kill all Android processes. Instead projects like Lil' Debi and Crouton (Debian chroot for ChromeOS) have a custom script to kill all processes running in the chroot.

The scripts to call to start and stop everything automatically:

handling /dev

As of version Lil' Debi v0.4.4, Android /dev/ is not bind-mounted in chroot. This means no /dev/block/, /dev/log/, /dev/graphics/ and such. Bind-mounting it there results in conflict between Android logger and syslog, so syslog users should not do that, unless they have workaround. Additionally, if /dev/ isn't bind-mounted some Android executables, such as *am*, *dalvikvm*, *logcat* and many others won't run from inside chroot.

Important Android Environment Variables

Android is a very limited environment, so there are some odd hacks in it. For example, Android does not support rpath for finding shared libraries. Android will only look in the hard-coded system path, i.e. /system/lib and /data/app-lib/com.myapp.packagename. You can make Android look for shared libraries in other paths using the env var LD_LIBRARY_PATH, and some Android apps with native executables rely on that hack.

Using **su -l** to login into the chroot may result in unsetting of some important Android variables, such as BOOTCLASSPATH and LD_LIBRARY_PATH.

Booting into Debian instead of Android

Download the zImage for your version of the Linux kernel that runs on your Android device to your laptop and run fastboot something like this:

fastboot -c "root=/dev/mmcblk0p3 rootwait" boot ./zImage