Open source, coffee and us….


Managing free and paid Android applications

The way applications are managed in the Android marketplace has an impact on how you organise your code for an application that you want to present in free and paid formats.

Essentially an application is identified by its package name and it is not possible to use the same package name for both a free and paid for version. This rules out the option of using within the package some internal flag to represent the paid or free status and then switching features on or off depending on that status.

Therefore the very first question you have to ask yourself is do you want a free version and a paid for version of your application. If not, then life is somewhat easier because you have to simply decide to offer it for either one or the other.

If you do want to offer both versions then you obviously need to decide what will differentiate the two versions – typically the free version will be ad supported and / or have a reduced feature set.

So what to do?

The crudest approach to solving this problem is to clone the whole project and then maintain two separate projects, and allow the two versions diverge as much as you want.
This will work, but will give you loads of headaches down the line when you have to start applying fixes, enhancements etc in two places. That unwritten law that states if it can go wrong it will, means that at some point you will forget to do something in one of the versions and it may not become apparent for some time. You will then spend some effort trying to work out which version has the latest good copy of code and then syncing it all up again. If you are happy to go that route then good luck.

Another approach is to use a single copy of code and then manually tweak package names, resources etc at release time.
As a manual exercise this is not trivial if you have a large application, therefore it is possible to make use of ant, and develop a script which will do all of this for you. An example of that approach can be found here

There may be other approaches, but here I will describe the approach we used which makes use of the Android library facility.  Note that it is not possible to deploy an apk from a library project.

The main steps are as follows (see notes below for specific details) :

  • develop main project in Eclipse – package name net.myPackage.application
  • when ready to create the paid and free versions do this:
  • change the main project to a library project
  • create a new empty android project for the paid version net.myPackage.applicationPaid
  • create a new empty android project for the free version net.myPackage.applicationFree
  • each of these new projects is then set to refer to the main library project
  • copy the manifest content (but not the manifest header which contains the package name) from the library project to each of the new projects just created – this is because the new projects do not override or pick up the manifest information from the library project.

So what does this give us:

  • we have a common project where all of the main code and resources are kept – leading to a single maintenance point for the majority of  the application
  • any resources used in the code which are not defined in the paid or free versions of the projects will pick up the content from the library project. The implication of this is that if we wish to create a version specific resource we simply create it with the same name in either of the free or paid versions and it will use that rather than the library version.
  • therefore the free and paid for versions of the application are used simply to override resources where needed – easy to maintain.
  • possible to have a boolean resource indicating paid or free status which can be tested by code in the library project and features switched on or off accordingly. Normally the library project would have the the default paid status value of the resource, and the free version would override it to the free value.
  • the paid and free versions can be deployed and tested using the normal methods


  • Do as much development in your main project as possible before switching it to a library version. A library version cannot be deployed as an apk and therefore any changes made after the switchover would  have to be tested with the paid and/or free version (depending on nature and extent of the change).
  • The names used in the manifext.xml of the main project which will later become the library project need to be fully specified so that they can be found from within the paid and free versions.
    ie normally one would have something like


and this should now be


  • To convert a project into a library project, use eclipse Project Properties / Android and tick the isLibrary box
  • To refer to the library project from the paid and free project versions, again use Project Properties / Android and in the Library section select the Add button and then select your Library version.
  • Remember to change the application name in the paid and free versions to make them identifiable once they are installed on a device – not good if your user can’t tell them apart in the application manager.
  • One area which will involve changes to all three projects is if you make changes to the manifest.xml ie introduce new activities, change permissions, new intent filters which apply to both the free and paid for versions. If only the paid version is effected then the changes would be made to the library and paid for versions of the manifest.xml, and similarly if the change only effects the free version then the change would be made to the library and free versions of the mainifest.xml.
Previous Topic

Cheap Pills in International Sites

Cheap Pharmacyviagra uk buy buy in Europe

Cheap Pharmacycialis uk


Onlinelasix online


Cheaporder cheap viagra

PurchaseDrugs no Prescription EUROPE
or herevalacyclovirbuy propecia ukviagra australia and you can see more here australia pharmacy generic