Just fire up the Market application on your device and press the Menu button. That gives you the “Accounts” option, which allows you to switch the Google Checkout account associated with your Market application:

Of course you have to have added your new Google account to the available accounts on the phone before you can do the above switch. To do this, go to:

Menu -> Settings -> Accounts & sync

and add your account (new Gmail email) here. Then you can go to the Market application and switch to this new account.

In the past this used to require a factory reset of the device or a root access.

Although this is a great feature for the consumer, it might also turn out to be an issue in the long run. All downloaded/purchased applications are associated with the Google Checkout account used at the time of acquiring them from the Market. So if you switch your account in the Market application, you will no longer have access to the applications you purchases or downloaded with the previous account. For example, when you go to “My Apps” in the Market application, you will not be able to see the application you downloaded with your old account.

Furthermore (unless Google is doing something new that I am not aware of) all the licensed application you purchased from the Market with the old account will begin to complain that they are not licensed for your new account.

There are some cases though, when this method will not do. For example, if you decide to publish your applications on the new Amazon App Store, you will find out that they require you to submit an unsigned apk first. They do some optimizations and DRM (if you chose to use it) processing of it, and then they allow you to download the new package and sign and re-upload the final .apk file.

Amazon provides an option to sign the package for you, but in a lot of cases that will not work. For example, if you use some Google API’s (like Google Maps, etc.) you must sign it yourself! Otherwise the application will not work!

Steps to sign your application:

1. Export the unsigned package:

Right click on the project in Eclipse -> Android Tools -> Export Unsigned Application Package

2. Sign the application using your keystore and the jarsigner tool (comes with the JDK):

Change directory to where your unsigned .apk file is. Then run:

jarsigner -verbose -keystore /path_to_keystore/mykeystore.keystore my_application.apk my_keystore_alias

It will ask you to provide your password:

Enter Passphrase for keystore:

Once you enter the password it will sign your apk. To verify that the signing is successful you can run:

jarsigner -verify my_application.apk

It should come back with:

jar verified.

Just an FYI: The jarsigner tool should be in your /usr/bin directory by default.

Here is a detailed documentation on signing your Android applications: http://developer.android.com/guide/publishing/app-signing.html

3. Do not forget to zipalign the .apk at the very end!

Even though this is not absolutely necessary, it is highly recommended. The zipalign tool optimizes the .apk file and makes it a lot faster to execute.

To zipalign your application:

zipalign -f -v 4 my_application.apk my_zipaligned_application.apk

As you can see, zipalign expects you to provide the input .apk file and specify what you want the output file to be named.

Zipalign tool documentation.

To fix this, just do:

Project->Clean

This will rebuild the project from scratch.

After some tests and digging it turned out that applications that have the “Copy Protection” turned on in the “Developer Console” would not be displayed in the Android Market on devices running version 2.2.2.

I have not tested this on devices with ver. 2.3 and 3.0, but I would suspect that the result would be the same.

For a long while the “Copy Protection” feature has been marked as “will be deprecated soon” by Google. No date or any other pointer has been published by Google as to when that will be. I guess we got the answer with this last OS update.

If you want your application to be available to all the devices running the latest OS versions, you will have to turn off the copy protection feature. Of course if your application is paid you would still want to make sure that only people that have purchased it will be able to run it. To do that, just implement the licensing service in your application.

The displaying of the Dialog has to happen on the UI thread, so you would do that either in the Handler object for the thread or in the onPostExecute method of an AsyncTask (which is a thread as well, just an easier way of implementing it). That is a textbook way of doing this and you would think that pretty much nothing wrong could go with this.

Surprisingly I found out that something CAN actually go wrong with this. After Google updated the Android Market and started giving crash reports to the developers I received the following exception:

android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
at android.view.ViewRoot.setView(ViewRoot.java:468)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:177)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
at android.view.Window$LocalWindowManager.addView(Window.java:424)
at android.app.Dialog.show(Dialog.java:239)
at android.app.Activity.showDialog(Activity.java:2488)
…
at android.os.Handler.dispatchMessage(Handler.java:99)
…

I only got a couple of these exceptions from thousands of installs, so I knew that was not anything that happens regularly or that it was easy to replicate.

Looking at the stack trace above it gives us a pretty good idea why it failed. It started in the Handler object, which naturally was called by a background thread after it finished its processing. The Handler instance tried to show a Dialog and before it could show it, it tried to set the View for it and then it failed with:

android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?

The 447a6748 number is just a memory address of an object that no longer exists.

Note- do not get hung up on the exact number. It would be different with every execution.

Now we know why the application crashed, the only thing left is to figure out what caused it?

We know that background threads execute independently of the main UI thread. That means that the user could be interacting with the application during the time that the thread is doing its work under the covers. Well, what happens if the user hits the “Back” button on the device while the background thread is running and what happens to the Dialog that this thread is supposed to show? Well, if the timing is right the application will most likely crash with the above described error.

In other words what happens is that the Activity will be going through its destruction when the background thread finishes its work and tries to show a Dialog.

In this case it is almost certain that this should have been handled by the Virtual Machine. It should have recognized the fact that the Activity is in the process of finishing and not even attempted to show the Dialog. This is an oversight of the Google developers and it will probably be fixed some time in the future, but in the meantime the burden is on us to take care of this.

The fix to this is pretty simple. Just test if the Activity is going through its finishing phase before displaying the Dialog:

private Handler myHandler = new Handler() {
  @Override
  public void handleMessage(Message msg) {
    switch (msg.what) {
      case DISPLAY_DLG:
        if (!isFinishing()) {
        showDialog(MY_DIALOG);
        }
      break;
    }
  }
};

As soon as the new Motorola Droid X came out I started getting reports that my applications would crash on it.

The description I was getting from people was that the application would start, then it would show the Google map and start moving the map and zooming in on to their current location and then all of a sudden the app would crash. By crash I mean they get taken back to the phone’s home screen. No “Force Close” dialog pops up… nothing… just gets back to the home screen.

If both the GPS and the Wireless Networks are turned off from the Locations settings then the applications would work fine, but of course that means that the current location of the device would be impossible to find.

At this point I knew that the problem had to do with either the LocationManagers or the LocationOverlays but I had no way of finding out exactly what the problem was until I could get my hands on a Droid X phone and connect it to my computer to look at the execution stack.

Well it turns out the problem is with the default MyLocationOverlay class. The Droid X phones throw an exception when they try to draw the dot showing the location of the device:

E/AndroidRuntime(10458): Uncaught handler: thread main exiting due to  uncaught exception
E/AndroidRuntime(10458): java.lang.ClassCastException:  android.graphics.drawable.BitmapDrawable
E/AndroidRuntime(10458): 	at com.google.android.maps.MyLocationOverlay.getLocationDot(MyLocationOverlay.java:180)
E/AndroidRuntime(10458): 	at com.google.android.maps.MyLocationOverlay.drawMyLocation(MyLocationOverlay.java:561)

Another developer (rgfindl) who had the same problem like I did and who had already made the trip to the Verizon store gave me the above stack trace.

Several possible solutions popped into my head:

1. Stop using the MyLocationOverlay class and start relying only on the LocationManager classes and draw/redraw my current location onLocationChanged.
2. Extend from MyLocationOverlay class and override the draw method.
3. Stop supporting the Droid X.

None of these solutions are ideal with the last one being almost unacceptable.

Luckily the same developer also gave me a link to a solution implementing the 2nd option above, so I did not even have to code it myself. Apparently that is not the first time Motorola phones (Motorola Cliq and Motorola Dext) have a problem with this class. Most likely their builds are missing the drawable resource.

Anyway, the solution consists of the .java file that implements the FixedMyLocationOverlay class, which inherits from the default MyLocationOverlay class and overrides the drawMyLocation method. And a .png file with a dot that will be representing the current location on the map.

Just use this derived class FixedMyLocationOverlay instead of the default MyLocationOverlay. If you look at the implementation of the drawMyLocation method, you will see that if the phone has no problem it will use the default implementation of the parent class, but if it throws an exception it will use the custom code to draw the location.

I would think that there are a lot of applications in the Android Market right now that use the default MyLocationOverlay class and all of them will be crashing on the new Droid X until either Motorola gets their act together or the developers realize the issue and work around it.

And to my surprise, the first time I looked at my phone this morning, I had this message on the screen:

Android 2.2 Upgrade Message

I was not sure how long it would take, so I just hit “Install Later”. Then a couple of hours later, when I was ready, I just went to Settings -> About Phone -> Software Update and hit “Restart & Install”:

Android 2.2 Settings -> About Phone -> System Updates

The phone rebooted and started the upgrade. The whole process with the installation took less than 5 minutes.

I am not going to go into details what the features of Android 2.2 are. There are so many announcements and blog posts on this matter already out there…

But what I am going to say is that Android is the leading OS in the mobile phone market right now. I can say this definitively, since I have been using iPhones for the past 2 years. I have a 3G and a 3GS phones. I encourage any iPhone user to go and check out an Android device. Please do not look at the low end hardware that runs Android (like the Cliq, the old G1, etc.). Check out the HTC Evo, the HTC Incredible, the Nexus One etc. See for yourselves before you make your decision to get another phone and lock into a 2 year contract. I will mention only a few things you will discover on the Android device that your phone probably does not have right now:

1. Turn by turn voice navigation
2. Built in tethering
3. Built in WiFi hotspot capability supporting multiple devices
4. Full support for Flash
5. Full blown multitasking on the OS level (no need for the programmer to do anything special)
6. Integrated speech recognition across the board. Voice input could be used anywhere in place of the text input.
7. Over the air updates and syncing. That means no iTunes or the like!

And many other features that I do not want to get into details right now. I am sure you can fill in the gaps for yourselves…

If you just connect the phone to the computer through USB and run adb devices you will find out that your phone is not recognized:

$ adb devices
List of devices attached
???????????? no permissions

This is easily fixable in Ubuntu. You have to add a line to a file in the /etc/udev/rules.d directory.

What line in which file depends on the manufacturer and model of the device. You can find out the Vendor ID number and Product ID number of the device by running (after you connected it via USB of course):

$ lsusb

For example, if you had a Nexus One connected you would get:

Bus 002 Device 004: ID 18d1:4e12

In this case the Vendor Id is “18d1″ and the Product ID is “4e12″. Please keep in mind that the Vendor ID for HTC changed from “0bb4″ to “18d1″. The older HTC phones like the G1 have a Vendor ID of “0bb4″.

Here is how to set up some of the major Android phones:

Step 1. Enable Unknown sources and USB debugging:

Go to Settings -> Applications and check the Unknown sources check-box, then go to Development and enable the USB debugging.

Step 2. Depending on your phone follow these instructions:

• G1
  Create/edit a file in /etc/udev/rules.d called 51-android.rules:

  $ sudo gedit /etc/udev/rules.d/51-android.rules

  Add the following line to it and save it:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”0bb4″, ATTRS{idProduct}==”0c01″, MODE=”0666″

• HTC Hero

  Add to the file (or create it if it does not exist- see above) /etc/udev/rules.d/51-android.rules the following line:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”0bb4″, ATTRS{idProduct}==”0c02″, MODE=”0666″

• HTC EVO

  Add to the file (or create it if it does not exist- see above) /etc/udev/rules.d/51-android.rules the following line:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”0bb4″, ATTRS{idProduct}==”0c8d”, MODE=”0666″

• HTC EVO Shift

  Add to the file (or create it if it does not exist- see above) /etc/udev/rules.d/51-android.rules the following line:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”0bb4″, ATTRS{idProduct}==”0ca5″, MODE=”0666″

• HTC ThunderBolt

  Add to the file (or create it if it does not exist- see above) /etc/udev/rules.d/51-android.rules the following line:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”0bb4″, ATTRS{idProduct}==”0ca4″, MODE=”0666″

• LG OPTIMUS LG-P506

  Add to the file (or create it if it does not exist- see above) /etc/udev/rules.d/51-android.rules the following line:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”1004″, ATTRS{idProduct}==”618e”, MODE=”0666″

• Motorola Xoom

  Add to the file (or create it if it does not exist- see above) /etc/udev/rules.d/51-android.rules the following line:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”22b8″, ATTRS{idProduct}==”70a9″, MODE=”0666″

• Motorola Droid
  Create/edit a file in /etc/udev/rules.d called 10-motorola-droid.rules:

  $ sudo gedit /etc/udev/rules.d/10-motorola-droid.rules

  Add the following line to it and save it:

  SUBSYSTEMS==”usb”, ATTRS{idVendor}==”22b8″, ATTRS{idProduct} ==”41db”, MODE=”0600″

• Nexus One
  Create/edit a file in /etc/udev/rules.d called 99-android.rules:

  $ sudo gedit /etc/udev/rules.d/99-android.rules

  Add the following line to it and save it:

  SUBSYSTEM==”usb”, ATTRS{idVendor}==”18d1″, SYMLINK+=”android_adb”, MODE=”0666″

Step 3. Restart udev:

$ sudo restart udev

Check if the device is recognized:

$ adb devices

You may need to stop and start the adb server:

$ adb kill-server
$ adb start-server

Update: Please note that some devices require to disconnect the usb cable at this point and then reconnecting it.

You should be good to go…