There are simple solutions to the problems you mention, but it is very difficult to know they even exist without several hours of research and trial and error. For framework environments like Android this slows app development and leads to apps that don't behave well. The tools and docs available right now need to be better if Android wants to be the dominate mobile platform for devs.
I'm moving to the "It's not me, it's you" phase of the relationship faster this time, though.
Turns out that for pre-3.1 it will round the wrong corners (http://code.google.com/p/android/issues/detail?id=9161), meaning you need "corrected" drawables for API level 12+
That's one example of things that definitely made the whole XML experience a little trippy for us.
"Ever try to change the color of a button on Android?"
android:background="#ffee11" on the button?
Or use something like CSS variables (you know -- where CSS wants to go) and pull from a resource. Are you talking about something much more complex?
You can define a shape resource and then reference that in your button. Your button can be almost any shape and look you desire, via a shared resource file so it's easy to replicate elsewhere in your app. Making a shape occupy n-percent of the screen, or having padding left, right, above, below is trivial, and I'm predominately an NDK developer and don't even deal with this normally (but just quickly validated it. Rounded corner buttons with gradient backgrounds and specific padding occupying n-percentage of the screen).
I am left completely baffled by your complaints. There is nothing arcane about a shape XML file (it is profoundly clear, and is obviously intended to be reused so you aren't scattering disparate presentation code -- such as a button style -- throughout your code), and if you don't like that you can declare the color directly. Of course that is only one of your complaints, but if you don't understand something so elegant and trivial, I have to question the rest of your concerns.
That . . . actually works! Well, now I'm embarrassed. I had previously had to go this route http://www.androidworks.com/changing-the-android-edittext-ui... with text fields, and assumed it was the only way.
How do you get buttons to occupy a percentage of the screen (I hesitate to ask, as it's probably something similarly trivial . . . but it's been such a painful subject for me that I really want to know!)?
In a LinearLayout take a look at layout_weight -- it is the key (or rather, one of the keys) to goodness. It really is an onion, and if you can get through the crying the flexibility comes in the layers.
Still, for correcting me on the button background thing alone, I suspect you've added years to my life. Dunno what the online equivalent of buying you a drink is, but . . . thank you.
I'm definitely feeling that way these days.
When I first started learning Android, I was very excited about the resource system. The ecosystem is highly fragmented, but they give you the tools to deal with it!, I thought. How cool, I want to learn from their wisdom!
Six months later, I'm actively shopping for a different UI framework. This one makes easy things hard and hard things impossible. I was recently trying to make a button 40% of the screen width and aligned kinda leftish and kept from getting too big on wide screens. In CSS, that's couple lines, maybe thirty seconds. But in Android . . . well, I spent six hours thrashing through documentation and recommendations and opinions on StackOverflow before I gave up and wrote my own Button class.
It's really that bad.
Ever try to change the color of a button on Android? It requires something like fifteen 9-patch PNGs, two or three arcane XML files, and navigating a style hierarchy for your activities. No siree, no .myButton { border: 3 px solid #C88; } here.
Ever try to wrap text on a canvas? Or scale a font based on the display size? Or add an element to a view when a screen is a little bit larger? The hoops you have to jump through are simply amazing.
I'm convinced it's not fragmentation, per se, that's the problem. The web has even more fragmentation, and it handles it well enough. No, it's that the tools you're given for dealing with the fragmentation are so very poor.