Today was the nail in the coffin of the Samsung Galaxy S that I use at work to do Android based testing of the library’s future work in the mobile area. The device is a stock device running Android 2.1 (Samsung’s updater app cowardly refuses to upgrade it to 2.2 for some reason) however as the device is for testing and since it has WiFi built in I’ve decided to use that. It isn’t connected to the cellular data network (or even have a SIM card) and this has lead to some interesting problems.

The first problem I noticed with it was the flagrant disregard for the proxy settings by all of the apps on the device -except the web browser. I’m connecting the device in a corporate environment with no cellular data so I know when something isn’t going through the wireless network. I’ve setup the proxy and using the web browser I can surf pages. However no other application seems to get to the internet. Google Maps? Just sits there doing nothing. I can go to maps.google.com in the browser fine though! Google Mail? Won’t even let me set up the account. Marketplace? Fail.

So this tells me that at least Android 2.1 level applications do not respect the proxy settings I had set up. I’ve obviously got something set up properly because the web browser users them. Looking around there seems to be suggestion that I should root the device to set proxies properly or something. For something that “just works” on an iPhone and it is something of a no brainer I would have thought it would have worked fine on Android, at least with Google’s own applications.

However the real nail in the coffin is the lack of complete 802.1x authentication, which while improving it appears that USQ’s current configuration makes it fail. USQ has started to deploy of 802.1x wireless networks to reduce the requirement to log into the wifi network, log into the Cisco access points and then from there gain access. This meant that the earlier wireless network testing was possible albeit a little tedious. Using it from an iPhone was just as tedious however there were apps to get around it. As of this week they’ve switched that network off and now Android doesn’t want to play the game.

The first problem with the 802.1x network is that USQ uses a certificate signed by AusCERT which doesn’t appear to be in the normal trust path for either Android or iOS. iOS gets around this by prompting the user to accept the certificate like what normally happens on a desktop web browser when an untrusted certificate is presented. One has to go through a rather complicated set of hoops to get this working on Android from what I’m told including putting the certificate on an SD card and navigating through a few layers of menu. Having the user download the certificates independently, find an SD card writer, put it on the SD card and then going through a process to import the certificate isn’t particularly user friendly. When you consider that USQ has something like 5000 people on campus so this sort of task doesn’t particularly scale well as opposed to clicking “accept”. Once we’ve gotten over that hurdle the second problem appears to be getting the Android device working properly with the AES encryption used. Apparently this is a barrier that an USQ ICT member with a masters degree is currently tackling though I believe that Android doesn’t support AES only PKIP so I don’t think he’ll have much luck.

Of course on iOS its rather easy, select network, enter credentials, accept certificate and then add proxy settings to the network. And you’re done. This was enough to convince one of our faculty librarians that perhaps the Sony Xperia X10 that they bought in the last few months was really not worth fighting against and now wants an iPhone. The X10 was sold with Android 1.6 which really just makes you wonder about fragmentation in the Android platform.

UPDATE: USQ’s certificates are signed by AusCERT, Australia’s version of CERT (Computer Emergency Response Team), not self signed as I had earlier suggested. AusCERT’s CA doesn’t appear to be in the normal certificate bundle for either platform. This means it came up unverified which is why I had assumed we’d been using self-signed certificates. The secondary issue appears to be the more secure AES being used for the authentication instead of the less secure PKIP. Android doesn’t support the more secure AES and thus fails to work even when the certificate is trusted or the signing CA is added. Additionally I’ve been told that you don’t need to root the device to install a certificate but you can put it on an SD card. These changes have been merged into the main document where relevant.