Things got even more interesting after the release of Honeycomb! All of a sudden the code that was fetching Picasa images and was working flawlessly started failing on devices running OS 3.0 and up. After some investigation I found the culprit- Google changed the URI returned when the user was selecting a Picasa image. This change was completely undocumented, or at least I could not find any documentation on this! So, on devices running Android OS prior to 3.0 the URI returned was an actual URL and now on devices running OS 3.0 and higher, the URI returned had a different format. For example:

1. https://lh4.googleusercontent.com/… (URI returned on devices running OS prior to 3.0)
2. content://com.google.android.gallery3d (URI returned on devices running OS 3.0 and higher)

I posted a brief solution on the official Android bug report site, but I will expand on it here.

In order to properly handle fetching an image from the Gallery you need to handle three scenarios:

1. The user selected a local image file
2. The user selected a Picasa image and the device is running Android version prior to 3.0
3. The user selected a Picasa image and the device is running Android version 3.0 and higher

Let’s delve straight into the code:

1. Start the Image Picker:

private static final int PICTURE_GALLERY = 1;
Intent photoPickerIntent = new Intent(Intent.ACTION_PICK, android.provider.MediaStore.Images.Media.EXTERNAL_CONTENT_URI);
startActivityForResult(photoPickerIntent, PICTURE_GALLERY);

In the first line above I am passing a URI to the intent because I would like to fetch the full image, not just get a Bitmap with the thumbnail. The Android team did a good job of acknowledging that if you just wanted a thumbnail of the image then you can get back a Bitmap object containing it, since a thumbnail would not be that big in size. But if you wanted the full image, it would be foolish to do the same, since that would take up a big chunk of the heap! So, what you get instead is some data about the image file, among which is the path to it.

2. We need to implement the onActivityResult method that will be called when the user closes (picks the image) the Image Gallery application:

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent intent) {
	super.onActivityResult(requestCode, resultCode, intent);
	switch (requestCode) {
		case PICTURE_GALLERY:
		if (resultCode == RESULT_OK && intent != null) {
			Uri selectedImage = intent.getData();
			final String[] filePathColumn = { MediaColumns.DATA, MediaColumns.DISPLAY_NAME };
			Cursor cursor = getContentResolver().query(selectedImage, filePathColumn, null, null, null);
			// some devices (OS versions return an URI of com.android instead of com.google.android
			if (selectedImage.toString().startsWith("content://com.android.gallery3d.provider"))  {
				// use the com.google provider, not the com.android provider.
				selectedImage = Uri.parse(selectedImage.toString().replace("com.android.gallery3d","com.google.android.gallery3d"));
			}
			if (cursor != null) {
				cursor.moveToFirst();
				int columnIndex = cursor.getColumnIndex(MediaColumns.DATA);
				// if it is a picasa image on newer devices with OS 3.0 and up
				if (selectedImage.toString().startsWith("content://com.google.android.gallery3d")){
					columnIndex = cursor.getColumnIndex(MediaColumns.DISPLAY_NAME);
					if (columnIndex != -1) {
						progress_bar.setVisibility(View.VISIBLE);
						final Uri uriurl = selectedImage;
						// Do this in a background thread, since we are fetching a large image from the web
						new Thread(new Runnable() {
							public void run() {
								Bitmap the_image = getBitmap("image_file_name.jpg", uriurl);
							}
						}).start();
					}
				} else { // it is a regular local image file
					String filePath = cursor.getString(columnIndex);
					cursor.close();
					Bitmap the_image = decodeFile(new File(filePath));
				}
			}
			// If it is a picasa image on devices running OS prior to 3.0
			else if (selectedImage != null && selectedImage.toString().length() > 0) {
				progress_bar.setVisibility(View.VISIBLE);
				final Uri uriurl = selectedImage;
				// Do this in a background thread, since we are fetching a large image from the web
				new Thread(new Runnable() {
					public void run() {
						Bitmap the_image = getBitmap("image_file_name.jpg", uriurl);
					}
				}).start();
			}
		}
		break;
	}
}

3. Implement the getBitmap method, which will download the image from the web if the user selected a Picasa image:

private Bitmap getBitmap(String tag, Uri url)
{
	File cacheDir;
	// if the device has an SD card
	if (android.os.Environment.getExternalStorageState().equals(android.os.Environment.MEDIA_MOUNTED)) {
		cacheDir=new File(android.os.Environment.getExternalStorageDirectory(),".OCFL311");
	} else {
		// it does not have an SD card
	   	cacheDir=ActivityPicture.this.getCacheDir();
	}
	if(!cacheDir.exists())
	    	cacheDir.mkdirs();

	File f=new File(cacheDir, tag);

	try {
		Bitmap bitmap=null;
		InputStream is = null;
		if (url.toString().startsWith("content://com.google.android.gallery3d")) {
			is=getContentResolver().openInputStream(url);
		} else {
			is=new URL(url.toString()).openStream();
		}
		OutputStream os = new FileOutputStream(f);
		Utils.CopyStream(is, os);
		os.close();
		return decodeFile(f);
	} catch (Exception ex) {
		Log.d(Utils.DEBUG_TAG, "Exception: " + ex.getMessage());
		// something went wrong
		ex.printStackTrace();
		return null;
	}
}

The decodeFile method takes a reference to a file and returns a Bitmap. This is pretty trivial. In my case I also scale down the image as I am reading it from the file, so it does not take much memory.

I think Google has some work to do about all this and if they want to seamlessly integrate Picasa with the Android Gallery application, they should have done a better job with the Image Picker functionality. The developer should not be doing all this heavy lifting and be concerned with where the actual image resides. The returned URI should be exactly the same no matter if the image is local or not. And if it is not local, the Gallery app should be fetching it for us. That way, we will have a consistent and predictable functionality. Right now you will be surprised how many applications out there do not handle Picasa images and crash with an ugly error.

I personally do not like this. So I just disable that feature. And while I am at it, I also enable the ruler, which displays the line number and the character position of the cursor.

To do that for all users, edit the /etc/vim/vimrc file add the following lines to it:

syntax off		" Clear any font/color/hilighting
set ruler		" Enable the ruler

If you want to do that just for a particular user, create a .vimrc file in that user’s home directory (if it does not already exist) and add the same lines to it.

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.

Check the compatibility of your wireless NIC first.
To find out what kind of chipset you have, run:

lspci | grep -i wireless

The ath9k driver is present in any kernel starting with version 2.6.27. The oldest supported ath9k version comes with kernel 2.6.32. That means most likely you already have the driver and there is no need to download it, all you have to do is enable it.

The general steps in order to enable ath9k are:

1. Get the kernel source and some necessary packages
2. Configure the kernel
3. Compile and install the kernel
4. Configure grub to boot from the new kernel image

Some steps might sound a bit intimidating, but actually they are very easy to do.

Since you will be running a lot of commands as root, it would be more convenient to open a bash shell as root instead of preceding all commands with sudo. The easiest way to do this is to run the following command it terminal:

$ sudo bash

Note: The above command has nothing to do with enabling the root login. I strongly recommend to never enable the root login due to serious security risks! Some blogs might ask you to do that, but there is hardly ever any reason to do this.

1. Get the kernel source and some necessary packages

# aptitude install git-core build-essential kernel-package qt3-dev-tools libqt3-mt-dev fakeroot
# apt-get install linux-source 

The above command downloaded the kernel source tarball in /usr/src.
In my case the kernel version I am working with is 2.6.32 (patch level 15). Replace these numbers with the version of your kernel source.
Now lets cd to the place we downloaded the kernel source:

# cd /usr/src

Uncompress and extract the kernel source:

# tar xjvf linux-source-2.6.32.tar.bz2
# cd linux-source-2.6.32

2. Configure the kernel

Before configuring the kernel, lets import the configuration of the currently running kernel. This way we do not miss to enable something we currently have and need:

# cp -vi /boot/config-`uname -r` .config

Now we are ready to add a few configurations to the kernel:

# make xconfig

This opens up an xwindow with a hierarchical structure representing the kernel settings:

Linux Kernel Configuration

First enable mac80211:

Networking  --->
  Wireless  --->
     Improved wireless configuration API
     Generic IEEE 802.11 Networking Stack (mac80211)

You can then enable ath9k in the kernel configuration under:

Device Drivers  --->
  [*] Network device support  --->
        Wireless LAN  --->
             Atheros 802.11n wireless cards support

If you re-used the existing configuration, note that Ubuntu kernels build with debugging information on, which makes the resulting kernel modules (*.ko files) much larger than they would otherwise be. To turn this off, go into “Kernel hacking”; then, under “Kernel debugging”, turn OFF “Compile the kernel with debug info”.

Save changes and exit.

3. Compile and install the kernel

First, let’s ensure a “clean” build:

# make-kpkg clean

Since the kernel compilation might take some time, it is best to set the CONCURRENCY_LEVEL variable, so that it can take a full advantage of the multiple processors or mulitple CPU cores on the machine. The CONCURRENCY_LEVEL variable is equal to the number of processors on the machine plus one. So if your machine has a dual core processor the variable will be equal to 3. To find out how many processors or cores your computer has run:

# lshw -C CPU

In my case I get cpu:0 and cpu:1, which means that I have a dual core processor.
Besides the CONCURRENCY_LEVEL, the only other thing we need to pay attention to here is the “–append-to-version” option. It basically adds that string to the end of the kernel name and could be set to anything. That gives you the opportunity to put there something meaningful to distingush the kernel from the other ones. In this case I called it “-mykernel”.

Now you are ready to compile:

# CONCURRENCY_LEVEL=3 fakeroot make-kpkg --initrd --append-to-version=-mykernel kernel-image kernel-headers

If you want to see the ubuntu splash screen (or use text mode) before you get to X instead of just a black screen, you’ll want to make sure the framebuffer driver loads:

# echo vesafb >> /etc/initramfs-tools/modules
# echo fbcon >> /etc/initramfs-tools/modules

Now install the kernel and the headers from the created Debian packages:

# dpkg -i linux-image-2.6.32.15+drm33.5-mykernel_2.6.32.15+drm33.5-mykernel-10.00.Custom_i386.deb
# dpkg -i linux-headers-2.6.32.15+drm33.5-mykernel_2.6.32.15+drm33.5-mykernel-10.00.Custom_i386.deb

Now let’s generate an initramfs (initrd) image, that will be loaded up by grub on boot:

# cd /boot

To avoid confusion with the next command, here is what my /boot directory contains before I run the mkinitramfs command:

# ls -altr
total 27700
-rw-r--r--  1 root root  160280 2010-03-23 05:37 memtest86+.bin
-rw-r--r--  1 root root 4034976 2010-08-20 14:22 vmlinuz-2.6.32-24-generic
-rw-r--r--  1 root root 1689036 2010-08-20 14:22 System.map-2.6.32-24-generic
-rw-r--r--  1 root root  115905 2010-08-20 14:22 config-2.6.32-24-generic
-rw-r--r--  1 root root  651618 2010-08-20 14:22 abi-2.6.32-24-generic
-rw-r--r--  1 root root    1196 2010-08-20 14:24 vmcoreinfo-2.6.32-24-generic
drwxr-xr-x 22 root root    4096 2010-09-04 15:27 ..
-rw-r--r--  1 root root       0 2010-09-07 22:11 initrd.img-2.6.31-wl
-rw-r--r--  1 root root 7977082 2010-09-07 22:49 initrd.img-2.6.32-24-generic
-rw-r--r--  1 root root  115845 2010-09-08 02:13 config-2.6.32.15+drm33.5-mykernel
-rw-r--r--  1 root root 3999488 2010-09-08 07:38 vmlinuz-2.6.32.15+drm33.5-mykernel
-rw-r--r--  1 root root 1644782 2010-09-08 07:38 System.map-2.6.32.15+drm33.5-mykernel
drwxr-xr-x  3 root root    4096 2010-09-08 16:01 .

Run the mkinitramfs to generate the initrd:

# mkinitramfs -k -o initrd.img-2.6.32.15+drm33.5-mykernel 2.6.32.15+drm33.5-mykernel

4. Configure grub to boot from the new kernel image

# update-grub2

The last thing to do is to ensure that the ath9k module loads on boot. That will avoid running modprobe ath9k after each reboot.
So lets add the line ath9k to the end of the /etc/modules file:

# echo ath9k >> /etc/modules

Now reboot your computer and chose the new kernel to boot into from the grub menu.

Your wireless NIC should be working now using the ath9k driver.

• I’d like to thank Jeff Rall for letting me work with him on this on his computer!
• The Linux Wireless Community
• Ubuntu Kernel Compile
• How to install the development version of atk9k

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

The program is called exiftool. So let’s install it first.

In terminal execute:

sudo apt-get install libimage-exiftool-perl

Now you are ready to start changing the meta-data of the images.

For example, if I wanted to change all the dates and times (DateTimeOriginal, CreateDate and ModifyDate) of the IMG_01.jpg file to the 8th of August 2010 at 3:35:33 PM I would do:

exiftool -AllDates='2010:08:08 15:35:33' -overwrite_original IMG_01.jpg

If I wanted to change the dates on all the files in the “images” directory, I would do:

exiftool -AllDates='2010:08:08 15:35:33' -overwrite_original images

The “-overwrite_original” option is necessary if you want to change the meta-data of the original images. If you omit that option, then exiftool will back-up the originals by making a copy of them and adding “_original” to the end of the file names.

If you want to change the dates to all the files in the “images” directory that were taken by a Cannon camera (and not touch the rest) I would do:

exiftool -AllDates='2010:08:08 15:35:33' -if '$make eq "Canon"' -overwrite_original images

As far as changing dates and times, there is another option of exiftool that lets you do time calculation.

For example, the other day I found out that my camera’s time was correct but the date was ahead by 30 days. That meant that all the photos I had taken lately had dates that were off by exactly 30 days. If I were to use the above examples I could set the dates individually (which would be a long and tedious process) or set all the images to the same date and time (which would be wrong). In this case I used the date calculating option and just executed:

exiftool -AllDates-=720:00 -overwrite_original images

That command subtracts 720 hours (30 days) off the dates of each image file in the images directory. Now every image has the exact date and time it was taken.

I have only scratched the surface of what this tool is capable of. For more information look at the man pages of the exiftool command.

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.