- Debian install apps on Android
- Manual installation in a chroot
- Running Debian binaries outside the chroot
- Available memory
- Group privileges on Android
- AF_INET privileges
- APT privilege dropping on Android
- exim4 and mailman chroot on Android
- Running GUI along side Android
- Integrate the Debian boot process
- handling /dev
- Important Android Environment Variables
- Booting into Debian instead of Android
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 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.
GNURoot lets you install a limited Debian environment without root access
Termux: Debian/Ubuntu environment without root access
MaruOS: uses Linux containers
UserLAnd: uses proot
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).
First, the phone was rooted by side-loading z4root
CyanogenMod 7.2.0-RC0 22b was flashed. This might not be necessary though
Set CPU to 710 MHz with the interactiveX governor. YMMV
- Side-loaded SSHDroid
- The SD card was formatted with the MBR scheme and a single ext3 partition was created. 15 sectors were left over
Then, on a workstation (any architecture), insert the µSD card, and:
sudo debootstrap --arch=armhf --variant=minbase --foreign wheezy /media/PHONE\ CARD/debian http://httpredir.debian.org/debian
For machines without externally mountable/addressable storage, you can use the script detailed here http://stackoverflow.com/questions/15278587/pipe-into-adb-shell to transfer the chroot whilst maintaining permissions etc. e.g.:
cd debian && tar czplf - . | /root/adb_shell.sh /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 ld.so:
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
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. The package android-permissions automatically sets up all groups used in an Android system (although you still have to manually add users to groups).
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).
APT privilege dropping on Android
The program apt-get (and all the other APT programs) drops privileges when doing network requests, thus fails because it does not have the inet group. One workaround is to add the user _apt to the group inet (3003) and also set it as the primary group for user _apt (because APT deliberately relinquish all groups except the primary one).
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=127.0.0.1:0" 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:
start: /etc/init.d/rc 2
stop: /etc/init.d/rc 0
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