Overview

It’s easy to feel overwhelmed or just plain stupid as a developer - and being a beginner can compound this feeling massively.

Not knowing something, but being surrounded by people who seem more intelligent, or more experienced than us, can make us doubt ourselves.

In this article, I wanted to show that usually with…

• patience
• clearly identifying our problem or goal
• time spent trawling documents
• a logical approach
• ultimately asking for help

… we can (usually) figure most things out.
… but not always.

As a heads-up; there isn’t a successful resolution to this blog.

I had a problem that stumped me, rather than just ask a question in a place like StackOverflow, I thought some people may be interested in the process that I went through, to try and reach a resolution.

A message I really wanted to convey with readers, is that even someone who has been doing the computer-thing for many years - can and will get totally stuck.

We all need to ask for help at some point. However, we will find that most people will be a bit more receptive to helping us if we can show that we’ve put a bit of effort into finding out an answer for ourselves first!

This article is really aimed at two types of people:

• To perhaps provide inspiration for the beginner, who encounters problems in their day-to-day and wonders how on earth someone could possibly begin to figure out something more complex by themself.

• If you’re here because you’ve been googling for the same specific problem as I’ve been looking at, you can skim-read this article and cherry-pick any useful content!

The “subject problem” for this article is almost incidental - but I thought I would share something that’s been a thorn in my side for a few weeks…

Be clear - what’s the problem?

Let’s start by clarifying what the actual problem is. If we can deliver a clear and concise explanation, we’ll be better able to ask for help.

Better still, by consciously rubber-ducking, there’s a really, really good chance that we’ll be able to figure the problem out by ourselves - just by explaining it better.

Anyway, here’s my problem:

• ” I’m trying to remotely debug a very basic sample application, that I’ve created using Unity 2019, which has been deployed onto a hardware Android device. “

• ” When trying to attach the Unity Debugger, I expect to be able to see both the USB and Wifi (TCP) instances of the Unity-player listed. However, only the Wifi(TCP) instance is appearing in the list. “

• “I’m using current versions of Visual Studio 2019 and the ‘VS2019 Tools For Unity’ Extension. I have also tried using JetBrains Rider with the same failing outcome.”

• “I have established that the problem is specific to my main development laptop. If I use another computer, I then see the result I am expecting. Therefore I have eliminated my mobile device as a common problem.”

• “However, by using the command-line tool ADB.exe, I can reliably demonstrate that I can create a connection, with the device showing both WiFi and USB connections. I feel inclined to discount USB drivers as the problem.”

• “I suspect that the problem is likely related to some conflict-related scenario with my installation of the Android SDK and/or ADB specifically. It perhaps could be something related to how the ‘Tools For Unity’ Extension (and Rider) interfaces with ADB.”

• “I can confirm that during any attempts to connect the debugger, my Unity application does have a ‘development build’ deployed and that it IS running on my mobile device!”

In the above summary, I made an assumption that the reader will know what “ADB” is. If you’re a casual reader, we can’t make that assumption - so don’t worry, we’ll talk about this topic a bit later in the article!

Next, let’s now add some technical detail, so that other people can see which versions of the software we’re talking about. Also, this is important for giving our question relevance to future readers (people are more likely to be interested in up-to-date content, not something from five years ago).

Specifically, I am using:

• Visual Studio Community 2019 - v16.3.8
• (Extension) Visual Studio 2019 Tools for Unity - v4.3.3.0
• Unity v2019.2.17f1
• Android SDK (as installed by Unity) - including ADB v 1.0.40
• My Android device is a Samsung S9 Plus

Just so we know what we’re all looking at, this is a screenshot of the dialogue box. We expect it to be showing two separate instances - the TCP connection (which is showing) and the USB connection (which is missing).

Is there any primary documentation to follow?

I believe that the following guides are the main sources of documentation that we should be referring to:

• Unity Documentation : Debugging C# code in Unity
• Microsoft Documentation : Troubleshooting and known issues (Visual Studio Tools for Unity)

Let’s try and break down the problem logically.

Let’s walk through some of the steps we could take to attempt to diagnose the problem and resolve things.

To my knowledge, these are quite a few moving-parts here - any of which could be causing the problem:

• Our App (e.g. not correctly set up for debugging, not correctly deployed, not actually running)
• Hardware connections (e.g. bad USB lead, etc)
• Networking (e.g. router, WiFi setup, Firewalls, etc)
• Device drivers (e.g. the specific USB driver for a particular mobile device)
• Android SDK (e.g. installed in wrong way, multiple copies conflicting, etc)
• ADB - Android Debug Bridge (related to SDK - similar questions about conflicts)
• Visual Studio (e.g. is there a bug in the IDE?)
• Tools For Unity Extension for Visual Studio. (e.g. is there a bug in the extension?)

Is the problem with my mobile device?

Before we go down a rabbit hole of diagnosis, let’s establish if this is a localised problem to the development computer - or whether this is related to the mobile device.

• Does this work on another computer?

To try this out, I recreated the sample Unity project (it was nothing more than a rotating cube) and deployed it to my device. When I tried to attach the debugger, everything worked as expected!!

Here is a screenshot (taken on the other computer), this time showing the USB instance that we are expecting to see:

• Is this a project-related problem?

It could be something to do with the Unity project - the code, the configuration, etc. To eliminate this, I quickly recreated the test project a second time, this time back on the problematic development machine. I deployed a new version of the app to the mobile device.

When connecting the debugger, I was back to square one - only the one instance was showing again.

By doing this, we established that this problem was specific to my main development computer. This is helpful to know, but my instinct is that this is likely to be a tricky problem to diagnose and fix.

Investigate Connections & Networking

Returning back to the problem computer; Let’s check that the following is not causing a problem:

• physically check the data cable - was it connected ok?
  
• check “enable USB Debugging”
• check “default USB Configuration” set to “transferring files” (not “USB tethering” or other option)
• try “revoke USB debugging permissions” on the device (subsequently re-accept permission).
• try temporarily turning the computer’s firewall off (windows defender)
  • this, in particular, was high on my list of candidate problems, based on various unrelated experiences over the years.
• check that any VPN (on the mobile device, on the computer) is not active
• specific to WiFi connections, check that our router has correctly assigned an IP (can we perform other internet activities using the WiFi connection?)

For me, none of these checks had any impact.

Check that our App is correctly built for debugging.

In Unity:

• “Development Build” selected?
• “Script Debugging” selected?
• “Wait for managed debugger” selected?
• Re-deploy - make sure we.re working with the build we think we are!

In Visual Studio:

• Is the app actually running when we attempt to attach the debugger?

And just to clarify that during these tests I really do have my application running and ready to be debugged, here’s a screenshot of what that looks like

It’s possible that we’re using a version of the Android SDK not recommended by Unity. We can check that this is ok by:

• In the Unity Editor, select “Edit” → “Preferences”
• Highlight the “External Tools” tab
• Check that the options are set to the recommended “install with Unity” selections.

For me, this was all correctly set, so nothing changed.

Investigate ADB

Next, let’s looking at something called Android Debug Bridge (adb.exe):

• ADB is one of several tools supplied as part of the Android SDK
• ADB is used to issue commands related to development and debugging.
  • It provides the “bridge” between the mobile device and our development/debugging application.
  • We can use it to do things such as deploying application packages.
    
• When we installed Android support for Unity, we should also have installed the Android SDK - therefore we should already have this tool installed on our computer.
• The exact location will depend on our installation folders and the exact version(s) of Unity we have installed. Be prepared to dig through a very long folder structure to find it!
  • An example of the folder location on my computer is: C:\Program Files\Unity\Hub\Editor\2019.2.17f1\Editor\Data\PlaybackEngines\AndroidPlayer\SDK\platform-tools
• We can read in-depth guides about ADB, here:
  • Android Developer : Android Debug Bridge (ADB) . This is a really useful and thorough resource.
  • xda-developers: what is adb. Look to the bottom of that article for a large list of things we can use ADB for.

As part of our process of attempting to diagnose our connection problems, we’ll demonstrate how we can use ADB to show that we can successfully connect to the Android device.

Courtesy of the guidance provided in this page Stackoverflow : Android Studio wireless ADB error, we will perform these steps:

• Open up a command prompt
• Navigate to the folder where adb.exe lives.
• adb kill-server (to clear out any existing process and start afresh)
• adb usb (to restart the adb server, listening for usb connections)
• adb tcpip 5555 (to tell adb to listen for tcpip connections)
• adb connect 192.168.1.213 (to tell adb to connect to the IP address of our Android device - the one here happens to be applicable to me, you will have to substitute with your own address)
• adb devices (to tell adb to list all of the connected devices)
  • if we add a -l switch to the end of that command, it lists the actual model connected.

If we look at the screenshot I made below, we can see that ADB reports that it can connect both to USB and the IP (Wifi) device. (N.b. For the purpose of taking the screenshot, I copied the platform-tools folder to the root of my disk.)

Finally, I wanted to make sure that ADB was really making a connection over the USB cable and not resolving some connection over WiFi and somehow misleading me.

To test this, I simply turned WiFi off on my phone and re-executed adb devices -l. I still had a successful result - albeit, as expected, I now only saw the one instance representing the USB connection.

Because we can get ADB to report a connection, at this point, I feel inclined to feel that we should eliminate several of the candidate problems that we identified earlier - these being hardware, networking and drivers.

For me, none of this fixed anything.

Other things to try related to ADB

Just before we move on, let’s think if there could be any other likely problems related to ADB.

I tried using an older computer to see if I experienced the same problems. In fact, I experienced another different problem.

I had at some point installed software for an old “HTC One - M8”. This was using another instance/version of ADB and it was being loading at startup. I found that this was conflicting with the version of ADB in the Android SDK - I had to uninstall this software to make any progress at all.

This could be revealing, as it suggests that ADB seems to be in use by different applications - not just by the Android SDK and/or the Unity Debugging Tools.

• Try uninstalling any companion apps that come with our phone.
  

Let’s explore this idea a bit further and see if it yields anything…

It could be that Visual Studio and/or the Unity Tools Extension is trying to run its own instance of ADB (I haven’t managed to research anything that suggests this though). Let’s take a sledgehammer approach and kill off any ADB processes that are running to see if that makes any difference:

• Open up the task manager and go across to the “Detail” tab.
• Locate and “end” any ADB processes.
• Retry connecting debugger in VS

This didn’t make any difference for me, although I did note that when I tried to use Visual Studio to connect the Unity debugger, no other instances of the ADB server where started - I don’t know if this is helpful or not?

For me, this didn’t fix anything.

Investigate device specific USB/ADB drivers

I initially discounted the windows device drivers for the mobile device USB, on the basis of “it already seems to be working”.

Let’s not presume that and make best efforts to address it.

• Go to the website of our mobile device vendor and download and install the latest USB drivers.
  • I have a Samsung phone, so I visited the Samsung Developer Downloads page

However, this still didn’t fix anything for me.

Dig deeper

Let’s see if we can research further.

I found a number of forum messages all sound very similar to my problem. However, none of these postings offered a working resolution.

In some cases these posts are a year or two old - this is not a new problem it seems. Some comments suggest that this problem is specific to Visual Studio (citing that other IDEs work fine). Others cite an incompatibility with Xamarin tools, which is a potentially interesting lead.

• 2017 : Unity Forum : Cannot Debug on Android Device
• 2017 : StackOverflow : Android Studio wireless ADB error (10061)
• 2015 : Unity Forum : Debug android with visual studio tools for unity
  • Interesting, someone in this thread mentions that there was once an incompatibility between Xamarin and Unity and that someone at MS is working on it. The link to the issue doesn’t work. I’ve uninstalled the Xamarin workload - no change.
• 2019 : Visual Studio Developer Community : Can’t attach to Unity debugger using latest version of Visual Studio Community 2019 for Mac
• 2017 / 2019 : Github - Unity/VSCode : Debugging android device possible?
• 2017 : Stackoverflow : Visual Studio Debugger not attaching to Unity
  • Interesting that this again refers to Xamarin not co-existing nicely with Unity. I wonder if this is still a problem - at this point, I’ve tried uninstalling Xamarin (I think it’s all removed).
• 2018 : Unity Forum : Cannot attach managed unity debugger to usb-connected hololens when using il2cpp
  • A reply in this thread mentions that the Unity Debugger uses TCP for connection and that Android makes USB look like TCP.

For me, none of these articles shed any light on how I might fix things.

Could this be a problem with Visual Studio or the Unity extension?

This is beginning to feel like it could be narrowing down to being possibly a problem with Visual Studio directly and/or the “Visual Studio Tools for Unity” extension.

The likelihood of there being a problem with the IDE or Extension seems really unlikely to me. However, our research earlier highlighted that there were bugs caused by interactions between Unity and Xamarin editing, so it’s not completely impossible that there could be bugs.

If this really is the case, then there’s no way we’ll be able to resolve it ourselves (we’ll have to reach out for support).

Before we do that, let’s try one last time to help ourselves by reading around the problem as much as possible:

Referring once again to the document Troubleshooting and known issues (Visual Studio Tools for Unity) , we learn a little about how Visual Studio attached the debugger to an Android process (quote):

“We use multicast for player detection (which is the default mechanism used by Unity), but after that we use a regular TCP connection to attach the debugger. The detection phase is the main issue for Android devices. Wifi is versatile but super slow compared to USB because of latency. We saw a lack of proper multicast support for some routers or devices (Nexus series are well known for this). USB is super-fast for debugging, and Visual Studio Tools for Unity is now able to detect USB devices, and talk to the adb server to properly forward ports for debugging.”

So what we learn from Microsoft docs is that behind the scenes, “Visual Studio Tools for Unity” is talking to the ADB server to enable the debugging features in VS. This is interesting, as it shows how all these elements combine together.

However, the troubleshooting suggestions provided in that document haven’t helped move us forward.

For now, we still are none the wiser if this is the problem

Let’s try out JetBrains Rider

I have been meaning to install Rider for ages. On my desk, I had a promotional leaflet from JetBrains telling me that “Rider can replace Visual Studio” and that it “supports Unity out of the box”.

Let’s see if Rider wants to play ball with us instead…

… and the answer is, no it doesn’t. I have exactly the same problem as I do with Visual Studio (still no USB instance).

Well, Rider had exactly the same problem as VS with the Unity Extension - so I’m inclined to discount that as a problem too!

Actually asking for help

At this point, I had to ask for help as I wasn’t getting anywhere by myself.

Knowing where to turn was itself a problem.

As variants of this question had already been asked on forums, without a great deal of engagement, I decided that this probably wouldn’t yield an answer - at least not in a timely way.

Instead, I thought I should ask for help directly from the experts who work closely in these areas. This fault evidently wasn’t a Visual Studio problem, as the problem also manifested when trying the Jetbrains Rider IDE.

The thing is, I needed someone who had a deep understanding of the subject, so I thought that perhaps the MS team who actually develop the Unity Tooling for Visual Studio may have insight that could help.

Normally, end-users are expected to raise support through a help desk process. The Microsoft helpdesk is a premium (paid-for) service. My issue with this, is that my projects and blogsite articles are not commercial (I earn nothing from them - they are created in the spirit of free community support) - so I didn’t particularly want to have to pay for help.

Instead, trying to be creative, I identified and tried reaching out directly to a developer, on the MS Unity Tooling team, using social media.

Having myself worked as a developer, frustrated by people attempting to bypass established user-support systems, I was respectful that I didn’t really want to harass developers by effectively “cold-calling” them.

I briefly explained what I was doing and asked where I should best go, to ask for help.

Eventually, I was supplied with an email address at MS, which I was told could be used to contact the team directly. Unsurprisingly, the developer wasn’t interested in engaging with me directly.

I emailed the team a few times, but those went unanswered.

A few weeks later, having been unable to interact with the dev team. I instead tried a different approach and contacted someone on the related MS developer relations team.

I received a friendly response, with an initial suggestion that I should raise a ticket with the MS helpdesk. After clarifying that this was a premium service and that I didn’t want to pay - especially when I was working on community projects and not a commercial venture - I waited for a “I’ll get back to you” which, disappointingly, was never followed up.

Timebox

As a blogger, my time is my own. However, after many weeks of not resolving my issues, I had decided that I pretty much run out of inertia.

As a professional developer in the workplace, it’s very likely that we wouldn’t have the luxury of indefinite time to chase up bugs and problems. So we need to manage how much time you spend on problems like this.

To the project manager, a developer diagnosing difficult tech problems can outwardly look much the same as being a problematic gambler - e.g. “just one more go, one more go, I’ll get it this next time!”.

We can feel that we are on the cusp of a solution, only for the resolution to slip out of reach as we discover that the rabbit hole goes much deeper still.

We need to respect that this is a problem and timebox accordingly.

As with development, there can be no right answer to this, but we do need to challenge ourselves to justify how much time is spent investigating problems.

Preferably ahead of spending time on the problem, we should ask:

• how important is the resolution of this problem to the business?
  • is this problem critical or genuinely blocking other activities? or are we just trying to perfect something that doesn’t really need to be perfected. Chasing perfection is expensive and often unnecessary.
• if the problem goes unresolved, what are the likely cumulative costs to the business going to be?
  • e.g. in the case of the problem talked about in this article, what is the ongoing cost of a developer having to use a different machine, or perhaps taking time to reinstall the OS etc.

When to ask for help?

This particular subject is really aimed at developers who work in teams of people of different ability and experience.

It’s typical for a less-experienced developer to struggle and take longer to come to a solution. But how long should this go on for?

• On one hand, asking for help is likely to resolve the problem more quickly.
• Conversely, a developer is much less likely to learn from the process if they always just ask someone else for an answer … there is nothing like stewing over a problem for a long time, in order to remember never to do “that thing” again!

That’s all folks ;-)

I’ve decided to publish the article as-is; I’m sorry I didn’t figure out a positive resolution to the problem for you, but this article may still be useful to someone (or may help them to join their own dots leading to a successful fix!)

If you think you may have a solution, I’d love to hear from you … I deliberately don’t have a comments section on this website, but you can get hold of me on twitter @siliconorchid or siliconorchid @ thatpopulargoogleemailservice.com

Blog Update 25 Aug 2021:

Roughly a year and a half after I originally published this article, I once again found myself stuck with the problem of the remote Unity Android Player instance not being listed in Visual Studio to attach the debugger.

This time I stumbled on a solution … a solution that is nothing more than a VS configuration setting!

Finally, a positive end to this story!

My other blog Logging and debugging with Android is one of my most popular articles - so I've just updated that article with a new section detailing the fix - as I'm sure there will be tonnes of people who will appreciate the update!.

In hindsight, it's frustrating that I was never successful in getting anyone from MS engaged with helping me out here - especially when, in the end, the solution turned out to be super straightforward to resolve.

The real hurdle was describing and identifying the problem, when the tooling provided zero indication or feedback as to why it was failing.

As a self-retrospective, there are no lessons to be learned here from a technical standpoint. From a social standpoint, there may be a lesson in being persistent with people who may be able to help you - it depends on how important the answer is to you I guess!

This is a link to my article that details the fix:

• Logging and debugging with Android - How to fix problem of missing Android debugger instance