Can anyone help interpret this:
If you're just looking for "what do I do next?":
Almost certainly you've got another debugger instance running, or a previously crashed debug session was not cleaned up by the OS. Find and kill that process and it will hopefully be cleaned up automatically. If it isn't cleaned up automatically, reboot is required.
If you're looking for an actual interpretation:
Breaking it down, you've got two error messages.
The first one is: [2015-07-23 06:58:24 - ddms] Can't bind to local 8600 for debugger
Your system ddms (Dalvic Debug Monitor Server) is logging that it cannot bind to a port to attach a debugger.
Sometimes you'd need to do digging to find out why, but almost always the reason a program cannot bind to a port is because another program has already bound to the same port. Typically that means you've got another instance of the program running and listening on that port, or it means a previous run crashed and the OS didn't release it from that port. If you've got multiple apps set for debugging, this can happen. If you need to do that, specify a different port.
The second error is an exception with a stack trace: Highlighting a few of those lines for interpretation:
[2015-07-23 06:58:26 - ddmlib] An established connection was aborted by the software in your host machine
java.io.IOException: An established connection was aborted by the software in your host machine (1)
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(Unknown Source)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(Unknown Source) (2)
at sun.nio.ch.IOUtil.write(Unknown Source)
at sun.nio.ch.SocketChannelImpl.write(Unknown Source)
at com.android.ddmlib.JdwpPacket.writeAndConsume(JdwpPacket.java:213) (3)
at com.android.ddmlib.Client.sendAndConsume(Client.java:675)
at com.android.ddmlib.HandleHeap.sendREAQ(HandleHeap.java:342)
at com.android.ddmlib.Client.requestAllocationStatus(Client.java:521)
at com.android.ddmlib.DeviceMonitor.createClient(DeviceMonitor.java:831) (4)
at com.android.ddmlib.DeviceMonitor.openClient(DeviceMonitor.java:799)
at com.android.ddmlib.DeviceMonitor.deviceClientMonitorLoop(DeviceMonitor.java:617)
at com.android.ddmlib.DeviceMonitor.access$100(DeviceMonitor.java:44)
at com.android.ddmlib.DeviceMonitor$3.run(DeviceMonitor.java:576)
Marker one, the exception message. "An established connection was aborted by the software in your host machine". That is the descriptive message that the system is passing on. That is the key to understanding.
Everything else is the stack trace, it shows where the code was when the exception occurred. Often you need to backtrack through them until you get to your code. You don't need to in this case, but understanding it can help.
So in the interest of understanding, that leads to the lines marked with (2).
Marker two, all five "sun.nio.ch" lines. Those all take place inside "sun.nio.ch." which are Sun's network IO libraries. You don't have the source (that's why it says "Unknown Source"). That doesn't matter, it almost certainly is not those libraries. The network libraries are used by millions of programs, the chances that you found a bug in them is almost zero. Just observe that in all of them, system libraries are attempting to write across a network.
Then marker 3, com.android.ddmlib, writeAndConsume. tells you it is happening inside DDMLib, trying to write to a network location. DDMLib is the library that lets your program talk to the Dalvic virtual machine.
Finally marker 4, which is where com.android.ddmlib is calling createClient. That means everything else, the writing and connecting and creating, all that is taking place when your program is trying to first create a connection to the virtual machine.
None of it appears to be your code.
So that should be all we need to know.
The error message from marker 1 tells you that an existing connection was dropped. Since all the stack trace functions are about writing, it was dropped when the code attempted to write out to a socket. It wasn't your code attempting to do it, marker 4 tells you it was when the connections to the virtual machine were first being established.
So putting all that together, the virtual machine is reporting that SOMETHING is already connected to the debugging port, and also the virtual machine is dropping different connections as soon as they are established.
What is already connected?
I'm guessing that almost certainly if you open up your task manager, you will discover another copy of eclipse (or some other Android debugger) running in the background. That instance is probably still holding a connection to your emulator or device. Kill the other instance and hopefully the OS will automatically release the connections.
If that doesn't work, if you cannot find what is connecting or if the system is maintaining a phantom connection to a dead process, rebooting the device, emulator, or your machine should resolve it.
> WTF does that means?
