Comment 7 for bug 1518764

Music app is part of the lifecycle exemptions list. When it is launched, QtMir obtains a wakelock for it to stop the system deep-suspending. This means that while Music app is open, your system cannot deep suspend, which is mainly a low-power CPU state.

Other apps however will still be frozen if they are not in front. Just Music app will never be frozen.

Since system not deep-suspended, it is possible for **any other process** on your phone to use as much CPU as it wants.

So if any of the daemons (and the music app) has a bug, it might end up consuming all your battery while your display is off.

Just testing it on Bq with today's rc-proposed image (190):
1. launched Music app. Wakelock held by shell for it ("power-cli list" prints an "active" lock held) - CPU usage zero (just watching "top"). Looks reasonable.
2. Blank the screen. Wakelock still held. CPU usage zero. Looks ok.
3. lit screen, playing a song. Wakelock held. CPU usage about 20%
4. blank screen while song playing. CPU usage stays around 20%.

This state could be improved as unity8.log is reporting frames being dropped: this means Music app is drawing, even though display is off - pointless. Fixing bug 1475678 should resolve this.

The remaining CPU is being used by media-hub and pulseaudio to play the audio.

5. pausing the song, and letting the display blank, I see almost zero CPU usage. Wakelock always held though. But that's as good as we can do.

With some playing around, I've not managed to get Music app to mis-behave: if no music is playing, music-app using no CPU really. So I suspect another process on the phone is misbehaving.

Could someone here who suffers from this issue please "adb shell" into their phone and run "top" and look at what processes are using CPU while your display is off.
Thanks
-G