* Certain devices decode h.264 wrong and crash, others don't, and it's hard to reproduce and virtually impossible to test
* No, there is no Android device dominating the others. Not even close. Program to API 7 or API 8 if you must, but the whole thing's a headache.
* No expectations for resolution
* This freaking bug (ARGH!!!!!!): http://code.google.com/p/android/issues/detail?id=1353
* Everything is sized relatively, but the only way to size to a % of the screen (that I've found) is to pad a view with empty views with different weights, and set the middle view to 0dp (density-independent pixels, which, because of some manufacturers' lies and trickery, aren't always density-independent) tall, and have it resize later. But wait! Setting it to 0dp messes up other aspects of resizing!
* The order of operations that Android goes through to resolve layouts, if it's even logical, is incredibly opaque, and at the very least, not at all intuitive. For example, denoting a view "A" to be above another view, let's call it "B", is not the same as denoting view "B" to be below view "A". Now try that with four views, arranged in a T formation. Hellish! And good luck trying to resize an image to clamp its left, top, and right edges to the screen, and crop it at the bottom - it won't work unless you clamp only a corner (i.e. top and left) then have it resize to fill the third clamped dimension, that is unless you're using other special tactics to mess around with other parts of your layout, in which case you'll waste a LOT of time finding the right answer, or one good enough to use.
* The concept of resource overlays in Android is a huge, huge, huge pain in the ass. Possibly necessary given the complete fragmentation of the devices.
* Devices will actually lie to you about their screen dpi/resolution because they think it'll be better
* Some devices might have bad defaults, or not allow you to select a button without tapping it (i.e. with a directional pad) while others will.
* Weak-linking and adding in checks for future functionality is not possible, to my knowledge, on Android. Adding in support for Honeycomb features entails actually not supporting them directly, but proxying them through a compatibility library.
* The error-checking for XML layouts and themes is weak.
* XML layouts and creating views in the equivalent of a view controller is entirely different and the mapping is not 1:1. Combining the approaches piecemeal complicates the whole process enormously.
* Asynchronous data can only really be loaded one way without causing lower-end devices to crash on large datasets, and that is with the whole cursor/content provider ecosystem, which is a poor excuse of an abstraction given Java's power.
* Parsing stuff tends to be dog-slow unless you spend an inordinate amount of time paying attention to it.
* Certain upcoming platforms running Android - and developed by Google itself - don't even support the NDK, which means you can't even dip into C/C++ for performance anymore for said platform.
God, I miss developing on iOS. It's too bad our app got rejected for using In-App Subscriptions, then rejected for not using In-App Subscriptions.