Managing two versions of an app in Android

The Corinthian

So, I have two versions of an app; a free version and a pro (paid) version. Both versions have essentially an identical codebase. The only differences are the APK name and a final boolean flag to denote if the version is the pro version. If set to false, some functionality is crippled in the code.

While this approach works, it necessitates the maintenance of two sets of almost identical code, so I thought I might find a better way of doing this. One approach I found was to keep a single codebase and change the application package name (allowing Eclipse to refactor accordingly) and instead of using that final boolean, use the application package name as the flag.

Now, this would work perfectly, except for one fly in the ointment; other than that flag value previously in the code, the two apps use different launcher icons.

So my question is, is there a way that I can see to it that the correct icon is employed, based upon application package name?

The_B_Man

You'll want the icon to be selected on install, so I don't think you can code anything since that'll only get executed when the app in opened. That pretty much just leaves the manfist.xml as you only option. Have a look at this, if you haven't seen it already:

http://stackoverflow.com/questions/1103027/how-to-change-an-application-icon-programmatically-in-android

Kavrocks

Not sure if the hook is there but with the gradle build system being used by Android Studio you can programmatically change a lot in the manifest file. Package name, version, etc. can all be changed on the fly. Not sure if there is a hook to change application icon but I don't see why not, the whole reason for moving to gradle seems to be to solve issues like this.

I've not been following Android development too closely for the last 6 months so not sure what the state of Android Studio or gradle is. I did hear a rumour that Android Studio would be leaving beta at Google I/O.

The Corinthian

The_B_Man wrote: »

You'll want the icon to be selected on install, so I don't think you can code anything since that'll only get executed when the app in opened. That pretty much just leaves the manfist.xml as you only option. Have a look at this, if you haven't seen it already:

http://stackoverflow.com/questions/1103027/how-to-change-an-application-icon-programmatically-in-android

Thanks. I came across that one already, but for some reason activity-alias was being treated as an activity, with the targetActivity being ignored and a 'does not exist' error being triggered.

I may return to trying to make that approach work, but reading other postings on this approach give me the impression that it's just shy of a dirty hack - and thus not terribly reliable. The fact that it requires runtime assignment of the activity, does not fill me with high hopes.

I suspect any viable solution will most likely be completely manifest / res driven, with no code whatsoever. If it exists.

Kavrocks wrote: »

Not sure if the hook is there but with the gradle build system being used by Android Studio you can programmatically change a lot in the manifest file. Package name, version, etc. can all be changed on the fly. Not sure if there is a hook to change application icon but I don't see why not, the whole reason for moving to gradle seems to be to solve issues like this.

If so, it's simply able to facilitate something that can be done manually - that is a solution already would exist - for example, exporting multiple versions of an APK with different package names, is also a feature that it promises, but ultimately this is simply automating something that can already be done manually.

MyPeopleDrankTheSoup

changing the package name everytime sounds pretty messy. the accepted way on stackoverflow is create a library of your base app and have 2 versions based off that library, paid and free.

but i don't agree with 2 versions of any android app. you're splitting your download count in 2 and that's the main way Google ranks apps along with rating.

i mentioned this in a previous thread of yours and you were worrying about reinstalls:
http://www.boards.ie/vbulletin/showpost.php?p=87650792&postcount=5

i implemented a simple android_id check in onCreate. it saves their android_id on my server and if they try and re-install and their android_id already exists in my database, it doesn't allow another trial. code took an hour and works great. though i don't think re-installs were that bad anyway.

The Corinthian

georgiecasey wrote: »

changing the package name everytime sounds pretty messy. the accepted way on stackoverflow is create a library of your base app and have 2 versions based off that library, paid and free.

I've seen the refactoring approach work well, especially when you have multiple versions of an app - and I don't simply mean free and paid, but also for distribution in other markets, such as those of Amazon or Samsung. Between all those those wrappers and the core app and any libraries (billing, ad networks, utils, etc) you've included for the app, you can end up with a lot of clutter before long.

That's not to say the stackoverflow approach is not a perfectly viable alternative, but it really depends on how many versions you're doing and how stable your Eclipse set-up is, IMHO. I think the approach you suggest would likely make more sense in the case here.

but i don't agree with 2 versions of any android app. you're splitting your download count in 2 and that's the main way Google ranks apps along with rating.

I agree and think much of the industry has moved away from the free and paid app approach in the 18 months, in favour of a more in-app 'upgrade' model. Given this, in some cases (such as an ads free version) as a separate app can still make sense upon occasion, I think - especially when you feel you won't get many going for it and don't want to waste too many resources on an elegant in-app solution.

i implemented a simple android_id check in onCreate. it saves their android_id on my server and if they try and re-install and their android_id already exists in my database, it doesn't allow another trial. code took an hour and works great. though i don't think re-installs were that bad anyway.

I wanted to avoid having to maintain a server for this purpose. I have such a set-up for one app and it's just been a pain in the arse, for little return.

In the end, they can reinstall and get another trial, if they completely uninstall the app, but if they want to go through that process every seven days (when their trial period ends), just to save a Franc, they're welcome to it. Then again, I'm presuming this is a tiny minority - if not, I may reconsider the server registry option.

The Corinthian

Follow up / related question:

Say I am using Eclipse and I have an Android application composed of two packages, a core package which is the app and a Settings package which stores a series of global settings for the app (e.g. in-app purchase market key for the app). The app also imports a library (e.g. an in-app wrapper lib), which in turn also uses a copy of that aforementioned global Settings package.

How I've implemented this, to date, is with three projects; the App, the Library and a third one for for the Settings (as a library). The Settings Lib exported as a Jar, then put in the build path of the Library and referenced the Library from the top level app, so to avoid the dreaded "Multiple dex files" error (as will happen if I reference the MySettings project from MyLib). Overall, it looks a bit like this:



Resources are prioritized correctly; those in MyApp will be used rather than those in MyLib. However, while MyApp will use the MyApp.Settings package, MyLib will instead use the MySettings.Settings one.

Why am I trying to do this? Well, I ultimately want that all my libraries can access the setting specific to an app from the settings package in the app project directly, without having to pass them to the library in question. This necessitates that I include an settings package as part of the development of the library which in theory would be ignored in favour of the app settings in a final app.

So am I missing something with this approach, or should I be looking at a completely different one?