Managing two versions of an app in Android

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.

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.