Problems installing and/or launching Android apps

Sometimes you try and launch your Android application from Oxygene for Java and nothing much happens. Sometimes you the application builds successfully and then nothing appears on the device. Sometimes you go to choose a target device to deploy to and none are listed. There are many of these sort of problems, which often have very simple solutions.

When building Android apps with any development tool, be it Oxygene for Java, C# and Mono for Android or Java and Eclipse, there are a lot of different tools trying to work together to produce the results you want. In the case of Oxygene for Java we have Microsoft’s Visual Studio, RemObjects’ Oxygene for Java compiler, Google’s Android SDK tools and Oracle’s Java tools. All different tools, of various versions from different software companies. Sometimes tools from different vendors don’t play well together.

For most of the problems I mention above i find the commonest cause is that the Android Debug Bridge (adb) daemon has gone ‘stale’. You can try a quick remedy by bringing up a command prompt and running these commands:

adb kill-server
adb start-server

Then try what you were trying before and see if that improves matters. Note that you’ll need the Android SDK’s platform-tools directory on your path to run the command without fully-qualifying the call to adb.exe.

If that doesn’t fix the problem then you should resort to the Android logs to see if there are any clues, for example, in the case of an application not installing on a device or emulator.

You can see the logs either by using:

adb –d logcat

or by running DDMS from the Android SDK and selecting the appropriate device.

During the attempt to install your app there will be log messages showing the progress and when the failure occurs you should see some sort of error message and maybe a call stack to assist working out what’s wrong.

Additionally, if you install your app from the command-line (as opposed to your IDE) you will often see an error code printed, which you can look for advice on with an Internet search. The error code is the name of a static field from the PackageManager class, albeit one that won’t be listed in the Android SDK documentation You can, however, find them in the Android source.

A command-line install looks like this

adb –d install –r mypackage.apk

The –r switch requests a reinstall, which preserves app data such as databases. If that is not important, skip the –r from the command.

For example, if you messed up the details of a certificate the app was signed with, you might get this:

Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]

or perhaps this:

Failure [INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES]

Searching the Internet will tell you that during the package manager’s verification process it couldn’t verify your package was suitably signed – perhaps because the certificate was in error, or maybe because you are using JDK 7 and haven’t worked out how to work with it’s set of new default values that affect harmonious Android development (I’ve written about this issue as it cropped up in this article).

Sometimes a small change in the application, like updating the package name or altering the signing process (i.e. changing the package’s signature), will mean an application can’t be re-installed over a previous version.

Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE]

You can easily deal with this by forcibly uninstalling the prior version, again using adb. If your app’s package is called org.me.myapp and is on a physical device, you’d use:

adb –d uninstall org.me.myapp

Change the -d switch to a -e if using an emulator instead.

I’ve been quite surprised how many times rather annoying issues have been deftly resolved by simply restarting the adb daemon, or uninstalling an old version of an app that was ‘getting in the way’ of a new version being installable.

One other point to mention before ending is that DDMS is a great log viewing tool, but it acts as a debugger. If you have it running and then try to launch an application for debugging from Oxygene for Java, you won’t get very far as DDMS will already have set itself up as the primary debugger. To debug, you must first close DDMS, which isn’t a great loss – the Oxygene debugger does have a logcat window that shows the same logging information as DDMS does.