Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACCESS_NETWORK_STATE permission being mandatory since 2.10.0 #6019

Closed
tibbi opened this issue Jun 11, 2019 · 2 comments
Closed

ACCESS_NETWORK_STATE permission being mandatory since 2.10.0 #6019

tibbi opened this issue Jun 11, 2019 · 2 comments
Assignees

Comments

@tibbi
Copy link

tibbi commented Jun 11, 2019

[REQUIRED] Issue description

The library requires the android.permission.ACCESS_NETWORK_STATE permission since version 2.10.0, it crashes at initialization via ExoPlayerFactory.newSimpleInstance(context), if not granted. I'm using the library only for playing locally stored offline videos, so is there any way I can tell ExoPlayer to just ignore everything internet related and work offline? IMHO that should be the default behaviour. Wrapping whole ExoPlayerFactory.newSimpleInstance(context) in a try/catch block will catch the exception, but then I won't receive a usable ExoPlayer instance.

Crashdump:

Process: com.simplemobiletools.gallery.pro.debug, PID: 5873
java.lang.SecurityException: ConnectivityService: Neither user 10901 nor current process has android.permission.ACCESS_NETWORK_STATE.
    at android.os.Parcel.createException(Parcel.java:1950)
    at android.os.Parcel.readException(Parcel.java:1918)
    at android.os.Parcel.readException(Parcel.java:1868)
    at android.net.IConnectivityManager$Stub$Proxy.getActiveNetworkInfo(IConnectivityManager.java:1216)
    at android.net.ConnectivityManager.getActiveNetworkInfo(ConnectivityManager.java:924)
    at com.google.android.exoplayer2.util.Util.getNetworkType(Util.java:1716)
    at com.google.android.exoplayer2.upstream.DefaultBandwidthMeter.<init>(DefaultBandwidthMeter.java:263)
    at com.google.android.exoplayer2.upstream.DefaultBandwidthMeter.<init>(DefaultBandwidthMeter.java:48)
    at com.google.android.exoplayer2.upstream.DefaultBandwidthMeter$Builder.build(DefaultBandwidthMeter.java:189)
    at com.google.android.exoplayer2.ExoPlayerFactory.getDefaultBandwidthMeter(ExoPlayerFactory.java:446)
    at com.google.android.exoplayer2.ExoPlayerFactory.newSimpleInstance(ExoPlayerFactory.java:337)
    at com.google.android.exoplayer2.ExoPlayerFactory.newSimpleInstance(ExoPlayerFactory.java:299)
    at com.google.android.exoplayer2.ExoPlayerFactory.newSimpleInstance(ExoPlayerFactory.java:193)
    at com.google.android.exoplayer2.ExoPlayerFactory.newSimpleInstance(ExoPlayerFactory.java:127)
    at com.google.android.exoplayer2.ExoPlayerFactory.newSimpleInstance(ExoPlayerFactory.java:115)
    at com.google.android.exoplayer2.ExoPlayerFactory.newSimpleInstance(ExoPlayerFactory.java:105)
    at com.simplemobiletools.gallery.pro.fragments.VideoFragment.setupPlayer(VideoFragment.kt:280)
    ...

[REQUIRED] Reproduction steps

The library itself has the required permission declared in the manifest file, but my app is offline and I don't want to request it, so I'm removing the permission with <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" tools:node="remove"/> in my apps manifest file.

[REQUIRED] Version of ExoPlayer being used

It is broken at com.google.android.exoplayer:exoplayer-core:2.10.1 (also 2.10.0), it used to work just fine with 2.9.6. I'm not using any other modules.

[REQUIRED] Device(s) and version(s) of Android being used

Testing on Android 9, but it doesn't matter in this case.

@tonihei
Copy link
Collaborator

tonihei commented Jun 14, 2019

That's an interesting use case. Our assumption was that this permission is a normal (i.e not dangerous) permission and thus is automatically granted without user interaction and cannot be revoked by the user. We didn't expect that someone would remove the permission via the manifest as done here. Can you explain why this is needed or how this makes a difference?

We would rather keep the permission by default because it's not clear if an app requests this permission automatically as it may not know that it needs it. However, we could catch the permission exception in the few places where we use the permission.

@tibbi
Copy link
Author

tibbi commented Jun 14, 2019

Well, I have a suite of apps used by millions of people. Some of the most important properties are apps being offline and having no unnecessary permissions, so I obviously want to avoid that redundant permission. I think that keeping it in your manifest file and catching all related exceptions would be a perfectly acceptable solution. Thanks

@google google deleted a comment from google-oss-bot Jun 16, 2019
ojw28 pushed a commit that referenced this issue Jun 18, 2019
This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.

Support this use case by gracefully catching the exception in the relevant
places.

Issue:#6019
PiperOrigin-RevId: 253759332
@ojw28 ojw28 closed this as completed Jun 19, 2019
ojw28 pushed a commit that referenced this issue Jun 19, 2019
This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.

Support this use case by gracefully catching the exception in the relevant
places.

Issue:#6019
PiperOrigin-RevId: 253759332
ojw28 pushed a commit that referenced this issue Jul 9, 2019
This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.

Support this use case by gracefully catching the exception in the relevant
places.

Issue:#6019
PiperOrigin-RevId: 253759332
@google google locked and limited conversation to collaborators Oct 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants