Let's take a look at the overview:
http://developer.android.com/guide/publishing/licensing.html
(note - much of overview is wordy and at times repetitions. Basically, to set up licensing, you need to download the jar file, add it as a separate project, add that project to your project as a library, set up a publisher account and then start implementing the apis; Things move quicker toward the bottom.)
To see the best part, start basically implementing the sample code)
Application Licensing
Quickview
Licensing lets you protect your application on any device that includes Android Market.
Your app maintains control of how it enforces its licensing status.
Adding licensing to an app is straightforward, using the library available through the SDK.
The service is free and is available to all developers who publish on Android Market.
In this document
Setting Up A Publisher Account
Setting Up the Development Environment
Integrating the LVL with Your Application
Including the LVL
Adding the licensing permission
Implementing a Policy
Implementing an Obfuscator
Checking the license
Implementing a DeviceLimiter
Setting Up the Test Environment
Test responses
Test accounts
Signing in on a device or emulator
Obfuscating Your Application
Publishing a Licensed Application
Where to Get Support
Appendix
Summary of LVL Classes and Interfaces
Server Response Codes
Server Response Extras
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.
Using the service, you can apply a flexible licensing policy on an application-by-application basis — each application can enforce licensing in the way most appropriate for it.
If necessary, an application can apply custom constraints based on the licensing status obtained from Android Market.
// this might be a good idea
For example, an application can check the licensing status and then apply custom constraints that allow the user to run it unlicensed for a specific number of times, or for a specific validity period.
// or for a certain number of item
An application can also restrict use of the application to a specific device, in addition to any other constraints.
// not sure I want to mess with that.
The licensing service is a secure means of controlling access to your applications.
// ok
When an application checks the licensing status, the Market server signs the licensing status response using a key pair that is uniquely associated with the publisher account.
// ok, I think.
Your application stores the public key in its compiled .apk file and uses it to verify the licensing status response
// ok
Any application that you publish through Android Market can use the Android Market Licensing service. No special account or registration is needed. Additionally, because the service uses no dedicated framework APIs, you can add licensing to any legacy application that uses a minimum API level of 3 or higher.
//k
To help you add licensing to your application, the Android SDK provides library sources that you can include in your application project.
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.
// ok
To help you add licensing to your application, the Android SDK provides library sources that you can include in your application project. 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 sounds good
Overview
Android Market Licensing is a network-based service that lets an application on an Android-powered device query a trusted licensing server, to determine whether the application is licensed to the current device user.
After receiving the server response, the application can then allow or disallow further use of the application as needed. In the service, the role of the licensing server is to provide the license status for the current user; the application itself is responsible for querying the server and conditionally granting access to the application.
// ok
Application, Android Market client, and server
The licensing service is based on the capability of the Android Market server to determine whether a given user is licensed to use a given application.
The server considers a user licensed if the user is recorded to have purchased the application, or if the application is available for free.
// ok
To properly identify the user and determine the license status, the server requires information about the application and user — the application and the Android Market client work together to assemble the information and pass it to the server.
// ok
In the licensing service, an application does not query the licensing server directly, but instead calls the Android Market client over remote IPC to initiate a license request. In the license request:
The application provides its package name and a nonce that is later used to validate any response from the server, as well as a callback over which the response can be returned asynchronously.
The Android Market client, which has greater permissions than the application, collects the necessary information about the user and the device, such as the device's primary Google account username, IMSI, and other information. It then sends the license check request to the server on behalf of the application.
The server evaluates the request using all available information, attempting to establish the user's identity to a sufficient level of confidence. The server then checks the user identity against purchase records for the application and returns a license response, which the Android Market client returns to the application over the IPC callback.
Notice that during a license check, the application does not manage any network connections or use any licensing related APIs in the Android platform.
License responses secured through public key cryptography
To ensure the integrity of each license query, the server signs the license response data using an RSA key pair that is shared exclusively between the server and the application publisher.
// ok
The licensing service generates a single licensing key pair for each publisher account and exposes the public key in the account's profile page.
// ok - public key is in profile page
The publisher copies the public key and embeds it in the application source code, then compiles and publishes the .apk.
// ok
The server retains the private key internally and uses it to sign license responses for applications published on that account.
// ok
When the application receives a signed response, it uses the embedded public key to verify the data.
// ok, the one in the app
The use of public key cryptography in the licensing service makes it possible for the application to detect responses that have been tampered with or that are spoofed.
Use of licensing in your application
To use licensing in your application, add code to the application to initiate a license check request and handle the response when it is received.
// ok
You can choose when, and how often, you want your application to check its license and you have full control over how it handles the response, verifies the signed response data, and enforces access controls.
// ok
To simplify the process of adding support for licensing, download and integrate the Licensing Verification Library, described below. Integration is straightforward.
// ok
When you are finished integrating the LVL, use a test environment provided by the publisher site to test your application's handling of server responses.
// ok
Finally, publish the application .apk on Market using the normal process. If you previously used the copy-protection provided by Android Market, you can remove it from applications that use licensing.
// ok
Licensing Verification Library simplifies implementation
The Android SDK includes a License Verification Library (LVL) that you can download and use as the basis for your application's licensing implementation.
The LVL greatly simplifies the process of adding licensing to your application and helps ensure a more secure, robust implementation for your application.
The LVL provides internal classes that handle most of the standard operations of a license query, such as contacting Android Market to initiate a license request and verifying and validating the responses.
It also exposes key interfaces that let you easily plug in your custom code for defining licensing policy and managing access as needed by your application. The key LVL interfaces are:
Policy — your implementation determines whether to allow access to the application, based on the license response received from the server and any other data available (such as from a backend server associated with your application). The implementation can evaluate the various fields of the license response and apply other constraints, if needed. The implementation also lets you manage the handling of license checks that result in errors, such as network errors.
// ok
LicenseCheckerCallback — your implementation manages access to the application, based on the result of the Policy's handling of the license response.
// ok
Your implementation can manage access in any way needed, including displaying the license result in the UI or directing the user to purchase the application (if not currently licensed).
// kind of repetitive
To help you get started with a Policy, the LVL provides two fully complete Policy implementations that you can use without modification or adapt to your needs:
ServerManagedPolicy is a flexible Policy that uses settings provided by the licensing server to manage response caching and access to the application while the device is offline (such as when the user is on an airplane). For most applications, the use of ServerManagedPolicy is highly recommended.
// ok - use ServerManagedPolicy
StrictPolicy is a restrictive Policy that does not cache any response data and allows the application access only when the server returns a licensed response.
// no good
The LVL is available as a downloadable component of the Android SDK.
// sigh
The component includes both the LVL itself and an example application that shows how the library should be integrated with your application and how your application should manage response data, UI interaction, and error conditions.
// swell. Can we do that?
The LVL sources are provided as an Android library project, which means that you can maintain a single set of library sources and share them across multiple applications.
// super.
A full test environment is also available through the SDK, so you can develop and test the licensing implementation in your applications before publishing them, even if you don't have access to a physical device.
// awesome.
Requirements and limitations
Android Market Licensing is designed to let you apply license controls to applications that you publish through Android Market.
// yep.
The service is not designed to let you control access to applications that are not published through Android Market or that are run on devices that do not offer the Android Market client.
// sure.
Here are some points to keep in mind as you implement licensing in your application:
Only paid applications published through Market can use the service.
// I thought they said free ones could use it? As in disable features if not paid.
An application can use the service only if the Android Market client is installed on its host device and the device is running Android 1.5 (API level 3) or higher.
// ok
To complete a license check, the licensing server must be accessible over the network. You can implement license caching behaviors to manage access when there is no network connectivity.
// Super.
The security of your application's licensing controls ultimately relies on the design of your implementation itself. The service provides the building blocks that let you securely check licensing, but the actual enforcement and handling of the license are factors in your control. By following the best practices in this document, you can help ensure that your implementation will be secure.
// Best practices.
Adding licensing to an application does not affect the way the application functions when run on a device that does not offer Android Market.
// no access to the internet?
Licensing is currently for paid apps only, since free apps are considered licensed for all users. If your application is already published as free, you won't be able to upload a new version that uses licensing.
// That's too bad. It means I can't use a switch in the code. That's unfortunate.
Replacement for Copy Protection
Android Market Licensing is a flexible, secure mechanism for controlling access to your applications. It effectively replaces the Copy Protection mechanism offered on Android Market and gives you wider distribution potential for your applications.
A limitation of the legacy Copy Protection mechanism on Android Market is that applications using it can be installed only on compatible devices that provide a secure internal storage environment. For example, a copy-protected application cannot be downloaded from Market to a device that provides root access, and the application cannot be installed to a device's SD card.
With Android Market licensing, you can move to a license-based model in which access is not bound to the characteristics of the host device, but to your publisher account on Android Market and the licensing policy that you define. Your application can be installed and controlled on any compatible device on any storage, including SD card.
Although no license mechanism can completely prevent all unauthorized use, the licensing service lets you control access for most types of normal usage, across all compatible devices, locked or unlocked, that run Android 1.5 or higher version of the platform.
The sections below describe how to add Android Market licensing to your applications.
// ok.
I don't know if I want to have two separate versions; actually, 12, since we're talking about 5 levels, plus the full. Well, I can go ahead and try, but it might not work. I might have to just comment out the code, everytime, or delete the jar.
Setting Up a Publisher Account
Android Market licensing lets you manage access to applications that users have downloaded from Android Market. To use licensing in an application, you need to have a publisher account on Android Market so that you can publish the application to users.
// see, they could have just not struck the first sentence completely.
If you don't already have a publisher account, you need to register for one using your Google account and agree to the terms of service.
// They could have skipped that sentence entirely.
Once you are registered, you can upload applications at your convenience and begin debugging and testing your licensing implementation. For more information about publishing on Android Market, see Publishing Your Applications
// they could have skipped the first sentence.
To register as an Android Market developer and set up your publisher account, visit the Android Market publisher site:
http://market.android.com/publish
// ok, let's go set one up.
ok, I did some setting up. I created a separate gmail account in my company's name - I'm not sure if that was the best idea, but I went with it. The profile has a public key. It says I can only do free apps now, but, I mean, I paid $25 so I'm not sure if it's just waiting for it to go through, or if I need to do something else. We'll see.
Onward...
If you already have a publisher account on Android Market, use your existing account to set up licensing. You do not need to register for a new account to support licensing (and doing so is not recommended, especially if you are adding licensing support to applications that you have already published). In all cases, if you have published applications, you manage licensing for those applications through the account on which the applications are published.
Once your publisher account is set up, use the account to:
Obtain a public key for licensing
Debug and test an application's licensing implementation, prior to publishing the application
Publish the applications to which you have added licensing support
// ok
Market licensing. The controls are available in the Edit Profile page, in the "Licensing" panel, shown below. The controls let you:
Set up multiple "test accounts", identified by email address. The licensing server allows users signed into test accounts on a device or emulator to send license checks and receive static test responses.
Obtain the account's public key for licensing. When you are implementing licensing in an application, you must copy the public key string into the application.
Configure static test responses that the server sends, when it receives a license check for an application uploaded to the publisher account, from a user signed in to the publisher account or a test account.
Figure 2. The Licensing panel of your account's Edit Profile page lets you manage administrative settings for licensing.
For more information about how to work with test accounts and static test responses, see Setting Up a Testing Environment, below.
// Ok, I saw those in Edit Profile when I set up the account.
// Ok, I just set it up the paid - it was an option in edit profile.
Setting Up the Development Environment
Once you've set up your publisher account on Android Market, the next step is to set up your development environment for licensing.
Setting up your environment for licensing involves these tasks:
Downloading the latest SDK, if you haven't already done so
Setting up the runtime environment for development
Downloading the Market Licensing component into your SDK
Setting up the Licensing Verification Library
Including the LVL library project in your application
Downloading the latest SDK
Licensing sample application
/////////////////// box /////////////////////////////////////
To work with Android Market licensing, you need a functioning Android application to which you can add licensing support.
If you are new to Android and don't yet have a functioning application, the LVL component includes a sample application that you can set up as a new application project. The sample provides a complete, working example of how licensing works. For more information, see Downloading the LVL.
////////////////// box end //////////////////////////////////
If you haven't done so, you need to download the Android SDK before you can develop Android applications. The SDK provides the tools that you need to build and debug Android applications, including applications that use Android Market licensing. For complete information, including installation instructions, see the Android SDK.
If you have already installed the SDK, make sure to update the SDK tools and ADT Plugin to the latest versions. You can update the SDK tools using the Android SDK and AVD Manager and ADT through Help > Software Updates... in Eclipse.
After you've installed the latest SDK and tools, set up your development environment as described below.
// ok, I've certainly got the SDK set up. But what about the sample app? Come back to it.
Setting up the runtime environment
As described earlier, applications check licensing status not by contacting the licensing server directly, but by binding to a service provided by the Android Market application and initiating a license check request. The Android Market service then handles the direct communication with the licensing server and finally routes the response back to your application. To debug and test licensing in your application, you need to set up a runtime environment that includes the necessary Android Market service, so that your application is able to send license check requests to the licensing server.
There are two types of runtime environment that you can use:
An Android-powered device that includes the Android Market application, or
An Android emulator running the Google APIs Add-on, API level 8 (release 2) or higher
The sections below provide more information.
// Ok, I should make sure I'm on release 2. Not sure - nothing on it.
Running on a device
You can use an Android-powered device as the runtime environment for debugging and testing licensing on your application.
The device you use must:
Run a standard version of the Android 1.5 or later (API level 3 or higher) platform, and
Run a system image on which the Android Market client application is preinstalled.
If Android Market is not preinstalled in the system image, your application won't be able to communicate with the Android Market licensing server.
For general information about how to set up a device for use in developing Android applications, see Developing on a Device.
// Ok, how do I know the Android Market application is pre-installed? Ok, it's just the app market app.
// skipping emulator setup
Updating your project configuration
After you set up a runtime environment that meets the requirements described above — either on an actual device or on an emulator — make sure to update your application project or build scripts as needed, so that your compiled .apk files that use licensing are deployed into that environment. In particular, if you are developing in Eclipse, make sure that you set up a Run/Debug Configuration that targets the appropriate device or AVD.
You do not need to make any changes to your application's build configuration, provided that the project is already configured to compile against a standard Android 1.5 (API level 3) or higher library. For example:
If you have an existing application that is compiled against the Android 1.5 library, you do not need to make any changes to your build configuration to support licensing. The build target meets the minimum requirements for licensing, so you would continue building against the same version of the Android platform.
Similarly, if you are building against Android 1.5 (API level 3) but are using an emulator running the Google APIs Add-On API 8 as the application's runtime environment, there is no need to change your application's build configuration.Downloading the LVL
In general, adding licensing to an application should have no impact whatsoever on the application's build configuration.
// ok
Downloading the LVL
The License Verification Library (LVL) is a collection of helper classes that greatly simplify the work that you need to do to add licensing to your application. In all cases, we recommend that you download the LVL and use it as the basis for the licensing implementation in your application.
The LVL is available as a downloadable component of the Android SDK. The component includes:
The LVL sources, stored inside an Android library project.
An example application called "sample" that depends on the LVL library project. The example illustrates how an application uses the library helper classes to check and enforce licensing.
To download the LVL component into your development environment, use the Android SDK and AVD Manager. Launch the Android SDK and AVD Manager and then select the "Market Licensing" component, as shown in the figure below. Accept the terms and click Install Selected to begin the download.
// At last - actually doing something. I appreciate all the background, but it seems a bit too wordy.
// What they should do is just bullet points, and expand on them with clicks.
// Ok, there was an error message:
parseSdkContent failed
java.lang.NullPointerException
and the selection is staying selected.
Ok, after browsing around, a restart of eclipse shows it as an installed package - along with in-app-billing, which I installed earlier. That's a bullet dodged.
Keep on plowing on.
When the download is complete, the Android SDK and AVD Manager installs both the LVL library project and the example application into these directories:
If you aren't familiar with how to download components into your SDK, see the Adding SDK Components document.
I should really figure out where that is...let's find market_licensing
It's in this directory: android-sdk-mac_86
But what does that tell me, really?
Keep on truckin'.
Setting Up the Licensing Verification Library
After downloading the LVL to your computer, you need to set it up in your development environment, either as an Android library project or by copying (or importing) the library sources directly into your existing application package.
In general, using the LVL as a library project is recommended, since it lets you reuse your licensing code across multiple applications and maintain it more easily over time. Note that the LVL is not designed to be compiled separately and added to an application as a static .jar file.
// What are they saying? How do I do it? I need to import the source?
Moving the library sources to a new location
Because you will be customizing the LVL sources to some extent, you should make sure to move or copy the library sources (the entire directory at
// ok...
You should then use the relocated sources as your working set. If you are using a source-code management system, add and track the sources that are in the working location rather than those in default location in the SDK.
Moving the library sources is important is because, when you later update the Market licensing package, the SDK installs the new files to the same location as the older files. Moving your working library files to a safe location ensures that your work won't be inadvertently overwritten should you download a new version of the LVL.
// ok, does this mean separate project?
Creating the LVL as a library project
Working with library projects
The LVL is provided as an Android library project, which means that you can share its code and resources across multiple applications.
// ok...
If you aren't familiar with library projects or how to use them, see Managing Projects.
// hold of on that for now
The recommended way of using the LVL is setting it up as a new Android library project.
// ok
A library project is a type of development project that holds shared Android source code and resources.
// ok
Other Android application projects can reference the library project and, at build time, include its compiled sources in their .apk files.
// sure
In the context of licensing, this means that you can do most of your licensing development once, in a library project, then include the library sources in your various application projects.
// sure
In this way, you can easily maintain a uniform implementation of licensing across all of your projects and maintain it centrally.
// ok
The LVL is provided as a configured library project — once you have downloaded it, you can start using it right away.
// ok
If you are working in Eclipse with ADT, you need to add the LVL to your workspace as a new development project, in the same way as you would a new application project.
// ok
Use the New Project Wizard to create a new project from existing sources. Select the LVL's library directory (the directory containing the library's AndroidManifest.xml file) as the project root.
// ok, let's copy market_licensing/library to the base level of the eclipse workspace
When you are creating the library project, you can select any application name, package, and set other fields as needed.
For the library's build target, select Android 1.5 (API level 3) or higher.
When created, the project is predefined as a library project in its default.properties file, so no further configuration is needed.
For more information about how to create an application project or work with library projects in Eclipse, see Managing Projects from Eclipse with ADT
.
// Ok. For some reason I had a lot of difficulty getting the copy done. Finder still doesn't love me, and the command
// line betrayed me...next...
Copying the LVL sources to your application
As an alternative to adding the LVL as a library project, you can copy the library sources directly into your application. To do so, copy (or import) the LVL's library/src/com directory into your application's src/ directory.
If you add the LVL sources directly to your application, you can skip the next section and start working with the library, as described in .
// let's make it an include
Including the LVL library project sources in your application
If you want to use the LVL sources as a library project, you need to add a reference to the LVL library project in your application project properties. This tells build tools to include the LVL library project sources in your application at compile time. The process for adding a reference to a library project depends on your development environment, as described below.
If you are developing in Eclipse with ADT, you should already have added the library project to your workspace, as described in the previous section. If you haven't done that already, do it now before continuing.
// Too much documentation!
Next, open the application's project properties window, as shown below.
// finally.
Select the "Android" properties group and click Add,
then choose the LVL library project (com_android_vending_licensing) and click OK.
// Could have said that a while back.
For more information, see Managing Projects from Eclipse with ADT
// I'm gonna go ahead and skip that.
Integrating the LVL with Your Application
Once you've followed the steps above to set up a publisher account and development environment, you are ready to begin integrating the LVL with your application.
Integrating the LVL with your application code involves these tasks:
Adding the licensing permission your application's manifest.
Implementing a Policy — you can choose one of the full implementations provided in the LVL or create your own.
Implementing an Obfuscator, if your Policy will cache any license response data.
Adding code to check the license in your application's main Activity
Implementing a DeviceLimiter (optional and not recommended for most applications)
Adding the licensing permission your application's manifest.
Implementing a Policy
ServerManagedPolicy
The LVL includes a complete Policy implementation called ServerManagedPolicy that makes use of license-management settings provided by the Android Market server.
// ok
Use of ServerManagedPolicy as the basis for your Policy is strongly recommended. For more information, see ServerManagedPolicy section, below.
// Sure thing.
Android Market licensing service does not itself determine whether a given user with a given license should be granted access to your application. Rather, that responsibility is left to a Policy implementation that you provide in your application.
// Whaaat? Who ever heard of such a thing.
Policy is an interface declared by the LVL that is designed to hold your application's logic for allowing or disallowing user access, based on the result of a license check. To use the LVL, your application must provide an implementation of Policy.
// ok.
The Policy interface declares two methods, allowAccess() and processServerResponse(), which are called by a LicenseChecker instance when processing a response from the license server.
// ok
It also declares an enum called LicenseResponse, which specifies the license response value passed in calls to processServerResponse().
// ok
processServerResponse() lets you preprocess the raw response data received from the licensing server, prior to determining whether to grant access.
// ok
A typical implementation would extract some or all fields from the license response and store the data locally to a persistent store, such as through SharedPreferences storage, to ensure that the data is accessible across application invocations and device power cycles.
// ok
For example, a Policy would maintain the timestamp of last successful license check, the retry count, the license validity period, and similar information in a persistent store, rather than resetting the values each time the application is launched.
// ok.
When storing response data locally, the Policy must ensure that the data is obfuscated (see Implementing an Obfuscator, below)
// ok.
allowAccess() determines whether to grant the user access to your application, based on any available license response data (from the licensing server or from cache) or other application-specific information.
For example, your implementation of allowAccess() could take into account additional criteria, such as usage or other data retrieved from a backend server.
In all cases, an implementation of allowAccess() should only return true if the user is licensed to use the application, as determined by the licensing server, or if there is a transient network or system problem that prevents the license check from completing.
In such cases, your implementation can maintain a count of retry responses and provisionally allow access until the next license check is complete.
To simplify the process of adding licensing to your application and to provide an illustration of how a Policy should be designed, the LVL includes two full Policy implementations that you can use without modification or adapt to your needs:
ServerManagedPolicy, a flexible Policy that uses server-provided settings and cached responses to manage access across varied network conditions, and
StrictPolicy, which does not cache any response data and allows access only if the server returns a licensed response.
For most applications, the use of ServerManagedPolicy is highly recommended. ServerManagedPolicy is the LVL default and is integrated with the LVL sample application.
// ok.
Guidelines for custom policies
// we'll skip all this
ServerManagedPolicy
Server Response Extras
For certain types of licensing responses, the licensing server appends extra settings to the responses, to help the application manage licensing effectively.
See Server Response Extras for a list of settings and ServerManagedPolicy.java for information about how a Policy can use the extras.
The LVL includes a full and recommended implementation of the Policy interface called ServerManagedPolicy. The implementation is integrated with the LVL classes and serves as the default Policy in the library.
ServerManagedPolicy provides all of the handling for license and retry responses. It caches all of the response data locally in a SharedPreferences file, obfuscating it with the application's Obfuscator implementation.
// good, it's done for me. That's good news.
This ensures that the license response data is secure and persists across device power cycles. ServerManagedPolicy provides concrete implementations of the interface methods processServerResponse() and allowAccess() and also includes a set of supporting methods and types for managing license responses.
// Nice.
Importantly, a key feature of ServerMangedPolicy is its use of server-provided settings as the basis for managing licensing across an application's refund period and through varying network and error conditions.
// nice.
When an application contacts the Android Market server for a license check, the server appends several settings as key-value pairs in the extras field of certain license response types.
// Ok.
For example, the server provides recommended values for the application's license validity period, retry grace period, and maximum allowable retry count, among others.
// Ok.
ServerManagedPolicy extracts the values from the license response in its processServerResponse() method and checks them in its allowAccess() method.
// Ok.
For a list of the server-provided settings used by ServerManagedPolicy, see Server Response Extras in the Appendix of this document.
// I'll be sure to do that.
For convenience, best performance, and the benefit of using license settings from the Android Market server, using ServerManagedPolicy as your licensing Policy is strongly recommended.
// Really? I hadn't noticed.
If you are concerned about the security of license response data that is stored locally in SharedPreferences, you can use a stronger obfuscation algorithm or design a stricter Policy that does not store license data.
// I'm good.
The LVL includes an example of such a Policy — see StrictPolicy for more information.
To use ServerManagedPolicy, simply import it to your Activity, create an instance, and pass a reference to the instance when constructing your LicenseChecker. See Instantiate LicenseChecker and LicenseCheckerCallback for more information.
// I guess this would be my startActivity?
StrictPolicy
// skip
Implementing an Obfuscator
// skip, it's done automatically
Checking the license from your application's main Activity
Once you've implemented a Policy for managing access to your application, the next step is to add a license check to your application, which initiates a query to the licensing server if needed and manages access to the application based on the license response.
All of the work of adding the license check and handling the response takes place in your main Activity source file.
// ok, my startActivity.
To add the license check and handle the response, you must:
Add imports
Implement LicenseCheckerCallback as a private inner class
Create a Handler for posting from LicenseCheckerCallback to the UI thread
Instantiate LicenseChecker and LicenseCheckerCallback
Call checkAccess() to initiate the license check
Embed your public key for licensing
Call your LicenseChecker's onDestroy() method to close IPC connections.
The sections below describe these tasks
The sections below describe these tasks.
Overview of license check and response
Example: MainActivity
The sample application included with the LVL provides a full example of how to initiate a license check and handle the result, in the MainActivity.java file.
// ok
In most cases, you should add the license check to your application's main Activity, in the onCreate() method. This ensures that when the user launches your application directly, the license check will be invoked immediately. In some cases, you can add license checks in other locations as well. For example, if your application includes multiple Activity components that other applications can start by Intent, you could add license checks in those Activities.
// ok
A license check consists of two main actions:
A call to a method to initiate the license check — in the LVL, this is a call to the checkAccess() method of a LicenseChecker object that you construct.
// ok
A callback that returns the result of the license check. In the LVL, this is a LicenseCheckerCallback interface that you implement. The interface declares two methods, allow() and dontAllow(), which are invoked by the library based on to the result of the license check. You implement those two methods with whatever logic you need, to allow or disallow the user access to your application.
// ok
Note that these methods do not determine whether to allow access — that determination is the responsibility of your Policy implementation. Rather, these methods simply provide the application behaviors for how to allow and disallow access (and handle application errors).
// gotcha
Figure 6. Overview of a typical license check interaction.
The diagram above illustrates how a typical license check takes place:
Code in the application's main Activity instantiates LicenseCheckerCallback and LicenseChecker objects.
// ok
When constructing LicenseChecker, the code passes in Context, a Policy implementation to use, and the publisher account's public key for licensing as parameters.
// ok
The code then calls the checkAccess() method on the LicenseChecker object. The method implementation calls the Policy to determine whether there is a valid license response cached locally, in SharedPreferences.
// ok
If so, the checkAccess() implementation calls allow().
// ok, we're in.
Otherwise, the LicenseChecker initiates a license check request that is sent to the licensing server.
// ok
When a response is received, LicenseChecker creates a LicenseValidator that verifies the signed license data and extracts the fields of the response, then passes them to your Policy for further evaluation.
// ok
If the license is valid, the Policy caches the response in SharedPreferences and notifies the validator, which then calls the allow() method on the LicenseCheckerCallback object.
// alright, we're in! Plus we store the response
If the license not valid, the Policy notifies the validator, which calls the dontAllow() method on LicenseCheckerCallback.
// That's what we need.
In case of a recoverable local or server error, such as when the network is not available to send the request, LicenseChecker passes a RETRY response to your Policy's processServerResponse() method.
// ok
In case of a application error, such as when the application attempts to check the license of an invalid package name, LicenseChecker passes an error response to the LicenseCheckerCallback's applicationError() method.
// ok
Note that, in addition to initiating the license check and handling the result, which are described in the sections below, your application also needs to provide a Policy implementation and, if the Policy stores response data (such as ServerManagedPolicy), an Obfuscator implementation.
// Do I get these automatically? I'm almost positive I get the ServerManagedPolicy; and I thought it mentioned it gave me the
// obfuscator implementation
Add imports
First, open the class file of the application's main Activity and import LicenseChecker and LicenseCheckerCallback from the LVL package.
import com.android.vending.licensing.LicenseChecker;
import com.android.vending.licensing.LicenseCheckerCallback;
If you are using the default Policy implementation provided with the LVL, ServerManagedPolicy, import it also, together with the AESObfuscator. If you are using a custom Policy or Obfuscator, import those instead.
import com.android.vending.licensing.ServerManagedPolicy;
import com.android.vending.licensing.AESObfuscator;
// Added all four.
Implement LicenseCheckerCallback as a private inner class
LicenseCheckerCallback is an interface provided by the LVL for handling result of a license check. To support licensing using the LVL, you must implement LicenseCheckerCallback and its methods to allow or disallow access to the application.
The result of a license check is always a call to one of the LicenseCheckerCallback methods, made based on the validation of the response payload, the server response code itself, and any additional processing provided by your Policy. Your application can implement the methods in any way needed. In general, it's best to keep the methods simple, limiting them to managing UI state and application access. If you want to add further processing of license responses, such as by contacting a backend server or applying custom constraints, you should consider incorporating that code into your Policy, rather than putting it in the LicenseCheckerCallback methods.
In most cases, you should declare your implementation of LicenseCheckerCallback as a private class inside your application's main Activity class.
Implement the allow() and dontAllow() methods as needed. To start with, you can use simple result-handling behaviors in the methods, such as displaying the license result in a dialog. This helps you get your application running sooner and can assist with debugging. Later, after you have determined the exact behaviors you want, you can add more complex handling.
Some suggestions for handling unlicensed responses in dontAllow() include:
Display a "Try again" dialog to the user, including a button to initiate a new license check.
Display a "Purchase this application" dialog, including a button that deep-links the user to the application's details page on Market, from which the use can purchase the application. For more information on how to set up such links, see Using Intents to Launch the Market Application on a Device.
Display a Toast notification that indicates that the features of the application are limited because it is not licensed.
The example below shows how the LVL sample application implements LicenseCheckerCallback, with methods that display the license check result in a dialog.
private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
public void allow() {
if (isFinishing()) {
// Don't update UI if Activity is finishing.
return;
}
// Should allow user access.
displayResult(getString(R.string.allow));
}
public void dontAllow() {
if (isFinishing()) {
// Don't update UI if Activity is finishing.
return;
}
displayResult(getString(R.string.dont_allow));
// Should not allow access. An app can handle as needed,
// typically by informing the user that the app is not licensed
// and then shutting down the app or limiting the user to a
// restricted set of features.
// In this example, we show a dialog that takes the user to Market.
showDialog(0);
}
}
// let's copy this in, and modify it to show toasts. I also want to see how that showDialog(0) takes the user to market.
Additionally, you should implement the applicationError() method, which the LVL calls to let your application handle errors that are not retryable. For a list of such errors, see Server Response Codes in the Appendix of this document. You can implement the method in any way needed. In most cases, the method should log the error code and call dontAllow().
// done
Create a Handler for posting from LicenseCheckerCallback to the UI thread
During a license check, the LVL passes the request to the Android Market application, which handles communication with the licensing server.
// ok
The LVL passes the request over asynchronous IPC (using Binder) so the actual processing and network communication do not take place on a thread managed by your application.
// I'm sure that's good.
Similarly, when the Android Market application receives the result, it invokes a callback method over IPC, which in turn executes in an IPC thread pool in your application's process.
// I'm sure that's fine.
The LicenseChecker class manages your application's IPC communication with the Android Market application, including the call that sends the request and the callback that receives the response.
// ok.
LicenseChecker also tracks open license requests and manages their timeouts.
// ok.
So that it can handle timeouts properly and also process incoming responses without affecting your application's UI thread, LicenseChecker spawns a background thread at instantiation. In the thread it does all processing of license check results, whether the result is a response received from the server or a timeout error. At the conclusion of processing, the LVL calls your LicenseCheckerCallback methods from the background thread.
// Ok.
To your application, this means that:
Your LicenseCheckerCallback methods will be invoked, in many cases, from a background thread.
Those methods won't be able to update state or invoke any processing in the UI thread, unless you create a Handler in the UI thread and have your callback methods post to the Handler.
// So, that's what this has been about.
If you want your LicenseCheckerCallback methods to update the UI thread, instantiate a Handler in the main Activity's onCreate() method, as shown below.
// I'm guessing we need to do this, so we can display something.
In this example, the LVL sample application's LicenseCheckerCallback methods (see above) call displayResult() to update the UI thread through the Handler's post() method.
private Handler mHandler;
@Override
public void onCreate(Bundle savedInstanceState) {
...
mHandler = new Handler();
}
// ok, let's add these. Wait, aren't I doing a Toast? What do I need this for?
Then, in your LicenseCheckerCallback methods, you can use Handler methods to post Runnable or Message objects to the Handler. Here's how the sample application included in the LVL posts a Runnable to a Handler in the UI thread to display the license status.
private void displayResult(final String result) {
mHandler.post(new Runnable() {
public void run() {
mStatusText.setText(result);
setProgressBarIndeterminateVisibility(false);
mCheckLicenseButton.setEnabled(true);
}
});
}
// Ok, this is getting away from me a little bit. This is code from the sample app. This is how it's working with the thread.
// I wonder if my toasts are useful or not. Ok, let's do this. We'll put the toast in the displayResult. I really
// should be looking at the sample app. I should've started out with it, really. Hey, where is it?
// Anyway, here's where I am right now with the inner class:
private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
public void allow() {
if (isFinishing()) {
// Don't update UI if Activity is finishing.
return;
}
// Should allow user access.
//displayResult(getString(R.string.allow));
displayResult("allow");
}
public void dontAllow() {
if (isFinishing()) {
// Don't update UI if Activity is finishing.
return;
}
//displayResult(getString(R.string.dont_allow));
displayResult("dont allow");
// Should not allow access. An app can handle as needed,
// typically by informing the user that the app is not licensed
// and then shutting down the app or limiting the user to a
// restricted set of features.
// In this example, we show a dialog that takes the user to Market.
// showDialog(0);
}
@Override
public void applicationError(ApplicationErrorCode errorCode) {
// TODO Auto-generated method stub
Log.d(StartActivity.TAG, "App error, code: " + errorCode);
Toast.makeText(StartActivity.this, "App Error - don't Allow", Toast.LENGTH_LONG);
}
private void displayResult(final String result) {
mHandler.post(new Runnable() {
public void run() {
Toast.makeText(StartActivity.this, result, Toast.LENGTH_LONG);
}
});
}
}
// next...
Instantiate LicenseChecker and LicenseCheckerCallback
In the main Activity's onCreate() method, create private instances of LicenseCheckerCallback and LicenseChecker. You must instantiate LicenseCheckerCallback first, because you need to pass a reference to that instance when you call the constructor for LicenseChecker.
When you instantiate LicenseChecker, you need to pass in these parameters:
The application Context
A reference to the Policy implementation to use for the license check. In most cases, you would use the default Policy implementation provided by the LVL, ServerManagedPolicy.
The String variable holding your publisher account's public key for licensing.
If you are using ServerManagedPolicy, you won't need to access the class directly, so you can instantiate it in the LicenseChecker constructor, as shown in the example below. Note that you need to pass a reference to a new Obfuscator instance when you construct ServerManagedPolicy.
The example below shows the instantiation of LicenseChecker and LicenseCheckerCallback from the onCreate() method of an Activity class.
public class MainActivity extends Activity {
...
private LicenseCheckerCallback mLicenseCheckerCallback;
private LicenseChecker mChecker;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
// Construct the LicenseCheckerCallback. The library calls this when done.
mLicenseCheckerCallback = new MyLicenseCheckerCallback();
// Construct the LicenseChecker with a Policy.
mChecker = new LicenseChecker(
this, new ServerManagedPolicy(this,
new AESObfuscator(SALT, getPackageName(), deviceId)),
BASE64_PUBLIC_KEY // Your public licensing key.
);
...
}
// Ok...I dug up the sample code from market_licensing and am making this compile with some tweaks
// such as adding the public key and salt.
Note that LicenseChecker calls the LicenseCheckerCallback methods from the UI thread only if there is valid license response cached locally. If the license check is sent to the server, the callbacks always originate from the background thread, even for network errors.
// That's kind of hard to follow.
}
Note that LicenseChecker calls the LicenseCheckerCallback methods from the UI thread only if there is valid license response cached locally. If the license check is sent to the server, the callbacks always originate from the background thread, even for network errors.
// Next.
Call checkAccess() to initiate the license check
In your main Activity, add a call to the checkAccess() method of the LicenseChecker instance. In the call, pass a reference to your LicenseCheckerCallback instance as a parameter. If you need to handle any special UI effects or state management before the call, you might find it useful to call checkAccess() from a wrapper method. For example, the LVL sample application calls checkAccess() from a doCheck() wrapper method:
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
// Call a wrapper method that initiates the license check
doCheck();
...
}
...
private void doCheck() {
mCheckLicenseButton.setEnabled(false);
setProgressBarIndeterminateVisibility(true);
mStatusText.setText(R.string.checking_license);
mChecker.checkAccess(mLicenseCheckerCallback);
}
// Ok, let's add the doCheck, but just the checkAccess call.
// Ok, now we have something like this:
/**
*
*/
private void checkLicense() {
// for licensing code
mHandler = new Handler();
// Try to use more data here. ANDROID_ID is a single point of attack.
String deviceId = Secure.getString(getContentResolver(),
Secure.ANDROID_ID);
// Library calls this when it's done.
mLicenseCheckerCallback = new MyLicenseCheckerCallback();
// Construct the LicenseChecker with a policy.
mChecker = new LicenseChecker(this, new ServerManagedPolicy(this,
new AESObfuscator(SALT, getPackageName(), deviceId)),
BASE64_PUBLIC_KEY);
doCheck();
}
private void doCheck() {
mChecker.checkAccess(mLicenseCheckerCallback);
}
// You can safely ignore the following, just grab you key from the merchant profile and stick it in there.
Embed your public key for licensing
For each publisher account, the Android Market service automatically generates a 2048-bit RSA public/private key pair that is used exclusively for licensing. The key pair is uniquely associated with the publisher account and is shared across all applications that are published through the account. Although associated with a publisher account, the key pair is not the same as the key that you use to sign your applications (or derived from it).
The Android Market publisher site exposes the public key for licensing to any developer signed in to the publisher account, but it keeps the private key hidden from all users in a secure location. When an application requests a license check for an application published in your account, the licensing server signs the license response using the private key of your account's key pair. When the LVL receives the response, it uses the public key provided by the application to verify the signature of the license response.
To add licensing to an application, you must obtain your publisher account's public key for licensing and copy it into your application. Here's how to find your account's public key for licensing:
Go to the Android Market publisher site and sign in. Make sure that you sign in to the account from which the application you are licensing is published (or will be published).
In the account home page, locate the "Edit profile" link and click it.
In the Edit Profile page, locate the "Licensing" pane, shown below. Your public key for licensing is given in the "Public key" text box.
To add the public key to your application, simply copy/paste the key string from the text box into your application as the value of the String variable BASE64_PUBLIC_KEY. When you are copying, make sure that you have selected the entire key string, without omitting any characters.
Here's an example from the LVL sample application:
public class MainActivity extends Activity {
private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example
...
}
// Next...
Call your LicenseChecker's onDestroy() method to close IPC connections
Finally, to let the LVL clean up before your application Context changes, add a call to the LicenseChecker's onDestroy() method from your Activity's onDestroy() implementation. The call causes the LicenseChecker to properly close any open IPC connection to the Android Market application's ILicensingService and removes any local references to the service and handler.
Failing to call the LicenseChecker's onDestroy() method can lead to problems over the lifecycle of your application. For example, if the user changes screen orientation while a license check is active, the application Context is destroyed. If your application does not properly close the LicenseChecker's IPC connection, your application will crash when the response is received. Similarly, if the user exits your application while a license check is in progress, your application will crash when the response is received, unless it has properly called the LicenseChecker's onDestroy() method to disconnect from the service.
Here's an example from the sample application included in the LVL, where mChecker is the LicenseChecker instance:
@Override
protected void onDestroy() {
super.onDestroy();
mChecker.onDestroy();
...
}
If you are extending or modifying LicenseChecker, you might also need to call the LicenseChecker's finishCheck() method, to clean up any open IPC connections.
// Ok, let's add it. Done. Next?
Implementing a DeviceLimiter
In some cases, you might want your Policy to limit the number of actual devices that are permitted to use a single license. This would prevent a user from moving a licensed application onto a number of devices and using the application on those devices under the same account ID. It would also prevent a user from "sharing" the application by providing the account information associated with the license to other individuals, who could then sign in to that account on their devices and access the license to the application.
The LVL supports per-device licensing by providing a DeviceLimiter interface, which declares a single method, allowDeviceAccess(). When a LicenseValidator is handling a response from the licensing server, it calls allowDeviceAccess(), passing a user ID string extracted from the response.
If you do not want to support device limitation, no work is required — the LicenseChecker class automatically uses a default implementation called NullDeviceLimiter. As the name suggests, NullDeviceLimiter is a "no-op" class whose allowDeviceAccess() method simply returns a LICENSED response for all users and devices.
Caution: Per-device licensing is not recommended for most applications because:
It requires that you provide a backend server to manage a users and devices mapping, and
It could inadvertently result in a user being denied access to an application that they have legitimately purchased on another device.
// That last part says it all. Skip it. Next?
Setting Up the Testing Environment
The Android Market publisher site provides configuration tools that let you and others test licensing on your application before it is published. As you are implementing licensing, you can make use of the publisher site tools to test your application's Policy and handling of different licensing responses and error conditions.
The main components of the test environment for licensing include:
A "Test response" configuration in your publisher account that lets you set the static licensing response returned, when the server processes a license check for an application uploaded to the publisher account, from a user signed in to the publisher account or a test account.
An optional set of test accounts that will receive the static test response when they check the license of an application that you have uploaded (regardless whether the application is published or not).
A runtime environment for the application that includes the Android Market application or Google APIs Add-On, on which the user is signed in to the publisher account or one of the test accounts.
Setting up the test environment properly involves:
Setting static test responses that are returned by the licensing server.
Setting up test accounts as needed.
Signing in properly to an emulator or device, before initiating a license check test.
The sections below provide more information.
// Well, let's just quickly run it and see what happens...
java.lang.IllegalArgumentException: java.security.spec.InvalidKeySpecException: java.io.IOException: corrupted stream - out of bounds length found
They said to get rid of the blanks - let's check the string. No spaces. What were the instructions?
To add the public key to your application, simply copy/paste the key string from the text box into your application as the value of the String variable BASE64_PUBLIC_KEY. When you are copying, make sure that you have selected the entire key string, without omitting any characters.
I think I truncated it. Let's try again.
Ok, now it's running, but not displaying any dialogs.
Let's write to the log, see of any of the callbacks happened...
Can't see any....
Ok, back to the directions.
Setting Up the Testing Environment
The Android Market publisher site provides configuration tools that let you and others test licensing on your application before it is published.
// good
As you are implementing licensing, you can make use of the publisher site tools to test your application's Policy and handling of different licensing responses and error conditions.
// ok
The main components of the test environment for licensing include:
A "Test response" configuration in your publisher account that lets you set the static licensing response returned, when the server processes a license check for an application uploaded to the publisher account, from a user signed in to the publisher account or a test account.
// I think I did that already
An optional set of test accounts that will receive the static test response when they check the license of an application that you have uploaded (regardless whether the application is published or not).
// I think I did that, too.
Setting test responses for license checks
Android Market provides a configuration setting in your publisher account that lets you override the normal processing of a license check and return a specified static response code.
// ok
The setting is for testing only and applies only to license checks for applications that you have uploaded, made by any user signed in to an emulator or device using the credentials of the publisher account or a registered test account. For other users, the server always processes license checks according to normal rules.
// ok, I must be doing the first.
To set a test response for your account, sign in to your publisher account and click "Edit Profile". In the Edit Profile page, locate the Test Response menu in the Licensing panel, shown below. You can select from the full set of valid server response codes to control the response or condition you want to test in your application.
In general, you should make sure to test your application's licensing implementation with every response code available in the Test Response menu. For a description of the codes, see Server Response Codes in the Appendix of this document.
A runtime environment for the application that includes the Android Market application or Google APIs Add-On, on which the user is signed in to the publisher account or one of the test accounts.
Setting up the test environment properly involves:
Setting static test responses that are returned by the licensing server.
Setting up test accounts as needed.
Signing in properly to an emulator or device, before initiating a license check test.
The sections below provide more information.
Setting test responses for license checks
Android Market provides a configuration setting in your publisher account that lets you override the normal processing of a license check and return a specified static response code. The setting is for testing only and applies only to license checks for applications that you have uploaded, made by any user signed in to an emulator or device using the credentials of the publisher account or a registered test account. For other users, the server always processes license checks according to normal rules.
To set a test response for your account, sign in to your publisher account and click "Edit Profile". In the Edit Profile page, locate the Test Response menu in the Licensing panel, shown below. You can select from the full set of valid server response codes to control the response or condition you want to test in your application.
In general, you should make sure to test your application's licensing implementation with every response code available in the Test Response menu. For a description of the codes, see Server Response Codes in the Appendix of this document
Figure 7. The Licensing panel of your account's Edit Profile page, showing the Test Accounts field and the Test Response menu.
Note that the test response that you configure applies account-wide — that is, it applies not to a single application, but to all applications associated with the publisher account. If you are testing multiple applications at once, changing the test response will affect all of those applications on their next license check (if the user is signed into the emulator or device using the publisher account or a test account).
Before you can successfully receive a test response for a license check, you must sign in to the device or emulator on which the application is installed, and from which it is querying the server. Specifically, you must sign using either your publisher account or one of the test accounts that you have set up. For more information about test accounts, see the next section.
// All that was basically to say you could set a test response on your publisher's profile.
Setting up test accounts
In some cases, you might want to let multiple teams of developers test licensing on applications that will ultimately be published through your publisher account, but without giving them access to your publisher account's sign-in credentials. To meet that need, the Android Market publisher site lets you set up one or more optional test accounts — accounts that are authorized to query the licensing server and receive static test responses from your publisher account.
Test accounts are standard Google accounts that you register on your publisher account, such that they will receive the test response for applications that you have uploaded. Developers can then sign in to their devices or emulators using the test account credentials and initiate license checks from installed applications. When the licensing server receives a license check from a user of a test account, it returns the static test response configured for the publisher account.
Necessarily, there are limitations on the access and permissions given to users signed in through test accounts, including:
Test account users can query the licensing server only for applications that are already uploaded to the publisher account.
Test account users do not have permission to upload applications to your publisher account.
Test account users do not have permission to set the publisher account's static test response.
The table below summarizes the differences in capabilities, between the publisher account, a test account, and any other account.
Table 1. Differences in account types for testing licensing.
Account Type Can check license before upload? Can receive test response? Can set test response?
Publisher account Yes Yes Yes
Test account No Yes No
Other No No No
// ok, it doesn't look like the test account is going to do me much good.
Signing in to an authorized account in the runtime environment
// Ok, I need to figure out how this works.
The licensing service is designed to determine whether a given user is licensed to use a given application — during a license check, the Android Market application gathers the user ID from the primary account on the system and sends it to the server, together with the package name of the application and other information. However, if there is no user information available, the license check cannot succeed, so the Android Market application terminates the request and returns an error to the application.
// i'm not even getting the error, AFAIK.
During testing, to ensure that your application can successfully query the licensing server, you must make sure that you sign in to an account on the device or emulator using:
The credentials of a publisher account, or
The credentials of a test account that is registered with a publisher account
// how do I do that?
Signing in to a Google account on an emulator
If you are testing licensing on an emulator, you need to sign in to a Google account on the emulator. If you do not see an option to create a new Google account, the problem might be that your AVD is running a standard Android system image, rather than the Google APIs Add-On, API 8 (release 2) or higher.
For more information, see Setting up the runtime environment, above.
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.
// I know, but, how?
If you are part of a larger organization or are working with external groups on applications that will be published through your site, you will more likely want to distribute test accounts instead, then use those to sign in during testing.
// nope.
To sign in on a device or emulator, follow the steps below. The preferred approach is to sign in as the primary account — however, if there are other accounts already in use on the device or emulator, you can create an additional account and sign in to it using the publisher or test account credentials.
// ok, here we go
Open Settings > Accounts & sync
Select Add Account and choose to add a "Google" account.
Select Next and then Sign in.
Enter the username and password of either the publisher account or a test account that is registered in the publisher account.
Select Sign in. The system signs you in to the new account.
Once you are signed in, you can begin testing licensing in your application (if you have completed the LVL integration steps above). When your application initiates a license check, it will receive a response containing the static test response configured on the publisher account.
Note that, if you are using an emulator, you will need to sign in to the publisher account or test account each time you wipe data when restarting the emulator.
Figure 8. Example of setting up a Google account on a device or emulator.
// Ok, now that I signed up under my publisher email, I got further, but the error message returned is
/LicenseChecker( 900): Calling checkLicense on service for com.jlptquiz.app
I/LicenseChecker( 900): Start monitoring timeout.
I/ActivityManager( 101): Displayed com.jlptquiz.app/.StartActivity: +5s102ms
I/LicenseChecker( 900): Received response.
I/LicenseChecker( 900): Clearing timeout.
D/QuizStartActiity( 900): App error, code: NOT_MARKET_MANAGED
// So, it sounds like it doesn't know that I'm a test app or something.
This link at SO has some ideas:
http://stackoverflow.com/questions/3497280/android-not-market-managed-error
It looks like the most popular answer says upload it, but save it as a draft! And make sure the version you're uploading is the same or greater.
Ok, let's try that - tomorrow. We've made some progress here, but it's getting late. I just watched the fireworks, and I'm getting sleepy. I *don't* want to publish it by accident!
No comments:
Post a Comment