This post describes my lessons learned with the Android Market Licensing service and the accompanying License Verification Library (LVL). I used it the first time for a completely new application, never published on the market before.
Getting started
From the description and instructions page you can read:
"Android Market offers a licensing service that lets you enforce licensing policies for paid applications that you publish through Android Market. With Android Market Licensing, your applications can query Android Market at run time to obtain their licensing status for the current user, then allow or disallow further use as appropriate".
"The License Verification Library (LVL) handles all of the licensing-related communication with the Android Market client and the licensing service. With the LVL integrated, your application can determine its licensing status for the current user by simply calling a library checker method and implementing a callback that receives the status".
That page is quite elaborate and definitely a good starting point for integrating the LVL into your project. Note that your app needs to support SDK 1.5 or higher (API level 3 and onwards).
The LVL I did not set up as a Library Project in Eclipse because it messed up my Subversion. It got totally confused, indicating stuff wasn't checked in, but I also could not check anything in even after a cleanup. Or it kept indicating there were waiting changes to check in, even though I had it checked in. Maybe it's Eclipse Ganymede, maybe it's me :). So I just imported the source code in my project. Disadvantage is I'll have to update each project that uses the LVL when an update of the LVL arrives.
Furthermore I used the ServerManagedPolicy and changed the salt for the AESObfuscator (which is used to securely obfuscate data written to and read from storage).
Note that the AESObfuscator has been reported to be quite slow.
Setting up a test response for license checks works fine for brand spanking new apps like mine was. On my emulator I used my developer account, on the real device (a Nexus One) another gmail account as test-account.
Quite essential in the documentation is the line "Signing in using a publisher account offers the advantage of letting your applications receive static test responses even before the applications are uploaded to the publisher site".
It took me (and apparently others) quite a while to figure out that that means that the test accounts only get the Test response when you've uploaded the app to the market and saved it! Otherwise they will get ERROR_NOT_MARKET_MANAGED.
To obfuscate or not to obfuscate
I decided not to obfuscate my application. Main reasons being:
- It won't prevent hackers from decompiling your code for 100% sure.
- It gets a real pain in the @ss to figure out the real line of the code when you get an error report or exception.
- You should do a full regression test after obfuscation. Of course :) you have that all automated but still...
Note also that
the post explaining ProGuard obfuscation requires a
fix (it obfuscates too much). It might be
updated now.
Here's
a tip when you're using
Proguard obfuscation to easily indicate which classes shouldn't be obfuscated (in short: by letting those implement a specificly named interface and put that as a keep-rule in the proguard config).
Great tip
here to even more minimize the number of classes/interfaces you shouldn't obfuscate.
For another nice introduction and more in-depth details on why you could use Proguard for obfuscation, shrinking and optimization, see
this post.
Server Response ExtrasDuring testing on the emulator I found out that the
Server Response Extras are never set for the test responses, so it's quite hard to test different behaviour here on different values. On the other hand, the default implementation seems to handle it quite ok. If you don't like it, you'll have to dive into the LVL code...
Testing new versions of an appI also found out that if you increase the
versionCode of your app, and try to test that app on a real phone with a test account,
you'll get back ERROR_NOT_MARKET_MANAGED. Most likely this is because of the new versionCode, which the market licensing service does not recognize/accept. I have not seen the ability to just upload a new version of an app and only save it, it seems you can only publish it... And this thus means your test accounts can't test the app before release...
Looking at a reply in
this post it seems you
don't even want to save a newer version because the current version of your app
disappears from the market! Another report of this
here.
As mentioned in the
first post, the only way to test a newer version seems to set the versionCode to the
currently published version and use that during testing on a real device with test accounts. Sounds doable, there's not too much risk of forgetting to increase the versionCode when publishing: the market won't let you upload an app with the same versionCode as already published.
Note: Maybe the new "draft upload" feature fixes the above issues (see sixth item in
this post), didn't try that out yet.
Some answers from Trevor Johns in
the post clarify things re: responses a bit but not all:
"If an app is not published AND not draft, then you'll get
ERROR_NOT_MARKET_MANAGED."Yes, but if your testing with your developer account on the emulator, you get back whatever is set in the test response. Even for an app with a newer versionCode.
"If an app is in draft (never published), then we send LICENSED for all requests for that app."Is it? It seems it sends back to test accounts on a real device what's set in the Test response. Not tested yet for increased versionCode.
The reply on 6aug10 from Trevor Johns in
this thread says it too. Unless I did something wrong, I noticed different behaviour.
"If an app is published (or has been published then unpublished), then
the response is driven by the dev console settings for the developer/testers, and purely by purchase history for everyone else."Yes, but if you have increased the versionCode, test accounts on a real phone get back ERROR_NOT_MARKET_MANAGED.
See also other responses in
this post.
I also wanted to test what happens when I publish a new version,
would people with an older purchased version of the app still get verified successfully, and what does the provided LVL code do when it gets back LICENSED_OLD_KEY?
My conclusion: that combination seems only testable on the emulator for the developer account before publishing the app (note I didn't try the scenario on a real device with the developer account). After really publishing the app you can test it of course, but that's a bit late, you want to try it before publishing, before the world can download it.
For an app never published before, you can test the LICENSED_OLD_KEY as described
here.
More securing your implementationOf course I followed also most steps described in
Securing Android LVL Applications. I did not add a CRC check. Tips on how to do that can also be found
here and
here.
WishesWhat would be
great to have available in the
developer console is to see how many verification requests failed, and with what error. This way you can get an
indication on how many people try to illegally use your app, and get an indication whether something might be competely wrong with your app (e.g nobody gets correctly verified anymore).
You could then also see how many people haven't upgraded yet via distinct the OLD_LICENSE_KEY responses.
As long as this kind of statistics is not provided by the market, but you still want to know about these kind of failures, what you could do is report any error results to your own separate server (though of course a skilled hacker could prevent that from being sent).
Finally: don't forget to add any issues you find to the
market licensing issues page.
17:25 triangular shine
29:00 Check the imeOptions for EditTexts/keyboard input. E.g imeOptions="actionNext" for example. Or "actionDone". NOTE: does not work on HTC Sense UI! So "actionNext" seems safest (might work, might not, but no harm done). For "actionDone" you still need a button for it on your screen anyway.
Del.icio.us
DZone
Reddit
Digg
