MotivationForProject - maxieds/AndroidADBExtraUSBConfig GitHub Wiki
Now (nearly two years later) I finally found an application (see here for the NFC BuzzCard emulator stub listed as an intentionally private repo on BitBucket) that prompted me to actually need a necessarily functional working ADB configuration for this phone. As it turns out NFC device emulation via HCE is now almost standard in recent Android SDK revisions, and is not terribly difficult to get working correctly to communicate with the ubiquitous 13.xxx kHz range (non-HID) door readers implemented in most building interfaces in your local large semi-urban campus sprawl on the US Atlantic coast. This makes tinkering with the default-issue DESFire EV1 devices provided to you as a student as a part of registration on campus a particularly fun hobby -- if only my antique two-year-old Motorola phone could be used for development with the stock tools Android Studio has to offer (and there are many).
NOW THE MOTOROLA DROID TURBO 2 HAS A WORKING ADB DEVICE PROFILE WITH A PREDICTABLE -- WITH NO FEELING LUCK MAYBE DRIVER INSTALLS HERE -- INSTALLATION ON LINUX AND WINDOWS 10!
As a disclaimer, I do not use, or readily have access to a Mac OS X box for testing and development. My feeling is that the "real" Android developers will be using Linux or Windows anyways -- especially as a Mac (FreeBSD though it may have once been, and still possessing a working terminal) is really just a pretty GUI wrapper for "no I'm not really using Windows" (anymore) style developers who for one reason or another never learned how to use Linux proper anyways. The UDEV configurations in this repo should transfer however, but of course have not been tested or verified on the Mac platforms. :iphone: :negative_squared_cross_mark:
Plausible explanations for the apparent lack of default configurations for "deviant" phones
Note that the DROID TURBO 2 didn't work out-of-the-box on Ubuntu either however, even after installing other variants of the udev rule sets, so my mod is necessary to fix at least this stubborn class of Motorola devices. One possible explanation for why this device doesn't work like nearly every other Android phone is a USB3 bug where file explorer, etc. works on the same USB port, but ADB fails. The purported non-software work around is to chain the phone's USB connection in serial to a cheap self-powered USB hub that effectively masks this bug, but I had no such luck with this experimental fix and of course your mileage may vary. More likely, the cause is that the phone preempts the typical detection sequence by changing the id of it's ATTR{idProduct}=="2ea4" to ATTR{idProduct}=="2ea5" (or some other related ID) when it is connected through USB debugging for use with ADB. See the following image detailing the respective dmesg and lsusb changes pre/post enabling USB debugging on a device connected via USB in Linux:
Short rant on the out-of-the-box quality of Motorola series DROID* phones:
For the record, I also DO NOT like or appreciate the OEM / Motorola drivers and software currently available for download as support for the phone on Windows 10. For one, they do not provide an effective functional ADB configuration after the install. And secondly, Motorola just tacks on administrative overhead with their buggy profile and checks for "upgrades". To be honest, as relatively straightforward as it was for me to get the device configured correctly on modern Linux and Windows 10 instals within a few hours of actually trying (READ: modifying the search string in my Google queries from DROID TURBO 2 to generic UDEV settings) to find a reasonable hacking solution to the problem, I'm honestly taken aback and more recently annoyed at the fact that the manufacturer shipped this device without at least satisfactory OEM software to configure it :anguished:! In short, this page demonstrates how to fix broken ADB device setups misconfigured not through user error, but instead by the deviant nature of their device, and moreover, suggests to me that one ought reconsider the Samsung XXX or other top-of-generation series of phones when considering my next new Android device purchase. I have had better luck with these devices in the past.