This is only a temporary workaround and not a real fix.

After having this happen to me and not being pleased with the current responses I went to worktrying to figure it out from the AOSP source. I have found a REAL solution.

Explanation

First off, a bit of (simplified) background on how Android installs and updates

The first time an app is installed:

1. The APK file is saved as

   /data/app/<full.package.name>-1.apk  (1.apk)

When the app is to be updated:

1. The updated APK file is saved as:

   /data/app/<full.package.name>-2.apk (2.apk)

2. The first version (1.apk) gets deleted.

On our next update(s):

1. The new APK is saved as (1.apk) and (2.apk) is deleted (Repeat forever).

The issue that most of us are having happens when the application is updated, but deleting of the old APK fails. Which itself does not yet cause the update to fail, but it does cause there to be two APK files in /data/app.

The next time you try to update the app the system can't move its temporary file because neither (1.apk) nor (2.apk) are empty. Since File#renameTo(File) doesn't throw an exception but instead returns a boolean PackageManager, it doesn't have any way to tell why it returns INSTALL_FAILED_INSUFFICIENT_STORAGE even though the failure had nothing to do with the amount of free space.

Solution

Run:

adb shell "pm uninstall <full.packge.name>"adb shell "rm -rf /data/app/<full.package.name>-*"

OR

Uninstall the app

Use your favorite method to delete BOTH:

/data/app/<full.package.name>-1.apk

/data/app/<full.package.name>-2.apk

Make sure nothing else blocks future installs in a similar way. In my case I had a /data/app-lib/<full.package.name>-1 directory lingering around! In this case, an install to the SD card worked, and a subsequent move to internal memory, too. (Creating /data/app-lib/<full.package.name> without the -1 ending.)

Why other "solutions" worked

• The code for installing to external storage is significantly different which does not have the same problems

• Uninstalling the app only deletes one version of the APK file in /data/app. That's why you can reinstall it once, but not update it.

• The amount of free space in an emulator isn't really relevant when this bug occurs

You need to increase the Android emulator's memory capacity. There are two ways for that:

1. Right click the root of your Android Project, go to "Run As" and then go to "Run Configurations...". Locate the "Android Application" node in the tree at the left, and then select your project and go to the "Target" tab on the right side of the window look down for the "Additional Emulator Command Line Options" field (sometimes you'll need to make the window larger) and finally paste "-partition-size 1024" there. Click Apply and then Run to use your emulator.

2. Go to Eclipse's Preferences, and then select “Launch” Add “-partition-size 1024” on the “Default emulator option” field. Click “Apply” and use your emulator as usual.

Thanks for posting this question. I have some additional insights that may help some developers.

I am debugging my application on a device (not the emulator). The device has 21 MB free on /data (as revealed by "df" when doing "adb shell") and my app is only 5 MB. However, I did find that if I deleted other apps on the device (without rebooting the phone or restarting adbd), INSTALL_FAILED_INSUFFICIENT_STORAGE would go away for a while and then come back.

So it seems that debugging my 5 MB app requires more like 20 MB of space in /data, and in addition something was leaking each time I debugged my app.

So I did "adb shell" and listed the ENTIRE /data directory with

cd /datals -a -l -R

And I looked at the 5000-line output to see where all the space was going.

I discovered vast quantities of wasted space on my device in the /data/klog directory in the form of old log files from months-old debugging sessions.

These were not my log files: they were created by some part of the Android infrastructure.

I deleted them and instantly saved 58 MB which was not attributed in the Settings app to any particular app. I have a small device so 58 MB is very significant (about 40%).

So far, I have not gotten INSTALL_FAILED_INSUFFICIENT_STORAGE again after many runs. Let's hope that was the real issue, though the OP suggests that his device had plenty of space (but didn't say how much).

Hopefully some of you will also be able to escape INSTALL_FAILED_INSUFFICIENT_STORAGE by periodically deleting /data/klog/*.

Or, you can at least do the ls -a -l -R in /data to see where all your space is going, if indeed there is really some (hidden) space issue.