8 ms·
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. W
by jbk 12y ago
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...
- aferreira 12y agoActually, 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 12y agoThat the phone application is launched does not mean the user is currently in a call, they could be browsing their contacts list.
- jbk 12y agoThat too.
- mcintyre1994 12y agoSkype 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 12y agoSkype wants to BE your phone app. It is not allowed.
- jbk 12y agoBut, 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.
- learnstats2 12y ago"Check out everything I do with my phone" is one of the permissions I would be more concerned about giving up.
- masklinn 12y ago> 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 12y agoSo does Android: http://developer.android.com/training/managing-audio/audio-focus.html http://developer.android.com/training/managing-audio/audio-f... http://android-developers.blogspot.com/2013/08/respecting-audio-focus.html http://android-developers.blogspot.com/2013/08/respecting-au...
- piyush_soni 12y agoI 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 12y agoThey have reasons for not-so-granular APIs. Plus they are know n for ignoring community requests (not just in Android).
- Nursie 12y agoIt is totally nuts. Whoever thought to bundle all of that stuff up in one huge permission...
- r00fus 12y agoThe 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?
- masklinn 12y ago> 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 12y ago> 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".
- mike_hearn 12y agoThe 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.
- iscrewyou 12y agoThis. 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.
- icebraining 12y agoMaybe they are bundled together like "read phone status and identity" and Pocket has no way around it. They aren't.
- Oletros 12y agoThey are
- icebraining 12y agoNo, they aren't. READ_CALENDAR is a separate permission from READ_CONTACTS.
- TheQwerty 12y agoYou'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-store-v5-1-11-adds-support-for-discounts-through-reward-vouchers/#changing-permission-buckets http://www.androidpolice.com/2014/12/06/apk-teardown-play-st...
- frik 12y agoVLC 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 http://www.videolan.org/vlc/download-ios.html
- gabemart 12y agoI 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 12y ago"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 12y agoCould you elaborate how it's a privacy concern? I have to get pretty darn creative to come up with any scenarios.
- dllthomas 12y agoWhat 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 12y agoAnd 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.
- MichaelGG 12y agoIt 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 12y agoAdding 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 12y agoOn 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 12y agoGood 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 12y agoIt 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.
- gdrulia 12y agoThis 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.
- johnsoft 12y agoI'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-focus.html 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.
- blueskin_ 12y agoSometimes, 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 12y agoWe _already_ do that in the play store description, of course. That does not prevent the emails.