All I can say is I really hope they shore up their OpenGL support in 3.0. Creating OpenGL apps with wide handset support for Android is a painful experience, with driver bugs and inconsistency all over the place -- even things as simple as mipmapping are touch and go with some handsets. If they ever want their games to seriously compete with iPhone games, they need to get some real consistency between manufacturers. A benchmark style scene that exercises every feature and has expected results defined could go a long way here, assuming they have some way to get the handset manufacturers to actually test with it.

But that's a really obvious suspicious case, and is a case where the existing system works perfectly -- you'll get a bunch of negative comments from users about your weird permissions, be complained about, and be removed. Remember that you fundamentally can't use a permission you're not notifying the user of. I'm talking about what you'd do if you actually wanted to get away with it, which is build an app that already has some legitimate use for the permissions you're requesting. In those cases you'd need to do code review, and you'd have no idea you should be looking in the first place. This means you'd need to code review everything with any special permissions, and doing a passably thorough job of that is basically impossible. It's make the US Patent Office look fast.

It's not an honor thing on Android either -- fundamentally you cannot access that data without having the appropriate permission declared in the manifest, trying to do so will fail and result in an exception being thrown. The user will be informed at download time of the permissions you use.

But that's already what happens. The permissions list on an Android app isn't an honor system -- if the app tries to access your contacts list, and that permission isn't in the manifest, the app will throw and exception and fail. Fundamentally you can't use a permission without informing the user up-front when they purchase it.

I don't get it, why is this being positioned as an Android problem? Last I checked, iPhone apps aren't even required to tell you what data they use in the first place -- is there an iPhone equivalent to the "uses internet access", "uses coarse location services" page that the Android Market displays to you? There's a ton of iPhone, Blackberry, Parlm, etc apps using advertising support, which is what the vast majority of this article is finger-pointing.

Nobody, at any marketplace service, is going to have time to do a code review of everything that gets submitted. Even console games -- which have a months-long and intensely painful approval process the likes of which you've never seen -- don't do code review. The very concept is ridiculous, there's way too much code and way too many people involved. You're going to have to trust your developers folks, and make use of the user-ratings tools if you don't.

Android's model of showing you what special access the software uses is about as good as I think you can get in the real world without learning to use a packet sniffer. RIM's ability to disable individual types of access is cool as well, but if the software needs it to function (or says it does) I'm not sure how the user is supposed to be in a position to use it intelligently. To avoid these sort of data harvesting problems, they'd have to somehow psychically know that the contact manager they're trying out uses that internet access for more than the occasional ad serve, and how would they know that?

The problem is, Android runs on a whole mess of hardware platforms and will be adding new ones regularly. As it stands right now it's on multiple flavors of ARM, x86, etc. Writing 100% native apps in C/C++ is exactly what they should be avoiding like the plague if they want to maintain any kind of reasonable compatibility across the board -- the NDK's existence is bad enough already, leading to marketplace listings that say "Works on Motorola Droid only!" and so on.

I work at a game company, and the majority of what's in version control is either binary or (effectively) unmergable. I know this is relatively unusual when it comes to software development, but this fact alone gives me a lot of pause when thinking about whether something like Git would be a good idea compared to SVN, Perforce, etc -- discovering conflicts immediately is vital in this sort of scenario. Mentions of things like six-second merges makes me believe they can't possibly be testing with a repository of any significant size (tens of gigs, at least). How well does something like git handle this scenario?

Not to mention P4 absolutely trusts the server as to the state of your local repository. Get a few files overwritten locally somehow and good luck figuring out what's wrong when something starts acting weird a month down the road.