当你建立一个开发者账号和开发环境之后(见设置签名)，你就可以在License Verification Library(LVL)给你的app添加签名了。
在LVL添加签名认证需要遵循下面这些步骤：
1.在你的应用的manifest.xml里添加签名权限
2.实现Policy —— 你可以选择LVL 中提供的完整的实现方案，或者你自己创建一个
3.实现Obfuscator, 如果你的Policy需要缓存任何签名认证结果
4.在你应用的main Activity中添加代码进行签名检查
5.实现DeviceLimiter(可选, 但是不推荐)
下面描述了这些步骤. 当你完成了这些操作, 你就应用可以成功编译你的应用了, 并按照设定的测试环境开始测试你的应用.
LVL包含了对全套源码完整的概述, 见Summary of LVL Classes and Interfaces
添加签名权限
为了使用Google Play发送签名验证请求到服务器, 你的应用本身必须有相应的权限: com.android.vending.CHECK_LICENSE. 如果你的应用没有进行签名认证权限的声明就尝试进行签名认证, LVL会抛出一个安全异常.
在你的应用里添加签名认证的权限, 需要在下创建元素 , 如：
下面是例子：
<?xml version"utf-8"?>
...
注意：你不可以在LVL库的项目的manifest中声明CHECK_LICENSE权限, 因为SDK Tools不会把它合并到依赖的项目中. 因此, 你必须在每个项目的manifest中进行权限声明.
实现Policy
Google Play的签名服务本身不确定是否应该让提交的签名通过认证. 相反, 这个职责交给了你应用中提供的Policy.
Policy是LVL声明的接口, 用来根据签名验证结果控制你的应用允许或禁用用户访问. 使用LVL, 你的应用必须提供Policy的实现.
Policy定了两个方法, allowAccess()、processServerResponse(), 当LicenseChecker实例处理来自签名服务器的响应的时候会被调用. 它还定义了一个叫做LicenseResponse的枚举类, 在调用processServerResponse()的时候把指定的签名验证结果传进去.
processServerResponse() 在决定是否授权之前让你对从签名验证服务器接收到的响应数据进行预处理.
一个典型的实现是可以从响应数据中提取一些或全部字段并存到本地进行持久化存储, 比如通过SharedPreferences 存储, 以确保可以跨应用访问, 而且不会因为设备关机导致数据丢失. 例如, Policy可以在持久性数据容器 中持有签名最后一次验证成功的时间戳、重试次数、有效期等类似的信息, 而不是在应用每次启动的时候重新加载这些数据.
当在本地存储响应数据的时候, Policy必须确保数据进行了混淆处理(见”实现Obfuscator”)
allowAccess()根据任何有效的签名验证响应数据(来自服务器响应或缓存)或其他特定应用程序信息决定是否授权给用户访问你的应用. 例如, 你实现的 allowAccess()可以带入一些额外的条件, 如usage或者从后台服务器检索到的数据. 在所有的情况下, 如果用户被授权使用应用, 方法应该只返回true. 如果因为网络或系统原因导致签名验证未完成, 你可以指定一个重试次数并允许用户暂时访问直到下一次完成验证.
为了简化你给应用添加签名的过程并提供一个设置Policy的说明, LVL提供了两个完整的Policy实现, 你可以直接使用而不需要任何修改:
ServerManagedPolicy, 使用服务器默认设置和缓存的响应结果来管理各种网络环境下的访问,
StrictPolicy, 不缓存任何响应结果并且只有服务器返回验证过的响应结果才能访问.
对于大多数应用来说, 比较推荐ServerManagedPolicy. ServerManagedPolicy是LVL默认的方案, 并且已经包含在LVL的示例应用中.
自定义Policy向导
在你的签名实现中, 你可以使用LVL提供的完整的Policy实现(ServerManagedPolicy或StrictPolicy)或者你可以自定义一个Policy. 对于任何自定义Policy, 这里有几个重要的设计要点需要理解并且在你的实现中使用.
签名验证服务器一般会限制请求次数以防止过度使用服务器资源而导致拒绝服务. 当一个应用超过了请求限制, 服务器会返回503响应码, 作为一个通用的服务器错误告诉你的应用. 这就意味着在限制被重置之前将没有可用的签名验证响应结果提供给用户, 这会无期限的影响应用用户.
如果你准备自定义一个policy, 我们推荐Policy:
把大部分最近的成功的签名验证结果缓存(并混淆处理) 在本地进行持久化保存
只要缓存的响应结果是有效的, 那么对所有的签名检查都返回缓存的响应结果, 而不是创建一个验证请求. 我们推荐根据服务器额外提供的VT设置响应结果的有效期. 更多信息见Server Response Extras
如果尝试任何请求都返回错误, 使用一个指数回避这个情况. 记录Google Play客户端自动尝试失败的请求, 因为在大多数情况下你的Policy不需要再去尝试
提供一个“宽限期限”允许用户在限定的时间或次数内使用你的应用, 在需要重新进行签名验证的时候. 当没有有效的签名响应结果时, 你可以设置一个范围很大的限制值控制在宽限期内的用户允许使用你的应用直到下一次签名检查完成.
依照上面列出的向导设计你的Policy是很关键, 因为它可以确保最好的用户体验, 甚至同时让你能在出错的情况下有效的控制你的应用.
记录任何服务器提供的可用的设置帮助你管理有效期和缓存, 重试宽限期等等. 使用服务器提供的设置非常简单并且高度推荐. 可以看看ServerManagedPolicy实现的例子. 有关于服务器的提供设置和信息可以见Server Response Extras
ServerManagedPolicy
ServerManagedPolicy是LVL提供的完整实现的并推荐使用的Policy接口. 这个实现已经作为默认的Policy跟LVL的类和服务整合在类库里.
ServerManagedPolicy提供了处理签名和重试响应的所有方法. 它会把所有的响应结果缓存到本地SharedPreferences 文件, 并使用应用的Obfuscator 的实现类混淆. 这确保了签名的响应数据是安全的并且不会因为设备关机而丢失.
ServerManagedPolicy 提供了接口的具体实现方法processServerResponse()和allowAccess()同时也包括一组支持管理签名响应数据的方法和类型.
重要的是, ServerManagedPolicy的关键特性是使用服务器提供的设置为基础管理应用的签名授权, 而不受各种网络和异常条件的影响. 当一个应用连接到Google Play服务器进行签名认证的时候, 服务器会把设置项作为key-value的形式存到某些响应类型的额外的字段中. 例如, 服务器提供了推荐应用签名使用的一些值, 尤其是是有效期、重试宽限期、最大重试次数. ServerManagedPolicy 把签名响应数据中的值传入到processServerResponse() 并在allowAccess()中校验值. 有关于ServerManagedPolicy使用服务器提供的设置项, 见Server Response Extras.
为了方便、更好的性能和从Google Play服务器上取得更好的签名设置效果, 强烈推荐使用ServerManagedPolicy作为你的Policy.
如果你担心存在本地SharedPreferences中的签名响应数据的安全, 你可以使用更强大的混淆算法或设计一个更严格的不存储签名数据的Policy. LVL包含了一个这样的例子, 更多信息见StrictPolicy .
使用ServerManagedPolicy, 只要将它导入到你的activity中, 创建一个实例, 当创建LicenseChecker的时候传递它的引用进去. 更多信息见Instantiate LicenseChecker and LicenseCheckerCallback
StrictPolicy
StrictPolicy是LVL提供的另一个可选的Policy的实现接口. 它提供的Policy比ServerManagedPolicy更为严格, 它不允许用户访问应用除非在访问的时候从服务器接收到标识用户可以访问的签名响应数据.
StrictPolicy的主要特点是不会把任何签名响应数据以持久化方式存在本地. 因为不存储数据, 重试请求不会被记录并且缓存的响应数据不会用于完成签名检查. Policy允许访问只能在：
从服务器接收到签名响应数据
并且响应数据标识用户验证通过可以访问应用
在LVL添加签名认证需要遵循下面这些步骤：
1.在你的应用的manifest.xml里添加签名权限
2.实现Policy —— 你可以选择LVL 中提供的完整的实现方案，或者你自己创建一个
3.实现Obfuscator, 如果你的Policy需要缓存任何签名认证结果
4.在你应用的main Activity中添加代码进行签名检查
5.实现DeviceLimiter(可选, 但是不推荐)
下面描述了这些步骤. 当你完成了这些操作, 你就应用可以成功编译你的应用了, 并按照设定的测试环境开始测试你的应用.
LVL包含了对全套源码完整的概述, 见Summary of LVL Classes and Interfaces
添加签名权限
为了使用Google Play发送签名验证请求到服务器, 你的应用本身必须有相应的权限: com.android.vending.CHECK_LICENSE. 如果你的应用没有进行签名认证权限的声明就尝试进行签名认证, LVL会抛出一个安全异常.
在你的应用里添加签名认证的权限, 需要在下创建元素 , 如：
下面是例子：
<?xml version"utf-8"?>
...
注意：你不可以在LVL库的项目的manifest中声明CHECK_LICENSE权限, 因为SDK Tools不会把它合并到依赖的项目中. 因此, 你必须在每个项目的manifest中进行权限声明.
实现Policy
Google Play的签名服务本身不确定是否应该让提交的签名通过认证. 相反, 这个职责交给了你应用中提供的Policy.
Policy是LVL声明的接口, 用来根据签名验证结果控制你的应用允许或禁用用户访问. 使用LVL, 你的应用必须提供Policy的实现.
Policy定了两个方法, allowAccess()、processServerResponse(), 当LicenseChecker实例处理来自签名服务器的响应的时候会被调用. 它还定义了一个叫做LicenseResponse的枚举类, 在调用processServerResponse()的时候把指定的签名验证结果传进去.
processServerResponse() 在决定是否授权之前让你对从签名验证服务器接收到的响应数据进行预处理.
一个典型的实现是可以从响应数据中提取一些或全部字段并存到本地进行持久化存储, 比如通过SharedPreferences 存储, 以确保可以跨应用访问, 而且不会因为设备关机导致数据丢失. 例如, Policy可以在持久性数据容器 中持有签名最后一次验证成功的时间戳、重试次数、有效期等类似的信息, 而不是在应用每次启动的时候重新加载这些数据.
当在本地存储响应数据的时候, Policy必须确保数据进行了混淆处理(见”实现Obfuscator”)
allowAccess()根据任何有效的签名验证响应数据(来自服务器响应或缓存)或其他特定应用程序信息决定是否授权给用户访问你的应用. 例如, 你实现的 allowAccess()可以带入一些额外的条件, 如usage或者从后台服务器检索到的数据. 在所有的情况下, 如果用户被授权使用应用, 方法应该只返回true. 如果因为网络或系统原因导致签名验证未完成, 你可以指定一个重试次数并允许用户暂时访问直到下一次完成验证.
为了简化你给应用添加签名的过程并提供一个设置Policy的说明, LVL提供了两个完整的Policy实现, 你可以直接使用而不需要任何修改:
ServerManagedPolicy, 使用服务器默认设置和缓存的响应结果来管理各种网络环境下的访问,
StrictPolicy, 不缓存任何响应结果并且只有服务器返回验证过的响应结果才能访问.
对于大多数应用来说, 比较推荐ServerManagedPolicy. ServerManagedPolicy是LVL默认的方案, 并且已经包含在LVL的示例应用中.
自定义Policy向导
在你的签名实现中, 你可以使用LVL提供的完整的Policy实现(ServerManagedPolicy或StrictPolicy)或者你可以自定义一个Policy. 对于任何自定义Policy, 这里有几个重要的设计要点需要理解并且在你的实现中使用.
签名验证服务器一般会限制请求次数以防止过度使用服务器资源而导致拒绝服务. 当一个应用超过了请求限制, 服务器会返回503响应码, 作为一个通用的服务器错误告诉你的应用. 这就意味着在限制被重置之前将没有可用的签名验证响应结果提供给用户, 这会无期限的影响应用用户.
如果你准备自定义一个policy, 我们推荐Policy:
把大部分最近的成功的签名验证结果缓存(并混淆处理) 在本地进行持久化保存
只要缓存的响应结果是有效的, 那么对所有的签名检查都返回缓存的响应结果, 而不是创建一个验证请求. 我们推荐根据服务器额外提供的VT设置响应结果的有效期. 更多信息见Server Response Extras
如果尝试任何请求都返回错误, 使用一个指数回避这个情况. 记录Google Play客户端自动尝试失败的请求, 因为在大多数情况下你的Policy不需要再去尝试
提供一个“宽限期限”允许用户在限定的时间或次数内使用你的应用, 在需要重新进行签名验证的时候. 当没有有效的签名响应结果时, 你可以设置一个范围很大的限制值控制在宽限期内的用户允许使用你的应用直到下一次签名检查完成.
依照上面列出的向导设计你的Policy是很关键, 因为它可以确保最好的用户体验, 甚至同时让你能在出错的情况下有效的控制你的应用.
记录任何服务器提供的可用的设置帮助你管理有效期和缓存, 重试宽限期等等. 使用服务器提供的设置非常简单并且高度推荐. 可以看看ServerManagedPolicy实现的例子. 有关于服务器的提供设置和信息可以见Server Response Extras
ServerManagedPolicy
ServerManagedPolicy是LVL提供的完整实现的并推荐使用的Policy接口. 这个实现已经作为默认的Policy跟LVL的类和服务整合在类库里.
ServerManagedPolicy提供了处理签名和重试响应的所有方法. 它会把所有的响应结果缓存到本地SharedPreferences 文件, 并使用应用的Obfuscator 的实现类混淆. 这确保了签名的响应数据是安全的并且不会因为设备关机而丢失.
ServerManagedPolicy 提供了接口的具体实现方法processServerResponse()和allowAccess()同时也包括一组支持管理签名响应数据的方法和类型.
重要的是, ServerManagedPolicy的关键特性是使用服务器提供的设置为基础管理应用的签名授权, 而不受各种网络和异常条件的影响. 当一个应用连接到Google Play服务器进行签名认证的时候, 服务器会把设置项作为key-value的形式存到某些响应类型的额外的字段中. 例如, 服务器提供了推荐应用签名使用的一些值, 尤其是是有效期、重试宽限期、最大重试次数. ServerManagedPolicy 把签名响应数据中的值传入到processServerResponse() 并在allowAccess()中校验值. 有关于ServerManagedPolicy使用服务器提供的设置项, 见Server Response Extras.
为了方便、更好的性能和从Google Play服务器上取得更好的签名设置效果, 强烈推荐使用ServerManagedPolicy作为你的Policy.
如果你担心存在本地SharedPreferences中的签名响应数据的安全, 你可以使用更强大的混淆算法或设计一个更严格的不存储签名数据的Policy. LVL包含了一个这样的例子, 更多信息见StrictPolicy .
使用ServerManagedPolicy, 只要将它导入到你的activity中, 创建一个实例, 当创建LicenseChecker的时候传递它的引用进去. 更多信息见Instantiate LicenseChecker and LicenseCheckerCallback
StrictPolicy
StrictPolicy是LVL提供的另一个可选的Policy的实现接口. 它提供的Policy比ServerManagedPolicy更为严格, 它不允许用户访问应用除非在访问的时候从服务器接收到标识用户可以访问的签名响应数据.
StrictPolicy的主要特点是不会把任何签名响应数据以持久化方式存在本地. 因为不存储数据, 重试请求不会被记录并且缓存的响应数据不会用于完成签名检查. Policy允许访问只能在：
从服务器接收到签名响应数据
并且响应数据标识用户验证通过可以访问应用
