So far, I’m very impressed. I would definitely suggest that anyone I like buy a pure google phone, having owned both the Nexus One and Nexus S (Pure google) and the Captivate and Streak (varying degrees of carrier and manufacturer shit). I’ll post more on it after a week or so.

Apparently, someone is high on PCP at ATT/Motorola. It’s cute that they think they can charge laptop prices for it, but at the end of the day, it’s an external screen and keyboard, and the price needs to reflect that. At the current price point, especially for people who aren’t eligible for upgrade pricing, you’d have to be out of your fucking mind to spend the money on it as opposed to, you know, buying a real laptop that costs the same and doesn’t depend on your phone to work.

Apparently most people agree.

Just in time for google books

Overview

In short, ADB shell allows you to run a shell on your phone, issuing commands from your computer and having the phone execute them. It’s the same basic idea as the shell environment in linux/osx terminal. It’s a command line environment, running on your phone, that you communicate with via the USB connection to your computer.

Setting up

In order to take advantage of the ability to run a shell on your phone to the fullest, you need to be rooted, and for the purpose of this article, I’m going to assume you are.

You also really need to have busybox installed. While android has some basic command line utilities (generally located in /system/bin), busybox has basically every command line utility under the sun. This market app installs busybox. Just install and run it and grant it superuser permissions, then hit “install”. If for any reason it gives you a choice, you want it installed to /system/bin.

For some reason, on my dell streak, it hangs up on installation, never telling me it’s done, even though it does successfully install busybox. If it hangs up on you too, failing to do anything after 2 or 3 minutes, just reboot. We’ll know soon enough if it worked.

Start a shell session

To start a shell session, connect your phone to your computer, making sure you have USB debugging enabled on your phone (Settings > Applications > Development). Open terminal and type

adb devices

It should return a device ID, indicating that your phone is connected, and ADB detects it. Now enter

adb shell

You should be rewarded with a dollar sign. Let’s make sure you’re rooted. Pick up your phone, unlock the screen, and keep it in your hand, then type:

su

The first time you do this, you’ll be prompted, on your phone, to grant adb shell superuser permissions. Obviously make sure “always allow” is ticked and select “ok” to grant permissions. It should return a pound sign in place of a dollar sign now. (My rom actually gives you SU permissions by default, a lot of them do not, so you will most likely have a dollar sign when you first enter shell, then a pound sign after granting SU)

Now enter:

busybox

and you should be greeted with something like this:

If you have a pound sign, and you get that response when you enter “busybox”, you’re good to go. That’s means you’re rooted and have busybox installed.

Basic Shell Usage

First, some basic commands.

cd

Change Directory. Just like in any other *nix environment, it’s one of the basics of terminal navigation. When you start a shell session, you’ll be in root, ( / ). From there, let’s say you want to move to the SD card.

cd /sdcard

Now you should be in the /sdcard/ folder. To verify, use

pwd

pwd = Print Working Directory. In other words, output your current location within the file system.

Now let’s see what’s on the sd card using

ls

ls = list. This command will list all files in the current directory.

Let’s say I want to start an adb shell session, get root permissions, go to a folder on the sdcard named “tempfolder”, make sure I’m in the right folder, and then list all files in that folder.

For directories with lots of files, use

ls | more

(The vertical line is above enter, lol)

This will list all files and folders, showing only what fits in the terminal window until you press a key to show more. The space bar will get it to load the next page of results.

For example, just using

ls

with no options in the system/bin folder results in this:

I’m not going to screenshot the whole thing, but based on the scroll bar on the side, you get the idea as to how many files it just spit out. Using the more option cuts the results up into much more manageable chunks:

Starting to make sense?

Busybox usage

Busybox is a bunch of unix terminal utilities that allow you do pretty much anything you want. There’s no way I could even remotely begin to cover all of the utilities included in busybox, much less all of the options for them, so I’ll just hit a few of the very common ones. The wikipedia article has a full list, and you can click a command and learn more about it.

cp

cp = copy. It’s exactly what it sounds like. Let’s say you have a file name myfile.txt in /sdcard/tempfolder, and you want to copy it to /sdcard/tempfolder2

busybox cp /sdcard/tempfolder/myfile.txt /sdcard/tempfolder2/

That will result in the original myfile.txt remaining in /sdcard/tempfolder and a copy of myfile.txt in /sdcard/tempfolder2

mv

mv = move

Again, just what it sounds like. Using the example for cp above:

busybox mv /sdcard/tempfolder/myfile.txt /sdcard/tempfolder2/

will move the original file from /tempfolder to /tempfolder2. The file will no longer be in the original location.

rm

rm – remove

Let’s say we want to get rid of myfile.txt

busybox rm /sdcard/tempfolder2/myfile.txt

mount

Not a lot of people will use this command other than to make a file/folder writable.

busybox mount

will list all mount points, but by far the most common usage of the mount command will be

busybox mount -o remount rw /system

That uses busybox to run the mount command with the option (-o) to remount the directory /system with the ability to both read and write (rw). In other words, if you can’t write to some file in the /system directory, or can’t modify some file located in that directory for a hack, that will remount the /system directory so that it’s writable. It should revert to read only (ro) after you reboot, or you can remount it yourself:

busybox mount -o remount ro /system

mkdir

make directory. This makes a new folder. For example, if you want to make a directory on your sdcard named “vids”

busybox mkdir /sdcard/vids

rmdir

Remove directory. Basically the same thing as the “rm” command, just for directories instead of just files. Let’s say we decide we don’t want that “vids” folder we just made…

busybox rmdir /sdcard/vids

Note that rmdir won’t remove a folder unless it’s empty. To do that we use rm and the recursive option. If you already put a video in the /sdcard/vids folder, and you want to just get rid of the folder and the video in it:

busybox rm -r /sdcard/vids

I’m starting to get cross-eyed from staring at my terminal window, so I’m going to stop for now, I’ll continue with fastboot usage and likely some more adb shell stuff within the next day or two. Hope this helps a little.

While the title specifically states “For Mac”, that really only applies to the installation. Once you have the SDK installed, the commands are more or less the same in ADB.

Installation (Mac Specific)

1. Download the SDK. It will come in the form of a zip. Extract it somewhere easy, like the root of your username. You’ll get a folder called “Android-sdk-mac_86″ or something similar.

2. In finder, navigate to the sdk, then find the tools folder. Open it, and double click “Android”. It will launch a terminal window, then a few seconds later, a GUI. On the left, click on “Available Packages”, then in the right pane, check the box to select all, and hit “install selected”.

It will download quite a bit of data, so depending on your connection speed, it may take a while. While you’re waiting on that, use my tutorial to set up a bash profile.

3. On your Android phone, go to Settings > Applications > Development, and make sure “USB Debugging” is checked. Connect your phone to your computer with the USB cable.

4. Assuming the SDK is fully installed and downloaded, close the terminal window it opened and the gui. Open a new terminal window. If you’re not sure how, press Command + Space and type “Terminal” then enter. You’ll get a black box with text. Type “adb devices” and press enter. If everything worked, it will return a device ID to indicate your phone is connected and detected by ADB.

Navigating Basics

In order to effectively use ADB, you need a basic grasp of navigating your computer from terminal. Opening a terminal session will start you at the root of your user name, in finder, this will be your user name in the left hand pane, right under “desktop”. Entering

~/

or

cd

will get you back here.

If you intend to flash an img, push a file, etc, the easiest way to do so is to navigate to the directory in which the file is located. For example, if you want to push (I’ll explain what “push” means in a few, just stay with me) a file that is located on your desktop, and is named yourfile.zip to the SD card on your phone, you can either use

adb push ~/username/desktop/yourfile.zip /sdcard

from anywhere in terminal, since you’re using the full path to the file, or you can first navigate to the file’s location:

cd desktop

and then

adb push yourfile.zip /sdcard

which doesn’t require the full path, but rather works from the current directory.

Either way, you need a basic idea either how to determine the full path of a file, or how to navigate to the file’s location. Let’s cover the basics.

cd – Change Directory. This is what you’ll use more than anything. The format is

cd (location)

For example, let’s say you have a folder on your desktop named “android”, and inside that folder you have a folder named “apps”. To get there from ~/, you would enter

cd desktop/android/apps

Now let’s verify our location in terminal.

pwd

Now use ls to list the files in that folder

ls

That pretty much covers the basics. A few shortcuts:

• cd will take you back to the root of your name from anywhere
• cd .. will take you up one directory
• ls -a will show all files

ADB Commands

adb push

adb push will “push” a file from your computer to your phone. The format is

adb push (location on computer) (destination on phone)

For example, let’s say you navigate to your desktop, and you want to move the file “song.mp3″ to the folder “music” on your phone’s SD card.

adb push song.mp3 /sdcard/music/

adb pull

adb pull is exactly the opposite. To pull song.mp3 from the music folder on your sdcard to your desktop:

adb pull /sdcard/song.mp3 ~/desktop/

adb install

adb install will you install an app via adb, using an apk file on your computer. If you have app.apk downloaded to your desktop, and have navigated to desktop in terminal

adb install app.apk

You need to have “Unknown sources” checked on your phone, found at settings > applications for this to work.

adb logcat

adb logcat is insanely valuable in trying to diagnose issues. Simply enter

adb logcat

and you’ll start to get a real time log of everything going on with your phone. It might not mean much to you, but it can be a valuable tool when asking for help.

That’s all I feel like writing for now, I’ll cover ADB shell, fastboot, and perhaps more extensive stuff later. Hope this helps.

Unfortunately, OSX doesn’t have a .bash_profile by default. Without creating a .bash_profile and adding your sdk/tools folder to path, you’ll need to navigate to the tools folder of your sdk and run scripts locally when using stuff like ADB and fastboot.

I know that just gave you a headache, so I’ll clarify with examples.

Let’s say you download the sdk, and unzip it to yourusername/android-sdk-mac_86

In order to run adb, you’ll need to open terminal, and type

cd android-sdk-mac_86/tools

then you’ll need to start every command with the dot slash ( ./ ), which tells the terminal to run commands from the folder you are currently in.

For example,

adb shell

attempts to run the script adb, with the command shell, to open a shell, and it looks for the scripts where ever it thinks scripts will be. On a Mac, it only looks in /bin by default. This is where the scripts for the commands you use to navigate in terminal are stored. It contains stuff like ls, mkdir, cd, etc.

If you want it to run a script from your current location in terminal, you have to add the dot slash. For example, still in your sdk/tools folder, the command

./adb shell

Will attempt to run the script “adb” with the command “shell” from your current location, in this case, sdk/tools.

We’re going to add sdk/tools to the places OSX looks for scripts, so you don’t need to be in that folder in order to use adb or any other SDK script. For instance, you can navigate to the desktop and use ADB to install an APK on your desktop without moving it to the tools folder. Clear as mud? Great.

Press Command (apple) + space and a spotlight search window will pop up in the upper right corner. Start typing “Terminal” until you see it highlighted, and press enter. A terminal window will open.

Type:

cd

Press enter. You should be in your root directory.

Now type:

touch .bash_profile

then press enter. You just created a file called “.bash_profile”. Now open it with text editor using this command:

open -e .bash_profile

Pressing enter will make text edit pop up, it’s likely blank, since you just created it. In the text file, paste this:

export PATH=${PATH}:/Users/yourname/whereveryoursdk/islocated/tools

Obviously replace yourname and the path to your sdk/tools folder with the correct info for your install.

Save the file and close text edit.

If you did it right, you’re done. With your android phone plugged in, type

adb devices

and if you get a device returned, you’re good to go.

12/07/10 Update:

It appears that updating your SDK to include all the new gingerbread stuff moves ADB from sdk/tools to /sdk/platform-tools. Basically, all you need to do is add one more line to .bash_profile. Under the line you added earlier, something like:

export PATH=${PATH}:/Users/yourname/whereveryoursdk/islocated/tools

Add this:

“fastboot devices” just returned back to the terminal prompt, without showing any connected devices, so I tried using the -i option to specify a usb vendor ID, like “fastboot-linux -i 0x413c reboot”. This just hung on “waiting for device”. I kinda ignored it, since I actually use my mac for most fastboot/adb, but tonight I was bored and fucking off on the CyanogenMod forums shoutbox, and someone was having the same problem. I did a bit of googling and found a solution that worked for me (and M.P.)

As usual, I’m not responsible for fucking your phone up or accidentally dividing by zero or going back to the future or hacking the gibson or anything else that happens. I’m not an expert. I wouldn’t listen to me, I’m kinda an asshole, I have no idea what I’m talking about, I’m usually just guessing. Proceed at your own peril, etc, etc, etc.

Here’s the step by step fix, assuming you’re running ubuntu 10.04:

1. Open a terminal window.

2. Log in as root.

sudo -i

3. Create a UDEV rule file.

cat > /etc/udev/rules.d/51-android.rules

This should give you a blinking cursor at the very beginning of a blank line, it’s waiting for you to tell it what the file needs to contain.

4. Enter this AFTER YOU REPLACE “XXXX” WITH YOUR VENDORID:

SUBSYSTEM=="usb", SYSFS{idVendor}=="XXXX", MODE="0666"

(You can find your vendor ID on this page.
For example, for my Dell Streak, I would use:

SUBSYSTEM=="usb", SYSFS{idVendor}=="413c", MODE="0666")

5. Press CTRL + D to save, it should return you to the terminal prompt

6. chmod the new file

chmod a+r /etc/udev/rules.d/51-android.rules

7. Try fastboot. It should work now.

fastboot devices

Hopefully you get “Attached devices” with your devices serial number, if so, you’re good to go, fastboot should no longer hang at “waiting for device”. To be sure, try

fastboot reboot

If your device reboots, you win life.

An AMOLED screen doesn’t actually display the color black at all, it simply turns off any pixel that is supposed to be pure black.

An LCD screen, on the other hand, does actively render the color black.

As such, an AMOLED screen displaying a black pixel looks exactly the same as an AMOLED screen that’s “turned off”, while an LCD screen looks decidedly different.

So, if you open photoshop/paint/whatever, and make an image that’s totally black, (hex code #000000), or just use this one I’ve so helpfully provided, it will look a lot different on an AMOLED screen than it does on an LCD.

This is black.

This is that very same image displayed on a Nexus One, with an AMOLED screen (left) and a Dell Streak, with an LCD screen (right), in the dark.

And both off, in darkness.

Note the AMOLED Nexus One looks the same, where it’s obvious when the Streak’s screen is on.

Now in normal light. Both powered on. Nexus One on the left, Streak on the right.

And again powered off.

Again, you can clearly tell when the Streak’s LCD screen is powered on, but the Nexus One’s AMOLED screen looks the same. This should be a pretty easy indicator as to which screen you have.