It would be interesting to add logging shims to the APIs along with a GUI by which semi-technical users could audit apps' behaviors. Why does Game XYZ need to access the internet? To download new levels or for some evil purpose? A listing of domains it hit would be a telling sign.

whispermonitor adds a littlesnitch-like gui to android to show and filter network connections:

http://www.whispersys.com/whispermonitor.html

it requires changes to the framework though, so it's only available in their own "whispercore" rom:

http://www.whispersys.com/whispercore.html

Google should implement basically everything that is on CM. They should just hire the freaking team already.

I would also like to see that developers were required to state why each permission is needed and present this to the user at install time.

But users might actually read the developers' explanations, in which case they would need to be true. If no 3rd-party verifies the permissions explanations before the app is released, then the only value is as a legal agreement between the developer and end-users. I would expect that to devolve into a 30-page EULA per app ... which has already happened, for many apps.

@ck2 is performing as thorough of a verification as possible without source code access. If I were a malicious app developer, however, I might program my app to wait a week before transmitting any user data.

As a developer I've often wished for this. You can stick it in the app description but it'd be nicer if it was on the permission screen. Marking permissions optional would be helpful too.

I've seen some apps in the android marketplaces that do have descriptions which attempt to explain the permissions. I've also seen apps that have a "lite" version with much fewer permissions needed.

But what I really want is the marketplaces to allow direct apk downloads because I always want to examine the file first on an emulator.

iPhone has the basic password to install things, and then beyond that:

1) Adult-rated apps need an explicit approval after the password before they will even install. Also applies to updates.

2) On first launch, apps that want to use badges or notifications or notification sounds have to ask for approval, although it is a generic approval of all three and doesn't discuss what they would be fore.

3) Before an app can use location services (current device location), it has to explicitly ask.

And, beyond those facts, my opinions:

1) This is pointless. If you want to block adult-apps, go ahead and do it in Parental Permissions. Especially since a lot of apps are adult because they do web stuff generically.

2) This is pointless, in my opinion, since you can't tell what they plan on doing with the alerts.

3) This works OK, although it is generally triggered after you request something location related so it feels redundant. Like, why is it asking me again, didn't I just click the location button? Does the average user understand that the prompt is coming from the OS rather than the app?

We've been over this a hundred times. Adding this sort of functionality would break potentially all existing apps. Has anyone bothered trying a nightly? I actually run them and this feature is near useless. Take away most of these permissions and apps crash and burn. It was in the API to begin with that the permissions would not be there, that's not how the manifest-declared permission system in Android was meant to work.

There's no easy way to add this to AOSP core in one swoop without making exceptions for legacy applications, to the point that no one would use it anyway.

I'd love to see this system evolve somehow to make permissions more granular, but it's going to be a breaking change and it's certainly not going to be implemented this way where fake data was returned. Not sure why people are shocked it works this way. I've tried to explain the breaking and problems that would occur from trying to implement this. Of course, a couple months ago when I tried to explain this, everyone here told me it was "simple" and that I just didn't understand. Oh well.

I don't understand how this makes apps crash and burn. Can you explain how does Angry Birds crashes and/or burns when it can't access the internet? Can you explain how a fart app will be broken when it returns a fake contact list?

It depends how the program was created. Programmers have to make assumptions, if one of these is broken, and the programmer hasn't 'handled' it, then the program will either crash or show bugs. Programmers do cut a lot of corners, where they feel assumptions are safe, and assuming the the permissions will be there is one of them.

I'd post logcats but I've already flashed new nightlies without the patch. The manifest method of requesting permissions in Android is a guarantee. Applications don't test for the availability or presence of permissions for things that they declare in their manifests. Because they have no reason to have to test for them. When they're not granted and the system retunrs an error or exception... it's not caught because it should, according to the API, never ever happen.

How would that not make an application crash? Additionally, returning fake data has it's own problems including at the very least integrity.

Instead of failing it should return fake data, the app never need know.