I have a paid application on the android marketplace, however, I want to release a free ad-supported version.

The easiest way I thought to do this was to set up a branch on my subversion repository that has the additional code to add the ads. However, when I went to submit this to the android marketplace, they require unique package names. This solution no longer works for me because I'd have to change the package of every class file, which would make merging the trunk and branch very painful.

What is the best way I can keep these two projects together, sharing patches, but with a different package?

  • 1
    Just a note that this question is not off topic here on Programmers. The primary issues are about project structure and configuration management issues, both of which belong here (and not on Stack Overflow or any other site).
    – Thomas Owens
    Apr 18 '12 at 19:01

Have you considered compiler directives?


#define FREE
// ...
#if FREE
Console.WriteLine("Free version");
Console.WriteLine("Paid version");

You can keep the exact same code base and target the two builds using two separate build scripts or a parametrable one.

msbuild /p:DefineConstants=FREE

To do it with Java, read this and this. And maybe this.

  • I didn't think Java listened to those things
    – Malfist
    Apr 18 '12 at 14:29
  • It does exist in Java too.
    – user2567
    Apr 18 '12 at 14:39
  • @Pierre303 I'm sorry, I didn't know you could do that. It still doesn't solve the package problem though....hmmm.
    – Michael K
    Apr 18 '12 at 14:46
  • 1
    @MichaelK: this is easily achievable with a well organized find and replace task in your build script.
    – user2567
    Apr 18 '12 at 15:02
  • This doesn't solve the problem of conditional resources in the /res folder either.
    – donturner
    Aug 28 '12 at 15:09

Only your application package must be unique. See here. That's the package declared in your manifest file. You can have most of your code in com.mydomain.myapp, and just have a different main activity in com.mydomain.myapp.free.


If you really want to do separate, the best way is to set it up as two parts of the same repository. That way you can at least merge changes across the different branches. If you want to keep things completely separate then you will be doing alot of schlepping patch files.

I've done this and frankly it isn't a great strategy in practice. Much better, especially in compiled environments, is to have a separate build process for free versus paid so there is one codebase rather than two. If there are two codebases things will diverge.

  • That's the thing, I don't want them separate. The only thing separate I want is the additional code that adds the ads. However, android forces me to have a unique package name for my app. So I'd be forced to have a greater change than just two or three files.
    – Malfist
    Apr 18 '12 at 14:30
  • Perhaps, a little precompiler voodo should work too. Build systems are awesome things. Apr 18 '12 at 17:23

Version control is a poor way of managing things like this. You'll end up with a maintenance nightmare - two separate applications that need to be almost identical.

Have you considered a multiple project solution? (caveot: I haven't actually done this, but it seems feasible, and I think Android will allow it. I'll try it later and see for sure.) Compile all your app code into a main project jar. Then create two separate Android apps, one for your paid version, and one for the free version. This will solve your package naming problem. These apps will just delegate to the main jar for pretty much everything, except that your ad version will include the code to support the ads.

You may also find this discussion on a similar topic interesting.

  • The code is a small part of the full picture, and JARring it up doesn't help deal with all of the additional data like resources, layouts, assets, etc. that goes along with it. That you can't bundle everything up neatly is an unfortunate shortcoming in Android, and it pains me to have to rubberstamp things that don't change much or can be configured from outside.
    – Blrfl
    Apr 18 '12 at 22:23
  • I agree. They did a great job of making it easy to build small apps but difficult to build large ones that need maintenance. There are some Maven solutions that look promising, but I haven't been able to explore them too much yet.
    – Michael K
    Apr 19 '12 at 12:09

Building your app using a feature toggle would allow you to reach your objective but you might have to rework a lot of code.

By defining 2 (I would recommand 3) feature container environment in a .ini file like :

features.ads = false
features.featureOne = true
features.featureTwo = true
features.premiumFeature = true
features.underDevFeature = false
features.debug = false;

features.ads = true
features.premiumFeature = false

; And the optionnal third
features.debug = true
features.underDevFeature = true

This way, you have a version that that is uniform and require only one branch in your version control source

In your specific scripts you then have to check if the feature is authorized, if not, you dont display it

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.