I don’t know if androids dream of electric sheep, but I’ve certainly been losing a lot of sleep over Google’s Android, and am glad that the Android Developer Challenge is winding up, as I’ve been doing all Android, all the time for the past month or so.

I have greatly enjoyed working with Android, as it’s much more capable than Java ME. It’s still very much a work in progress, and only time will tell if Google and their partners are able to best current mobile programming systems… or if the web will simply obviate the whole thing, as it’s doing in many other areas. Win or lose, I will continue to support Android as a platform that Hecl runs on, but in the meantime, I hope to go back and look at some less future-oriented code and get back to some Java ME work. More on that soon…

In any case, here’s hoping that the contest judges see the value in bringing a scripting language to mobile phones! I also hope to see actual hardware soon, as I’m really looking forward to getting my own Android phone.

As I mentioned in an earlier article, one of the goals for the Android port of Hecl is to make it as easy as it is to create Java ME applications:

1. Write the script.
2. Wrap it up and send it to the phone.

No “compiling” (well, none that’s obvious or explicitly asked of the user, at least, as we’ll see) or fiddling with build files or writing new Java classes or any of that.

We’re still not there yet 100%, but I did managed to hack together a system that, from an original Hecl.apk, creates a new application that can be installed on the emulator. This is tricky, because Android looks at the uniqueness of the package and class utilized for the application, meaning you can’t just rename Hecl.apk to Foo.apk and install it as a separate app. The emulator will overwrite your old copy of Hecl.

Here’s what we go through to make this work. Be forewarned – big, ugly hacks that are not for the faint of heart follow. The command line isn’t exactly beautiful either, but it beats all the individual steps that it replaces, as we’ll see.

java -jar /home/davidw/workshop/hecl/jars/AndroidBuilder.jar -android 
    /opt/android-sdk_m5-rc15_linux-x86/ -class Example -label "Hecl Example" 
    -package my.example -permissions ACCESS_LOCATION,ACCESS_GPS

1. The first thing that needs to be done is to replace the AndroidManifest.xml that is contained within our “template” application, that resides in Hecl.apk, a copy of which is contained within the AndroidBuilder jar file. Since the compiled version of the xml file is a binary format that hasn’t been reverse engineered or documented yet, the best way to do this was to simply:
2. Write out a new AndroidManifest.xml in our temporary work directory that uses our provided package name, label and class.
3. Using the aapt command in the SDK, create a new, empty apk file, specifying the newly created xml file as the manifest file to use.
4. Now we can extract the compiled version of the xml file, for later use.
5. At this point, we extract a version of Hecl.jar contained within AndroidBuilder.jar to the temp directory.
6. Now we need to generate some Java classes that correspond to the new package and class names that we’ve passed to AndroidBuilder. Ideally, I would have done this with some tools to write the byte code out directly, since the classes are so simple: all they do is subclass the Hecl and SubHecl classes so that methods fall through to those.
7. But instead, I just write out the .java code and compile it.
8. The two new classes get stashed inside the copy of Hecl.jar that we’re working with.
9. We now use the dx command to compile the entire jar into the classes.dex file that Android uses.
10. Since Hecl.apk is just a zip file, we can replace the AndroidManifest.xml file and classes.dex file with the new files we have created.
11. At this point, we rename the whole works, and move it out of the temporary working directory to the current directory.

Phew! That’s a lot of ugly work. It’s obvious that a lot of this should and could be handled in a less “brute force” way, but for now it gets the job done. The only thing left to do is replace the Hecl script, which is very easy:

zip -r Example.apk res/raw/script.hcl

This makes it possible to whip out new Android Hecl scripts without carrying around a lot of project infrastructure – all you really need is AndroidBuilder.jar and your script.

Naturally, all of this is very much a work in progress, so it may not work as advertised, and, given the mess that we go through, bugs are likely as well. Do report them if you find any, and have fun! In the future, it will be necessary to make it so that it’s possible to add resources to the apk file with zip, and have them be available to Hecl applications, which was actually the focus of the previous article.

Android relies heavily on something called “resources” to access portions of the system that aren’t directly in the Java code. For instance, if you had an ogg file that you wanted to use to play a sound with, you would add it as res/raw/foo.ogg. Then, during compilation, the aapt tool transforms all your resources into a Java file called R.java, which is basically a series of integers that can be used to reference the actual resources. For instance, to set up our hypothetical ogg file, we would do:

MediaPlayer mp = MediaPlayer.create(context, R.raw.foo);

That’s all well and good as far as it goes, and if you don’t have any reason not to use it, you should.

However, with Hecl, one of my goals is to make it very easy to create applications. This means:

• No complex directory layout structure.

• No big long build files that require tools like ant.

• No complex compilation steps.

I’m not there yet, on the Android platform, which is a bit more complex than Java ME (where it is indeed so easy to create new Hecl .jars that it’s possible to do it on the fly via this web site: http://builder.hecl.org), but I am making progress.

One thing that a user might want to do is add their own files to the .apk file that actually gets installed on the phone. Since it’s just a zip file, that’s pretty easy:

zip -r Hecl.apk res/raw/foo.ogg

However, without a resource, there is no way to access that file, so the question is: how can we get ahold of it somehow?

The first piece of the puzzle is Java’s ZipFile class, which lets us open up a zip compressed file, such as the .apk file that contains the ogg file we’re interested in in this case.

The critical passage is getting ahold of the actual filename on the Android filesystem of the code that’s currently running. It turns out to not be too difficult, if a bit obscure:

String filename = this.getPackageManager().getApplicationInfo(packagename, 0).sourceDir;

With that information in hand, we can feed it to ZipFile, and then access the contents at run time.

It’s not a perfect nor complete solution, yet. So many of the Android API’s require a resource ID, so it takes some extra coding to do things from the InputStream that we can get out of the zip file, but there may be ways to make this easier. For instance, we could simply dump the contents of raw/ into an application specific data directory the first time an application runs, in order to at least be able to access the files as files, rather than InputStreams connected to ZipEntries. In any case, at least it’s possible to access files added to the .apk without requiring the compilation step.

I’m not sure how many other use cases there might be for direct access to the .apk file, but if other people need to do this, hopefully this information will be helpful.

The latest component of Android Hecl that I have been working on is a simple shell server that lets you interact with Hecl remotely, in order to be able to telnet in, run commands and see what they do. In order to give it a whirl, fetch Hecl from svn:

svn co http://hecl.svn.sourceforge.net/svnroot/hecl/trunk/hecl hecl

Then install the Hecl.apk:

adb install android/bin/Hecl.apk

Select the Hecl Server demo, at the bottom of the list:

You also need to make sure that port forwarding is set up:

adb forward tcp:7405 tcp:7405

At this point, you can telnet to port 7405 on localhost, and run Hecl commands:

> puts hi
hi
> androidlog "hello world"

> java android.telephony.TelephonyManager telman
telman
> set phoneinfo [[activity] getSystemService phone]
android.telephony.TelephonyManager@435c8f80
> $phoneinfo getLine1Number
15555218135

Since this simple server runs in its own thread/interpreter, you can’t control the GUI from it. To do that, there is a ‘maineval’ function that sends code back to the main interpreter:

> maineval {set layout  [linearlayout -new [activity]]}
1
> maineval {$layout setorientation VERTICAL}
1
> maineval {set layoutparams [linearlayoutparams -new {FILL_PARENT WRAP_CONTENT}]}
1
> maineval {$layout addview [textview -new [activity] -text "Hi!" -layoutparams $layoutparams]}
1
> maineval {[activity] setcontentview $layout}
1

Gets us this very, very simple screen:

Hecl’s Java reflection support is still fairly alphaish, but you can use it to query classes about their methods and constructors, and call them most of the time; errors should be sent to me or the mailing list.

I found this little server particularly useful when fiddling around with some of the undocumented android classes, as a way to experiment in a running system.