Live data from Hacker News

Android: I don't need your permission

blog.danlew.net

121–130 of 190 posts

Re: Android: I don't need your permission

#121

> Case in point: android.permission.CALL_PHONE. You need it to initiate phone calls from your app, right? This kind of thing is why I can't see myself switching to Android as my primary mobile OS any time soon. If anything, I can see a bright future for Microsoft. In spite of the fact Windows Phone exists, Android is very much the Windows of the mobile ecosystem. Permissions on Android are horrendous for developers.…

> If a developer can't tell the difference between ACTION_CALL and ACTION_DIAL, what chance does the average end-user have?

Huh? If a developer had made the choice correctly, the user would never need to know about it.

Re: Android: I don't need your permission

#122
post #119

> Case in point: android.permission.CALL_PHONE. You need it to initiate phone calls from your app, right? This kind of thing is why I can't see myself switching to Android as my primary mobile OS any time soon. If anything, I can see a bright future for Microsoft. In spite of the fact Windows Phone exists, Android is very much the Windows of the mobile ecosystem. Permissions on Android are horrendous for developers.…

> If anything, I can see a bright future for Microsoft. I have both Android and Windows Phones. The Windows Phone is actually quite good and from developer point of view, a pleasure compared with Android tooling and APIs. Just the way Microsoft behaved with the customers has made many look elsewhere.

I've been developing for Android since 2009. I also own Windows Phones too. I prefer WP.

If WP would achieve just 10% market share in my country, I'd drop Android in a heartbeat.

My app deals primarily with Bluetooth BR/EDR + BLE comms to to external devices. Its been nonstop bugginess.

Nevermind Wifi Direct, which I can't get working on a good day. I keep hoping the opengarden guys will be able to overcome the crappy Android apis.

Re: Android: I don't need your permission

#124
post #66

Earlier quoted context omitted.

But, we're not an activity! That's the issue! We're a background service to play audio. And adding a new permission is the opposite of what we want.

You don't have to be an activity at all, your service can do that. But the comment where someone might just be browsing their contact list makes sense too.

A service is not a pausable activity.

Re: Android: I don't need your permission

#125
post #41

I wish it was that easy in all cases. For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service). The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work. But on the play store it's w…

It almost seems like they do it intentionally to improve tracking and desensitize users. Only a terrible engineer would think needing to know if the phone is ringing needs a permission, let alone one that provides unique IDs plus the phone numbers on phone calls. It's one more reason I've gone from loving Google to actively avoiding them. (Also, they've very aggressive in getting people to turn on location info and h…

It should need a permission in my opinion. Why should a calculator (for example) know if there is incoming call?

But this case should be handled by a permission in dialer (or whatever handles incoming calls) - something like "allow to broadcast mute to all other applications".

Re: Android: I don't need your permission

#126
post #60
post #41

I wish it was that easy in all cases. For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service). The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work. But on the play store it's w…

It is totally nuts. Whoever thought to bundle all of that stuff up in one huge permission...

It would be bad either way. Now you have strong permission, otherwise you'd have hundreds of them.

What could help are groups in which you could select only certain items, but it would be presented to users as a group. But they would be able to open the group and see each individual item.

And of course, the biggest issue is that users can't manage (restrict) the permissions themselves (without a superuser app at least).

Re: Android: I don't need your permission

#127
post #41

I wish it was that easy in all cases. For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service). The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work. But on the play store it's w…

I think if all such problems are reported to Google (bugs filed), they might fix these in the next versions of the APIs (i.e., making permissions more fine-grained and less inclusive)

They have reasons for not-so-granular APIs. Plus they are know n for ignoring community requests (not just in Android).

Re: Android: I don't need your permission

#128
post #121

> Case in point: android.permission.CALL_PHONE. You need it to initiate phone calls from your app, right? This kind of thing is why I can't see myself switching to Android as my primary mobile OS any time soon. If anything, I can see a bright future for Microsoft. In spite of the fact Windows Phone exists, Android is very much the Windows of the mobile ecosystem. Permissions on Android are horrendous for developers.…

> If a developer can't tell the difference between ACTION_CALL and ACTION_DIAL, what chance does the average end-user have? Huh? If a developer had made the choice correctly, the user would never need to know about it.

Unless the developer actually needs to do something that requires a permission.

Re: Android: I don't need your permission

#129
post #126
post #60

Earlier quoted context omitted.

It is totally nuts. Whoever thought to bundle all of that stuff up in one huge permission...

It would be bad either way. Now you have strong permission, otherwise you'd have hundreds of them. What could help are groups in which you could select only certain items, but it would be presented to users as a group. But they would be able to open the group and see each individual item. And of course, the biggest issue is that users can't manage (restrict) the permissions themselves (without a superuser app at leas…

I don't think it would be bad to have more granularity. Being able to detect when a call is coming in, in order to mute, is entirely different from being able to read phone identity (IMEI etc), incoming phone numbers etc etc.

It may not need hundreds more permissions, it may even only need one more as this one seems to be a very common problem.

Re: Android: I don't need your permission

#130
post #77

Earlier quoted context omitted.

The same people that would prefer if you give all permissions. I still see no reason why Google doesn't implement more granular permissions models. Has the latest Android given you the ability to restrict an apps permissions after install without resorting to trusting 3rd party tools like xPrivacy or uninstalling the app?

The existing permissions are already so fine grained it's insane. Almost every API has its own permission, regardless of whether that would be understandable to normal users or not. The Android security model does a great job of security . It was not designed to be a general purpose privacy guard that lets you engage in some complicated multi-way negotiation with every app you install over every aspect of your person…

They clearly aren't so fine-grained as all that, not in this area, because they still have a single permission that covers not only knowing when a call is in progress, but also phone identifiers like IMEI, the incoming phone number and a load of other stuff.
Post reply on HN