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

Ubuntu 11.04 dropped yesterday, and I’ve taken the opportunity to install some other user interfaces marketed for touch-centric devices. The GTK-based virtual keyboard (onboard) is also inadequate.

Unity has just replaced GNOME on Ubuntu, and Canonical is putting all its support behind it as a mobile platform.

• It’s lightweight, and it starts up quickly.
• The dock/launcher on the left side supports the “grab&drag” gesture for scrolling.
• The full application menu can be accessed by a quick tap on the upper-left corner, and has large, finger-friendly buttons.
• The dock hides as soon as an application opens, and displays when the user pushes the mouse cursor against the left edge of the screen (or upper-left corner); this is somewhat awkward for touchscreen users.
• In fact, there are a number of hover-dependent events that are difficult or impossible to trigger using a touchscreen.

GNOME Shell was kicked out in favor of Unity, but it’s also supposed to be finger-friendly. I had to add a PPA, and the installation completely broke the theming across all GTK applications, but this was expected and understandable.

• It’s very accessible without a mouse, and nothing becomes unusable because of specific mouse requirements.
• The “grab&drag” gesture is well-supported, including for window management; windows could be dragged between virtual desktops.
• There’s also a long-press gesture for accessing context menus.
• Virtual desktops are added and removed dynamically; there is always an “empty” desktop on the bottom of the list, which creates a new desktop when a window is dropped on it.
• The dock on the left scales in size as icons are added and removed from it, so there may be problems with a long list.

Plasma Mobile is only a technology preview at this point. It doesn’t even come with an Xsession script, so I had to run plasma-mobile to start it. The interaction is very smartphone-like, with “grab&drag” supported everywhere (including widgets). However, “everywhere” is relative because Plasma Mobile does not have an application launcher at all.

Xfwm is my touch-agnostic baseline. I keep XFCE around on a separate partition so I could use Ubuntu+1 on my main partition and have recovery tools if/when it breaks. The touch screen works mostly like a mouse, in this case. Docks are all the rage these days, and XFCE is no exception; it auto-hides under the bottom of the screen, so it’s also somewhat difficult to reach.

In my opinion, a compelling touchscreen experience must provide, in no particular order:

• “grab&drag” and long-press gestures
• a virtual keyboard on par with those of Android and iOS, or a graffiti-like text input mechanism à la PalmOS
• multitouch, if possible
• differential treatment of screen and mouse inputs, so that the mouse doesn’t trigger gestures or virtual keyboards and can be used for precision manipulation

What do you think is important in a touch interface?

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.

Dimensions: 0.9″h × 11.8″w × 8.6″d @ 3.8 lb (1.72 kg)
Motherboard: Tripod Motherboard MARIO-6050A240910-MB-A03
Chipset: Intel CG82NM10 PCH
Processor: Intel Atom N455 (Pine Trail) @ 1.66 GHz single-core with hyperthreading
Graphics: integrated Intel GMA (Pineview) @ 200 MHz with VGA port
Audio: integrated Intel 82801G HDA with stereo speakers and 3.5 mm stereo output plug
Memory: 2GB Hynix DDR3 1Rx8 PC3-10600S RAM
Flash: ITE IT8500E Flash ROM
Storage: 16 GB SanDisk SDSA4DH-016G SSD on 1.5 Gbps SATA interface
Display: 12.1″ 1280×800 active-matrix color CCFL-backlit LCD with matte surface
Keyboard: full-sized 74-key keyboard
Touchpad: oversized multitouch clickpad
WiFi: AzureWave Atheros 9280 802.11 a/b/g/n supporting WEP, WPA, and WPA2
Bluetooth: Atheros AR5BBU12 with V2.1 EDR
Mobile: Qualcomm Novatel Gobi2000 PCI Express Mini Card
Battery: 63 Wh removable Li-po battery for up to 8 hours use or 8 days standby
Cooling: fan
Other: integrated USB 2.0 port, webcam, and SD card reader

Bill Detwiler did an excellent photo tour of the Cr-48′s innards, since he promptly cracked his device open when he received it. It is interesting to note that the keyboard has media keys instead of function keys, and a search key instead of caps-lock (the latter can be configured to act as a caps-lock key). The mobile broadband chipset supports pretty much every extant mobile data standard, such as HSPA/UMTS (800/850/900/1900/2100 MHz), quad-band EDGE/GPRS/GSM (850/900/1800/1900 MHz), and dual-band EV-DO/CDMA (800/1900 MHz). The chipset also supports GPS, AGPS, and another AGPS standard called gpsOneXTRA™. It comes with 100 Mb/month of free data service from Verizon for two years.

jtdgrz managed to obtain the `lspci` output on the device, which revealed some more information about the hardware:

• 00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge
• 00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller
• 00:02.1 Display controller: Intel Corporation Pineview Integrated Graphics Controller
• 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
• 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
• 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
• 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
• 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
• 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
• 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
• 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
  00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)
• 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)
• 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
• 01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

This unit is not for sale, but you can sign up for one until December 21st if you live in the USA. And if you’ve already applied, you can use the Cr-48 Shipping Tracker to guess if/when you’d receive it. Good luck!

Oh, and since this device has been called the CR-48 with a capital R, I’d like to mention that Cr-48 is a codename, not a model number… and Cr-48 is an unstable isotope of chromium

Outside the Cr-48

Inside the Cr-48

The Cr-48 goes for cheap on eBay... but don't be fooled! http://cgi.ebay.com/320630449778

Topics of Discussion on Omegle

What did we learn today? Well, although females are in general more interesting than males, people prefer talking about men (specifically) to talking about women. The sexual orientation chart may not tell us exactly what we think it tells us, because lesbians may be considered gay in some cases. The countries chart shows the top twenty countries mentioned on Omegle, with India in the lead, and California and New York are two of the most popular states in the United States.

At any rate, this is just for fun, so don’t lose any sleep over it. If you’d like to read some of the conversations yourself, just hit up the repository. You can also have freshly-tagged conversations delivered to your feed reader or mobile device by subscribing to the Atom feed. Remember, this is the raw and unfiltered stuff; viewer discretion is advised.

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.