Good for you. We Android users appreciate people picking up Google's slack. :) It looks like your people are mixing the regular hardening advice with some ported stuff from BSD/Linux security work. This is low-medium in that it won't stop serious attackers if you get popular. Yet, even baking in the basic hardening by default should reduce risk of many real-world attacks. The other stuff might do more in final form. Keep at it.
Having read a few of your other comments I'd be curious to hear your thoughts on ways in which we could harden Android (on here or via email).
Our focus now is indeed adding memory protections to the underlying OS, to get Android up to date with at least 2004-era exploit mitigation. Before moving on to higher-level stuff :)
Linux is so inherently insecure that it's hard to say without processor & toolchain modifications. What you can do is follow lead of the others: combine a microkernel (eg OKL4, OC.L4) with paravirtualized Android with security-critical components running outside of Android. The Nizza Architecture [1] below illustrates this. A better, but commercial, approach [2] shows how to handle drivers and some other things better. It's been deployed in a ridiculous number of phones with success. So, standardize on a phone, audit/test the crap out of the drivers, put an OKL4/Nizza-style architecture on it, and pull out anything security-critical to run on microkernel with careful input validation & state management. Should reduce TCB, increase reliability, and prevent spoofing if you fully implement Nitpicker for mobile. Hope that helps.
Quick note: be sure to clear all internal registers and cache if kernel transitions from trusted software to untrusted software if you're worried about covert channels (esp key leaking). Both of those can leak keys to professionals if they compromised the Android portion.
