[jbk]

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 written "read phone status and identity" and that's really really scary for the users.

And even if we're 100% open source, so people can check the application, and even people recompile VLC, this is a complaint we receive a lot...

[masklinn]

> 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.

It's seriously back-asswards that you'd have to have access to all phone state just to be able to start and stop audio on phone calls.

By comparison iOS has an audio interruption system which gets triggered on phone calls, alarms (calendar and clock) and other applications taking over the audio, the application getting interrupted neither not knows nor cares where the interruption comes from, only that it doesn't have the audio stream anymore.

[quantumet]

So does Android:

http://developer.android.com/training/managing-audio/audio-f...

http://android-developers.blogspot.com/2013/08/respecting-au...

[jbk]

We're already doing this. It's not enough. See our source code.

[yincrash]

Could you link to the relevant class?

[jbk]

src/org/videolan/vlc/audio/AudioService.java

[mlrtime]

link to method (I think): https://github.com/mstorsjo/vlc-android/blob/master/vlc-andr...

[gabemart]

This simply doesn't work for pausing audio when the phone rings. The ringer doesn't request audio focus.

[leni536]

The ringer doesn't request audio focus.

I would think that this is a bug in the ringer and not an overall limitation of the Android permission system.

[ygra]

Which doesn't really help the users stuck on Android versions that never get any update or bugfixes. In which case apps have to take the pragmatic route and just work around the issue. Even if that requires a scary permission.

No user would point to Google and say »VLC doesn't pause when the phone rings, fix the ringer, please.«. Rather they point to VLC and say »VLC doesn't pause when the phone rings, fix VLC please.«

[tripzilch]

Would be nice if you could request "you're using an older version of Android so we need more scary permissions".

[MichaelGG]

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 history. They use dark UI patterns to trick people into activating stuff.)

[hrjet]

Adding to that: In Android Lollipop, One can't edit / delete local (phone-stored) contacts. They have to be synced to cloud in order to edit / delete them. If this is intentional, it is a sick dark UI pattern.

[hrktb]

On one hand it's backwards from the user experience POV. On the other hand it garantees consistency and resolves most of the weird edge cases of contacts syncing.

I think the common wisdom would be to put the burden on the engineers to find a solution that somewhat handles all the quircks. Personally I've had so many sync failure and weird behaviors from all the services tried until now that I would settle for a more reliable system, even it had severe usability limitations.

I envy organizations that can omit "obvious" features when they don't have a good enough solution to satisfy all the edge cases.

[gpvos]

Good to know, so I won't update to Lollipop.

I have no desire to use syncing, so I would be stuck without an essential feature, in order for them to fix edge cases in something that I don't need.

[wtbob]

It wouldn't matter if contacts were encrypted client-side, but Google seen to have a severe allergy to client-side encryption. Mozilla are really leading the way on this issue.

What I think is particularly sad is that Google could still make a huge amount of money without exposing one's private information directly.

[9point6]

Don't all the current nexus devices come with full-device encryption enabled?

[wtbob]

Full-device encryption does nothing when data are transmitted off-device.

E.g., as long as my photos stay on my phone, they are encrypted, but if I back them up to Google+ then Google may read them.

Which is really pretty crazy: Google don't need to read those photos (or my contacts, or my documents); my computers need to, and the computers of those I share the photos with need to.

I could encrypt each photo with a unique key, and encrypt that key with my own private symmetric key, as well as my friends' public asymmetric keys, and then both they and I could view the photos at any time (our devices knowing how to access the keys we have authorised for them), but Google would not.

[kasabali]

It doesn't make your synced contacts encrypted in client side, though.

[ansible]

I think it is turned on by default for 5.0. But it has certainly been an option before that. I turned it on with my Nexus 4 under 4.4.

[MichaelGG]

So all the shit that comes pre installed in a SIM is now permanently available?

[rplnt]

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".

[tripzilch]

> Why should a calculator (for example) know if there is incoming call?

Because it's running on a phone.

Remember those cool requestAnimationFrame side-channel timing attacks. I think it'd be pretty hard to hide at least certain things like these from an app if it really wanted to know. In this case I think it's pretty fair to just give it an API call for it.

[MichaelGG]

Why shouldn't it? It's on a phone; it's part of basic usability. And the cure in Google's case is far, far worse. Give them access to your IMEI and phone numbers in and out. I know assume incompetence over maliciousness, but this stretches belief. Especially combined with the rest of Google's little tricks.

[marcosdumay]

> I know assume incompetence over maliciousness, but this stretches belief.

It's worse than that. Android had a saner permission interface, with a separated permission just for detecting if the phone is ringing. Google "updated" it to the current format alledging the previous one was too confusing.

[gabemart]

I also have an audio app with a background audio service on Google Play, and I also have to request the READ_PHONE_STATE permission. I have an explanation in my store listing but I still get emails about it every week.

It's totally nuts. Knowing the phone is ringing or off the hook should not be privileged information.

[dllthomas]

"Knowing the phone is ringing or off the hook should not be privileged information."

It seems like it could be a privacy concern. It seems a common enough need that it probably shouldn't be lumped together with other things, though.

[MichaelGG]

Could you elaborate how it's a privacy concern? I have to get pretty darn creative to come up with any scenarios.

[dllthomas]

What makes a privacy concern legitimate, to your mind? It's giving data about a person to a group that otherwise would not have had access to it. It seems first order a privacy concern.

There's also some possibility it could be turned into more sensitive data - if my app tends to be recommended around social circles, and I see two people were on the phone over the same period of time, it's likely they were talking.

[MichaelGG]

And if a service can reach out to the Internet, it knows my IP can tell where I am. And if it suddenly cuts out after being on a known IP, then maybe I'm going through a local tunnel.

That's what I meant by you have to get really creative to think how this could possibly be impacting. If you have a sandbox, you have to choose which permissions you're going to ask for carefully, to avoid overloading users.

Android made a bad decision by making phone apps needing permission to know if the phone is active, then compounded that by tying it into device ID and who you're calling.

[dllthomas]

"The privacy concerns are not significant enough to merit demanding permissions" is certainly a defensible position; I'm not sure whether I agree with it, but it's not crazy.

That is distinct, though, from "there is no privacy concern."

[johnsoft]

I'm not doubting that you've thought things through and you're correct, but could you explain why handling audio focus events isn't enough? http://developer.android.com/training/managing-audio/audio-f...

I've been working on a streaming music player for Android lately. After doing some basic testing on one device, onAudioFocusChange seems to be all I need to duck and pause/resume for incoming calls, but I'd like to make sure I handle all the corner cases correctly.

[Nursie]

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

[rplnt]

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).

[Nursie]

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.

[r00fus]

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?

[mike_hearn]

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 personal data. Such a system might be a feature of future operating systems, but currently I'm unaware of any such OS.

[Nursie]

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.

[blub]

The future is here, it's called iOS. Blackberry does a decent job too. In fact, companies that don't do ads & tracking seem to have this in common. Not sure what the sit with MS is, they used to have something like the Android model.

[masklinn]

> 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.

In fact they have gone the other way with "permission groups"

> 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 hidden "AppOps" (post-install management of permissions) appeared in 4.3 but was removed in 4.4.2, so no.

[ZoFreX]

> In fact they have gone the other way with "permission groups"

It's interesting that they went forward and then back on this. Ages ago the permission "read contacts and call log" was split up into two separate permissions. These days the Play Store displays either permission the same way - something like "read contacts or call log".

[blueskin_]

Google will never do that themselves, because it interferes with their own datamining business. XPrivacy will always be required to control your own data.

[gdrulia]

This has always baffled me, especially when phones doing their phone mission worse and worse over time. What I would really like is that all non-system applications would be pushed to hold pattern, similar as if application is not visible, except it would be applied to background services as well, so that all resources would be available to calling application. Maybe that would solve the lag I experience with every android phone when someone calls me and I try to pickup.

[iscrewyou]

This. This is why I am moving to iOS.

I installed Pocket. It wanted permission Contacts and Calendar. Contacts, I understand for sharing purposes. Calendar? Yeah, fuck off.

Maybe they are bundled together like "read phone status and identity" and Pocket has no way around it. Maybe it is not. As a user, I should not have to worry about that.

Contact and Calendar in no way should be bundled together.

[frik]

VLC isn't available on iOS anymore. At least not in Apple AppStore in Europe :/

Rumors say Apple removed/hide VLC. Though Apple hasn't removed all the shady gray-zone VLC closed source forks that float around in AppStore with questionable Ads and micropayments. The original VLC is still there for Jailbreak users: http://www.videolan.org/vlc/download-ios.html

[icebraining]

Maybe they are bundled together like "read phone status and identity" and Pocket has no way around it.

They aren't.

[Oletros]

They are

[icebraining]

No, they aren't. READ_CALENDAR is a separate permission from READ_CONTACTS.

[TheQwerty]

You're correct that they are indeed separate permissions but I think when Google started putting them in buckets for displaying to the user they lumped the two together.

For instance on one address book app the website currently shows them asking for: Contacts/Calendar -read your contacts -modify your contacts

While the app on my phone says: Contacts -read your contacts -modify your contacts

According to Android Police an update earlier this month to the Play Store app appears to have separated them again: http://www.androidpolice.com/2014/12/06/apk-teardown-play-st...

[hellbanner]

There's still no way to pick and choose on Android is there?

[sleepychu]

Not vanilla, CM's privacy guard does a fairly decent job.

[blueskin_]

Sometimes, I've seen apps on the play store with a section explaining what each permission request is for with details of what it uses and why. Did you consider adding a section like that for VLC?

[jbk]

We _already_ do that in the play store description, of course.

That does not prevent the emails.

[piyush_soni]

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)

[rplnt]

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

[aferreira]

Actually, I don't think you need it.

If you can request permission to read the list of activities and do so when your activity is paused, you can search for the phone application (or even similar ones, such as Skype) and pause your audio playback?

Just a thought.

[masklinn]

That the phone application is launched does not mean the user is currently in a call, they could be browsing their contacts list.

[mcintyre1994]

Skype is an even worse example too, I use it for IM more than calls and it presumably stays open for a long time, probably forever on those occasions.

[Nursie]

Skype wants to BE your phone app. It is not allowed.

[jbk]

That too.

[jbk]

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.

[aferreira]

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.

[jbk]

A service is not a pausable activity.

[learnstats2]

"Check out everything I do with my phone" is one of the permissions I would be more concerned about giving up.