Shared publicly  - 
How to get Samsung Nexus S 4G and Droid Charge phones recognized in a vmware VM for Android development (mostly posted for my own future reference):

The Environment

I do Android app development work in virtual machines, mainly to keep the environment free of other projects and personal stuff, and permit easy archiving of both the app and the development environment (allowing easy delivery in entirety to a customer when necessary.) I recently upgraded this environment to Ubuntu 11.04 running in vmware Fusion 3.1.3 on my Mac running OSX 10.6.7.

The Problem

After installing the android SDK in a freshly installed vm, my HTC Hero and HTC Evo 3D were recognized as usb devices (as evidenced by 'lsusb'), but my Samsung Droid Charge (and previously a Samsung Nexus S 4G) were not. 'adb devices' responded with '???????????? no permissions' for the HTC Hero and with no entry for the Samsung devices.

Troubleshooting, Part 1

'lsusb' showed the HTC devices when they were plugged in, but not the Samsung devices. 'dmesg' showed that the Samsung devices were recognized briefly but USB enumeration (Google "usb enumeration"), where the system learns more about the device, failed:

[ 280.960219] usb 1-1: new high speed USB device using ehci_hcd and address 2
[ 296.016944] hub 1-0:1.0: unable to enumerate USB device on port 1

Clues from the 'net pointed to vmware as the problem. On the mac, the vmware VM files are folders, and in them among the messages in the file vmware.log, was found these entries:

Jul 09 12:12:54.218: vmx| USB: Found device [name:SAMSUNG_Android vid:04e8 pid:68c3 path:13/15/8 speed:high family:vendor,comm,storage]
Jul 09 12:12:54.687: vmx| USB: Removing autoconnect pattern from slot 0
Jul 09 12:12:54.688: vmx| USBGM: Device SAMSUNG_Android disconnected; clearing vmx autoconnect.
Jul 09 12:12:54.688: vmx| USB: Disconnecting device 0xfd8000004e868c3

vmware was disconnecting the phone right after connecting it. This is documented in vmware KB article 1025256 (Google "usb.quirks.device0"). Per vmware:

"These issues can occur because the USB devices do not implement the USB protocol as expected by Fusion."

(So, is this worth Samsung's time spinning up to give vmware a call and troubleshoot this? For me, yeah, but how many people are building Android apps for Samsung phones in vmware VMs on Macs?)

The First Fix

Per the KB article (and other posts about this issue) and after stopping the VM, I added the following lines to the beginning of the .vmx file in the Mac's virtual machine folder:

usb.quirks.device0 = "0x18d1:0x4e22 skip-reset"
usb.quirks.device1 = "0x04e8:0x68c3 skip-reset"

Mosts posts, and the article, only mention the first line. Here, the first line is for the Nexus S 4G, and the second is for the Droid Charge. The use of "device1" instead of "device0" is based on a careful review (read: WAG) of the rest of the vmx file. Since I don't have a Nexus S 4G on hand, I can't confirm that this works for it (but it did when I had the Nexus S 4G and the first line was the only line added.) I do know that the Droid Charge is now recognized, so I believe that if you have multiple Samsung phones with this problem, changing the number at the end of the key might let you apply this fix for each phone.

Remaining Issue

After making this change, HTC and Samsung phones were recognized by Ubuntu (as evidenced using 'lsusb').

However, 'adb devices' reported '???????????? no permissions'. This latter problem is apparently fairly common and some Googling and experimentation on this machine showed that what is going on here is that the serial device used by adb to access the phone (for example, /dev/ttyACM0 in my setup) is set with root ownership and no world permissions. If you dig around in the /dev/serial folder you will find an entry for your phone and can find out which /dev device is created for it. If you 'ls -al /dev/ttyACM0' (replace ttyACM0 with the name of your device) you can see the permissions, and you will see that no read or write permission is given for "world".

The Second Fix

Unlike the first problem, this problem has nothing to do with vmware, and the process for resolving this permission issue has been widely reported by others. The fix involves telling the device manager to change the permission to the Android device.

The first step is to use 'lsusb' to identify and write down the product ID and vendor ID of the phone. This is then provided to udev (Google "udev") in a rule that changes the permission of the /dev device so that adb can access it. This is described below.

A typical 'lsusb' response is

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 04e8:68c3 Samsung Electronics Co., Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The second line identifies the phone. The hex values 04e8:68c3 are the product ID and vendor ID of the phone, separated by a colon.

The next step of the solution as commonly reported is the creation of the udev rule. As root, you create a file named '51-android.rules' in /etc/udev/rules.d, and in it place this line:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="68c3", MODE="0666"

It should be apparent where the vendor and product IDs have been inserted.

On my machine, I wanted to change permissions for four devices: a Nexus S 4G (no longer in my possession), an HTC Hero, an HTC Evo 3D, and a Samsung Droid Charge:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e22", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0c9a", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0cba", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="68c3", MODE="0666"

After saving the file, udev must be restarted in order to read the rules: 'sudo restart udev'. When udev sees a match for a USB device with the given vendor and product IDs, it sets the device permission to 0666, or read/write for owner, group and world (world being us, since owner is root.)

Other Notes

It was observed that after making a change, or due to transient errors, it was sometimes necessary to do one or more of the following:

- run 'adb kill-server'
- unplug and replug the phone
- verify in VMware's Virtual Machine USB settings that the phone is attached to the virtual machine

I also observed that a phone attached during boot was not always recognized and had to be unplugged and replugged after boot to be recognized.


The debugging process was not as clean as shown and reflected a number of dead ends and hints provided by those who had previously posted their findings on the web. The links mentioned above point to a sampling of those posts.
Add a comment...