dimitar.me

How to Switch your Google Checkout Account in the Android Market Application

With Google’s last update of the Market application on the Android devices, it became a lot easier to now switch your Google Checkout account associated with all your application purchases.

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.

How to sign an unsigned Android package (.apk file)

If you develop with Eclipse, you most likely use the built in Export Wizard to export and sign your Android applications.

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.

Eclipse Project is Flagged with an “Android Packaging Problem” Error

Sometimes while developing in Eclipse you will notice that the Android Project will be flagged with the red “x” but none of your source files or resources will have errors. If you look in the “Problems” tab you will notice that the project is flagged with an “Android Package Problem” type and the “Location” will be Unknown.

To fix this, just do:

Project->Clean

This will rebuild the project from scratch.

Android Version 2.2.2 Prevents Applications with Copy Protection Turned on from Displaying in the Market

Today I got the Over the Air update of my Nexus One phone to version 2.2.2. To my surprise I could not see some of my applications that were published in the Android Market. Neither could I see a big chunk of the total applications in the Android Market.

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.

Android – Displaying Dialogs From Background Threads

Having threads to do some heavy lifting and long processing in the background is pretty standard stuff. Very often you would want to notify or prompt the user after the background task has finished by displaying a Dialog.

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;
    }
  }
};