Shouldn't WifiLockManager check if a lock is already held?

[crocsandcoffee]

Hey there,

I wasn't sure what was the right issue type to use here, so I thought I'd ask here first.

I recently came upon a crash in firebase: java.lang.UnsupportedOperationException: Exceeded maximum number of wifi locks. After following the breadcrumbs, I found it came when calling ExoPlayer.prepare() which eventually leads to acquiring a wifi/wake lock, depending on player configurations set.

I took a look at the source code in Exoplayers WifiLockManager and noticed the updateWifiLock() method doesn't check if the wifi lock is held, before attempting to acquire one. Here is link to the source method: https://github.com/google/ExoPlayer/blob/release-v2/library/core/src/main/java/com/google/android/exoplayer2/WifiLockManager.java#L83

I believe what you want to do is something like below, to avoid obtaining multiple wifi locks.

if (enabled && stayAwake) {
     if (!wifiLock.isHeld) wifiLock.acquire();
} else {
      wifiLock.release();
}

[marcbaechinger]

The JavaDoc of WifiManager.WifiLock.acquire() says that any call to acquire after the first call is ignored if WifiLock.setReferenceCounting(false) is called.

ExoPlayer is doing this right after the creation of the WifiLock since this commit. The commit actually changed from the approach you are suggesting to not using reference counting.

With what version are you seeing this problem? The change went into 2.11.4.

[crocsandcoffee]

Interesting.... I followed through on all the links, commits and documentation you shared, and indeed if you disable referencing counting then repetitive calls to acquire should be ignored. However, I am seeing these crashes with my app in production using v2.18.0. I checked source and looks like the file WifiLockManager has changes since the commit you shared, with how the wifiLock is created. Now idk if this may be a culprit, but my read through of current code looks OK, but the crash I shared shouldn't be happening then with v2.18.0