Here I assume you've read all the licensing documentation, and that you're using the SDK. You said nothing, so I'm going for the "defaults". There are a few clues on the Android developers blog as well as on the Internet.
I asked myself the same question last year. Or at least something similar. So let's go one step at a time:
My question is, is this too often? Is
getting a cache response anymore
draining than checking a variable for
example?
I would say that the difference is going to be "imperceptible" to "not much". First of all, the validity timestamp (VT field from extras) is stored locally, properly encrypted/obfuscated. I'm assuming you're using the ServerManagedPolicy policy, since you said nothing about it.
Depending on the kind of the app, we should notice that you may be even writing things on onPause, for example (checking for changes if applicable, of course). So, I wouldn't worry about it.
But because there is no perceptible harm does not mean you should do something. That's why I disagree with what Kerin posted:
I'm sure you'll stop loads of piracy and you aren't wasting your time at all.
More on that later. For now I say that you shouldn't need to do lots of checkings. That's what the policies are for. They handle it probably better than you and me. Anything else is indeed a waste. Personally, I only do checkings on onCreate (obviously), and also in one more situation rarely used (but very important on the app usefulness).
What you should do, however, and I say because nobody said here yet, is properly obfuscate and change the LVL library, as well as your own code side (the checkerCallbacks). Here, I changed a lot of things on the LVL library, including some simple single key cryptography (weak), and also changed how the interfaces are implemented, and how arguments are passed, and so on. Basically, I created my own LVL after posting that question here on SO.
On the opposite of what you're doing, I also customized the VT field in order to mandate a minimum time for the validity of the cached response. That's why my app is to be used in the wild, where net access is not always available. Those subtle details depend on your app, what it does, how it does, where people would be using them.
If you're a developer, it's easy to forget about the user. There is nothing worse than a legitimate user being denied access to an app he bought. So far, I didn't have problems (I check usage statistics and compare to my account), but I believe games have more trouble (it's typical of that field).
So, returning to my constructive (please, we are all trying to learn here, myself included) critic about Kerin's post, I would say that even LVL itself is not enough to "stop loads of piracy".
If you know anything about how Android works, you'd know that the apks can be easily decrypted to source code, just use dex2jar and jdgui (Google them). In fact, I always decrypt my apps before publishing to check if everything is working the way it should. And take into account that I never did computer college, I just happened to learn java and Android to create my own app that I needed and was unavailable for Android (a tide app for my country). I'm sure there are hackers and techies much smarter out there that can do even more.
People start thinking that LVL will stop piracy, and then learn the ugly truth and be disappointed. That's not what the LVL is for. Just look at the code... it was made to avoid "automated" piracy. It is to force someone to personally look into the code, see how it works, and then "switch" the proper flags, if he can make sense of them. But then again, if you use proguard, it will make the task horrible, exhaustive (believe me, that's why I use dex2jar + jdgui myself).
If your app is being sold for $1 or even around $5 or more, it will make this trouble not worth it. That's my stance on the LVL. Obviously, if you have an niche app that costs $100, for example, you probably can do it properly, server side, with public keys. But I feel that it's not the case here.
Anyway, just my 2 cents.
