If you want to handle the case where the app has been uninstalled and reinstallled, I think your best bet is to store activation data off- device via the network.
A fairly secure way of doing this is to create a Certificate Request to your server, including your device ID in the DN, and send back a signed X509 certificate with a suitable expiration date. A side benefit is that this certificate can be used to secure bidirectional communications between your server and the phone. If you include a nonce in your protocol, you're secure against man-in-the-middle and replay attacks. You're never really secure against someone getting their hands on the phone, rooting it, disabling signature checks somehow, and changing the behavior of your app. Don't store nuclear secrets on your phone, please. On Feb 25, 11:58 am, Streets Of Boston <[email protected]> wrote: > How do you make a time limited trial version, where limiting the time > is fairly fool-proof? How do you know how long the user has your app > installed (including the possibility that the app has been uninstalled > one or more times...)? > > Thanks! > On Feb 25, 2:34 am, 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
