The NDK is a GCC-based cross-compiler that lets you embed object code in a traditional Android app. It also works as a standalone cross-compiler, though it is not advertised as such. It is quite rough when used by itself, and agcc wraps the complexity in a little script. While agcc and agcc2.pl are written in Perl, agcc.bash is a Bash script. It also supports the latest revisions of the NDK, though r7 is slightly buggy.

With agcc.bash, building native Android software feels almost like working with GCC. As a quick example, let’s try the classic hello world:

AGCC_NDK=~/android-ndk-r6 ./agcc.bash hello.c -o hello

That wasn’t too exciting… but what happened there? I have the NDK installed at ~/android-ndk-r6 and I told agcc.bash where to look for it, using the AGCC_NDK environment variable. I then invoked agcc.bash as if it were GCC. Let’s see what agcc.bash did behind the scenes:

AGCC_NDK=~/android-ndk-r6 AGCC_ECHO=yes ./agcc.bash hello.c -o hello

=> ./agcc.bash hello.c -o hello
<= /home/jyio/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -o hello -I/home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/include -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -DANDROID -DSK_RELEASE -DNDEBUG -UDEBUG -march=armv5te -mtune=xscale -msoft-float -mthumb-interwork -fpic -fno-exceptions -ffunction-sections -funwind-tables -fmessage-length=0 -march=armv5te -mtune=xscale -msoft-float -mthumb-interwork -fpic -fno-exceptions -ffunction-sections -funwind-tables -fmessage-length=0 hello.c -Bdynamic -Wl,-T,/home/jyio/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/arm-linux-androideabi/lib/ldscripts/armelf_linux_eabi.x -Wl,-dynamic-linker,/system/bin/linker -Wl,–gc-sections -Wl,-z,nocopyreloc -Wl,–no-undefined -Wl,-rpath-link=/home/jyio/android-ndk-r6/platforms/android-8/arch-arm -L/home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/lib -nostdlib /home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/lib/crtend_android.o /home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/lib/crtbegin_dynamic.o -lc /home/jyio/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3/libgcc.a -lm -ldl

See how it transformed our innocent little command into a monster! This might be overkill for a hello world program, but it provides pretty good support for more complex software such as OpenSSL, cURL, and Python. It would be a good idea to add the NDK toolchain and agcc.bash to $PATH before trying to build a big program. In my case, the toolchain resides in ~/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin. If you want to build some software that come with configure scripts, you might start with:

CC=agcc.bash ./configure

Do try this at home! Relevant links:

• Android NDK r6 (or, the latest version)
• agcc.bash
• hello.c

How do you get this particular OS update on a second-generation Kindle? Well, let’s just say it’s not officially supported.

Look at the pretty pictures.

The Bloxes website features construction images as well, and the process is similar.

They’re not exactly inexpensive, and shipping takes a while. Instead of ordering bloxes, I decided to prototype my own on paper just for fun. This design might require some modification for use with cardboard (in particular, I’m sure you could figure out how the original design works and apply it to your project).

If you have the resources, go ahead and roll your own cardboard modules. As usual, it’s easier said than done…

Here is where the magic happens.

Note that this code is for using Twisted with gevent (i.e. libevent and greenlet). For using Twisted with greenlet alone, there is corotwine. Twisted can also be used with Eventlet.

If you haven’t seen corotwine yet, I’d urge you to have a look. It lets you use Twisted with a blocking syntax. It’s not quite what I wanted, but it does what it says on the tin. I wanted to use Twisted with Twisted syntax, greenlet with greenlet syntax, and maybe even let the Twisted bits talk with the greenlet bits. It is apparently quite easy with gevent.

The first thing you want to do is monkey-patch select.select. This is the method that Twisted uses to wait for file descriptors, and we can let gevent handle that with libevent and greenlet. Next, you run reactor.run either in the main greenlet or in a new greenlet.

As long as Twisted and greenlet code stay separate, everything is peachy. There are some problems when they start mixing. Because the Twisted reactor runs in a single greenlet, calling gevent.sleep (or doing anything else that involves a greenlet switch) actually blocks all of Twisted. Long-running jobs could be done in new greenlets, though. And if another greenlet wants to work with a Twisted transport (i.e. to send or receive data), it’s not going to happen until gevent sees some network activity destined for Twisted and switches to its reactor. These are the same problems you’d see with corotwine, and I suspect they might be alleviated with a greenlet-aware reactor.

Update: gTwist, the original code for gevent-Twisted integration, has been replaced with a more robust system called geventreactor. As its name implies, geventreactor is a gevent-powered Twisted reactor.

echo "src/gz inportb-android-froyo http://repo.inportb.com/android/froyo" > /cache/etc/opkg/inportb.conf

After doing that, we could refresh the package list

opkg update

Installing a package then becomes as easy as

opkg install name-of-package

And we could keep all our packages up-to-date using

opkg update; opkg upgrade

It’s also quite simple to set up a repository for distributing packages.

First, we fetch the latest opkg-utils off SVN at <http://svn.openmoko.org/trunk/src/host/opkg-utils/> and make it. Then, we designate a directory (the repository) to dump all our packages in. Finally, every time we update the repository, we generate a new package feed

cd path/to/repository; opkg-make-index . > Packages

Now all we have to do is make sure the directory is visible on the Web, and share its URL. The end user would add a line to a file within /cache/etc/opkg

src name-of-repository http://host/path/to/repository

We could also gzip the feed to reduce bandwidth usage

gzip -c9 Packages > Packages.gz

The repository line would be changed accordingly to

src/gz name-of-repository http://host/path/to/repository

We could have multiple files in /cache/etc/opkg, and each one of those could have multiple lines. The idea is that each vendor could have multiple repositories, and keep them in the same file for ease of management.

<ShamelessAdvertisement> Incidentally, it is almost trivial for Dropbox users to set up a repository. If you need 2.25GB of premium Web-accessible storage to host your repository or anything else for free, simply sign up through my referral link. You could also skip the referral and get 2GB.</ShamelessAdvertisement>

opkg install path/to/package.opk

or, if it’s on the Web

opkg install http://host/path/to/package.opk

And to remove the package, we would go

opkg remove name-of-package

But what if we wanted to share our own software with others? In this case, we would create our own packages. An Opkg package is essentially a Debian package with fewer control fields. If you know how to make a Debian package, you should be well on your way. In general, a package is an ar archive containing a control tarball, a data tarball, and a debian-binary file. For example let’s have a look at the opkg-hello package:

package.opk (ar)
+- debian-binary (text)
+- control.tar.gz (tarball)
...+- control (text)
...+- preinst (script)
...+- postinst (script)
...+- prerm (script)
...+- postrm (script)
+- data.tar.gz (tarball)
...+- system
......+- bin
.........+- opkg-hello (example program)

Now, debian-binary simply contains the string 2.0; it signifies that the archive is indeed a Debian[esque] package. The files within control.tar.gz are cached when the package is installed, and contain information about the package itself, how the package is to be installed, and how the package is to be removed. The contents of control describe the package and are used to build the repository feed, which we will cover later. There are also scripts that govern the installation and removal processes and require execution permission: preinst runs before the package is extracted, postinst performs any configuration after the main files are in place, prerm prepares the system before the package is removed, and postrm cleans up after the main files are gone. Let’s have a look inside these files:

control
Package: opkg-hello
Version: 0.0.1
Description: Sample OPKG package
Section: cyanogenmod/applications
Priority: optional
Maintainer: Jiang Yio
Architecture: all
Homepage: http://inportb.com/
Source:
Depends:

preinst
#!/system/bin/sh
echo "preinst: preparing to install package"
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

postinst
#!/system/bin/sh
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
echo "postinst: installed package"

prerm
#!/system/bin/sh
echo "prerm: preparing to remove package"
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

postrm
#!/system/bin/sh
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
echo "postrm: removed package"

Other than emitting some debugging information, the scripts also make the /system tree writable while the package is installed or removed.

Now that we have the anatomy of an Opkg package, we could create more like it with ease. Here are a couple of helpful commands:

make a tarball
tar zcvf name-of-tarball.tar.gz list of files and directories

make an archive
ar -r name-of-archive.opk list of files and directories

Other than that, just be sure all the files have the right owner, group, and permission. It would also help to know something about the Android directory tree — for example, we dropped the example program in /system/bin, which we know is part of the search path.

For user applications, we already have APK’s.

These are self-contained blocks that may be easily installed and removed. The APK system is great for running untrusted software that needs to be sandboxed, but it is not flexible or efficient enough to manage the operating system itself. Android users typically do not update their systems very often, and when they do so, they update the whole setup at once. This presents two problems: firstly, users don’t receive updated software as it becomes available and secondly, each update is a resource-intensive and time-consuming task. It would be great if system software could be updated piecemeal, just like a real Linux setup.

The Debian packaging system solves this problem very well, but its size makes it unsuitable for mobile devices. Nevermind that Cydia users use Debian packages — it’s still good to be frugal. Since we’re not going to install Debian software onto our phones (which would probably break many things), we don’t have to stick strictly to the Debian format; on the other hand, Debian provides a very nice model for us to emulate.

Enter Opkg.

Here is a package manager and format that very closely resemble the Debian package manager and format. In fact, Opkg is capable of working with Debian packages. The difference is that it’s tiny and it’s designed for mobile devices.

For starters, I have compiled a statically-linked build of Opkg. It is able to install local (and http-hosted) packages as dpkg does. It can also maintain a list of software sources a la apt-get. Its small size (745KB) makes it easily-integrable into almost any Android system.

If you’re feeling adventurous and would like to try this on your rooted Android phone, the files are currently hosted on my Dropbox account. You do need root access, so if you use a cooked ROM such as CyanogenMod, you should be good to go. Please keep in mind that there is only one package at the moment (the example), but it’s not difficult to make more.

1. Prepare a fresh NTFS partition on the USB disk /dev/sdX and mount it at /mntX1, then copy all files from the Windows installer disc or image into /mntX1
2. Install Grub2:
   cd /mntX1; sudo grub-install --no-floppy --root-directory=/mntX1 /dev/sdX; sync
3. Download the latest Grub4Dos, and unpack grub.exe into /mntX1
4. Create /mntX1/boot/grub/grub.cfg:
   set timeout=0
   set default=0
   menuentry “Install Windows” {
        linux16 /grub.exe --config-file=”root (hd0,0); chainloader (hd0,0)/bootmgr”
   }

I was surprised that such a complicated setup actually worked. Be sure to substitute your own values for /mntX1 and /dev/sdX. In the Grub4Dos config, (hd0,0) refers to the first partition on the boot disk; you’d need to change that if you want to boot the installer from a different partition.