IzzyOnDroid

• Intro
• App-Lists
• Articles
• Books
• Downloads
• App-Repo
• Imprint

Privacy Links

↓ Your product here? ↓

Das Inoffizielle Android-Handbuch Android kennenlernen, Tipps & Tricks Buy at Amazon for EUR 16,99

Das Inoffizielle Android Systemhandbuch Tiefer ins System einsteigen Buy at Amazon for EUR 7,00

Die besten Android-Apps Den Androiden austatten Buy at Amazon for EUR 5,00

 

ADB for end-users

Toyota Robot; © Chris 73 (GNU)
Source: Wikimedia

Most of you probably already heard of the Android SDK, a toolkit mostly for Android software development¹. One of its components is ADB, the Android Debug Bridge, used to interact between the (development) computer and the Android device. A pretty mighty tool you can do many interesting things with – but again, it’s only one of the components within the SDK.

Also, most of you might have seen tutorials pointing out steps involving ADB – be it for a simple logcat, shell access, side-loading of apps, or any other instruction. Some of you might simply have skipped then, looking for an alternative solution: Why downloading a full 90+ MB (which installed take up much more space) with a full development toolkit, when you just want a little piece of it? After all, you neither buy a cow if all you want is a steak. So is that really necessary? Luckily, not at all – as I’ve already shown in my original post on this topic about a year ago. Which is what I will pick up here, and enrich it with some usage examples picked from one of my books².

Is there a minimal installation of ADB?

In fact, it is not necessary to install the entire SDK if one does not want to use it for development. To be able to run basic ADB commands in the context needed by an average user, a rudimentary installation is completely sufficient. I will try to explain how to do this, and hopefully cover the most used computer systems.

Requirements

First, you will need the basic binaries. These can be found e.g. in the download section here on the site – simply click the Downloads tab to the left, and pick the bundle for your OS. There are adb-binaries-* for Linux, Mac, and Windows. Admitted, they might not match the “always latest version” – but they’ll fully meet our daily needs as end users. If you insist on a more up-to-date version, you might find appropriate download links to the SDK Tools at Blogspot; compare with the downloads from here to get an idea which of the files to extract from there.³

Windows users

If your computer is running Windows, you will also need the special drivers for your device: no real generic solution here, so you need to check this out yourself; usually, those drivers are offered for download on the manufacturer’s website. Of course you can try Koushs Universal Driver, which works for many devices, if you cannot find specific drivers there.

Linux and Mac OS users

Linux and Mac OS users might need to make their device known to their operating system. For Linux, you find the necessary steps described in my answer here. Not being familiar with Mac OS, I can not speak for it.

Installation

Linux

For Linux, this is quite easy: Simply unpack the downloaded binaries into a directory of your choice. At the time I’m writing this, this will only be two files: adb and aapt (the latter being used by tools like QtADB⁴, and not necessarily needed to execute ADB commands directly). Adjust their file permissions to make them executable (e.g. from the command line: chmod 0755 adb aapt). Finally, it’s a good idea to include the chosen directory with your $PATH variable, so you can call adb from wherever you are. A good place for that is at the end of your ~/.profile file to include an additional line like export PATH="~/bin:$PATH" (if you extracted the binaries to ~/bin).

Windows

The Windows download holds a couple more files. Also extract them into a directory of your choice. If you want them to be callable from wherever you are, without preceding the complete path, you need to add that path to your environment variables as well. Not being a Windows user, I must leave the “how to do this” to you.

MacOS

Should be pretty close to the Linux description. I can give no exact details here either, not owning a Mac device.

Usage and use cases

So what are some practical use cases for the end user? I already indicated some in the introduction to this article, so let‘s start with those. But first make sure your device is connected and identified: if adb devices doesn’t show anything, it is not. If it shows some “strange string”, you should be OK

Logcat

Android system logs are pretty useful for debugging and troubleshooting. Even if you think you cannot read and interprete them yourself, being able to provide a dev with those increases your chances he can solve the issue you’re experiencing. For this, we’ve got e.g. adb logcat with a bunch of parameters – from which I will only pick two especially useful for us non-developers: -v time converts the timestamp preceding each line into human-readable format, and -f <filename> stores the output into a file, which you then can investigate with your favorite file viewer.

But logcat is not the only thing we’ve got to check for debug information. There’s also adb bugreport collecting a load of details. The output you better redirect to a file as well: adb bugreport > bugreport.txt would do so. Again, that file will prove valuable to the developer to figure out what’s going on; but peek into it at least, it’s interesting for sure

Shell Access

If you’re a Linux user, I probably don’t need to explain to you what a “shell” is. Simply put: a command line running directly on your device. You can enter it via some terminal app – or via adb shell. Now what to do there? What command line tools are available here? A shell command reference will provide you with some interesting candidates. A much shorter list here, so you get an idea:

• pm (the package manager): invoke without parameters to get a help screen. Deals with “packages” (which is what the apps are, seen from OS level). You can list which are installed, show their permissions, install/uninstall or enable/disable (aka “freeze/defrost”) them, and more. The latter is of special interest when you need to factory-reset your device after having disabled some bloatware, so you can easily repeat that (see freezing via command-line for details).
• am (the application manager): again, invoking that without parameters shows a help screen. This tool deals with your apps from a rather “process oriented” view. You can start “activities” (i.e. directly jump to a specific screen in an app), force-stop or kill apps, and more. Some fancy examples?
  • adb shell "am start -a android.intent.action.VIEW -d https://duckduckgo.com/": open a browser with that URL
  • am start -a android.intent.action.CALL -d tel:012345678: start a phone call
  • adb shell "am start -n com.android.settings/com.android.settings.Settings": open Androids settings screen
  • adb shell "am start -a android.intent.action.INSERT -t vnd.android.cursor.dir/contact -e name ’Martin Mustermann’ -e phone 1234567890": create a new contact
  • busybox sed -n ’s/<package name="([^"]+)".*enabled="false".*/1/p’ /data/system/packages.xml | while read PKG; do pm enable "$PKG"; done: “defrost” all apps you’ve disabled. Might be useful if you froze too many, and after a boot the home screen doesn’t show up anymore. As long as you can access the device via ADB, that’s a possible way out.

Linux admin thought: ”I’ll convert you into a tiny little shell script!” Sure, why not?

#!/bin/bash
if [ -z "$‌1" ]; then
  read -p "Which number to call: " NUMBER
else
  NUMBER=$‌1
fi
echo "Initializing call to $NUMBER..."
am start -a android.intent.action.CALL -d tel:$NUMBER

Now you don’t need to remember that strange command line anymore: save above snippet into docall, make that executable (chmod 0755 docall), put it into your path. Called with a parameter, it directly starts the call. Without, it asks you for a number. Oh, it would also try calling ”ahsfdjadk”, no error checking on the scripts side

Copy files from/to your Android device

If you feel a little like me, firing up some graphical program on both ends just to copy over a single file is a bit overkill – if a simple call from the command line can do that as well. For this, we’ve got adb push (computer → device) and adb pull (device → computer). Both support two parameters: source, and target. One catch which might get you from time to time: both parameters always must be of the same type. So if you want to copy a file, source and target must be a file. The commands will fail if you specify something like adb push somefile.ext /sdcard (file → directory).

Side-loading of Apps

For installing and uninstalling apps, we have two interesting possibilities with ADB: You’ve got an app you think is making trouble, and want to uninstall it without losing its data? Of course, you could first make a backup to restore later. But adb uninstall offers another possibility with its -k parameter, which stands for "keep data": while adb uninstall <package_name> would uninstall the data along with the app, adb uninstall -k <package_name> would keep the data intact. So if removing the app showed it was innocent, simply adb install <apk_file> to put it pack (of course, you need the .apk file for the latter).

adb install has a few interesting parameters as well: -r for “reinstall” (if you want to replace an already installed app), and -s to directly install it to the devices SD card. Might come in handy.

Backup & Restore

Helium Backup

Starting with Android 4.0, a backup feature was “sneaked in” pretty secretly, without any big announcements. As with all things ADB, it works at the command line. Basically two commands are dedicated for this task: adb backup and, as its counter-part, adb restore. adb backup allows for a couple of options which, as the name suggests, are all optional:

• -f <file>: the file you want to store the backup into. Default is backup.ab
• -apk or -noapk: whether to include the .apk files of apps, or just backup their data (with the latter being the default)
• -shared or -noshared: whether to include data from the sdcards. Default is -noshared.
• -all: backup all apps (so you don’t have to specify each of them separately at the command line)
• -system or -nosystem: whether to include system apps. Be careful with that (see below why)
• last option to give on the command line is a list of packages to back up.

adb restore on the other hand only supports a single parameter: the backup file to restore. This is an all-or-nothing job, you cannot pick parts. While you could restore user apps and their data even on completely different devices, you cannot do so with (all) system apps – as some of those might be pretty device and Android-version depending. And that’s why I wrote to be careful whether you really want to include them in a backup.

Let’s view some practical examples. Backup an app with its data from one device, and restore it on the same or another device seems to be a good one. For that, we first need the apps package_name, which is easiest to derive from its page at Google Play. To have some fun, let’s take a backup app to back it up: Titanium Backup has the Playstore URL https://play.google.com/store/apps/details?id=com.keramidas.TitaniumBackup. Find the package name at its id parameter: com.keramidas.TitaniumBackup.

# Back it up:
adb backup -f titanium.ab -apk -noshared -nosystem com.keramidas.TitaniumBackup
# Restore it:
adb restore titanium.ab

Of course, some of the parameters I specified for the backup are obsolete: -noshared -nosystem are defaults. I did so nevertheless to give you a better idea of how to construct the command line. Not a command line friend? No problem, you can use some GUIs which are available specifically to this command. Directly on the device, that would e.g. be Helium Backup (usable with or without root), which utilizes the just described ADB commands locally, saving the backups to your devices SD Card – a screenshot is included at the beginning of this “chapter”. If you’re rather after a tool to be used from your computer, you might wish to take a look at Holo Backup – available at least for Linux and Windows.

Conclusion

You see, there’re a lot of things you can do to have your Droid playing along fine via ADB⁵. If you feel your USB cable is to short (and you’d rather do that all wireless), or want some additional ideas: Be welcome to the app lists for ADB. For example… Much more to find on the web, from “nice little tricks” up to interesting (graphical) tools.