How can I support my Android application for multiple Android stores?

I have recently started selling my Android application on the Google Android Market, and implemented their application licensing scheme to prevent against unauthorized use of my application. I am now planning on releasing it for the Amazon Android App Store as well, and want to know the best way of maintaining two versions of my application: one that implements the Android Licensing, and another that does not.

Although my current solution works, it is not optimal, and I am trying to figure out ways other people have dealt with this. Right now, I have implemented two splash scree开发者_开发问答ns for my application, SplashGoogle.java and SplashAmazon.java. I have two corresponding Manifest files, GoogleManifest.xml and AmazonManifest.xml. Each manifest defines a different splash as the launcher intent.

When I want to release a version of my application, I rename one of these manifest files to AndroidManifest.xml, export the application, and then do the same for the other Manifest. This is my solution because it is the best I could come up with, and do not know of other ways to go about doing this. It works because the only difference between the Amazon and the Google market versions of my application, are the corresponding splash classes, one which checks the licensing and the other which does not.

Down the road, I may want to implement additional changes (or consolidate to only have one splash screen) and am looking for a more permanent means of managing subtle changes within the same application.

I imagine that similar issues arrise when developers create lite, free, or ad-supported versions of paid applications.

Additional Notes:

1. For the version that uses Google's Android Licensing, I request the CHECK_LICENSE permission in the AndroidManifet.xml file, while in the Amazon version, this is not necessary.

^{I am not sure if this should be considered a community wiki, but if so, please mark it as such as opposed to closing the question. I believe this would be useful to a lot of developers out there.}

I would start by refactoring your existing codebase into an Android Library Project. This is pretty easy to do. Be sure to read this. The documentation is pretty sparse but I was able to get it to work with it. Be careful to follow the section "Declaring library components in the the manifest file" exactly.

So to refactor into a library you basically mark the existing project as a library project. You just have to tick a box in the projects settings (see the link).

Now go to the library and we want to change the package name to something different. So for example if your released version package is com.mywebsite.myappname.android_market then I would rename this to com.mywebsite.myappname.common_code

You can right click the Project and select Android Tools->Rename application package. This half worked for me. I also had to manually rename all references in the code to my R class manaully. You can just use a global search replace though to rename from com.mywebsite.myappname.android_market.R to com.mywebsite.myappname.common_code.R

Now your library is ready

Now time to make the actual project that you will build.

Create a new android project and name with the package name for android market such as com.mywebsite.myappname.android_market. Follow the instructions on the link to add your new commons library as a library this package uses.

One limitation with Android Library Projects is that the manifest of the library will NOT be merged into the manifest of your top level project. You need to paste it in there by hand. Also (see link) you need to make sure everything in your manifest uses fully qualified package names. So if you used to have activity names such as android:name=".SplashScreenActivity" change it to android:name="com.mywebsite.myappname.common_code.SplashScreenActivity"

So again you need to merge everything by hand, including permissions, intents, activities etc.

Now just build the top project and you are good. Make a wrapper for each variant that you want to build.

You could also have these new top level projects implement anything that is different between your different versions. So your Android Market wrapper could implement one splash screen, and your Amazon version a different splash screen. Or you could just use an enum in your common project to drive it an keep both splash screens in there.

Another nice feature is that resources in the top project will override resources in the library if they are provided. So if you want to for instance on your splash have an Amazon Version Logo and a Android Market logo that changes based on the version just use the same image name as in commons and put a different copy in the two versions.

While not directly related to your question I encountered a similar roadblock in creating both free and paid versions of my application. Android allows you to export any application as a library. You can find this option within the project properties in Eclipse. So by exporting your entire application as a library, you can then incorporate it in to other applications. Once your library has been exported you can create an Amazon and Google app using the library as a base. This will prevent you from having to rename the XML files to get each application in to a usable state.

Libraries are nice because you can also package up resources with them as well. You can even add resources containing the same name in the client applications and these will overwrite the library's version. So you could have different splash screens based on the market your application is in. The only place libraries fell short for me was including assets. Unfortunately raw, unprocessed assets will not be included in a client application from a library.

I would look into using version control like git and having three branches. One branch would not have a manifest, this core branch would have all common code that you could update once. The other two branches would be Amazon, Google, and what ever else comes up. These branches would have app specific code, the manifest, splash screens etc. When your done working in your core branch and want to push updates, you can make a temp branch off core called googleRelease (or something) and merge your google branch.

This is a relatively generic example, git is powerful and you could approach it in a variety of ways.