HMD的CPOSarvikas很久前就曾表示，HMD旗下的诺基亚智能手机都将升级到安卓8.0系统，而就在昨天首款搭载该系统的Nokia手机终于来了。Sarvikas在推特上晒出了诺基亚8的安卓8.0图片，短短的文字写着诺基亚8终于吃上了奥利奥，而且运行非常流畅，等它各项测试都完美通过后，我们就开放推送，可见安卓8.0给了Nokia不少信心来收复往日的大好河山。与此同时，三星和MOTO也宣布旗下全部主流机型都会升级到安卓8.0，除了这三家机商以外，华为、OPPO等也会在年内将主流机型升级到与8.0匹配的系统。iPhoneX还没上市，8.0就已经小步快跑弯道超车了。

当然除了机商需要适应新的安卓8.0，更多给予安卓环境的系统、软件、app也需要重新适应新的8.0体系。甚至手游发行也需要重新适配8.0体系，如果不快速跟进，未来半年里你的游戏很可能都无法上线，所有的机商适配8.0了，而你的游戏没有，这情何以堪啊！重新适配8.0系统需要做的很多工作，有些细节部分甚至是推倒重来，TypeSDK可以算是反应最快的那批了，早在大家还在聚精会神的研究7.0的时候，TypeSDK就针对即将到来的安卓8.0做了很多准备工作，其中就包括出现在谷歌官方开发文档中明确表示的对反编译打包的不支持，尤其是“APKsignatureschemev2”这条。

由于在v1中仅验证未解压的文件内容，因此在APK签署后可进行许多修改，可以移动甚至重新压缩文件。事实上，编译过程中要用到的zipalign工具就是这么做的，它用于根据正确的字节限制调整ZIP条目，以改进运行时性能。而且我们也可以利用这个东西，在打包之后修改META-INF目录下面的内容，或者修改Zip的注释来实现多渠道的打包，在v1签名中都可以校验通过。但v2签名将验证归档中的所有字节，而不是单个ZIP条目，因此在签署后无法再运行zipalign。现在在编译过程中，Google将压缩、调整和签署合并成一步完成。如有任何自定义任务篡改APK文件或对其进行后处理（无论以任何方式），那么v2签名会有作废的风险。

简而言之就是，出于代码安全或其他一些问题考量，CP是不会把源码给到聚合打包工具进行打包的，那么在出各种渠道包的时候，必须对CP给出的原始安装包进行反编译，再配上不同渠道的id来适配不同渠道的要求。那么在这个反编译过程中，会产生对原始安装包签名的修改，有修改就会导致经反编译打包出来的APK与Android7.0及更高版本的签名不一致导致无法安装，不知道列位是否看明白了。

反编译打包除了谷歌的不支持以外，还有一系列弊端，诸如——

渠道不支持，如果渠道知道游戏开发商没有使用渠道官方提供的SDK，而使用了由第三方提供进行了反编译和修改的渠道SDK后。游戏下架、公司拉黑不是没有可能，如果因此造成渠道用户手机被黑造成经济损失，开发商还会摊上官司。

程序员嫌麻烦，使用反编译方法能简化聚合SDK发布复杂度，但会给使用者造成技术门槛。反编译项目如遇问题，通常会出现闪退、黑屏等状况，而程序员无法判断问题原因，只能等待聚合SDK工具开发者来解决。试想临近上线提包，却因为包有问题毫无办法，只能期望第三方能及时响应解决问题，这简直就是把程序员放在火上烤。

老板投资人不欢迎，反编译方案无法做到真正开源，即使号称服务端和工具代码开源，用户也必须依赖聚合SDK开发者提供的渠道反编译文件合成渠道包。用户使用时间再久也只能依靠第三方，无法做到真正掌握系统。如果公司即将上市，技术审计时被发现有关键系统还掌握在别人手里，自己无法维护更新，这时老板一定想劈了CTO。

TypeSDK早在2017年出就嗅出了这些问题，有针对性的对自己的产品做了大刀阔斧的改动。除了打包工具，TypeSDK还提供了如自主发行、渠道发行等多种发行方式帮助手游快速上线，而且与市面上所有其他的发行解决方案都不同，其他方案只是基于手游厂商的零散需求堆积垒砌出来的产品，缺乏对厂商发行过程中真实问题的认知和实际需求的思考，能做到的只能是头痛医头脚痛医脚。TypeSDK则是一套为研发运营公司内部使用而设计的产品，它几乎涵盖了所有的发行方式，从根本上解决了发行过程中会遇到的所有问题，它的诞生过程是由内而外的，所以设计理念和起点就与其他产品完全不同。其他产品与TypeSDK相比较，完全不具备可比性。

新的安卓8.0已经到来，但想第一时间尝鲜却颇有难度，因为诺基亚8仅在欧洲及部分亚洲的国家开卖，是否会登陆国内市场还是个未知数，想要尝鲜的用户可以直接购买香港版本。但是如果你是手游发行，TypeSDK提供的可是全球发行服务，这个可以比Nokia分区发售给力多了。