[go: up one dir, main page]

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

NetworkTypeObserver doesn't update it's initial value after creation #10970

Closed
1 task
rychagovDi opened this issue Feb 8, 2023 · 1 comment
Closed
1 task
Assignees

Comments

@rychagovDi
Copy link

ExoPlayer Version

2.18.2

Devices that reproduce the issue

Pixel 6 running Android 13

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

No

Reproduction steps

Can't find a real auto-quality dash-vp9 video in demo app - it always asks to choose quality before playback start.

The issue is in adaptive quality selection - due to initially low bandwidth, player choose low quality at the start of playback.

Expected result

Video starts with good quality, accordingly to actual network bandwidth.

Actual result

Video starts with bad quality, because of low initial bandwidth

I investigated the issue, and it seems like NetworkTypeObserver#Receiver#onReceive method doesn't get called after registering broadcast receiver (even later, 'asynchronously').

Seems like NetworkTypeObservers' internal impl expects sticky behavior from BroadcastReceiver (so it would receive last network type after receiver registering) - but actually it doesn't work this way.

Moreover, https://developer.android.com/reference/android/net/ConnectivityManager#CONNECTIVITY_ACTION is deprecated and Google advices to use NetworkCallback or/and direct call to ConnectivityManager#requestBandwidthUpdate() to force-receive current network state and it's bandwidth.

Media

Not applicable

Bug Report

@tonihei
Copy link
Collaborator
tonihei commented Feb 10, 2023

Thanks for reporting!

It looks like this is caused by the newly added REGISTER_NOT_EXPORTED flag when registering the receiver. Up to Android 12, it works just fine and if I mark the registration with REGISTER_EXPORTED on Android 13, it also starts working again.

However, as far as I can see, this shouldn't be needed because callbacks from the system never require REGISTER_EXPORTED. There is a public Android bug reporting this as well at https://issuetracker.google.com/260336345. I'll follow up with the relevant team internally to figure out if this is a system bug or intended behavior .

tonihei added a commit that referenced this issue Feb 28, 2023
Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: #10970

#minor-release

PiperOrigin-RevId: 512020154
tonihei added a commit to androidx/media that referenced this issue Feb 28, 2023
Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: google/ExoPlayer#10970

#minor-release

PiperOrigin-RevId: 512020154
tonihei added a commit to androidx/media that referenced this issue Mar 2, 2023
Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: google/ExoPlayer#10970

PiperOrigin-RevId: 512020154
(cherry picked from commit 93e1179)
tonihei added a commit that referenced this issue Mar 2, 2023
Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: #10970

#minor-release

PiperOrigin-RevId: 512020154
(cherry picked from commit 34b9824)
@tonihei tonihei closed this as completed Apr 4, 2023
@google google locked and limited conversation to collaborators Jun 4, 2023
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

2 participants