While the downloadable license approach sounds good on the face of it, there are just too many loose ends for my tastes as it stands. We already have a very limited channel for communicating with our customers, and I don't want to waste those characters
What I've done is create a master build script, which takes a project name, tags it in Subversion, cleans and switches a build working copy (or does a checkout if needed). I then do two exports from that working copy. I run an XSLT script on the AndroidManifest.xml to handle the differences there, including changing the package, removing the debuggable='true' flag, removing ADMOB ID's, etc. Any differences, I handle programmatically. I don't actually change the code packages, just the references in the manifest and the manifest's package name. Any excess code I'm tentatively planning to remove via Proguard, but I haven't gotten that far yet. In effect, I have three versions -- DEV, FREE, and PRO. DEV is internal-only. I also maintain a change log page I show the users the first time they run after they update. I'm thinking of generating this page content from a filtered view of the Subversion log, but for now I'm manually updating it. It hides any changes they've already seen, based on a record in the Shared Settings. Which is where this all breaks down -- these settings aren't shared between the different versions. Here's my plan for dealing with that: 1) Create a content provider for the settings for my app. 2) When launching the PRO version the first time, if it detects the FREE versions, it will suck in the existing settings from the FREE version. 3) When launching the FREE version, if it detects the PRO version, it will not launch its service, and will take the user to an explanatory page, with a link to the application management page in the system settings. 3a) I plan to listen for PACKAGE_ADDED, and transfer the settings there. That looks to me to be the most reliable place. 3b) I suppose I should monitor PACKAGE_REMOVED, and if the PRO version is uninstalled, re-enable the FREE version. I should only need these in the FREE version, so once a user upgrades there would be no need to launch the app on each install/uninstall. 4) The DEV version will have a couple extra menu items to invoke these operations manually for testing. (For what it's worth, I notice that com.android.voicedialler monitors PACKAGE_ADDED and PACKAGE_RECEIVED, as do a few others with no other obvious reason. I wonder if some of them are doing a similar trick?) This looks to me to be about the best I can do. Does anybody see any problems I've missed? Have a better/simpler idea? It's really too bad the platform doesn't provide a way for one app to supersede another, when signed with the same key. This could be handled much more cleanly at install time. On Feb 24, 11:34 pm, String <[email protected]> wrote: > On Feb 25, 4:00 am, Carmen Delessio <[email protected]> wrote: > > > It seems like it should be possible to have 2 apps signed with same > > certificate. > > See the info below. If your paid app exposed functionality to your free app > > you would get the free/paid goal. > > The free app would check whether paid app was installed, if it was it would > > be used. If not an upgrade message would be displayed. > > This is exactly what I do with one of my apps, TerraTime. I call the > paid app the "license", and it has essentially no functionality of its > own; it just needs to be present for the full functionality of the > free app to be unlocked. I have a slightly different marketing > strategy - my free app has the full feature set, but is just time- > limited to a trial period. It's that time limit which the license > unlocks. But the same approach should work for a freemium model like > yours. > > The major advantage to this is a single code base. From this > perspective, it works well. > > There are a number of small drawbacks that I've found, however. > Primarily, it causes some confusion for the user... The free app is > named "TerraTime Trial", but it needs to stay installed when the user > upgrades. I mostly get around this with clear instructions in all the > relevant places. This may be less applicable with your strategy; just > make sure you don't name the free version "Lite" or some such. And > make VERY clear in the app description that it's a freemium model, or > you'll get complaints. > > Overall, it'd be better if the Market supported in-app purchases (like > certain other App Stores do). But there are so many other, more > serious problems with the market that this feature is probably - > hopefully - pretty far down the priority list. > > A completely different possibility might be to organize your code into > a single JAR file which you can then include in both application > packages. While this would let you maintain only a single version of > your Java source, it wouldn't help you with other code (manifests, > resources, etc). Also, I've personally never got it to work, but I > think that's more to do with unfamiliarity with Eclipse & Java outside > of the usual Android development track. > > String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
