Backup your Android without root or custom recovery

Recently discovered a neat new way to back up apps on my Android without having to use Titanium Backup, having to unlock bootloader or root the device to take a NANDroid snapshot. The icing on the cake - I can do it from command line!

Warning: this method is only available to devices running Ice Cream Sandwich or higher and it has bugs, but it is an alternative for folks who want to make a backup before rooting their device.

You'll need to have the latest adb installed and in you path, USB debugging enabled and your phone connected to your Mac.

The command in question has the following format:

adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>]

Here are some common uses:

1. Backup all non-system apps, their data and your shared data (i.e. SD card contents):

adb backup -f /path/to/backup-file -apk -shared -all -nosystem

2. Backup all apps, their data and shared data (note: won't work on DRM protected apps):

adb backup -f /path/to/backup-file -apk -shared -all -system

3. Backup only app data (not the APKs themselves) and your shared data:

adb backup -f /path/to/backup-file -all

4. Backup only non-system apps:

adb backup -f /path/to/backup-file -apk -noshared -nosystem

5. Backup only your shared data:

adb backup -f /path/to/backup-file -noapk -shared -nosystem

6. Restore everything from your backup:

adb restore /path/to/backup-file

During backup your phone will display a backup confirmation screen giving you an option to enter an encryption password. In my case it would only work with non-empty password, otherwise it would generate a zero-sized file.

Install adb and fastboot on OS X

There are plenty of packages floating around the Internet with just the adb and fastboot utilities for OS X, but I prefer installing those (and few other android utilities) on OS X is via Android SDK. This way you know exactly what you're getting and it's easy to can keep them up-to-date with Android SDK Manager.

First download the latest Android SDK package from http://developer.android.com/sdk/index.html (android-sdk_r20.0.3-macosx.zip at the time of this writing).

Change into your download directory and unzip archive into your preferred location. I like my home directory so I run:

unzip android-sdk_r20.0.3-macosx.zip -d ~

This creates a android-sdk-macosx directory in our home directory. Now run android application inside the tools directory to open Android SDK Manager (ASM).

~/android-sdk-macosx/tools/android

ASM will connect to various repositories and present you with all possible Tools, Platforms and Add-Ons that could be downloaded and installed. Since we're only interested in few specific tools, deselect all except "Android SDK Tools" and "Android SDK Platform-tools" packages and then install / upgrade them.

Note: to accelerate checking for updates during future runs, go to "Tools"->"Manage Add-on Sites..." and click on "Disable All" button in "Official Add-on Sites" tab. From now on ASM will check only the default repository containing tools and APIs.

Now we'll add android tools to our PATH to make executing them more convenient. Create or edit .bash_profile file in your home directory to contain these lines, just don't forget to replace YOURUSERNAME with your actual user name:

ANDROID_TOOLS=/Users/YOURUSERNAME/android-sdk-macosx
export PATH=${PATH}:${ANDROID_TOOLS}/platform-tools:${ANDROID_TOOLS}/tools

Done.

Rooting Jelly Bean Galaxy Nexus from OS X

Now that we've unlocked bootloader on our Galaxy Nexus and updated OS to Jelly Bean 4.1.1, rooting it is extremely simple. In fact, to root GNex all you need is su (Super User) binary as one of the system apps. Since /system partition is mounted as Read Only, we need to boot into custom recovery mode and install su utility on our phone from there.

In this example we'll use ClockworkMod Recovery. You don't have to install the ClockworkMod Rom Manager application, or replace your stock recovery partition with CWM's. Having unlocked bootloader allows us to boot into CWM Recovery without overwriting anything on our device, as you would boot into Linux on PC from a LiveCD/USB.

Upgrade Galaxy Nexus to Jelly Bean with fastboot on OS X.

Great news for Galaxy Nexus owners that are still waiting for their Over The Air (OTA) update to Jelly Bean. Last week Google released Jelly Bean 4.1.1 factory images for most Nexus devices (no image for CDMA/LTE Galaxy Nexus yet). This is particularly useful for folks that didn't buy their GNex from Play Store (i.e. the yakju / takju variant) and have one of the regional/carrier variants (like yakjuxw, yakjuxs, yakjuux, yakjusc, yakjuzs, yakjudv, yakjukr and yakjujp), which will take even longer to get an OTA update.

The only requirements are: GSM version of Galaxy Nexus, factory image and fastboot utility in your PATH (I'll make a separate post on how to setup fastboot utility on Mac OS X).

Google Apps email, GoDaddy hosting and SPF records

The other day I was setting up another web site using GoDaddy for hosting and DNS and Google Apps for email. The two Gs make a great combo since GoDaddy allows for quick domain verification right within Google Apps admin view, while their configuration tool automatically creates the necessary MX records for Google Apps. The deployment is as fast as it gets.

The issue arose when I tried to send test email from the web application using Google's SMTP servers. Apparently GoDaddy rejects all outgoing SMTP connections to any servers but its own relay-hosting.secureserver.net. Not much can be done about that,  so I guess I just have to configure my SPF records to define which servers are authorized to send emails on behalf of my domain.

For Google Apps it's a well documented procedure, just add the following TXT record:

"v=spf1 include:_spf.google.com ~all"

Now what settings to add for GoDaddy's servers? GoDaddy's SPF wizard would have me use something like this:

"v=spf1 a mx include:smtp.secureserver.net ~all"

Since I've changed my MX servers to Google's and they won't be sending any mail, the "mx" mechanism could be dropped. Same goes for "a" mechanism since, as I discovered, GoDaddy does not allow its shared hosts to send any email directly. Let's dig into the "include:smtp.secureserver.net" portion and see what's inside...

dig smtp.secureserver.net -t txt

Here's the contents of TXT record: "v=spf1 include:spf.secureserver.net -all". OK, let's dig deeper...

dig spf.secureserver.net -t txt

Now we get a whole set: "v=spf1 include:in.spf.secureserver.net include:in2.spf.secureserver.net include:ext1.spf.secureserver.net include:ext2.spf.secureserver.net include:ext3.spf.secureserver.net include:mon.spf.secureserver.net include:exch.spf.secureserver.net -all". Yikes! Do I have to check all of these one by one?

Luckily, there's an easier way with a free online tool called SPF Parser. Just paste smtp.secureserver.net into the text field and get the entire list of all A and relevant SPF records recursively parsed.

The output contained IP address of GoDaddy's relay server, so in theory it should work, so my final SPF record becomes:

"v=spf1 include:_spf.google.com include:smtp.secureserver.net ~all"

Once new record is in place, validate it over at Scott Kitterman's site, where you can see what your domain is currently reporting, whether it's valid and whether an email sent from certain IP shall pass of fail SPF verification.

Multiple time zones in Google Calendar

Imagine this: you're in Jakarta when client from Kuala Lumpur requests a conference call at 3 pm. You start thinking: "Is it 3 pm their time or yours? Must be theirs. What was it again in local time? I know there's an hour difference, but are they ahead of me or behind? I think they're one hour ahead, but better double check..." If you work with clients in different timezones you probably familiar with that scenario.

Luckily, Google Calendar takes care of this problem quite nicely:

1. Go to Settings -> General -> Your current time zone
2. Set your primary time zone if you haven't done so yet
3. Check "Display all time zones" for full list of time zones
4. Click on the "Show an additional time zone" link to add another time zone
   
   
   
   
   
5. Chose you additional time zone from the list
6. Enter your custom labels
   
   
   
   
   
7. Save changes, and your appointments will have a nice label for each time zone next to them:
   
   
   

Convert Unix, Windows, Mac line endings using OS X command

Today I had to copy some MySQL data from Debian server into test environment on my MacBook. While importing data from tab delimited text files, I noticed warnings that data in the last column of several tables was being truncated. I looked at the tables and noticed MySQL doing some very strange formatting when printing them. It looked almost as if last column was padded with a bunch of white space. I opened import file in TextWrangler and it appeared fine, but when I looked in document options, I saw this:

 

The good ol' EOL (end-of-line) character...

Different operating systems use different characters to mark the end of line:

• Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
• Macs prior to OS X use CR (carriage return, '\r', 0x0D)
• Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A)

I'm guessing the person who sent me those files first transferred them to his Windows machine in ASCII mode, so newline characters got automatically converted during transfer.

Since some of the files were very big, instead of changing line endings in TextWrangler I decided to use command line (shocking, I know).

First I executed

cat -v file-name

to confirm existence of the dreaded ^M (carriage return) at the end of every line, and then ran

tr -d '\r' < file-name > file-name-unix

to generate new files without CR characters.

tr (translate character) is a nice little utility that does just that, substitutes one character with another or deletes it (like in my example). It's available on pretty much any *nix distro so no need to install additional software.