Contents

1. Introduction
2. Background
3. Fixing
4. Reverting changes
5. Final Notes

[Introduction]I have seen a couple people with this problem. If one unplugs their headphones and re-inserts them afterwards, the audio is muted and cannot be unmuted. I went through this problem on this thread. This tutorial aims to solve this problem by installing an alternate version of PulseAudio with fixed jack detection.

[Background]
PulseAudio, or simply "Pulse", is the default sound server on Ubuntu. A sound server is a service that runs in the background and helps deliver and manipulate audio. The reason this problem occurs is because the headphones "mode" that Pulse has is broken. It won't unmute. So when you plug in your headphones, and Pulse switches to that mode, it won't produce audio. In the next section we'll get to (hopefully) the solution.

[Fixing]The easiest way to fix this is by installing the fixed PulseAudio sound server. First I'll give a short version for experienced users with a list of commands, then I'll give a step-by-step version for newer users with more details.

Short Version
Enter these commands in a terminal. Ensure you have no programs open to prevent data loss. Use the first command
Code: sudo add-apt-repository ppa:diwic/jack-detection
sudo apt-get update && sudo apt-get upgrade
sudo reboot
cp -r ~/.pulse/presets ~/Desktop
rmdir ~/.pulse
sudo reboot
cp -r ~/Desktop/presets ~/.pulse If this is hard to understand, give the long version a shot.

Long version

Step 1: Open a terminal
Open a terminal emulator with this key combo: CTRL+ALT+T. Alternatively, depending on your desktop environment, you can either click on the application menu, go to accessories and click on "Terminal", or press the "Super" (Windows key or Command) key and type "Terminal."

Step 2: Add PPA and install new Pulse
For this next step you must add a PPA, or Personal Package Archive. A PPA is a repository hosted on the Internet that contains packages. Type this command in the terminal to add this PPA:
Code: sudo add-apt-repository ppa:diwic/jack-detection Now we must update the package lists and "upgrade" to the new PulseAudio. As a side-effect it also upgrades any other packages that need it, so be aware!
Code: sudo apt-get update && sudo apt-get upgrade Now you must reboot. Make sure you aren't working on anything, as we'll be rebooting several times during this process.

Step 3: Reconfigure PulseAudio
You may notice that the audio isn't working. The reason for this is Pulse hasn't been configured to work with the new version you've just installed. To rectify this problem, enter these commands.

If you've installed pulseaudio-equalizer and have set custom presets, you should back them up if you want to keep them:
Code: cp -r ~/.pulse/presets ~/Desktop This copies the presets folder to your desktop for safe-keeping. Now we have to delete PulseAudio's configuration so it can generate a new one:
Code: rmdir ~/.pulse Now restart the computer. You can do this from the terminal with: sudo reboot
The audio should be working and hopefully the jack detection works. To get your presets back:
Code: cp -r ~/.pulse/presets ~/Desktop And you can do what you want with the copy on your desktop. I hope that this fixed your problem! If it didn't, we can undo the changes in the next section.

[Reverting Changes]You can undo the changes you made and be back to normal by entering these commands in the terminal, as always, make sure you're not working on anything:
Code: cp -r ~/.pulse/presets ~/Desktop
sudo apt-get install ppa-purge
sudo ppa-purge ppa:diwic/jack-detection
sudo reboot
rmdir ~/.pulse
sudo reboot
cp -r ~/Desktop/presets ~/.pulse [Final Notes]
So there's my guide! If it worked, I'm glad I could help. If it didn't, I hope the reversal guide did. Feel free to contribute to this tutorial. Leave suggestions, improvements, and ask for help if you need to. Thanks for reading!

This guide addresses how to install adb (Android Device Bridge) for Android Devices.

This guide is currently written using Ubuntu 11.10. It will be updated periodically for changes within the Android SDK and any changes the would accompany future Ubuntu releases.

This guide is directed for individuals interested in rooting their Android device or those interested in flashing custom ROMs, software development, or theme alterations or just about any other activity that would necessitate use of adb or fastboot for device modification.

1. Install the Android SDK and Download the Platform Tools Package from within the Android SDK Manager

Grab the Android SDK for linux: Google Android SDK

Place the file within your home directory.
Unpack the sdk within the your users home directory:
Code: cd ~
tar -zxvf android-sdk_r16-linux.tgz ***Android-sdk version number may vary depending on version of the SDK downloaded.


Within the ~/android-sdk-linux/tools subfolder is an executable called android. Despite the non-descript name, the executable android is actually the Android SDK Manager. Launch the Android SDK Manager.
Code: ./~/android-sdk-linux/tools/android Select Android SDK Tools and Android SDK Platform-tools.(Screen shot provided below). Any additional packages may be downloaded as well. Go grab a bite to eat!!

The platform tools package contains both the adb and fastboot executables. These programs will be located within the newly created directoy ~/android-sdk-linux/platform-tools

2. Modify your PATH environment variable to include the adb and fastboot executables.
The PATH environment variable may be either modified within ~/.profile (or ~/.bash_profile) or within ~/.bashrc. (The ~/.profile file is read upon login for all interactive shells, and the ~/.bashrc file is read upon all non-interactive shells (i.e sftp). In most cases and by default the ~/.profile file imports all settings from the ~/.bashrc file). The PATH statemnt must be altered to include the /android-sdk-linux/tools and /android-sdk-linux/platform-tools directories.

I modified my PATH statment within gedit by adding the following to the bottom of the ~/.bashrc file:
Code: export PATH=${PATH}:${HOME}/android-sdk-linux/tools:${HOME}/android-sdk-linux/platform-tools 3. Create udev rules for Ubuntu to correctly identify the device when it is plugged into the USB port

This is the most difficult part of the entire process.
First plug in the device to the usb port, then execute the following command:

Code: lsusb This should produce output similar to the following:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 063: ID 04e8:6860 Samsung Electronics Co., Ltd

In my working example, my device was correctly identified:
Bus 001 Device 063: ID 04e8:6860 Samsung Electronics Co., Ltd

The statement above can be deciphered:
Bus 001 Device 063: This information helps us determine the name of the device node. The device node's name is: /dev/bus/usb/001/063
04e8: The vendorID
6860: The productID

Using device node's name (/dev/bus/usb/001/063), its possible to query the device and discover its attributes. Discovery of these attributes is necessary since udev matches the device based on specific criteria. We need to right a ruleset that udev can use to match the device. The first step of this process is discovering criteria that can be plugged into our ruleset. This can be done in one of two ways, each are acceptable. The output of either of these methods generates the information for us to construct the udev rule for the device. The query program we are using for this method is known as udevadm

Query Method #1
Code: udevadm info -q all -n <name of device node> In my particular situation, the name of my device node is: /dev/bus/usb/001/063, so hence my command would be:
udevadm info -q all -n /dev/bus/usb/001/063

This gives output similar to the following:
$ udevadm info -q all -n /dev/bus/usb/001/063
P: /devices/pci0000:00/0000:00:1d.7/usb1/1-8
N: bus/usb/001/063
S: libmtp-1-8
S: GalaxyNexus
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-8
E: MAJOR=189
E: MINOR=62
E: DEVNAME=/dev/bus/usb/001/063
E: DEVTYPE=usb_device
E: DRIVER=usb
E: PRODUCT=4e8/6860/216
E: TYPE=0/0/0
E: BUSNUM=001
E: DEVNUM=063
E: SUBSYSTEM=usb
E: ID_MTP_DEVICE=1
E: ID_MEDIA_PLAYER=samsung_galaxy-s2
E: ID_VENDOR=samsung
E: ID_VENDOR_ENC=samsung
E: ID_VENDOR_ID=04e8
E: ID_MODEL=Galaxy
E: ID_MODEL_ENC=Galaxy
E: ID_MODEL_ID=6860
E: ID_REVISION=0216
E: ID_SERIAL=samsung_Galaxy_0146B06501005018
E: ID_SERIAL_SHORT=0146B06501005018
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ffff00:ff4201:
E: DEVLINKS=/dev/libmtp-1-8 /dev/GalaxyNexus
E: TAGS=:udev-acl:

Criteria that we will be using for matching are those lines starting with E: - E=ENV=Device Property value


Query Method #2

Code: udevadm info -a -p $(udevadm info -q path -n <name of device node>) In my particular situation, the name of my device node is: /dev/bus/usb/001/063, so hence my command would be:
udevadm info -a -p $(udevadm info -q path -n /dev/bus/usb/001/063)

This command gives output similar to:

$ udevadm info -a -p $(udevadm info -q path -n /dev/bus/usb/001/063)

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:1d.7/usb1/1-8':
KERNEL=="1-8"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{configuration}==""
ATTR{bNumInterfaces}==" 2"
ATTR{bConfigurationValue}=="1"
ATTR{bmAttributes}=="80"
ATTR{bMaxPower}=="500mA"
ATTR{urbnum}=="29"
ATTR{idVendor}=="04e8"
ATTR{idProduct}=="6860"
ATTR{bcdDevice}=="0216"
ATTR{bDeviceClass}=="00"
ATTR{bDeviceSubClass}=="00"
ATTR{bDeviceProtocol}=="00"
ATTR{bNumConfigurations}=="1"
ATTR{bMaxPacketSize0}=="64"
ATTR{speed}=="480"
ATTR{busnum}=="1"
ATTR{devnum}=="63"
ATTR{devpath}=="8"
ATTR{version}==" 2.00"
ATTR{maxchild}=="0"
ATTR{quirks}=="0x0"
ATTR{avoid_reset_quirk}=="0"
ATTR{authorized}=="1"
ATTR{manufacturer}=="samsung"
ATTR{product}=="Galaxy"
ATTR{serial}=="0146B06501005018"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="1403"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0300"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="1"
ATTRS{devnum}=="1"
ATTRS{devpath}=="0"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="8"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 3.0.0-14-generic ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:00:1d.7"
ATTRS{authorized_default}=="1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7':
KERNELS=="0000:00:1d.7"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x27cc"
ATTRS{subsystem_vendor}=="0x103c"
ATTRS{subsystem_device}=="0x3010"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="20"
ATTRS{local_cpus}=="ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
ATTRS{companion}==""

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

Criteria that we will be using for matching are those lines starting with ATTRS -- ATTRS-Device Attributes

Using either ENV or ATTRS, we can construct a ruleset for udev. Full information how to construct rules can be found here, I'll provide examples on how to use the criteria to construct the ruleset.

By arbitrary convention, the ruleset file will be called 51-android.rules.
Code: gksu gedit /etc/udev/rules.d/51-android.rules The following are examples of rulesets that can be placed within the file (only one(1) ruleset is needed - Each should be only 1 line):
SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="04e8", ENV{ID_MODEL}=="Galaxy", MODE="0666", SYMLINK+="GalaxyNexus"

SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="04e8", ENV{ID_MODEL_ID}=="6860", MODE="0666", SYMLINK+="GalaxyNexus"

SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", ATTR{product}=="Galaxy" MODE="0666", SYMLINK+="GalaxyNexus"

As written above, these rules which listed matching criteria (SUBSYSTEM, ENV,ATTR) will only modify the mode of the device (0666=rw-rw-rw-) and create the symbolic GalaxyNexus link at /dev/GalaxyNexus. Additional actions however can be assigned to the device, such as activities to perform when the device is plugged in, or removed. These activites could be specified as follows:
ACTION=="add", RUN+="<name of action>"
ACTION==”remove”, RUN+="<name of action>"

**IMPORTANT**

• Each ACTION statement must be listed on its own line.
• The path to the program must be the full qualified path.
• There may also be multiple action lines or multiple add/remove statements

.

Example:
ACTION=="add", RUN+="/usr/local/bin/NexusMount.sh"
ACTION==”remove”, RUN+="/usr/local/bin/NexusUnmount.sh"

It would be possible for example to play a sound or .mp3 file when the device is inserted or ejected (similar to windows).

Once done constructing the rule, save the /etc/udev/rules.d/51-android.rules file.

Testing the ruleset
Its often a good idea to test the ruleset before executing it. Its very easy to make errors writing the ruleset so I would encourage this simple process to verify the ruleset is correct. This can be done using the udevadm tool.

Code: udevadm test --action=<"Copy entire ruleset here"> <path to device node> The ruleset is the contents of the entire 51-android.rules file.
The path to the device node can be discovered using:
udevadm info -q path -n d=<device name>
In the example above the name of my device was: /dev/bus/usb/001/063 (Which was discovered using the lsusb statement).

Putting this altogether as an example:
udevadm test --action="SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="04e8", ENV{ID_MODEL}=="Galaxy" MODE="0666", SYMLINK+="GalaxyNexus"" $(udevadm info -q path -n /dev/bus/usb/001/063)

Although the output is rather long, two lines in the output correctly identify the ruleset actions are to be applied correctly:
udev_rules_apply_to_event: MODE 0666 /etc/udev/rules.d/51-android.rules:1
udev_rules_apply_to_event: LINK 'GalaxyNexus' /etc/udev/rules.d/51-android.rules:1

Once verifying the ruleset is correct, restart the udev service:
Code: sudo service udev restart 4. Log out and then log back into computer.
With the device plugged in, adb should work similar to the following:
$ adb devices
List of devices attached
0146B06501005018 device

fastboot can also be ran, however this is only valid if the device has booted into fastboot mode:
$ fastboot devices
???????????? fastboot

***References
Attached Images AndroidSDKManager.png (86.6 KB)