Category: Android

I’ve seen other attempts at universal ADB (Android Debug Bridge) drivers, but I’ve tested those and not had any luck. The following steps have worked for a wide variety of devices that I’ve tested it with. With such a huge variety of different Android devices available it isn’t always easy to find the right USB driver, but you need an ADB USB driver to connect development and debugging tools. This is different then being able to add and remove files from the Android device.

Disclaimer: I’ve done this a few times, and talked to others who have done it too, all without any incident. This is however a bit of a hack, and may result in some unintended consequence, which may including voiding your warranty, damaging your computer, damaging your android device, or even causing your hair to fall out. Proceed at your own risk.

First of all, you need the Android SDK installed. You don’t need the ADT Bundle or Android Studio if you don’t want those. Just scroll down to Use an Existing IDE. If you have RAD Studio XE5 (an edition with Mobile) installed then you had the option to install this during the RAD Studio install. I’ll include directions for either installation method. Google provides a USB driver for their Nexus line of devices. This is the driver we are going to use, but first we need to modify it to work with our device. I’m assuming you are running Windows. OS X doesn’t need device specific USB drivers.

These directions are for Windows 8.1. Run the Android SDK Manager. You can do this from the Android Tools start menu item that is installed with RAD Studio, or run the android.bat file located in the SDK\Tools folder of the Android SDK installation. This brings up the Android SDK Manager. Scroll to the bottom and look for Google USB Driver in the Extras category. If that is not installed then put a check mark next to it and install it. Next go to the folder where your Android SDK is installed. With RAD Studio XE5 the default install location is  under Users\Public\Documents:

C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522

From there go to the \sdk\extras\google\usb_driver folder, as that is where the Google USB Driver is installed. I typically make a copy of these folder somewhere else, as we will be modifying some of these files. If you get an updated driver, then your changes will be overwritten if you leave them here. Next we need to go to Device Manager with your new Android device attached (and in developer mode). Look for the entry for Android under Other devices. This is your Android device without a driver loaded. If you don’t see it then either it isn’t connected, or your Android device isn’t in developer mode. It is possible it may show up with the name of the Android device, but it should still be under “Other devices” and have the yellow triangle on it. Right click on this device and select properties. Then go to the Details tab and from the dropdown select the Hardware Ids property.

These are the identification for your specific Android device. It should look similar to the picture above.

Now using your favorite text editor open the android_winusb.inf file we found in the usb_driver folder above. Locate the line that says [Google.NTamd64]. You’ll see some entries above this line, these are for 32-bit installs (it is section [Google.NTx86]), and the entries after the line are for 64-bit installs. Chances are you only need to edit one section, since you are doing this for your own windows install, but you can edit both sections if you are not sure. The lines are the same.

So add lines similar to the following in the section(s) you choose.

;Samsung Galaxy S3 
%SingleAdbInterface% = USB_Install, USB\VID_04E8&PID_6860 
%CompositeAdbInterface% = USB_Install, USB\VID_04E8&PID_6860&MI_03

You probably noticed that is that crazy looking string on the right looks really similar to the values we saw for the Hardware Ids from device manager. The line prefixed by the semicolon is a comment, so I usually put the name of the device there.

Notice that the portion of the identifier with REV_#### is missing (I usually leave it off, but it should work either way). Also the %SingleAdbInterface% line doesn’t have the MI_## portion, while the %CompositeAdbInterface% line does include it. You might need to experiment with this to find what works (again remember the disclaimer).

If you want to load the driver for Google Glass, then it should look something like the following.

;Google Glass
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_9001&REV_0216&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_9001&MI_01

%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_9001&REV_0216&MI_00
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_9001&MI_00

(the first two lines are for the 2nd edition, the second two lines are for the 1st edition I believe).

Advanced: If you want to load the driver for the bootloader, then put your device into bootloader mode and add a %SingleBootLoaderInterface% line for the value that shows up in Device manager then (it will be different).

Now save the android_winsub.inf file. Unfortunately since it is modified, the signature is invalid and Windows won’t let you load it. With Windows XP this wasn’t such a big deal, but in recent versions the driver signature is enforced. There is a way around it though.

Check out the following guides for loading unsigned drivers in specific OS:

• Windows 7 or Vista
• Windows 8
• Windows 8.1

I’ve also made a video of the process on Windows 8.1

What to learn more about connecting to devices and gadgets? Join me for my free webinar on Programming Devices and Gadgets with RAD Studio on January 22nd.

Delphi automatically installs and runs your app for you, but sometimes it is nice to do manually from the command-line. Here are the commands you need. These all assume adb (Android Debug Bridge) is on your system path and you only have one Android device (or emulator) attached. They should work on both Mac and Windows.

See the end for notes on multiple devices or if you are running both an emulator and device.

First to install your app:

adb install path\ProjectName.apk

In this example path\ProjectName.apk is the full relative path to the apk. The apk usually has the same name as the project. If your apk is already installed, then use the following command to “reinstall” it, leaving the data intact:

adb install -r path\ProjectName.apk

The great thing about the -r is it works even if it wasn’t already installed.

Now if you want to uninstall your apk you can do that too:

adb shell pm uninstall -k com.embarcadero.ProjectName

Again, com.embarcadero.ProjectName is the default name of the package. If you changed it under Project Options -> Version Info -> Package, then use that value instead. BTW, the pm in there is the Android Package Manager.

One note, when Delphi deploys your app to run it, it performs an uninstall first. This results in all the data being cleaned out, which can be useful during development to be sure you don’t leave anything behind from the previous run. When a user updates an app from the App store, or installs it via most any other means, then it performs a reinstall, which leaves the data intact.

Now if you want to run it, things get a little more interesting. Now we use the Android Activity Manager (AM).

adb shell am start -n com.embarcadero.ProjectName/com.embarcadero.firemonkey.FMXNativeActivity

There are two parts to this. Before the slash is the package name, just like for uninstalling it. After the slash is the name of the Main Activity, which unless you’ve edited your AndroidManifest.template.xml (and some other fundamentals of your app) is always com.embarcadero.firemonkey.FMXNativeActivity. If you are trying to start an app written with another tool, then consult the AndroidManifest, but it is common for most tools to use MainActivity, so you can launch it like:

adb shell am start -n com.other.ProjectName/.MainActivity

If you want to stop your app after it is running, you just need the name of the package and the following:

adb shell am force-stop com.embarcadero.ProjectName

This can be useful to test what your app behaves like from a fresh restart, vs. just returning from the background.

The Android adb tool is very powerful. Most of these are using the shell command which actually allow you to pass commands to the modified Linux shell that runs inside Android. You can actually use “adb shell” to open a shell prompt and navigate your device like a remote machine.

If you have both an emulator running and a device attached then you can use the switch -d like

adb -d shell

and it directs it to the only device. If you use -e then it goes to the emulator.

When you have multiple devices then use -s and the device ID which can be obtained via the adb devices command.

There are so many other useful things you can do with adb. Check out the documentation.