> 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.
Curiously, it looks like Google's AOSP music app requests READ_PHONE_STATE but unless I'm missing something they don't use it - relying entirely on focus loss instead. Granted, I'm not sure anything actually uses this code now...
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.«
Split your APK based on SDK version. Have different manifests with different permissions & code for the respective versions. The new Gradle toolchain makes all of that easy to do, but it is tough to maintain lots of version specific code long term.
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.