Subsonic Forum

The service dies on android 4.3 when the device screen is off. This happens both on the lock screen when pressing next, and when the next track is invoked with the screen off. It appears that graphical resources are being recycled on screen off in the latest Android OS. Perhaps we need to register as a broadcast listener for screen on/off events?

Code: Select all

E/AndroidRuntime( 5307): FATAL EXCEPTION: Thread-298
E/AndroidRuntime( 5307): java.lang.RuntimeException: Canvas: trying to use a recycled bitmap android.graphics.Bitmap@42127e60
E/AndroidRuntime( 5307):        at android.graphics.Canvas.throwIfRecycled(Canvas.java:1058)
E/AndroidRuntime( 5307):        at android.graphics.Canvas.drawBitmap(Canvas.java:1128)
E/AndroidRuntime( 5307):        at android.media.RemoteControlClient.scaleBitmapIfTooBig(RemoteControlClient.java:1571)
E/AndroidRuntime( 5307):        at android.media.RemoteControlClient.sendArtworkToDisplay(RemoteControlClient.java:1340)
E/AndroidRuntime( 5307):        at android.media.RemoteControlClient.sendArtwork_syncCacheLock(RemoteControlClient.java:1325)
E/AndroidRuntime( 5307):        at android.media.RemoteControlClient.access$800(RemoteControlClient.java:65)
E/AndroidRuntime( 5307):        at android.media.RemoteControlClient$MetadataEditor.apply(RemoteControlClient.java:568)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.util.ImageLoader.setImage(ImageLoader.java:190)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.util.ImageLoader.loadImage(ImageLoader.java:135)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.util.compat.RemoteControlClientICS.updateMetadata(RemoteControlClientICS.java:75)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.service.DownloadServiceImpl.setCurrentPlaying(DownloadServiceImpl.java:547)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.service.DownloadServiceImpl.playNext(DownloadServiceImpl.java:688)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.service.DownloadServiceImpl.playNext(DownloadServiceImpl.java:672)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.service.DownloadServiceImpl.access$1400(DownloadServiceImpl.java:71)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.service.DownloadServiceImpl$7.onCompletion(DownloadServiceImpl.java:1192)
E/AndroidRuntime( 5307):        at android.media.MediaPlayer$EventHandler.handleMessage(MediaPlayer.java:2306)
E/AndroidRuntime( 5307):        at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 5307):        at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 5307):        at github.daneren2005.dsub.service.DownloadServiceImpl$1.run(DownloadServiceImpl.java:168)
E/AndroidRuntime( 5307):        at java.lang.Thread.run(Thread.java:841)

Ouch. I guess I'll be holding off on upgrading my nexus 4 until this is resolved... Can't be without dsub!

I honestly won't know anymore details until after 4.3 is announced/released. There might have been a change to the way it works, and more info will probably come out about it at that point. Or it may just be a bug that hasn't been fixed in it yet. Remember that wasn't release software, but it was a stolen beta image. I have a Nexus 7 so once it is actually released I can test more.

daneren2005 wrote:I honestly won't know anymore details until after 4.3 is announced/released. There might have been a change to the way it works, and more info will probably come out about it at that point. Or it may just be a bug that hasn't been fixed in it yet. Remember that wasn't release software, but it was a stolen beta image. I have a Nexus 7 so once it is actually released I can test more.

I can tell you that the Google Music app does the same thing with album art. It reloads it after screen off... And even when the app is in the foreground. I'm thinking you'll have to check isRecycled for the next album art image or register with wake/sleep events and handle it that way. No rush though, I'm just going to patch out the call to load album art on mine until it's official. (Or hey maybe even add a jz :goto_99)

Sent from my GT-I9505G

Mind sharing your fix here or one github when you are done? I honestly don't understand why that change would making it be recycled early since the image is loaded right before it is displayed.

Sent from my HTC One X using Tapatalk 2

I have it working at 100% re-loading images as needed as near as I can tell.
Check yo github, mr mang. Or should I say... Mr Scott. ;P

Honestly, I'm starting to wonder if it is causing issues because there is now a barrier between Activity level memory and Service level memory. The ImageLoader class is a static object attached to the Activity, and the RemoteControlClient is using it within the DownloadService. But it is still linking to the Activity ImageLoader in order to not be keeping duplicate copies of the images in memory. Changing the service priority or registering for wakeup events shouldn't make any difference here. Because the service has a ongoing notification, it is already at the highest level possible to not be a target for starvation collection. And no matter what, bitmaps are NEVER supposed to be recycled by the system without your explicit say so, and the only time I explicitly recycle the images is if the buffer is full. The buffer I allocate is fairly large, so there is no reason it should be running into this limit quickly (while testing I usually had to go through 30-40 songs before I filled it). And once it does it should be recycling the oldest images first, not the newest. Something just seems fishy here, but for now I am going to go ahead and pull your commit anyways. It seems like a bandaid right now for a bigger issue, but it should work until I can get the newer release myself and debug what is actually going on here. Thank you for being willing to research and fix this issue, and then for being willing to share the fix

As a diagnostic step, at one point, I actually commented out your explicit recycle line, and was still getting the issue.
It seems like the new revision of the system is a lot more aggressive when it comes to memory optimization. I wonder if maybe the ImageLoader object resources are getting sniped at because the Activity object is getting suspended when the screen goes off. That is my thought: Maybe the system is nuking bitmap objects when an activity is put into a suspended state... In either case my code was written with mindfulness to the idea that it will hurt nothing to have it there even if you resolve the issue. In a perfect scenario, all of the checks I put in will simply show as valid, and program execution will continue as normal.

I'm sure when the API is officially released they will give us a new method for sheltering our bitmap objects from the evil GC monster.

P.S.
Thanks for mentioning you had a github. I was all set to do all of that modding in smali.

That is true that the code you added is perfectly good validation code that should be there anyways, even if everything was behaving correctly. Yah, we will just have to see when the official release comes. Although don't be too sure that it will actually be documented. 99% of the problems that arise from new versions are never documented except for on Stack Overflow with devs asking wtf is going on

I can confirm that DSub crashes on the official 4.3 for the Nexus 4. Thanks for working on a fix so rapidly!

I will see if a update is ready for my Nexus 7 and probably post a fix tonight. Stay tuned.

It's still not showing an update for my Nexus, but I am going to trust Fenny. At the very least it shouldn't cause the problem to be any worse than it already is