Android – how to deploy multiple versions of the same app – Mea Cup O' Jo
Skip to content


Android – how to deploy multiple versions of the same app

So you have paid and free version of the same app and you want to deploy both to the Android Market (AM). There you’ll have a nasty surprise – AM wants to identify your app by its package and you will have to move one of the versions to the another package. I had to do it for my DroidIn app so here’s least painful way of doing it that I could come up with:

Let say you have your paid version in com.foo.widget and you want your free app to be in com.foo.widget.free

  1. Deploy your paid version to the AM
  2. Come back to your code and open Android manifest
  3. Change <manifest package=”com.foo.widget”/> to <manifest package=”com.foo.widget.free”/>
  4. Save it – and you will be horrified with all errors in your project at this point
  5. The most important thing from this point on – you will no longer be able to refer to your activities and services by a shortcut in the manifest file. The example of shortcut? Here – <activity android:name=”.HOME”/>
  6. You will have to refer to these by full package name so the element above will look like <activity android:name=”com.foo.widget.free.HOME”/>
  7. Save the manifest again. Now your R generated file will appear in the new package (ROOT/gen/com.foo.widget.free.R.java)
  8. Which means you will have to go to your activity(s) source file, or any file that refers to R.class and change import statement(s) to look at the new location. The more files you have, the more painful that will be, of course.
  9. When you no longer have compilation errors change @string/app_name to reflect free version and you ready to package and deploy

If you know of easier way of achiving the same result – please let me know, I would love to hear it

Posted in Android.


10 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. sdelmont says

    I was going down the same route of using a "sub-package name" for different releases, and ran into the same issue with the R class.

    My fix was to add an R.java file at the com.foo.widget level, copy the contents of the generated com.foo.widget.free.R.java file and change the package name.

    The only inconvenience is that whenever I add a new resource, the Eclipse plugin updates the generated file automatically, but I have to remember to copy the contents again.

    Still, it's way easier this way, since resources are not changed that often, and if you forget to copy the generated changes, you get a compiler error (most of the time).

  2. droidin says

    I can see that. What helps me is not to have anything that refers to R in the top folder. Then I can do global search/replace on import com.foo.R. Since I only do that in the Lite release branch and I never do my development on any release branches it works out well enough

  3. fiverings says

    My fix was to create a package with the same name as the pro version and then put a Feature class in that. The Feature class contains only the constants controlling the behaviour of the application eg:

    package com.foo.pro
    public class Feature {
    public static final boolean DUMMY = true;
    public static final boolean USE_ADVERT = true;
    }

    This way, it doesn't matter what the application package is called, there is always a package with the pro namespace in it. This way when you change the application package name to com.foo.lite, the compiler is still happy.

    If there's a class that doesn't make a reference to the Features class, I add in a new constant referencing the DUMMY constant to make sure I don't accidentally remove the namespace.

    The only problem with this is you get warnings in the source code about unused namespaces which I can't seem to get rid of. But other than that, I just have to change the package name and set the available features and the app compiles either way.

    • droidin says

      Thank you

      • jkhlk says

        what do u mean by reflect on @string/app_name

        • droidin says

          Only that you may want to change default title of your app to reflect "Lite" version. E.g. if you app_name=Foo you may want to change it to app_name=Foo Lite

  4. Brian Cooley says

    If you are using Eclipse, you can click on the package name in the src folder and then select Refactor>Rename from the menu to fix all the broken references.

  5. sbh says

    Is this simply an old post, or is there a reason that breaking the core code out into a library is not recommended? This was my solution, and as far as I can tell it works fine. I have two very small launcher Activities with distinct name spaces and then all the common code is in the library.

  6. droidin says

    Indeed. At the time of writing library option wasn't available

  7. Manojr Tiwari says

    This doesn't work for all apps.



Some HTML is OK

or, reply to this post via trackback.