Java – Why can’t OSX detect android Galaxy S for USB debugging

Important Update : As @equiman points out, there are some USB cables that are for charging only and do not transmit data. Sometimes just swapping cables will help.

Update for some versions of adb, ~/.android/adb_usb.ini has to be removed.

Executive summary: Add the Vendor ID to ~/.android/adb_usb.ini and restart adb

Full Details: Most of the time nothing will need to be done to get the Mac to recognize the phone/device. Seriously, 99% of the time "it just works."

That being said, the quickest way to reset adb is to restart it with the following commands in sequence:

  adb kill-server
  adb devices

But every now and then the adb devices command just fails to find your device. Maybe if you're working with some experimental or prototype or out-of-the-ordinary device, maybe it's just unknown and won't show up.

You can help adb to find your device by telling it about your device's "Vendor ID," essentially providing it with a hint. This can be done by putting the hex Vendor ID in the file ~/.android/adb_usb.ini

But first you have to find the Vendor ID value. Fortunately on Mac this is pretty easy. Launch the System Information application. It is located in the /Applications/Utilities/ folder, or you can get to it via the Apple Menu in the top left corner of the screen, select "About this Mac", then click the "More Info..." button. Screen grab here:

Expand the "Hardware" tree, select "USB", then look for your target device. In the above example, my device is named "SomeDevice" (I did that in photoshop to hide the real device manufacturer). Another example would be a Samsung tablet which shows up as "SAMSUNG_Android" (btw, I didn't have to do anything special to make the Samsung tablet work.) Anyway, click your device and the full details will display in the pane below. This is where it lists the Vendor ID. In my example from the screenshot the value is 0x9d17 -- use this value in the next command

echo 0x9d17 >> ~/.android/adb_usb.ini

It's okay if you didn't already have that adb_usb.ini file before this, most of the time it's just not needed for finding your device so it's not unusual for that file to not be present. The above command will create it or append to the bottom of it if it already exists. Now run the commands listed way above to restart adb and you should be good to go.

adb kill-server ; adb devices

* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached 
123ABC456DEF001 device

Strings are immutable. That means once you've created the String, if another process can dump memory, there's no way (aside from reflection) you can get rid of the data before garbage collection kicks in.

With an array, you can explicitly wipe the data after you're done with it. You can overwrite the array with anything you like, and the password won't be present anywhere in the system, even before garbage collection.

So yes, this is a security concern - but even using char[] only reduces the window of opportunity for an attacker, and it's only for this specific type of attack.

As noted in the comments, it's possible that arrays being moved by the garbage collector will leave stray copies of the data in memory. I believe this is implementation-specific - the garbage collector may clear all memory as it goes, to avoid this sort of thing. Even if it does, there's still the time during which the char[] contains the actual characters as an attack window.