One code base, two applications on Android

Written by on October 1, 2010, 10:19 am

It was my understanding that application package name and the internal java package names in your Android project were distinct. Application package names need to be globally unique, internal package names can be whatever the hell you like. So, if you are using the same code base (with various resources) to build multiple applications, this all should be fairly painless ... you would think.

Turns out, this is a massive pain in in the arse. If you change the package attribute for the manifest element in your AppilcationManifest.xml (this is the application package name, the one that needs to be unique) to something other than the package containing your Application object, you will quickly enter a world of hurt. In my case I am trying to use net.cannonade.glossary for my internal java package name and net.cannonade.ballet for my application package name.

As this post notes, once you change the application package name you will discover that all your source files will compain because they can no longer locate the resources that they were previosly getting from net.cannonade.glossary.R.

At this point I probably should have stopped. If I am writing script to run through all my source and modify code from net.cannonade.glossary to net.cannonade.ballet, then my ideal of having generic source and application specific resources seem unattainable. But I had commited to trying to figure this out, so I stumbled blindly onward.

So you go through all your source files and add:

import net.cannonade.ballet.R;

This resolves all the compile errors because my application classes can now find the generated resource files. Seems painfull, but all working so far. In fact, I run the app at this point and it all seems to work fine.

Everything was not as it seemed. It seems Eclipse gets very confused about which app it is debugging if there are any previously installed apps on the emulator (with different appilication package names). So it seemed like it was working fine, because it was running my previous build with the old package name. So you need to start fresh and delete those old binaries from the emulator. To do this you need to dig through a alarming number of settings screens:

Application Screen/Settings/Applications/Manage Applications/app/uninstall/OK/OK

Snarky side note - To do this on the iPhone, I would have to:

long press app/X/OK

Ok. So once I figured this out and was debugging the right binary, I discovered a problem that I have not been able to figure out.

When I need to show a new activity in my app, I use the following piece of code:

Intent newIntent = new Intent(); newIntent.setClassName("net.cannonade.glossary", "net.cannonade.glossary.GlossaryRoot"); startActivity(newIntent);

The first time I do this is from my android.intent.category.LAUNCHER activity, My splash screen code just shows my company logo for a short timeout and then starts my root activity (using the code above).

Another snarky side note - To do this in XCode, create default.png

My problem is that startActivity throws an ActivityNotFoundException:

Unable to find explicit activity class {net.cannonade.glossary/net.cannonade.glossary.GlossaryRoot}

My intial thought was that, as a result of the changed application package name, the package name was different in some way. I thought the best way to determine what the new package name/class name should be is to update my application manifest to use GlossaryRoot as my android.intent.category.LAUNCHER activity and then check what those two strings should be by querying them from the loaded activity in the onCreate method:

String thisPackage = this.getClass().getPackage().getName(); String thisClass = this.getClass().getName();

So my app loads up with GlossaryRoot as the new LAUNCHER activity and I expected the thisPackage and thisClass variables to contain something other than net.cannonade.glossary and net.cannonade.glossary.GlossaryRoot respectively.

To my dismay I discovered that when queried from the launched activity, the package name and class name matched what I was passing into my intent at run time. So basically if the Activity is loaded based on the manifest LAUNCHER attribute, it is fine. If I try and load it at run time, with exactly the same package name and class name, it fails to find the activity.

I am stuck and have decided, given that I have to modify all my source anyway, I will just update my script to use net.cannonade.ballet everywhere. When I need to ship a new app with different resources, I will update my script to change it to that new package name.

So perhaps I am doing something fundamentally wrong here. Perhaps there is simple way of getting around this problem. If there is an Android gronk out there with some answers, I would love to hear from you.

Permalink - Tags: Development,Android