A repost (yeay no edit functionality), my first real post on slashdot that needs line breaks
> *Splash screen (and side note: the tutorials I found on the web on how to make one were all horrible, involving spawning threads and making sleep calls).
Why the crap are you wasting peoples time with sleeping for a splash. If a client asks for this, make it actually do something useful. Create an activity that starts downloading relevant data. At worst, sleep for a duration and then call finish(); startActivity(...);. There's an entire activity there to do real work while.
> *Intents to just play full screen video, or audio and matching image.
And your point? I'm glad this intent fulfills your need but if you want to raise REAL android issues, lets talk about mp3 playback on 2.1, 2.2 and 2.3+ devices. Lets talk about how 2.2 devices vary in the backend hardware decoder and what kind of havoc that raises. Lets talk about having to roll our own implementation of the http live spec.
> *An Image widget that can use a resource or a URL as the source.
This could be useful as a builtin but it's stand alone. What if your caching what your app downloads? What if you're looking to share that image via intent with other applications that accept that? Let's talk about the real issue here, and that's a lack luster api for handling multiple concurrent web requests that integrate with all of the niceties android does offer. Then lets talk about a WebImageView class.
> *A wrapper around their gyroscope and accelerometer to form a compass sensor. Something they used to have (ORIENTATION_SENSOR) then deprecated.
This does suck.
> *A single function call method to get a URL as a string (or as an image, etc).
Same point as two questions ago essentially. This is a dead end that accomplishes very little. I'd be insulted by Google if this was some "improvement" announced on their dev blog.
> *A view that displays the output of the camera, and manages requesting access to the camera when the activity is paused/unpaused. Really, how the hell did they miss this?
Valid point, this along with other phone sensors are needlessly complicated to work with. The complication comes down to, in my opinion, how the api is represented. They could require we still do all of the necessary bits, just like presented as above, but create a much better api.
> *A JSON parsing library that will take JSON and an object definition and use reflection to turn the JSON into a java object.
See GSON, It's stupid easy and works great. XML is a bigger issue.