Thoughts on Android

Posted by: stak
Tags: code
Posted on: 2011-01-28 01:51:59

While I was initially impressed by Android's architecture and APIs, I am now somewhat less than impressed. I've been spending a lot of time over the last few days trying to add my own AccountAuthenticator and the results haven't been pretty. I followed the docs at first, but that failed miserably. After much investigation I found the SampleSyncAdapter code and figured out what it was doing and replicated that. That helped somewhat - at least I was able to get an account added.

If it was just that API then I wouldn't have a problem with it. But I think there's something underlying the Android implementation that is seriously messed up. There's a lot of cross-process communication going on under the hood, and there's a lot of hoops that the system jumps through when doing the IPC. I don't fully understand the process model in Android, but there's a lot of intricacies with permissions, protections, and hidden IPC calls that seem to be making things much more complicated than they appear.

As an example, at one point I tried calling BluetoothAdapter.getDefaultAdapter() from a helper thread and that died saying it couldn't create a Handler object from that thread because I hadn't called some Poller method. It was pretty absurd since it was trying to invoke the method via IPC and needed the Handler for the callback. But of course, this isn't documented anywhere and I only found out at runtime when it threw the exception. Unless every codepath gets exercised during testing, stuff like this has the potential to blow up apps in production, which is very, very bad.

I'm still having a problem where I call AccountManager.getAuthToken().getResult() from my app, which does get through to my AccountAuthenticator and obtains an auth token, but then that thread of execution just hangs somewhere. It never returns back to the app, and I have no idea why. I did try poking through the relevant AccountManager code but didn't have the time to figure out all the magic and abstraction going on in there. Debugging with Eclipse wasn't much help either since (a) there's no source jar distributed with the emulator and (b) after I got a source jar that somebody made available, it still wouldn't set breakpoints or let me debug that code, and I don't know why.

Another issue I keep running into is the number of different permissions I need to keep adding to my app to do things. I do like the idea of having fine-grained permissions so that the user knows exactly what the app is up to, but some of these permissions don't really map to concepts the user can readily understand. How would you explain to an average user the difference between the MANAGE_ACCOUNTS, AUTHENTICATE_ACCOUNTS, USE_CREDENTIALS and GET_ACCOUNTS permissions? The distinction is confusing enough for developers, let alone users. And not just app developers - the AccountManager.invalidateAuthToken() method documentation claims to allow both MANAGE_ACCOUNTS and USE_CREDENTIALS, but when I try to use with USE_CREDENTIALS it throws an exception. Clearly this stuff is complex for Android contributors too. It's also not clear to me which permissions are propagated when the under-the-hood IPC stuff happens.

Since I'm working against Android 2.1, I'm sure some of this stuff has been addressed in newer versions. And my experiences have been mostly confined to the accounts API, so they may not be representative of the platform as a whole. I also haven't spent a lot of time reading through the developer guide. I did skim it, but who really reads that stuff end-to-end? But I'm still worried because I'm starting to get the feeling that some of the fundamental design decisions behind the Android architecture are turning out to be poor ones.

Name:
Comment:	Allowed expansions in comments/replies: [i]italic[/i], [u]underline[/u], [b]bold[/b], [code]code[/code], [sub]subscript[/sub], [sup]superscript[/sup], [url=http://some.url]linked text[/url]
Human verification:	=