One of the reasons is because Unity (annoyingly and unnecessarily) runs ADB (Android Debugger) in the background when you start Unity – EVEN if you don’t use Android. This persists beyond Unity. This means when you shut down Unity, ADB is start a spawn of the Unity process.
You need to kill adb.exe within your shutdown sequence if within the editor~
Yell at Unity for lazy coding for spawning adb.exe when we’re not even using Android as a selected platform. All they’d need to do is check out platform and only include it if (android)
I doubt anyone filed a bug - this is a relatively minor nuisance and at least to some degree not the fault of Unity at all. The issue with adb though is probably specific enough that it is actionable and worth a report.
Seems that it was fixed – for 2017.1, go figure, even though it was reported a year ago in 5.x.
And I thought 5.6 was unstable, reading some horror stories about the freezing in 2017 and how the next .NET version was just sort of thrown in, more or less unusable if you don’t want to freeze every few mins. Of course no one would upgrade for this little fix haha, but I’ve definitely looked into it.
I’d pay cash for a truly stable version, even though most enterprise software companies are generally expected to do that, it’s a shame that Unity doesn’t follow standard expectations when it comes to “stable releases”. “Upgrade to the next version for fixes!”, they say –oh, we forgot to mention the other 10k bugs we introduced and left untested. Buy the next version, it’ll fix those! --oh, we forgot to…–.
If it’s like many of the other bugs, there’s also a good chance it was just “marked” as fixed, hoping no one would notice, like many of the other “fixed” bugs
Not sure what relevance Baron Beartooth has because it won’t mean the game is automatically fixed at all, or even if Rust will ever, ever move to that version.
This is not a Unity issue, it’s a Steam issue. Starting the steam API will permanently mark the current process to be running for the “in-game” check. This spreads to any child process you spawn while the steam API is loaded. I believe it does not matter if you call the shutdown API, that only frees memory (does not unmark it).
So if you run the API in the editor, any process spawned has to be stopped (including the editor itself) before you’ll stop being “in-game”. Whether this is a spawned browser from the asset store, any program through opening an asset or ADB running doesn’t matter.
If you talk about editor then its because Steam have a hard time understand which process that it should monitor. i usually just kill the steam client process when it fails to understand the game is not running
So it’s Steam’s fault that Unity unnecessarily creates a subprocess of ADB when no Android is present at all? And it was apparently fixed in 2017.x as a bug (should be a patch since it’s existed for years), so it doesn’t… really make sense what you say. But hey.
Yeah the ADB for non-windows is a unity issue, sorry. I should’ve read better. (It’s still sort of a steam issue though, it just gets worse when combined with the ADB issue)
I just came across the same issue. There was no adb in my Task Manager. I ended up restarting my computer, and my game was back to normal. I am pretty sure that it’s Unity Editor’s fault.
Did you also close any file explorer / web browser windows that may have been opened from within Unity? As others have pointed out, Steam also considers these.
Unrelated to Unity, this explains issues I’ve seen while using Steam in general.
If this is the case, to me that’s pretty clearly a Steam thing because of the exact use cases mentioned. If a game opens a browser and I then go and do other stuff in that window, the game should be able to explicitly tell Steam that it’s not running any more and Steam should respect that.
It could be worth checking to see if that’s an issue in the Steam API, or the .NET wrapper.
As this thread popped up when I looked for my own notes for this issue (and those notes did not), and because it’s probably also helpful for others, I’m posting this here:
In a nutshell: When running the game inside Unity, any process that was started by Unity will keep the game “running” in Steam. That includes Visual Studio, Rider or any IDE that Unity opens. It also includes processes like adb.exe, or, as I found out after doing some process dependency investigation, VBCSCompiler.exe and conhost.exe. Or SteamVR. And of course, Unity itself still running (exiting play mode obviously doesn’t close the Unity process - and that’s what Steam is looking at).
IMHO, this is neither Unity’s fault, nor Steam’s fault. It’s just how these things work and you have to know it. There are good reasons for Steam to do it the way it does it, and there are good reasons for Unity to behave the way it does.
It’s a pretty annoying issue though. It spans across to ANY process that you invoke through Unity, including Explorer windows, VLC Media Player, Photoshop, etc.
In future when I’m not specifically testing Steam API features I think I’ll write an editor feature to just turn it all off to save me this hassle.
It is very unlikely that this will ever change. It’s not a bug. It’s simply how the two systems are designed. Steam is primarily designed for players, Unity is designed for developers. If you find the behavior annoying, one simple way to solve it is to disable connecting to Steam in the editor unless you really have to.
