Learn Android Market Licensing Service: Part 2（FINISH）

上文介绍了LVL的简易使用方式，本篇文档介绍复杂使用方式，这种方法比建议之前的方式多了三个环节：第一，实现自定义的 Police；第二，实现自定义的 Obfuscator；第三，实现自定义的 DeviceLimiter。

在Android Market Licensing Service中，Licensing Server 只会返回适用于当前用户的 License，并不会决定用户是否可以使用，它把决策权留给了开发者。开发者要行使这个权利，需要通过一个叫做 Policy 的 interface。API 文档是这样描述 Policy 的：used by LicenseChecker to determine whether a user should be have access to the application。其共定义了两个方法：allowAccess() 和 processServerResponse()。

开发者需要自行实现该接口，在实现过程中需要注意到一种情况，Licensing Server 会对来自应用的请求有次数限制，通过这种限制避免其被滥用，应用请求一旦超过限制，那么Licensing Server 将返回503的状态码。因此，加入缓存机制是有必须要的，比如保存文件，–当然需要对缓存进行必要的混淆。同时，只要缓存的响应还有效，那么优先返回缓存的响应，而不是再次向 Licensing Server 发请求。当然 LVL 也准备两个类，它们完整地实现了 Policy ，分别是 ServerManagedPolicy 和 StrictPolicy。前者是 LVL 的默认选项，也是推荐选项，其把服务器的响应混淆之后缓存到了 SharedPreferences 文件中，既保证了安全，又解决了关机后信息保存问题；后者则比前者更加严格，没有缓存。

在实现 Policy 的时候，如果想缓存 License，那么明文保存肯定是不安全的，因此需要对 License 进行混淆，这在 LVL 中通过一个interface来实现，就是 Obfuscator。实现这个 interface， 需要注意到这几点：首先，混淆的过程一定要是可逆的；其次，要使用设备相关的信息作为混淆算法的 key；最后，最好要有完整性检查。LVL 也已经准备了一个实现类，即 AESObfuscator，其采用 AES 算法进行加解密。

一般情况下，License 是和用户的账户信息相对应的，但是如果说用户故意散播自己的帐号，其他人冒用该账户，进而也可以获得 License，这也是可能的。为此 LVL 提供了一个 interface，即 DeviceLimiter，通过其中的方法 isDeviceAllowed 来控制是否在具体某个设备上运行应用。LVL 也提供了默认实现 NullDeviceLimiter。对设备进行检查可以在一定程度上减少上述冒用账户的问题，但是这样做，需要开发者自行把账户信息和设备信息的关系保存在后台服务器（当然开发者负责提供），一旦处理不好有可能让正常更换手机的用户失去运行应用的权利，因此对设备进行检查并不是 LVL 中必须的步骤，而且 Android 官方也不推荐这种做法。

LVL Class Diagram

为了确保应用的安全，除了 Android Market Licensing Service，混淆应用代码显得非常重要。混淆代码会加大恶意用户对应用反编译的难度。一旦反编译成功，移除 license 检查就相当容易了，再重新编译发布，这显然不是开发者愿意看到的。适用于Android应用的混淆工具有好几种，其中 ProGuard 为官方推荐工具。

保护与破坏，正版与盗版，总是形影不离，这就是矛盾，就像武侠世界里的铁布衫和铁砂掌，谁能说得清哪个更厉害？想想像 Microsoft 这样的软件巨头也遭遇 Windows 五块钱一张的窘境，开发者是不是心理平衡一点了呢？面对破解，最有效的做法是提高应用的品质，扩大用户的基数；其次是加大被破解的技术难度和使用难度，降低破解版本的占有率；再则是尝试免费+广告，并积极探索其他盈利模式。

在这个知识和信息爆炸的时代，昨天你从学校或者公司学到的技术今天再来用，可能它带来的回报还赶不上日新月异的 CPI，正如你看到的，软件行业的门槛已经变得越来越低了。与此同时，貌似没有门槛的做生意却要比汇编还要难掌握。毕竟做买卖这个行当一直存在于人类的历史当中，而软件应用不过才数十年的时光，要掌握一门有着成千上万历史的手艺难度自然可想而知。一流的软件从业人员，不仅是个出色的工程师，而且还是一个优秀的商人，这个不需要解释吧。