If LVL just allows me to verify once that the user has a right to use the app that is a big step forward. Buy the app, validate right to use on first use, cache results for a long time to accommodate airplane mode. I believe some of the mainstream PC music software I use uses the internet once to activate the product and then can be used without internet connectivity going forward.
After experimenting with buying and getting a refund, I'm going with my current approach which is designed for the post refund period. The refund process is a potential vulnerability, but I'm going to trust it to delete all traces of my app from the refund requesting phone, and not make any policy decisions based on being in the refund period. I think Dianne Hackborn made the very important point in some other related thread that LVL is 'good enough' in the sense that it requires a rooted phone to defeat, and the mainstream phone user is not using a rooted phone. In a similar vein, attacking the refund process doesn't strike me as something many mainstream phone users will do. On Aug 10, 11:51 am, String <[email protected]> wrote: > I hate to say this, but LVL may not be usable for your app. It's > fundamentally a server-based licensing technique, and if your app is > specifically meant to be used offline - when no server connectivity is > possible, in fact - then it strikes me that there's a fundamental > problem there. > > Nonetheless, I concur that a "refund period expired" flag would be an > excellent server extra. > > String > > On Aug 10, 7:13 pm, OldSkoolMark <[email protected]> wrote: > > > This simple use case is proving trickier than I would have thought it > > would be. My app is designed to operate while the phone is in airplane > > mode. > > > 1) A user downloads the app, runs it once with wireless connectivity > > to get a license. > > > Then there are two cases to consider: > > > 2a) User requests a refund with the permitted timeframe, and > > 2b) User is happy with the app, and switches to airplane mode forever. > > > My initial approach is to set the validity timestamp preference to > > some date far in the future. This is fine for 2b, but what about 2a? > > During the refund period, seems to me that my app should interact with > > the license server just like any standard ServerManagedPolicy-based > > app would, and only after the refund period expires would I set the > > cache validity horizon to forever. Can I rely on refund mechanism > > deleting my app and stored preferences thereby making 2a a non-issue? > > > It occurs to me that a very useful server extra would be a boolean > > indicating whether the refund period has expired. > > -- 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
