Design

The installer is the native backend to NativeMarket, though how much will be implemented in the (android) front end and how much in the backend is still up for debate.

The goal of NativeMarket is to support native (Linux) applications and full desktops on Android devices, and support both root and non-root users.

The root case is much simpler:

• we can mount an ext2/3 image as a loopback filesystem anywhere we choose
• we can chroot(2) inside of this filesystem and install a full system in here
• we only need slight modifications to systems not to interfere with the native devices of the android host system, because it won't see udev events
• we can bind-mount the X socket, if TCP/IP isn't being used

The non-root case requires the following:

• we need a fakechroot environment, that fixes up the ELF interpreter of child processes, this is non-trivial
• we need some kind of mapping from permissions on the FAT filesystem (the only reliable, shared medium we have on non-root, though we can experiment with using /data/local/tmp most devices will not have the storage capacity for a full system here) ** this is essentially umsdos, a happily forgotten kludge from the early days of linux, but reimplemented in userspace with a sqlite3 permissions store (yay for modernity!)
• we have to figure out how to support only a single user, but use applications from sources that will have the system-wide binaries and resources as the root user, this means either using the libfakechroot (or similar library) or hacking up the package managers ** we can drop root, it's not needed and will simply be ignored (actually, on vfat at least, chown will simply fail silently, and tar, cpio, etc. don't care)
• we have to resolve the remaining dependencies, since we will not always have a full system, we will only have a bare minimum debootstrap (in fakeroot/fakechroot??)

The root case is harder in one way, we have to resize the ext3 image, but this is similar enough to a virtual machine (and the Android emulator) that it's not unexpected, and in the root case, we can have the image or just a partition mounted from a sparse supporting filesystem ** use a configuration file? this is good enough for advanced users who can extract the installed .img to a partition or move it somewhere else ** we can source it from the chroot script, if we go that way

We will have an "initrd" which is essentially a cramfs or zip/tgz file (extracted) containing the X libraries, keymaps, installer binary and resources (gtk, qt, ncurses?) It will do the following:

• request NativeMarket or an Android server (through a socket??) to notify the user it's downloading a file, once that file has been selected from either NativeMarket or the installer (which??)

• when the file has downloaded it will either be a chroot img (ext3 bzip2'd) or tar.bz2, which will either already be in place or extracted (or we can extract the ext3 itself)

• in the root case, a loop device will be found, the image will be losetup'd to it, and mounted

• the base image will be resized to the desired size (root case)

• the installer will then finish operations inside of the chroot, probably by launching cdebootstrap for debian/ubuntu, or installing the needed packages if the base image is used for apps (or even if not, not decided)

• the installer will notify the Android service of progress

• if a single app is selected, it and it's dependencies will be installed from a native package, this will work the same in the root and non-root cases thanks to libfakechroot

• a launcher stub will be added to Android launcher if requested, launching the whole image or FAKECHROOT and the desired application or desktop (etc.)