Android App Hard Crashing - may be Oreo related [Ticket Open]

Copying @support

On my Nexus 5X, Roon is constantly crashing ever since I upgraded to Oreo. Before then it worked fine.

The behavior is quite weird, though…

  1. Frequently it crashes right after launch.
  2. Sometimes it crashes a couple of minutes into the first song.
  3. Sometimes it never crashes. If I relaunch it often enough, I can usually get it to play.

I have already tried deleting the cache and all data, uninstalling, and reinstalling. It didn’t help.

Let me know if there’s a way to send logs, or if I can be helpful in tracking down the bug…

Hi @Vog ---- Thank you for the report and sharing this observation you have made with your Nexus 5X running Oreo. The insight it appreciated!

Moving forward, to help aide in our understanding of this behavior may I very kindly ask you to please provide the following information:

  • A brief but accurate description of your current setup, using this link as a guide.

  • Describe your network configuration/topology, as well as providing insight into any networking hardware you are implementing. I want to have a clear understanding of how your devices are communicating and the tools being used to make these connections possible.

  • If you have any additional remote devices, how are they behaving?

  • Would you kindly please provide some further insight in regard to the times when you notice this failure (i.e “after launch”, “after a couple of minutes”, “sometime it never crashes…”)…

    • When it crashes at launch are there any other active applications or process running on the device? Are you presented with the “looking for core” screen at any point, or does the application just close?

    • When it crashes after a couple of minutes of the first song how is playback for those couple of minutes? No dropouts are anything, correct? What is the behavior like in the app while it is active just before the failure? Any error messages? Do yo notice it failing on the same track or sample rate every time?

    • When you notice that it doesn’t crash, is there anything different in regard to how you are using the application? Are you doing anything different, procedurally speaking?


Hi @Eric.

Here’s some more info, as requested…

Roon Version 1.3 (build 262) stable (64bit)
Windows 10 64bit
Music is stored on a local hard drive
Fast PC underneath it all (fast processor, lots of RAM, etc.)

Device: Nexus 5X (and Pixel – see below)
Android version: 8.0.0
Security patch level: October 5, 2017

Using default output of the audio device (i.e., the phone itself)
Nexus 5X and Pixel are on the internal wireless network

This exact same setup worked perfectly for months prior to the Oreo update.

The crash happens at launch, or soon after, on an extremely frequent basis. Watching it closely, what happens is that:

  1. Roon launches like normal.
  2. Then the screen dims (like it used to – prior to Oreo it used to stay in a dimmed state, I believe as a fix for the “stopped outputting audio” issue).
  3. The screen will then go dark, and Roon is no long running.

If I start playing music between #1 & #2 above, every once in a while it won’t crash for a few minutes (I haven’t timed it, but it’ll get through a decent sized chunk of a song).

If I relaunch it often enough, it will at some point operate correctly.

I just tested it on a Pixel that also has Oreo (same data as above), and the exact same issue occurs so it’s not specific to the Nexus 5X device itself. That said, it seems to have a better success rate on the Pixel (not sure why).

Let me know if you need anything else,


Hi @Vog ---- Thank you for the follow up and providing the requested feedback!

Moving forward, upon reviewing you last update it sounds like you may be experiencing the same issue being reported here. Would you kindly review and confirm?

I’d like to combine threads if this is the same failure being experienced on your Android 8 devices, as I am currently working with the user in the other thread to determine what is triggering this issue.


Hi @Eric.

It seems to be similar, though it’s hard to be 100% sure. The behavior where it “just disappears” is exactly what I’m seeing, though, so I’d guess it’s the same problem.

FYI, under Android 7.0 there was a Roon update that actually prevented the screen from fully going to sleep. The screen would dim, but stay on. That solved the wifi wake-up issues I had been experiencing here. Prior to that update I never tried the battery optimization solve, as the wifi keep alive apps worked just fine. After the update, though, everything worked well and I was able to uninstall the keep alive apps.

The reason I share all of this is that this screen dimming behavior doesn’t seem to work under Android 8…

Let me know what else you need,



Some more info that’s hopefully helpful… this morning I did a quick test, and found that if I set my screen to turn off after 30 minutes (rather than the default 30 seconds) Roon doesn’t crash (at least for 30 minutes). This matches what I was visually seeing (shared in my earlier posts) – it looks like the issue is tied to the screen turning off.


Hi @Vog,

What I do to keep the Roon app running is switch it to the background (press home button) before the screen turns off (no, not very user friendly :frowning: ). I never had a crash with the app in the background.

Can you try if this also works in your case?

Hi @Vog ---- Thank you for the follow up and the feedback, both are very appreciated!

By chance, did you have an opportunity to test the “work around” mentioned in Jan’s post above? Let me know. Remote logs will be next.


@Eric & @Jan_Koudijs,

I just had a chance to play around a bit, and here’s what I found…

  1. Jan’s work-around does indeed work for me. Going to the home screen keeps Roon from crashing. Thanks, Jan.

  2. Interestingly, when Roon is running but in the background the screen only dims but does not turn off. This “dim but don’t turn off” behavior came in a Roon update a while ago and fixed the “music stops playing” issue under Android 7.

To be clear, if Roon is not running the screen will dim first but then turn off. I validated that behavior. It is Roon that is keeping the screen from turning off, and it does that whether it’s in the foreground or the background.

So my guess (and it’s just a guess) is that there’s something in Roon’s “keep the screen dim but don’t turn off” code that crashes Roon when Roon is in the foreground, but doesn’t crash it when it’s in the background.

I hope this helps,


Thanks for the follow up, @Vog! I will be contacting you via PM momentarily, with the mentioned log gathering exercise.


I don’t have this behavior on my Pixel C.

@Jan_Koudijs may be right.

I am now having trouble replicating what happened yesterday with the screen dimming staying on even with Roon in the background, which is weird. So either I messed up yesterday (which I don’t think I did, but you never know), or something else is going on…


Hi @Vog ---- I wanted to touch base and see how things were going with the Android remote. Any new observations or progress here?

Your ticket is still with our techs, but wanted to check in :sunglasses:


Hi @Eric.

Thanks so much for checking in.

Things are pretty much standardized now – the “go to the home page before it dims” solve is working, so that’s what I’m doing every day. Not ideal, but not terrible.

I can officially report that the screen staying dimmed on the home page with Roon running in the background is, shall we say, “erratic”. Sometimes it does it, sometimes it doesn’t – it’s completely inconsistent. I haven’t been able to consistently replicate it either way, nor determine what’s driving the variation, so am clearly failing my Roon QA duties. :sunglasses:

Let me know if I can be of any more help,


Hi @Vog ----- Thank you for the follow up and more importantly, thank you for your patience while we have been looking over the provided remote logs from the affected device.

Moving forward, after examining your logs our techs have noted that they are not seeing any traces related to the application crashing. In light of this our QA team is going to keep working on trying reproduce this behavior. Once we are able to reliable reproduce this issue, the easier it will be for us to “fix” the problem.


Hi Eric.

Just to make sure… are you not able to reliably reproduce the behavior, or not able to reproduce it at all?

If the latter, let me know and I can send you a video of exactly what happens. It occurs quite consistently on multiple devices, so it’s a pretty easy video to create. :grinning:


Hi @Vog ---- My apologies for any vagueness in my previous response.

It is indeed the latter. We have been unable to reproduce this behavior in house, at all. A video example of what you are seeing would be very appreciated!