Minimal installation of ADB
ADB stands for Android Debug Bridge and it is a toolkit included in the Android SDK package, used mostly for debugging problems with Android applications and Android system itself. This is a must for Android developers, even if you’re using PhoneGap or PhoneGap Build to develop them. But in this case, you don’t have to install entire SDK. This post shows minimal approach for getting your hands on Android debugging along with some side-effect issues, you my run into.
A few words on ADB and QtADB
ADB is a command-line tool, which might be a bit hard to operate, especially for newbies. But, there’s no problem, as there’s a piece of software called QtADB, a visual addition over command-line tool. The most details about it, you’ll find on its homepage and in this Android Enthusiasts Stack Exchange answer. Start from this point, if you have some time, as it can provide you with some usefull tips and handy links, you won’t find here.
What you can get with QtADB? In general you:
- have access to console (
Shell
), - browse detailed system log (
Logcat
), - can caputre current screen state (
Screenshot
), - can read and manage your text messages (
Messages
), - get extendend information about your device (
Phone info
), - can manage installed applications and read detailed info about them (
Apps
), - have access all files and folders on your mobile device, including system partition (
Files)
.
Note, that most options require you to have non-generic, modded version of Android (like Cyanogen Mod for example). On generic systems you’ll have access to Screenshot
and Logcat
sections. Other will remain empty or unusable and some may even hang-up QtADB. Note also, that for text messages management (Messages
) you’ll have to install extra service application on your device (QtADB.apk
), available on homepage of QtADB.
I’ve tested this program on LG GT540
with Cyanogen Mod 7
and all was fine. I’ve also tested it with Samsung Galaxy Tab P1000
(first), but since there’s a generic Samsung Android 2.3
on-board it, I faced above mentioned limitations. I made some attempt to test it on first Google Nexus
(without number), with generic Android 4.2.1
on-board, but I failed. Though Windows installed all the drivers (see below) and though I enabled USB debugging mode (also see bellow), QtADB was unable to find this phone.
Getting QtADB
OK, after some introduction and presentation, here is how to get it.
First of all, get QtADB version and ADB binaries for your system (available for Linux, Windows and MacOS). You can download it from QtADB download page or from author’s website. Put them all (unzip) into one folder and you’re ready to go.
Now, enable USB debugging mode in your mobile device and connect it via cable to your computer. It depends on your mobile device and system on it. On generig Android 2.3
(as well as Cyanogen Mod 7
), you have to go to Settings > Applications > Development
, check USB debugging
and confirm. On generic Android 4.2.1
you’ll have to enable developer mode at first. To do this, go to Settings > About phone
and tap Build number
seven times. Then go to Settings > Developer options
, turn them on, if they’re not already turned on, check USB debugging
and confirm. I put instructions for Android 4.2.1
just as an addition here, since I failed to use QtADB on this version of Android.
Next step is to get USB drivers for your mobile device + operating system pair. It depends entirely on what do you have on both sides of this pair. Consult mentioned Android Enthusiasts answer for some details and useful links. In most cases, you’ll need a specific USB driver, required for ADB (debugging), not the one you use for copying files etc.
Depending on what operating system and mobile device you have, you may face few situations:
- all is set — system is using default or already installed USB driver,
-
your system lacks of proper driver, but will install it automaticaly, once you connect your device,
-
you need a debugging driver (you have standard USB driver installed, but you need extra one for ADB) and your system fails to install it automatically; you can get it on Google, at your device’s manufacturer website or by searching the Internet.
If you have:
- installed proper USB driver,
- enabled USB debugging mode in your device,
- QtADB unzipped in the same folder, where you have
adb
andaapt
,
you should be ready to rumble. Run QtADB and see, if you detects your phone.
If not, run command-line, go to the folder, where you have apt
and execute adb shell busybox ls -l -a
. If you see list of files, then ADB itself works fine and have connected your phone, so there is something with QtADB itself. Follow to FAQ section to get some more information.
If instead of file list you see error: device not found
, then there are some major problems with your USB connection or mobile device. Try to read read this Android Enthusiasts answer again or this guide or this forum thread. If this won’t help, try to search the web for error: device not found
string.
An alternative — AirDroid
According to QtADB’s author, this program is discontinued and he encourage to use AirDroid instead. Some resources about it:
I took a quick look at what AirDroid offer and I think I won’t use it, staying with old, good QtADB.
My key reasons:
- I don’t think AirDroid will let you do so deep operations like changing system partition files etc.,
key reason for using QtADB, was access to logcat
logs; AirDroid doesn’t have such feature (or I’m blind),
with QtADB you don’t have to install anything on mobile device, you want to access (with small exception of SMS service, if you want to manage text messages); AirDroid mobile application in key element and without it you won’t do anything,
I don’t like the idea of services, where someone could (at least in theory) gain access to my device. Yes, yes, I know, I know… hashed passwords in DB, possibillity to use AirDroid without account etc. etc.; but even so, I think that when I’m using QtADB, without any kind of account, Internet access and via USB cable, it is a little bit safer; maybe it is just because I’m to old, wako or old-fashioned.
Of course, there are also many benefits of using AirDroid:
- web-based control panel, that does not require anything on controlling computer and thus allow access even from public sites,
access without cables via WiFi to even remote device, to which you don’t have physical access (after you register AirDroid account),
additional features, like for example an abillity for easy converting spare mobile device into CCTV security camera or e-nanny / babyphone etc.
But, the key reason I started using QtADB was debugging of my applications and overall system condition, while AirDroid is much, much more oriented toward remote access to the device.
Conclusion
I’m a PhoneGap Build developer, writing simple apps in pure HTML 5 and CSS, with no Java code or PhoneGap plugins, so I don’t think I’ll ever need ADB or QtADB. But it is overall useful software, to debug even non-development problems, so consider getting it to your computer. For example, it helped me (by analysing logcat
logs) to find out that problems with downloading files on my LG GT540
were caused by some nasty thing (app or user) that renamed /mnt/sd_card/download
folder to /mnt/sd_card/Download
(with capital D
in the beginning). So, if anything else fails in chasing ghosts on your mobile Android-based device, always consider reading logs using QtADB.