Honestly, I'm not sure you can plan your community like that (you can try, but I don't think that's how it works). I consider certain minima to be important:
1) the technical interaction with people outside the project (which we do in spades, but not for every part of the stack)
2) Proper, real, oss licensing so others can even consider taking part without having to contort.
3) An eng staff on the google side that knows that they can work with people outside the company.
What I don't think is my role is to tell the Android team 'you must take a patch' or set some minimum number of patches that must come from 'outside'. They're simply under enough pressure that they don't need me to do that, nor do I think it would be ipso facto reason enough to change what isn't fundamentally broken.
Also, I'm not sure I actually believe in an outside/inside distinction. How is it possible that someone 'outside' can be part of the community? So...."what do you mean by community" is the existential crisis that we must think about, and we should think about it while also making shipping deadlines...
Anyhow, thanks for the kind words regardless. I've tried to not sugar coat this, android and its developers probably are what people want -technically- from a handset project, but there is a clear desire for 'more' that I don't think google will be able to satisfy in the short term. Our priorities are on iterating the os and stack first and everything else second, third and so on.
With hiring and some tweaks of internal processes we might be able to make a few more people happy, so I think that the only thing that will 'fix' this is time. That said, I suspect in 2 years I'll be talking about some practice someone has glommed onto on some google project that they disagree with. But, so long as code is releasing, I'm pretty happy :-)