Details on the next public SDK

I had hoped to reserve judgment until after an official announcement from Google, however after speaking with Dan Morrill and Jason Chen at Google I/O, it seemed clear that the OHA, up the corporate chain, has not taken the development community seriously. I have confirmed that the ADC winners have now received an updated version of the SDK which they are bound by NDA to keep private. These projects are thus forced to be closed until the NDA restrictions are lifted, which include no source release, performance benchmarking, discussion of new features, screenshots, etc. These restrictions are expected to last until the next public SDK is dropped.

So, when is the next public release? Surely after over 3 months since M5 and only a few major releases so far it should be close, perhaps landing after round 2 of the ADC is over? Not so. The SDK is not expected until either shortly before handset launch later this year, or perhaps on or after that date. We can rest assured that there will be significant changes in this release: modified and new APIs, new core SDK features (like Wi-Fi, bluetooth, etc), modified UI, and of course many important bug fixes. As a result, our applications will require substantial revision to work [well] on this new version, reducing the likelihood that losing ADC entries will be able to "compete" for visibility on the handsets as they launch. Not to mention, generally stressing the larger development community with excessive unnecessary work and "wandering" development with no clear indication of what's coming and when.

I see this as a serious problem, running directly counter to the claims of openness and developer support, however Google and the OHA apparently do not feel that a commitment to openness is binding in the face of proprietary inconvenience.

So, I feel there is no choice but to suspend my development on the current platform and await the launch of handsets. Hopefully I will be able to catch up quickly and still offer a stable and feature-rich application within the first few months of handset availability. That said, I will now be starting on the desktop client for my media streaming system. If anyone is interested, my project is currently open source and I am actively interested in contributors, even if you want to work on the Android component using M5 *grin*.

My ADC Submission: Five, a media distribution technique

I have created a system by which your music can be accessed anytime on the go using your cell phone's wireless data connection. Simply install the server software onto your home PC and configure the phone to connect to it. Initially, the meta database will be downloaded and then from there only changes will be synced to the phone. The media itself is retrieved on demand and cached to the storage card. In my real-world tests with a remote server and simulating GPRS or EDGE data throughput has been very promising, requiring only 3 - 8 seconds of buffer time before most content can be played.

For more screenshots and info, see http://android-five.googlecode.com. The system, though currently closed, will be opened under the terms of the GPL after the first round challenge winners are announced, regardless of outcome.

I will also be posting a video this week, showing my system in action. Stay tuned.

Obligatory Google I/O Posting

Seems like Google I/O is all the rage these days, so I decided I'd officially mention that I will be attending. I live in Seattle so airfare was cheap, plus I have friends in the area who want to go too.

Advanced Tab Activity Demo

I was inspired by the simple TabHost/TabWidget demonstration by Jeffrey Sharkey, and decided to expand upon it significantly. In my demo, I have replaced all the default drawables and layouts, created my own custom ColorStateList, and even utilized TabActivity for greater isolation.


Download: TabActivityDemo.tar.gz

The code and images for this demo are in the public domain, so please feel free to use and modify as you wish.

NOTE: TabActivity is currently marked as deprecated, but according to this post, I believe that may be in error.

Tool to read Android binary XML files

I have successfully reverse engineered a good portion of the Android binary XML file format that is found inside of Android package files (.apk). With this tool, you can explore the XML layout, drawable, and animation files used in the applications distributed with the SDK (phone, browser, contacts, etc). My primary motivation for doing this was to simply observe some of the common practices and get a sense for what Google is doing internally that isn't necessarily available through their API demos and samples. Below you can find two links to download either the stand-alone convertor or the collected output as run over every APK file found in the phone's /system directory:

Download: axml2xml.pl
Download: android-xmldump.tar.gz

Please note that this tool was a very quick hack and some of the XML files I found failed to parse. Not many, and the only ones I found were raw XML documents (not Android resources) so I didn't bother to explore any further incompatibilities. If you find any resources that fail to parse or have any insight into the format, feel free to leave a comment and I will investigate when I have time.

EDIT 2012-08-22: Android's come a long way since this post.  It's now possible to use the aapt tool to read the contents of XML documents (and a whole lot more) of APK files.  For example:

android dump xmltree foo.apk AndroidManifest.xml

Custom Android list widget to access large sorted lists on touch devices

I have developed a custom Android widget for m5-rc14 that automatically (and efficiently) sections a sorted list by alphabet letters and offers a side-bar widget for quickly jumping to each section. This widget could be very useful for any project offering an extremely large list to the user, such as a music player showing artists or albums.

Some things left out with this widget are a smooth scroll to the selected position as well as a finer control for sections that have large item counts themselves. More to come later :)

Here's a screenshot using dummy data:



Download: AlphabetListView.tar.gz

Licensed under the GPLv2.

EDIT 2012-08-22: This approach represents very old design patterns for Android and has been broadly replaced by upstream components such as the fast scroll mode of ListView.

Android Eclipse Plugin / AIDL bugs

UPDATE: This work-around is no longer necessary since m5-rc14 fixed the aidl bugs.

The current Android SDK (m3-rc37a) has numerous bugs surrounding the aidl parser, the most annoying of which makes it very difficult to work with a project utilizing aidl imports and the Eclipse Android plugin. In order to ease some frustrations, I have created a wrapper around the aidl tool which tries to guess certain usage parameters and automatically inject the necessary -I switch.

To use the script, enter your Android SDK tools directory and issue the following:

mv aidl aidl.google

Then save the following script as aidl:

#!/usr/bin/perl

my @aidl = split /[\/\\]/, [ grep { /\.aidl$/ } @ARGV ]->[-1];

foreach (reverse @aidl)
{
last if $_ eq 'src';
undef $_;
}

my $I = join('/', map { $_ if $_ } @aidl);

my @args;

push @args, "-I$I" if $I;
push @args, @ARGV;

system("$0.google", @args);

And finally, set the script executable:

chmod +x aidl