tag:blogger.com,1999:blog-85761543503675544412024-03-13T09:33:50.453-05:00Public scratchpadUnknownnoreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8576154350367554441.post-35151099076991020002014-11-13T00:03:00.003-06:002014-11-15T20:38:26.180-06:00How to make the truly universal adb and fastboot drivers for WindowsThere are many internet sites out there offering so-called universal adb driver packs for Windows. Usually it's a repacked <a href="https://dl-ssl.google.com/android/repository/latest_usb_driver_windows.zip">Google USB Driver</a> package for Nexus devices with its <span class="mono">android_winusb.inf</span> file updated to include various <span class="mono">USB VendorID</span> and <span class="mono">ProductID</span> combinations. Why it is not truly universal? Because if your device's combination is not included - it obviously will not be supported by such driver package.<br /><br />
Yet Microsoft has made it quite easy to make a truly universal driver. When looking for a proper driver for the new device Windows can match not only by the <a href="http://msdn.microsoft.com/en-us/library/windows/hardware/ff546152(v=vs.85).aspx"><span class="mono">HardwareID</span></a> (i.e. combination of <span class="mono">USB VendorID</span>, <span class="mono">ProductID</span> and optionally <span class="mono">InterfaceNumber</span>) but also by <a href="http://msdn.microsoft.com/en-us/library/windows/hardware/ff539950(v=vs.85).aspx"><span class="mono">CompatibleID</span></a> (i.e. combination of <span class="mono">InterfaceClassID</span>, <span class="mono">InterfaceSubClassID</span> and <span class="mono">InterfaceProtocolID</span>) which is fortunately the same for all android <span class="mono">adb</span> and <span class="mono">fastboot</span> interfaces for both simple and composite USB devices.<br /><br />
A few years ago I have made such driver and I have been successfully using it with many different Android devices before I completely switched to linux environment for all my development. Here's how you can make one for yourself:<br /><br />
<ul>
<li>Download the latest Google USB driver package from the link above</li>
<li>Unzip the <span class="mono">usb_driver</span> folder</li>
<li>Open the <span class="mono">usb_driver\android_winusb.inf</span> file in a text editor (the Notepad will work)</li>
<li>Replace the <span class="mono">[Google.NTx86]</span> and <span class="mono">[Google.NTamd64]</span> sections with the lines below:</li>
<br /><div class="code"><b>
[Google.NTx86]<br />
%SingleAdbInterface% = USB_Install, USB\Class_ff&SubClass_42&Prot_01<br />
%SingleBootLoaderInterface% = USB_Install, USB\Class_ff&SubClass_42&Prot_03<br />
<br />
[Google.NTamd64]<br />
%SingleAdbInterface% = USB_Install, USB\Class_ff&SubClass_42&Prot_01<br />
%SingleBootLoaderInterface% = USB_Install, USB\Class_ff&SubClass_42&Prot_03<br />
</b></div><br />
<li>Save the file and you got yourself a truly universal adb driver!</li>
</ul>
<br /><br />
Do not forget to update <a href="/2014/11/adb-device-detection-in-windows.html"><span class="mono">%USERPROFILE%\.android\adb_usb.ini</span></a> if needed.
<br /><br />
After installing properly modified driver the following command should say <span class="mono"><b>WinUSB</b></span> in the <span class="mono"><b>Service</b></span> line:
<br /><br />
<div class="code"><b>
powershell "gwmi Win32_USBControllerDevice | %{[wmi]($_.Dependent)} | <br />
?{$_.CompatibleID -like \"USB\Class_ff^&SubClass_42^&Prot_0?\"} | fl Name,DeviceID,Service" <br />
</b></div><br /><br />
And here is the whole inf file already modified:
<br /><br />
<div><script src="http://gist.github.com/ktnr74/1daad6a22ad38ee4d983.js?file=android_winusb.inf"></script></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8576154350367554441.post-49413213941944294002014-11-05T16:28:00.001-06:002016-08-06T13:02:17.309-05:00ADB device detection in WindowsIn my previous <a href="/2014/09/the-most-comprehensive-write-up-on-how.html">post</a> I mentioned the command I use to automatically populate the <span class="mono">~/.android/adb_usb.ini</span> file with USB Vendor IDs for all connected ADB devices:
<br /><br /><div class="code"><b>
~$ find -L /sys/bus/usb/devices -maxdepth 2 -path "*/modalias" -printf "%h\t" -exec cat {} \; | \<br />
awk -F: '/icFFisc42ip0/ {print $1}' | xargs -i cat {}/idVendor | awk '{print"0x"$1}' | sort -u >> ~/.android/adb_usb.ini
</b><br /></div><br /><br />
But many people also have found this command to be extremely useful for ADB connection trouble-shooting. The command is obviously linux only. And some of my colleagues who still use Windows asked me if I happened to know a similar command for Windows. I gave it some thought and decided to use <span class="mono">powershell</span> for the task and here is what I have come up with:
<br /><br /><div class="code"><b>
powershell "gwmi Win32_USBControllerDevice | %{[wmi]($_.Dependent)} | <br />
?{$_.CompatibleID -like \"USB\Class_ff^&SubClass_42^&Prot_0?\"} | <br />
%{write \"0x$([regex]::match($_.deviceid.tolower(), 'vid_(\w+)').groups[1].value)\"} | <br />
sort -u" >> %USERPROFILE%\.android\adb_usb.ini
</b><br /></div><br /><br />
That was a single line I had to split for better readability.<br /><br />
Also if <span class="mono">ANDROID_SDK_HOME</span> is set, <span class="mono">adb</span> will use <span class="mono">%ANDROID_SDK_HOME%\.android\adb_usb.ini</span> instead.<br /><br />
And the best part of it is that to work (i.e. properly detect ADB devices) it does not need any drivers. You will need to install drivers to be able to use <span class="mono">adb</span> but not for the detection!
<br /><br /><h3 id="Troubleshooting">Here is how to use this command for troubleshooting:</h3>
Disconnect all other adb devices you might have other than the one you want to troubleshoot. First thing you want to make sure that adb is properly configured on the device side (i.e. "USB debugging" is enabled, etc). Some manufacturers do not test their devices thoroughly which sometimes results in situations when adb works only when combined with other specific interface. I have seen a device which would only enumerate adb interface when in MTP mode but not in PTP or Mass Storage modes. So check different combinations and run the following command after every change:
<br /><br /><div class="code"><b>
powershell "gwmi Win32_USBControllerDevice | %{[wmi]($_.Dependent)} | <br />
?{$_.CompatibleID -like \"USB\Class_ff^&SubClass_42^&Prot_0?\"} | fl Name,DeviceID,Service"
</b><br /></div><br /><br />
Again that was a single line. The point I am trying to make is that you can not do anything on your PC side to make adb work until this command shows some output. If it shows nothing - the problem is not with your PC software configuration. It is with either your device software configuration or hardware (including PC, android device and everything in between - like USB cables, hubs, etc)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8576154350367554441.post-79508520949824738522014-09-23T21:29:00.000-05:002014-10-17T15:55:29.057-05:00The most comprehensive write up on how to make adb work in a debian based linux environmentIt is very surprising to me to see how many people are still to this day (almost 7 years since the first public release of Android) confused about proper way of making <span class="mono">adb</span> command work in linux environment.
<br /><br />
The most common misconceptions about running <span class="mono">adb</span> in linux are:
<h3>1. You have to install some kind of "adb" driver</h3>
<h3>2. You have to install full Android SDK</h3>
<h3>3. You have to run adb as root</h3>
none of which are true!
<br /><br />
Here are some actual issues to take care of:
<br /><br />
<h3>1. Where to get the <span class="mono">adb</span> binary from?</h3>
While there are plenty of third party packages available personally I prefer to use the binary which comes directly from Google themselves - the one included with the official Android SDK. But what if we need just the <span class="mono">adb</span> binary alone and do not want to install the whole SDK? The first of the following commands downloads and parses the source code of the latest SDK Manager to find the link for the latest version of <span class="mono">platform-tools</span> package containing the <span class="mono">adb</span> binary. The second command downloads <span class="mono">platform-tools</span> package and extracts the binary into the current directory. The third one obviously makes the binary executable:<br /><br /><div class="code"><b>
~$ eval $(wget -qO - "https://android.googlesource.com/platform/tools/base/+/master/sdklib/src/main/"\<br />
"java/com/android/sdklib/repository/SdkRepoConstants.java?format=text" | base64 -d | tr '\n;' ' \n' | \<br />
sed -e "s/\(NS_LATEST_VERSION\|URL_GOOGLE_SDK_SITE\|URL_FILENAME_PATTERN\)/\n\1/g" \<br />
-e "s/%1\$d/\$NS_LATEST_VERSION/" | tr -d ' ' | grep "^[A-Z_]*=" | sort)<br /><br />
~$ wget -qO - "$URL_GOOGLE_SDK_SITE$(wget -qO - "$URL_GOOGLE_SDK_SITE$URL_FILENAME_PATTERN?format=text" | xml2 | \<br />
grep "/sdk:platform-tool/" | grep "\-linux\.zip$" | tail -n 1 | cut -d= -f2)" | funzip 2> /dev/null 1> ./adb<br /><br />~$ chmod 755 ./adb</b><br /></div><br /><br />
<h3>2. I downloaded the binary but it does not run! Why?</h3>
The Google <span class="mono">adb</span> binary has some dependencies. It requires the following libraries to be installed: <span class="mono">libncurses5 libstdc++6</span>. Also the Google <span class="mono">adb</span> binary is 32bit and if your linux system is 64bit you need to make sure that 32bit versions of those libraries are also installed. In most debian based systems you can solve those dependencies by running the following commands:
<br /><br /><div class="code">
<b>~$ sudo dpkg --add-architecture i386 2>/dev/null</b><br />
<b>~$ sudo apt-get -qqy update</b><br />
<b>~$ sudo apt-get -qqy install libncurses5:i386 libstdc++6:i386 zlib1g:i386</b><br />
</div><br /><br />After that running <span class="mono">./adb devices</span> command should produce at least these lines:
<br /><br /><div class="code">
<b>~$ ./adb devices</b><br />
* daemon not running. starting it now on port 5037 *<br />
* daemon started successfully *<br />
List of devices attached<br />
</div><br />
<br /><br />
<h3>3. Running <span class="mono">./adb devices</span> returns an empty list!</h3>
In linux no special driver is required for user space programs to access USB devices privided they have permissions and are willing to handle the exchange protocol by themselves. The <span class="mono">adb</span> binary uses low level <span class="mono">libusb</span> library to access the device. So how does it know to which out of all connected <span class="mono">USB</span> devices it needs to talk to? It is looking for devices with a specific interface. Let's examine the <span class="mono">lsusb -v</span> command's output on a system which has an android device with enabled "USB debugging" connected to it:
<br /><br /><div class="code">
<b>~$ lsusb -v | grep -B 3 -i iInterface</b><br />
    bInterfaceClass     255 Vendor Specific Class<br />
    bInterfaceSubClass   66<br />
    bInterfaceProtocol    1<br />
    iInterface            4 ADB Interface<br />
</div><br /><br />You can check any Android device from any manufacturer - its adb interface will always have<br /><br />
<span class="mono">  bInterfaceClass=255</span><br />
<span class="mono">  bInterfaceSubClass=66</span><br />
<span class="mono">  bInterfaceProtocol=1</span><br /><br />
Because this is exactly what <span class="mono">adb</span> tool is looking for! But in some misguided optimization effort Google decided to filter out devices with "unknown" USB Vendor IDs first. You can see the latest list of the "Google approved" Vendor IDs by running the following command:
<br /><br /><div class="code"><b>~$ wget -qO - "https://android.googlesource.com/platform/system/core/+/master/adb/usb_vendors.c?format=text" | \<br /> base64 -d | grep "define VENDOR_ID"</b>
</div><br /><br />
What to do if your device's manufacturer did not make the list? If you already know its USB Vendor ID you can add it in <span class="mono">0xffff</span> hexadecimal format (one ID per line if you have multiple IDs) to the <span class="mono">~/.android/adb_usb.ini</span> file. Make sure to run <span class="mono">./adb kill-server</span> command afterwards. Because while being just a single file the <span class="mono">adb</span> tool actually consists of 2 distinct parts - <span class="mono">adb daemon</span> and <span class="mono">adb client</span>. When you ran very first <span class="mono">adb</span> command like <span class="mono">./adb devices</span> - it left the daemon part still running. And since the configuration file is only being read by the daemon part when it is starting up - the only way to make it read the changes we just made to the ini file is to kill the daemon and restart again.
<br /><br /><br />
<h3>4. I don't know my device's Vendor ID or I added it to the <span class="mono">adb_usb.ini</span> but <span class="mono">./adb devices</span> still shows nothing!</h3>
There is a way to check if any adb devices are connected to the system. And by "adb devices" I mean Android devices with adb interface enumerated (i.e. with "USB debugging" option enabled on the device). The following command does not depend on the local adb configuration. In fact I should have probably started with it before downloading any files or installing any packages:
<br /><br /><div class="code">
<b>~$ find -L /sys/bus/usb/devices -maxdepth 2 -path "*/modalias" -printf "%h\t" -exec cat {} \; | \<br />awk -F: '/icFFisc42ip0/ {print $1}' | xargs -i cat {}/idVendor | awk '{print"0x"$1}'
</b><br />
</div><br /><br />This command should produce exactly one line with Vendor ID per connected adb device. If you do not see any output - you need to start looking at other possible reasons for the adb interface enumeration failure like always popular:<br /><br />
    "USB debugging" is not enabled on the device<br />
    Defective/disconnected USB cable<br />
    Defective USB hub (if used) or USB port in your system<br /><br />
Let's rule out the hardware issues first. Unplug your Android device and run the following command:
<br /><br /><div class="code">
<b>~$ bash -c 'LSUSB=$(lsusb|sort); read; diff -a <(lsusb|sort) <(echo "$LSUSB")' | grep "^<" | awk '{print $7}' | \<br />
xargs -i lsusb -v -d {} | grep -B 3 iInterface</b>
</div><br /><br />
It is not supposed to produce any output or even return back to the command prompt just yet. Plug your Android device back in, wait for like 5 seconds and press [enter] key on the keyboard. Now you should get your command prompt back. But most importantly you should expect to see some lines printed out. If you did not get any output - that means that your android device does not enumerate any interfaces at all. Which is very unlikely and suggests a hardware problem. But if you got some interfaces listed just not the adb interface - this means that the hardware (USB cable/hub/port) is working fine but you have "USB debugging" switched off on the device.<br /><br /><br /><center><h1>SO STOP WASTING TIME AND TURN "USB debugging" ON!!!</h1></center><br />
In case of hardware problems replace the USB cable, connect your device directly to the USB port on the PC if you used a USB hub before, try connecting to a different USB port and try again...<br /><br />
So you fixed all problems and the <span class="mono">find -L /sys/bus/usb/devices ...</span> command finally started printing some numbers. As I mentioned before those numbers are USB Vendor IDs for all currently connected adb devices. If you had not added them yet to your <span class="mono">adb_usb.ini</span> file do it now:
<br /><br /><div class="code">
<b>~$ find -L /sys/bus/usb/devices -maxdepth 2 -path "*/modalias" -printf "%h\t" -exec cat {} \; | \<br />awk -F: '/icFFisc42ip0/ {print $1}' | xargs -i cat {}/idVendor | awk '{print"0x"$1}' | sort -u >> ~/.android/adb_usb.ini<br />
~$ ./adb kill-server
</b><br />
</div><br /><br />
<h3>5. <span class="mono">./adb devices</span> command shows ???????????? no permissions!</h3>
This is the best news you got all day! Congratulations! This means that <span class="mono">adb</span> tool can finally see and recognize your device. It just does not have permissions to access it. Let's give it the permissions:
<br /><br /><div class="code">
<b>~$ echo 'ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:ff420?:*", MODE="0666", '\<br />
'GROUP="plugdev", SYMLINK+="android/$env{ID_SERIAL_SHORT}"' | sudo tee /etc/udev/rules.d/90-universal-android.rules<br />
~$ sudo udevadm control --reload-rules<br />
~$ sudo udevadm trigger --action=add --subsystem-match=usb<br />
~$ sudo killall -9 adb
</b><br />
</div><br /><br />
<h3>6. Finally <span class="mono">./adb devices</span> command shows my device and all other <span class="mono">adb</span> commands also work properly! Thank You!!!</h3>
<br /><br />You are welcome. You can move the <span class="mono">adb</span> binary to a directory in your <span class="mono">$PATH</span> now.<br /><br />
Also for your convenience I put all the above commands into a single shell file:
<br /><br />
<div><script src="http://gist.github.com/ktnr74/911c2e122832919c4a86.js?file=install_adb.sh"></script></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8576154350367554441.post-69663895710787071282014-09-22T22:27:00.001-05:002023-02-12T11:04:58.163-06:00Calling Android services from ADB shellMany android automation recipes contain references to the "service call" command:
<br />
<br />
<div class="code">
# service<br />
Usage: service [-h|-?]<br />
    service list<br />
    service check SERVICE<br />
    service call SERVICE CODE [i32 INT | s16 STR] ...<br />
Options:<br />
  i32: Write the integer INT into the send parcel.<br />
  s16: Write the UTF-16 string STR into the send parcel.<br />
</div>
<br />
<br />
The command is indeed very useful. But the problem is that the calling "CODES" are android version specific and recipes often get out dated sometimes even after a minor version update. I am frequently being asked to update those codes for my recipes. I decided to share a small bash script I have been using to look up service codes for specific Android versions:
<br />
<br />
<div><script src="https://gist.github.com/ktnr74/ac6b34f11d1e781db089.js"></script></div>
<br />
This script checks the Android version of your phone and the java package name of the service you specified as a parameter. Then the script downloads the service <a href="http://developer.android.com/guide/components/aidl.html">AIDL</a> file for your phone's Android version from <a href="https://android.googlesource.com">https://android.googlesource.com</a> and parses it. So obviously it only works for the standard Android services it can find the source code for.
<br />
<br />
This is how I usually run the script. For example let's find out the calling code for "getCallState()" method of the "phone" service. I usually have multiple phones connected to my system so I need to specify which one to use by setting the ANDROID_SERIAL variable first. If you have just a single phone connected you can skip that part:
<br />
<br />
<div class="code">
~$ ANDROID_SERIAL=XXXXXXXXXX ./get_android_service_call_numbers.sh phone | grep getCallState<br />
ANDROID_SERIAL=XXXXXXXXXX<br />
ro.build.version.release=4.4.4<br />
TAG=android-4.4.4_r1<br />
SERVICE=phone<br />
SERVICE_PACKAGE=com.android.internal.telephony.ITelephony<br />
    32 int getCallState()<br />
<br /><br />
</div><br /><br />
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8576154350367554441.post-70396699296487876362013-07-10T23:05:00.000-05:002013-11-01T11:46:36.312-05:00Installing Android platform tools (ADB) on Ubuntu and Debian systems<div>
Here is a short script I use to install the latest version of Android platform tools on those of my systems I do not need full blown Android SDK on:<br />
<br />
<br /></div>
<div>
<script src="http://gist.github.com/ktnr74/6023471.js?file=install_adb_platform_tools.sh"></script></div>
<div>
<br />
<br />
The script requires root permissions to install prerequisite packages. It downloads and unpacks <b>adb</b> and <b>fastboot</b> binaries into <b>$ANDROID_SDK_HOME/platform-tools/</b> folder (or into <b>~/android/platform-tools/</b> if <b>$ANDROID_SDK_HOME</b> is not defined). The folder will be added to the current <b>$PATH</b>. And finally the script will create a universal <b>udev</b> rule to take care of device permissions for all Android devices regardless of their VendorID.
<br />
<br />
The script has been tested on 32 and 64-bit versions of Ubuntu 12.04, 12.10, 13.04, 13.10 and Debian 7.0, 7.1, 7.2.
<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8576154350367554441.post-28542790062116916552013-06-23T11:54:00.000-05:002014-11-08T10:11:55.586-06:00Emulating touchscreen interaction with sendevent in AndroidI know this has been explained many times before. But I keep getting asked about it over and over again. So I decided to summarize it in one place I could refer to in the future.<br />
<br />
<br />
Android uses Linux kernel so it processes input events the same way as any other linux system. In case of touchscreen displays it uses the same <a href="https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt">multi-touch protocol</a>. There are 2 different versions of the protocol - <b>Type A</b> and <b>Type B</b>. Usually it does not matter which protocol to use for injecting events since the kernel driver supports both protocols at the same time. In my automation scripts I use <b>Type A</b> just because I tried it first and it worked right away and I did not have to try <b>Type B</b>.<br />
<br />
Android provides these two convenient tools for dealing with input events:<br />
<br />
<ul>
<li><a href="http://source.android.com/tech/input/getevent.html">getevent</a> - for dumping input events and providing information about input devices</li>
<li>sendevent - for injecting input events</li>
</ul>
<br />
Every sendevent command requires 4 parameters:<br />
<ul>
<li>device_name (string)</li>
<li>event_type (decimal int)</li>
<li>event_code (decimal int)</li>
<li>value (decimal int)</li>
</ul>
<br />
First you need to find the name of touchscreen device. The following command requires busybox to be installed:<br />
<br />
<div class="code">
getevent -pl | busybox sed -e ':a;N;$!ba;s/\n / /g' | busybox awk '/ABS_MT_TOUCH/{print $4}'
</div>
<br />
<br />
<br />
Let's assume it printed out "/dev/input/event0" - this would be the first parameter.<br />
<br />
For touch events only 2 event types are used:<br />
<ul>
<li>EV_ABS (3)</li>
<li>EV_SYN (0)</li>
</ul>
<br />
Touching the display (in case of <b>Type A</b> protocol<b>) </b>will result in an input report (sequence of input events) containing the following event codes:<br />
<ul>
<li>ABS_MT_TRACKING_ID (57) - ID of the touch (important for multi-touch reports)</li>
<li>ABS_MT_POSITION_X (53) - x coordinate of the touch</li>
<li>ABS_MT_POSITION_Y (54) - y coordinate of the touch</li>
<li>ABS_MT_TOUCH_MAJOR (48) - basically width of your finger tip in pixels</li>
<li>ABS_MT_PRESSURE (58) - pressure of the touch</li>
<li>SYN_MT_REPORT (2) - end of separate touch data</li>
<li>SYN_REPORT (0) - end of report</li>
</ul>
<br />
Let's say we want to emulate a touch down event at the point with coordinates x=300, y=400. We will need to execute the following sendevent commands:<br />
<br />
<div class="code">
sendevent /dev/input/event0 3 57 0<br />
sendevent /dev/input/event0 3 53 300<br />
sendevent /dev/input/event0 3 54 400<br />
sendevent /dev/input/event0 3 48 5<br />
sendevent /dev/input/event0 3 58 50<br />
sendevent /dev/input/event0 0 2 0<br />
sendevent /dev/input/event0 0 0 0</div>
<br />
I used arbitrary values of 5 for the ABS_MT_TOUCH_MAJOR (makes for very small finger tip for high precision) and 50 for the ABS_MT_PRESSURE (a slight tap) which work good enough for most applications.<br />
<br />
For most touch screens on the market it takes 20 to 50 milliseconds to reliably register the touch. So I would recommend to wait at least 50 milliseconds before sending the release event<span style="font-family: Consolas;"><b> </b></span>report<span style="font-family: Consolas;"><b>. </b></span>If you want to emulate the long touch - then you wait longer. You can use busybox usleep command:<br />
<br />
<div class="code">
busybox usleep 50000
</div>
<br />
<br />
<br />
The release report is really simple. To let the input device know that all previous touches have been released - you just send the empty report with ABS_MT_TRACKING_ID = -1:<br />
<br />
<ul>
<li>ABS_MT_TRACKING_ID (57)</li>
<li>SYN_MT_REPORT (2)</li>
<li>SYN_REPORT (0)</li>
</ul>
<br />
<div class="code">
sendevent /dev/input/event0 3 57 -1<br />
sendevent /dev/input/event0 0 2 0<br />
sendevent /dev/input/event0 0 0 0
</div>
<br />
<br />
<br />
This is how injecting touch events could be implemented in python:
<br />
<br />
<br />
<script src="https://gist.github.com/ktnr74/6635186.js"></script>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8576154350367554441.post-30430678895755654332013-04-27T22:07:00.001-05:002013-09-09T09:33:58.691-05:00Universal udev rule for all Android devicesWhen an Android device is plugged in to a linux system, by default only root has access to the device. In order for regular users to be able to access the device - the device permissions need to be changed. To automate this, Google <a href="http://developer.android.com/tools/device.html" target="_blank">recommends</a> adding Vendor ID of every Android device as a separate line per ID.<br />
I thought that there has to be a better way to do it. Here is the rule I came up with:<br />
<br />
<div style="background-color: #cccccc; color: black; font-family: Consolas; font-size: 13px; line-height: 200%; padding: 15px; vertical-align: baseline; white-space: nowrap;">
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:ff420?:*", MODE="0666"
</div>
<br />
<br />
This rule matches all adb and fastboot interfaces<span style="font-size: small;"> for any android device, no matter the Vendor ID.<br />
<br />
</span>Unknownnoreply@blogger.com0