I’m having the exact same problem with Stuck Partial Wake Locks tagged AudioMix. I’ve looked everywhere in my code and can’t find anything related to a wakelock being acquired and not released. I can’t even find any reference to AudioMix. Any help would be greatly appreciated as this is killing my Android Vitals on the Play Store! Thanks
FYI, I have tested the problem in my game a bit more using
adb shell dumpsys power, although I only have a device to test :S. Anyway I will tell you what I discovered using this device (OnePlus A3003 with android 8.0.0).
When downloading the game form the store, an AudioMix wakelock appears when the game is in foreground. It disappears seconds after going background.
When using the same code debugged through Android Studio no wakelock appears, never.
I hope this can be helpful to find the problem
Any update on this guys?
Any news? It would be very useful for me to fix this
Sorry to bother again with this, but it is getting worse. Now it affects Android 8.0.0 and 8.1 and the percentage of sessions with anr is higher because the percentage of android devices with android 8 is growing up. @slackmoehrle there is nothing we can do to solve it?
Ok. Thanks for updating. I’ll tslk to the engine devs about this. I think they thought this was device specific. What devices are you using?
I was told the team is still researching this issue.
I have tried to reproduce the issue on my devices with no success. The anr is appearing on the google play console and the “By device” section is empty -_-
Sorry for not being of any help
firstly I want to say
partial wake lock will case more battery down, not cause ANR. as far as I am confirmed, we can reproduce this issue indirectly .
- BetterBatteryStats this app can monitor your app’s wake lock info, refer to xda-developers
- Android wifi ADB, debug your app over WIFI, with it we can prevent charging when debug
- install BetterBatteryStats, it will monitor
partial wake lockinfo
cpp-tests, start to play a audio
- when the audio is playing, click the Power button directory, it will close screen directly
- wait a moment, click power button again, now the audio in cpp-tests will resume
- open BetterBatteryStats, switch to Partial Wakelocks item, you will found
- when the audio is playing, click HOME button, and then click POWER button, you won’t found
refer to Play Console Help to know more about those infos.
when debug over WIFI I can found logs, like this
08-03 14:15:57.707 1955-3489/? D/PowerManagerService: [api] setDozeOverrideFromDreamManager: screenState: OFF screenBrightness: -1 [api] acquire WakeLock flags=0x40 tag=DreamManagerService uid=1000 pid=1955 ws=null pkg=android 08-03 14:15:58.244 1955-2531/? I/PowerManagerService: [PWL] On : 421825604 (26559 ms ago) [PWL] mStayOn: false mWakeLockSummary & WAKE_LOCK_STAY_AWAKE: 0 mUserActivitySummary: 0x1
Thx for the info!
By your words, I understand there is no solution for the problem, am I right? :S
In the other hand, this issue is appearing for me under “ANR rate” report, so I called it an ANR issue. Sorry if this misled you to an incorrect approaching to the problem
I reviewed the engine code, not any wakelock being acquired too.
AudioMix it’s a system part, as long as music playing needed, even system audio effect it will acquire wakelock.
partly true, for no any wakelock being acquired in the engine code.
don’t worried for this warn info, it doesn’t have bad effect when someone playing your game. I suggest you to test battery usage for your game, attention to monitor the game player behavior.
I am also having this issue in which Google Play vitals report that my game has a stuck partial wake lock named ‘AudioMix’.
I have corrected one scenario that I identified and described on this Pull Request on cocos2d-x repository
@drelaptop, this metric from the vitals affects the game visibility on Google Play. The threshold is 0.1%.
Could you take a look later on the Pull Request and see if it makes sense. It was easily reproducible with my game and I believe it will with other games/applications as well.
I have been on holidays the last two weeks so I have been completely disconnected from this issue… and now it seems we have good news!!
I have detected another scenario in which AudioMix wake lock would get stuck while the game was on background. Check if this is the case with your application.
So, if the Scene’s EventDispatcher is disabled and the game is minimized, the AudioMix gets stuck.
On my case, the EventDispatcher was being disabled on the transition from one scene to another, and only re-enabled after the transition completed.
If the game got minimized while the transition had not finished yet, the wake lock got stuck even though the sound was paused.
WOW! I must do some tests but my game disables EventDispatcher lots of times so maybe this is my case. Do you have any solution for that?
I simply re-enabled the EventDispatcher when I process the didEnterBackground() event
Oh thanks! I will try it in our next update and will post the results here (maybe we will have data in october).
Again thanks @gibertoni for your help
@drelaptop, I think I have found new info about this problem. I have been testing my game on an HTC One with Android 5.0.2. If I play a large sound file on loop mode (.ogg format played by
UrlAudioPlayer) the next thing happens (100% reproducible):
experimental::AudioEngine::pauseAll();works fine during the first play of the file.
- After it enters the first loop,
experimental::AudioEngine::pauseAll();does not pause the looped audio!
I have debugged and
UrlAudioPlayer::pause is called correctly on step 2, but somehow it cannot pause the music.
So the thing is, when my game calls
AppDelegate::applicationDidEnterBackground() and I call
experimental::AudioEngine::pauseAll();, if a sound is looped using
UrlAudioPlayer, the sound keeps playing even when the game is on background (I have tested, It happens when using home button, turning off the screen or even getting a call). Maybe this is the ANR I have seen on the Google Play Console.
I have been lucky to found a device where I can reproduce the problem
I have found a temporary workaround, instead of just calling
experimental::AudioEngine::pauseAll();, if I use this code to pause, the sound is paused correctly:
experimental::AudioEngine::pauseAll(); experimental::AudioEngine::resumeAll(); experimental::AudioEngine::pauseAll();
I just let you know, maybe you can fix this in the future
Thanks for all!