Creating demo and full version app based on one code base/project

Question

I have developed one Android app in one project with Eclipse - it's structured (coming from iPhone) so one constant defines whether it's the demo or the full version.

Now I have the problem that everytime I want to create the demo version I need to change the constant but also need to make a copy of the project with a different package name.

Obviously changing code in the original full version needs to be copied over to the demo or I would have to redo the creation of the demo app everytime I submit my app.

I see three possible approaches:

1. While I have looked into library projects it is still unclear to me how this really provides a good solution in this case.

For example if I have the full version with an activity structure:

A1
A2
A3

using utility classes U1,U2

Certainly U1 and U2 can be in a library project and referenced from both projects - but the activities, strings.xml, graphics, layouts need to be duplicated (or is there another way that I don't see?) This does not seem to be a good way forward and unfortunately has not been explained in similar questions on this topic when this approach was suggested.

2. The other way would be to create different package names based on different build settings (similar to iPhone), however, this does not seem to be possible in Eclipse rather than by using some external scripts (which - honestly - i rather avoid since it seems rather error prone) while also the compilation has to be invoked outside Eclipse

3. The probably most straight forward approach (and also currently with smalles effort) is to just manually copy the project, change the one constant, rename the package and compile/export every time I submit. This - however - seems to be rather "basic" and certainly does not look professional (as compared to iPhone/xCode build setting/target solution)

What would be the best approach (requiring minimum amount of changes and still being stable and easy to use) ?

Many thanks!

EDIT

For everyone who tried tim's solution - it works fine, however I ran into a problem with custom attributes.

Check this: How to solve Android Libraries custom attributes and package name remapping during build? it will solve the isse for libraries

Puritan

Answer 1

I'm doing this currently in eclipse, and it is not difficult.

1. Convert existing source to library project.

2. Create two new projects, free and paid.

3. Include the library project in the free and paid projects.

It's not necessary to have a single Activity or resource inside the free/paid projects. All you need is a manifest for each which referenes the activities from your library. My free and full projects do not currently have a single java, resource, or layout file of any kind, it's just a manifest which references activities from the library.

I use the exact same code for both projects, and I differentiate them by saying :

if(getApplicationContext().getPackageName().equals("full version package name")) {
    //do full stuff
} else {
    //do free stuff
}

Some gotchas I've hit, especially if you've already released your app on the market:

• If you change the full name/path of any activity, it will disappear from your homescreen. Therefore if your library has a different package name than the existing version, you will lose any homescreen icons. They can be replaced by the user but it's not ideal.
• Similar for appwidgets, if you change their receiver name, they will disappear on upgrade.
• You may not under any circumstance change the package name of a released application.

If you've already released a free and pro version, it's somewhat unfortunate, because the activity path will need to change to a common library path, and you can't rename the released package to match the library path. So somebody will have to lose their existing icons.

In my case I had only released a free version before splitting them, and I was able to name the library with the same package name as the free version. I was skeptical that you'd be allowed to include a library with the same package name as the wrapper package, but apparently it's possible to do so (working fine for me).

So in my case I've got three projects:

• Core Library: package name : com.myname.myapp
• Free Version: package name : com.myname.myapp
• Pro Version: package name : com.myname.myapp.Pro

And the free and full version manifests add activities which are named com.myname.myapp.ActivityA or com.myname.myapp.ActivityB, which exist only in the library project.

Dafodil

thank you very much for the additional clarification - I will try this the next couple of days (so far I have not released any of the two on GooglePlay yet - fortunately as I understand from your comment :-) – Puritan

I like this. Will have to take note next time. – Loricate

I tried this approach. The main problem here is that you have to copy code and you end up having three projects! The better way is actually using flavors. This is a great tutorial which helped me: youtube.com/watch?v=7JDEK4wkN5I – Lietuva

Answer 2

I see the simplest approach would be to have three projects:

1. demo
2. full
3. library

The demo and full projects will each have their own unique package name as defined in their respective Manifest file. Their Activities are merely ports that send information in a bundle to the primary Activity in the library project. The Activity in the library project will read the Bundle passed in for the necessary parameters that determine whether it was launched by the demo Activity or the full Activity. Then it will proceed accordingly.

So the logic is like this:

User launches the demo Activity -> The demo Activity creates a Bundle with the information that says it's the demo Activity -> The demo Activity launches the library Activity which then executes the rest of the program in demo mode.

OR

User launches the full Activity -> The full Activity creates a Bundle with the information that says it's the full Activity -> The full Activity launches the library Activity which then executes the rest of the program in full mode.

Loricate

While it's possible to do so, there's no need to have a wrapper activity pass bundles to the library. You can instantiante library activities directly into the release package manifests. See my answer for more detail. – Dafodil

Answer 3

It's very simple by using build.gradle in Android Studio. Read about productFlavors. It is a very usefull feature. Just simply add following lines in build.gradle:

productFlavors {
    lite {
        packageName = 'com.project.test.app'
        versionCode 1
        versionName '1.0.0'
    }
    pro {
        packageName = 'com.project.testpro.app'
        versionCode 1
        versionName '1.0.0'
    }
}

In this example I add two product flavors: first for lite version and second for full version. Each version has his own versionCode and versionName (for Google Play publication).

In code just check BuildConfig.FLAVOR:

if (BuildConfig.FLAVOR == "lite") {
   // add some ads or restrict functionallity

}

For running and testing on device use "Build Variants" tab in Android Studio to switch between versions:

Scrutinize