That's not true.
UMTS signalling traffic is actually a big worry too.

Setting up and tearing down radio resource connections all the time has a burden on the network. Mobile applications, with their diverse update patterns (e.g. polling every 30 minutes (email apps), or minute or even few seconds (e.g. IM apps)), can make it difficult for carriers to set up their RRC inactivity timers and various other settings in a way that minimises signalling load on the network.

I can't compile programs written in the Java language to Dalvik?

You need to differentiate between the bytecode and the virtual machine. Anyway, the answer is no, not directly.
The "Java language" or Java bytecode does not run on the Dalkiv virtual machine.

Desktop: The Java language is compiled to Java bytecode and run on the Java virtual machine.

Android: The Java language is compiled to Java bytecode. Using an Android tool, Java bytecode is transformed to Dalvik bytecode, which is then run on the Dalvik virtual machine.

I don't believe the patents in this case have anything to do with the Java language, the Java compiler, the Dalvik translator, or the Dalvik bytecode format.
Sun's patents generally regard the virtual machine technology. Google have implemented an incompatible virtual machine, but of course with similarities to Java.. that's where the problems appear to lie.

Stop foaming at the mouth.

Calm down, dear.

Dalvik is compatible with the Java language.

No it's not. Nor is the JVM compatible with the Java language.
The Java language != Java bytecode != Dalvik bytecode

Dalvik ... was created both to be Java compatible and also under the assumption that Sun was friendly towards open source systems.

Google wrote an entire new, incompatible bytecode language and virtual machine to circumvent licensing any Java components from Sun.
So I doubt Google made any assumptions about the "open source friendliness" of Sun.

Clicking on that link and reading the heading "Gloda is an index, not a data store" would suggest yes.

Android apps don't necessarily have to have a launcher icon (e.g. services, live wallpapers etc.).

Apps can also run automatically at boot time, therefore unless the user somehow discovered that the installed app was malicious and manually uninstalled it, they'd be stuck with this malware forever — assuming Google didn't have this remote-removal functionality.

You get 140 bytes of data per SMS, so with the default GSM 7-bit alphabet that gives you 160 characters.

I can't remember how alternative encodings work, but I seem to recall you get about 70 characters when you text with extended character sets, suggesting that it's some sort of UTF-16 like encoding scheme. That number drops if you start doing message concatenation.

Some of that is true, but XML and the XMPP protocol are highly compressible.

XMPP uses a long-lived TCP connection between servers, so the continued exchange of <message from="foo@wavesandbox.com/Wave" to="bar@example.com/Wave"> will compress to substantially fewer bytes on the wire.

The XMPP Foundation has done a lot of work on this, and continues to work on scalability issues; particularly between federated servers. Indeed, XMPP has reached a point where it's a fairly mature, secure and speedy technology — clearly making it desirable for companies such as Google to use as a foundation for interesting applications such as Wave.

Ah, didn't realise only IE supported defer!

I never quite understood the HTTP/S detection, as I would have thought it'd be simpler to do "//google-analytics.com/..." (i.e. no explicit protocol). Though again I don't know what standard, if any, defines that behaviour. But if it is/was standard, then you could have a single script block. But of course, as you say, developers who call _gat from elsewhere (such as myself) would have to know when the content had loaded. So, er yeah.. forget all of that! :)

I guess inconsistent browser is also why they disabled gzip support? Though I would have thought it would be trivial to Vary by User-Agent.

Or they could probably just use the "defer" attribute on the script tag.