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.

If you’re using windows and executing adb from the local folder, you just need to go to /platform-tools instead of /tools. If you’re on a *nix machine, you just need to add /platform_tools to your PATH:

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

Should be good to go after that.

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.

HELP!

I realize that an open operating system means taking the good with the bad, and carrier customization is inevitable. Their primary reason for being in the mobile phone business is to rape their customers make money, and they’re going to want to add their apps that offer paid content and services. We’re in dire need of some control over their implementation though, to prevent stuff from happening like AT&T Navigator running constantly. I was amazed how much of their crap is set up to launch automatically, just using resources for no reason. I’m obviously a big proponent of rooting, but you really shouldn’t HAVE to modify your phone to make it run well, especially when the hardware is more than capable.

A good start would be some basic standards to which carriers have to adhere in order to call the OS “Android”. They can still add all their bloatware, but how about making all additions to the ROM install to the data partition? Can we also set some standards for recovery and system images? It’s infuriating to own multiple android phones and need multiple drivers and file formats to be able to flash a rom or restore to stock or do a factory reset. The built in method used on the Nexus One is beautiful in it’s simplicity and flexibility. Why not make it THE way to issue updates and restore?

We’ve also seen that the carriers will concede to manufacturers in the case of the iPhone, they just need some prodding, and the manufacturers are making tons of money on a free operating system, they’ll certainly concede a few minor things like that.

Dear Android Phone Manufacturers,

Stop it.

Seriously, stop screwing around with Android. Your modifications are pretty much universally hated. I’m looking at you, Samsung. How much did you pay a team of software engineers to make Android run so poorly? If I had gone from an iPhone 3GS to a Galaxy S, without first having used a phone with unmolested Android, I would have thrown that pile of AIDS and fail into a river, and ordered an iPhone 4.

Did no one at Samsung have a Nexus One for comparison? You had to have noticed that after you “fixed” Android, the Nexus One just completely raped it in every way, despite having slower hardware. Did you notice it, and just figure no one would care? Did you think that people would really appreciate the colored boxes around their app icons and the horizontal app drawer so much they would overlook the fact that their phone took a good 3-5 seconds to respond when you tapped on one of those pretty icons to open an application?

And what the hell did you do to the recovery process? Was the phone based system that used the neat, all encompassing update.zip just too easy? Did you really need to incorporate the Windows only (Some of us use other OSes, btw. You know, Unix based systems?) KIES bullshit? Seriously? I need to download 4 or 5 files totaling near 500MB, boot to a windows partition or make a virtual machine, and install your horrid drivers in order to do the same thing any other Android device can do with a 100MB update.zip and no computer? Brilliant, thanks for the innovation.

I want all of you to be locked in a room with a box of Galaxy S phones and a box of laptops from a variety of manufacturers and beaten mercilessly until you get all the phones in download mode with the correct drivers installed on the laptops. I hope you all have your affairs in order.

HTC almost gets a pass on this, in that their Sense skin actually does make some appreciable changes that some people actually prefer, but I still take issue with the depth of integration. They could easily make Sense more modular, making it easier for users to set their phone up however they like (you know, the reason they went with an Android device in the first place?), and easier for HTC to stay on top of the rapidfire progress of Android.

On principle alone, Motorola needs to be beaten with the corpses of the Samsung guys for the bullshit bootloader lock. What the fuck is the point? I paid for it, can I please, please do whatever the hell I want with it now? In the words of Sgt. Hartman, “Do you mind if I be in charge for a while? Thank you very much!”.

I don’t even see the logic here. We’re always going to win. You’re never going to lock us out. We’ll always get around it. It comes down to this: People who want to hack their phone will. No matter what you do. The vast majority of your customers will never do any major modifications. Is it really worth spending the time and money on a complex bootloader to try to keep people from modifying something they paid good money for? Why not make things easier on everyone, include a Nexus One style “Your Warranty Will Be Voided” message, and be done with it. I just saved you millions of dollars in software development man hours, you’re welcome.

In short, can someone please, PLEASE tell me why you are spending so much money developing software that makes the Android OS slower, less responsive, larger, and harder to use?

Dear Carriers,

You can basically just read the manufacturer section and pick the parts that apply to you. Oh don’t play dumb, you know which parts apply.

I realize that you are in the business of screwing people out of as much money as possible while providing just the minimum required service providing mobile phone service, and I realize that you see your horrible, terrible, AIDS infested pus oozing diseased abortions you so amusingly call “extras” apps for paid content as another income stream, but you’re also wasting your time and money trying to force these apps on us.

The same argument about Motorola locking the bootloader applies here; if the customer actively wants your suckware app off their phone, they’re gonna get rid of it. Just install it to /data like a normal app, so people can just get rid of it without having to root. No one is going to go “WELL, I CAN’T REMOVE THIS FAIL APP, SO I GUESS I’LL JUST SIGN UP FOR IT, LOL!”, the idea that trying to require it to be on the phone will make more people use it is absolutely absurd. The people that want to use it will use it, and won’t try to remove it. The people that want to remove it clearly don’t want to use it. Use your fucking heads a little, I know it doesn’t come naturally, because it’s just so goddamn rare with you guys, but try real hard this time.

Thanks for your time guys, now try to get your shit together, because some guy on the internet said so!

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:

If true, they better make an ATT version