在我们开发的过程中，几乎每天都需要打包生成apk安装包，那我们是否有仔细的了解过一个apk从生成，到最后用户的使用过程中，都会经历什么样的过程，中间的实现原理是如何的，下面我们就一起了解一下吧。
Apk的生成过程：从Android Studio的项目创建到---------> 各大应用应用商店上架的Apk文件， 中间经历了什么？
知识点汇总：
一：生成各种代码，资源文件，依赖包等文件，通过Gradle构建生成Apk。
二：通过jks签名文件，对生成的Apk文件进行签名。
三：通过AndResGuard，Proguard对签名Apk进行混淆
四：通过爱加密，腾讯乐固等第三方工具，对Apk进行加固
五：通过了解各大应用商店的上架要求，完成Apk的上架
六：扩展阅读
一：各种代码，资源文件，依赖包等文件，通过Gradle构建生成Apk
我们从立项到后续的迭代开发，大部分时候都是填充下面的配置文件和源码文件，我们在开发的过程中需要了解下面各个文件的作用是什么？
项目配置文件：
1、AndroidManifest.xml文件。
2、各种Build.Gradle配置文件。（grovvy语言）
3、proguard_rules.pro配置文件。
4、jks或keystore签名文件。
项目源码文件：
1、AIDL文件。（多进程）
2、src文件夹各种java源码文件。
3、res文件夹各种资源文件。
4、asset文件夹文件。
5、各种依赖的jar包。
6、各种依赖的aar包。
7、各种依赖的module项目。
8、各种依赖的.so文件。（JNI开发）
我们知道，在做开发的时候，我们的开发平台需要依赖JDK和SDK，其实在JDK和SDK中，里面除了开发需要的API源码，里面还包含生成apk所需要的各种各样的插件，下面就一一介绍这些插件吧。
生成Apk相关插件介绍：
附加：jarsignr是Java本生自带的一个工具，他可以对jar进行签名的。而signapk是后面专门为了Android应用程序apk进行签名的工具，他们两的签名算法没什么 区别，主要是签名时使用的文件不一样。
Apk的生成流程：（谷歌官方）
我们仔细的看看这张图的流程，最后会生成一个签了名的apk文件，apk文件其实是一个压缩文件，我们可以看看apk文件包含了什么？
Apk文件的组成：（解压看看apk的组成）
各个文件夹的作用：
Apk各个文件夹详解：
Assets目录：存放需要打包到APK的静态文件，该目录与res目录不同之处在于,Assets目录支持任意深度的子目录，我们的开发者可以根据自己的需求来任意部 署文件夹的架构，而且res目录下的文件会在.R文件中生成与其对应的资源ID，， Assets不会自动生成对应的id，访问的时候需要AssetManager类。
Lib目录：该目录用来存放应用程序所依赖的native库文件，native库一般是用C/C++进行编写的，这里的lib库可能包含4种不同类型，根据CPU型号的不同，我们大体可 以分为ARM，ARM-v7a，MIPS，X86，分别对应着ARM架构，ARM-V7架构，MIPS 架构和X86架构，这些so库在apk包中构成如下图： 其中，不同的CPU架构对应着不同的目录，每个目录中可以存放非常多的对应版 本的so库，而且这个目录的结构固定，用户只能按照这个目录来存放自己的so库。 目前市场上使用的移动终端大多是基于ARM或者ARM-v7a架构的。从厂家上来分 是有三种，arm，x86，MIPS，arm 系列是绝大多数手机上使用的，x86 主要是运 用在平板上，而 MIPS ，我基本上就没见过。
Res目录：res是resource的缩写，这个目录存放的东西是资源文件，存放这个文件夹下的所有文件都会和上文所说的，映射到Android工程中的.R文件中，生成对应 的资源ID，访问的时候直接使用资源ID，即R.ID.FILENAME，res文件夹下可以包 含多个文件夹；anim是存放动画文件的；drawable目录存放图形资源；layout目录 存放布局文件；values目录存放一些特征值；colors.xml存放color的颜色值等等。
META-INF目录：保存应用程序的签名信息，签名信息可以验证APK文件的完整性。当AndroidSDK在打包APK文件时会计算APK包中的所有文件信息的完整性，并且把 这些完整性保存到META-INF文件夹下，应用程序在安装的时候首先会根据META-INF文件夹校验APK的完整性。通过这种手段，我们就可以在一定程度上保证APK中的每一个文件不被篡改。以此来确保我们的APK应用程序不被恶意修改或者被病毒文件感染，这有利于确保Android应用的完整性和系统的安全性。META-INF目录中包含 的文件有CERT.RSA，CERT.SF和MANIFEST.MF。其中CERT.RSA是 开发者利用私钥对APK进行签名的签名文件，CERT.SF和MANIFEST.MF记录了文件 中文件的SHA-1哈希值。
AndroidManifest.xml：这是Android应用程序的配置文件，是一个用来描述Android应用“整体咨询”的设定文件，简单的说，这相对于Android应用向Android系统的“自我介绍”配置文件，Android系统可以根据Androidmanifest.xml文件来完整的了解这个APK应用程序的咨询。不难想到，每个Android应用程序都必须包含一个Androidmanifest.xml文件,并且它的名字是固定的，是禁止修改的。
classes.dex：传统的Java程序，首先先把文件编译成class文件，字节码都保存在了class文件中，Java虚拟机可以通过解释且执行这些class文件。然而Dalvik虚拟机是在Java虚拟机进行了优化，执行的是Dalvik字节码，而这些Dalvik字节码就是由Java字节码转换而来的。一般来说，Android应用在打包的时候通过AndroidSDK中的dx工具将Java字节码转换为Dalvik字节码。Dx工具可以对多个class文件进行合并，重组和优化，通过这些操作，可以达到减小体积，缩短运行时间的目的。
Resources.arsc：用来记录资源文件和资源ID之间的映射关系，用来根据资源ID寻找资源。Android的开发是分模块的，res目录专门用来存放资源文件，当在代码中需要调用资源文件时，只需要调用方法“findviewbyid()”就可以得到资源文件，每当在res文件夹下放一个文件，aapt就会自动生成对应的ID保存在.R文件，我们调用这个ID就可以，但是只有这个ID还不够，.R文件只是保证编译程序不报错，实际上在程序运行时，系统要根据ID去寻找对应的资源路径，而resources.arsc文件就是用来记录这些ID和资源文件位置对应关系的文件。
二：通过jks签名文件，对生成的Apk文件进行签名
签名流程：对APK中所有文件内容分别进行Hash计算，并将结果以BASE64编码格式保存在MANIFEST.MF。使用开发者的私钥对MANIFEST.MF进行加密，将加密结 果保存在CERT.SF。最后CERT.RSA(证书信息包括公钥）和上面的两个文件，放入 APK的META-INF目录下。
两种签名机制V1和V2的区别：V1：通过ZIP条目进行验证，这样APK 签署后可进行许多修改可以移动甚至重新 压缩文件。 V2：验证压缩文件的所有字节，而不是单个 ZIP 条目，因此，在签名后无法再 更改(包括 zipalign)。正因如此，现在在编译过程中，我们将压缩、调整和签署合 并成一步完成。好处显而易见，更安全而且新的签名可缩短在设备上进行验证的 时间（不需要费时地解压缩然后验证），从而加快应用安装速度。
附加：Android 7.0引入一项新的应用签名方案APK Signature Scheme v2，它能提供更快的应用安装时间和更多针对授权APK文件更改的保护，在默认情况下，Android Studio 2.2和 Android Plugin for Gradle 2.2 会使用APK Signature Scheme v2和传统签名方案来签署您的应用。
签名文件jks详解：
描述：jks文件是一个java中的密钥管理库，里面存放我们的私钥，公钥以及证书。
使用：应用发布上线的时候,使用jks文件对其签名,可以防止应用被恶意篡改替换，同样也是开发者身份的标识，加强应用的安全性。
日常开发中经常会使用到地图,分享,支付等的第三方框架,申请时往往需要填入应用的sha1值,正式发包时使用的是jks文件中的sha1值,本地测试时使用的是本地的debug.jks中的sha1值。
得到了jks文件中的SHA1值,这个值就是申请时需要填入各个第三方平台的正式包的值SHA1值。这个SHA1值就是证书指纹，是对证书的数据摘要，证书是隐式创建的，提取一下jks文件中的证书文件，再对证书文件进行摘要,使用sha1算法后，也就是是jks中的SHA1值。
Apk签名需要解决什么问题：
第一点：如何判断证书是否有效
因为签名的时候是使用私钥对MANIFEST.MF进行加密保存在CERT.SF中， 之后只需要用证书中的公钥对CERT.SF进行解密，将结果和MANIFEST.MF进行 比较即可，注意，在证书正确的情况下如果更改的APK里面文件内容，此时以上 判断还是不会通过。因为MANIFEST.MF保存的是APK里面所有文件的Hash值， 只要改变了APK里文件内容，Hash值就会变化。
第二点：如何判断APK是否被更改
在签名保证MANIFEST.MF有效的前提下，只要对当前APK所有文件的内容 的Hash值的BASE64编码和MANIFEST.MF相应文件存的值进行比较即可。
安装应用时PackageManagerService会对APK进行签名检查，具体分为以下几步：1.读取CERT.RSA(证书信息包括公钥）、MANIFEST.MF、CERT.SF 2.使用获取的公钥对CERT.SF解密，将解密结果和MANIFEST.MF进行比较，如果相同说明证书有效、MANIFEST.MF未被更改。 3.对APK中所有文件内容分别进行Hash计算，将结果的BASE64编码和MANIFEST.MF里的相应内容进行比较，全部相同则APK的内容未被更改。
三：通过AndResGuard，Proguard对签名Apk进行混淆
背景：由于java和.net这类高层抽象语言，具有天生的易反汇编特性，其编译后的程序包包含了大量的源代码变量、函数名、数据结构等信息，根据其编译后的程序包，可以非常容易的得到近乎源代码质量的反汇编代码。如果不加混淆，相当于直接将源代码拱手送人，内容严密的app权限审核可以说是形同虚设。如果大家想避免源代码泄漏后重新修改策划而额外增加的工作量，建议都加上混淆。
介绍：ProGuard是一个免费的java类文件压缩,优化,混淆器.它探测并删除没有使用的类,字段,方法和属性.它删除没有用的说明并使用字节码得到最大优化.它使用无意义的名字来重命名类,字段和方法。
ProGuard功能介绍：
1、压缩。移除无效的类、类成员、方法、属性等；
2、优化。分析和优化方法的二进制代码；根据proguard-android-optimize.txt中的描述，优化可能会造成一些潜在风险，不能保证在所有版本的Dalvik上都正常运行。
3、混淆。把类名、属性名、方法名替换为
简短且无意义的名称；
4、预校验。添加预校验信息。这个预校验是作用在Java平台上的，Android平台上不需要这项功能，去掉之后还可以加快混淆速度。
混淆原理：用“ 不能直接猜出含义 的通用变量名和函数名a b c等”替换编译后程序包中“ 具有明显语义信息的变量名和函数名”，这样，通过逆向工程得到的只是难以理解的代码。
混淆 ProGuard常用语法：
1、-libraryjars class_path 应用的依赖包，如android-support-v4
2、-keep [,modifier,...] class_specification 不混淆某些类
3、-keepclassmembers [,modifier,...] class_specification 不混淆类的成员
4、-keepclasseswithmembers [,modifier,...] class_specification 不混淆类及其成员
5、-keepnames class_specification 不混淆类及其成员名
6、-keepclassmembernames class_specification 不混淆类的成员名
7、-keepclasseswithmembernames class_specification 不混淆类及其成员名
8、-assumenosideeffects class_specification 假设调用不产生任何影响，在proguard 代码优化时会将该调用remove掉。如system.out.println和Log.v等等 -dontwarn [class_filter] 不提示warnning
附加：混淆配置开源项目：https://github.com/msdx/android-proguard-cn
从混淆的原理可以得出以下两点信息：
１、重命名变量名可能会导致程序异常。因为程序是需要跟平台交互的，平台只会以固定类名来调用我们的app，这就涉及到需要屏蔽不能重命名的函数及类 proguard.cfg文件就是起这个作用的，混淆后哪个地方出错，就将相关的类和函数加入到混淆屏蔽列表里面去。
２、由于混淆只改变字符串，并不能改变程序逻辑，耐心的hacker还是能够理解程序的设计思路并尝试修改。但这类人群不会太多，加上有我们自定义框架的牵制，逆向工程也绝非轻而易举。
在package编译时使用proguard混淆，即使用晦涩的名字重命名类名、字段名、函数名,以精简、优化和混淆代码。使用proguard处理的好处是apk文件会有一点点变小，同时更加难于被反编译。
混淆代码的好处：
1、创建紧凑的代码文档是为了更快的网络传输,快速装载和更小的内存占用。
2、创建的程序和程序库很难使用反向工程。
3、所以它能删除来自源文件中的没有调用的代码。
4、充分利用java6的快速加载的优点来提前检测和返回java6中存在的类文件。
检查混淆和追踪异常：
混淆过的包必须进行检查，避免因混淆引入的bug，一方面，需要从代码层面检查。使用上文的配置进行混淆打包后在
1、dump.txt：说明apk中所有文件的内部结构。
2、mapping.txt：提供原始和混淆过的类，方法和字段名称之间的转换。
3、seeds.txt：列出未进行混淆的类和成员。
4、usage.txt：列出从apk移除的代码。
高级混淆的方法：
因为Java语言是支持双字符的，所以可以将包名，类名，变量名，方法名定义成中文，或者其他国家的语言都可以的。
混淆一般是采用了proguard.jar工具，这个工具混淆之后的代码默认都是26个大小写字母，所以如果想把代码混淆成中文，那么就需要对这个工具下手，由于 proguard.jar是一个开源项目，我们可以通过修改源码里面的SimplyNameFactory的代码，从而可以修改成中文，也可以修改成其他国家的语言。
效果图：
付费混淆方案：
Android默认集成了ProGuard,它是一个免费的用于压缩、优化和混淆Java字节码的工具，混淆的功能主要是用简短的无意义的字母组合来对代码中的类、字段、方法和属性进行重命名，但它无法对字符串进行混淆。
即使用Proguard后，我们还是可以看到反编译后代码中完整的字符串定义，我们可以选择商业版的Proguard-DexGuard。DexGuard对代码、资源、字符串、AndroidManifest.xml等进行了全面的加密和混淆。
混淆资源：
资源加载过程分析：
在开发过程中我们通过aapt生成的R.java中的常量来使用资源，而在编译之后使用常量的地方都会被替换为常量的值，也就是说我们通过Resource使用一个int数值来查找使用资源。那么Resource是怎么通过int数值找到具体的资源呢？我们解压apk可以看到里面有个resources.arsc文件，这个文件也是由aapt生成，文件中保存着资源id和资源key的映射关系。Resource就是按照这个映射关系找到资源的。
资源混淆原理和实现：
一般情况下查找资源的过程中不会用到资源名，也就是key。当然res数据中也有当前res的key在key string pool中的索引，但一般情况下用不到。根据这个原理我们可以在打包完成之后对key进行混淆。而且刚刚说到res数据中保存的都是字符串在string pool中的索引。所以我们混淆只需要修改res string pool和spec string pool两个字符串池。其他的数据不用修改，从而实现，资源名在在最终的 Apk中得到修改。
混淆资源的好处：
1、解决apk瘦身,主要就是压缩了资源文件。
2、修改了文件名字及映射关系，即使用晦涩的名字重命名。
混淆资源的方案：
1、微信资源混淆方案（https://github.com/shwenzhang/AndResGuard）
2、美团资源混淆方案（仅仅是提供了修改的思路,并未将混淆的函数公开）
四：通过爱加密，腾讯乐固等第三方工具，对Apk进行加固
加固原理分析：
1、为什么要对原始dex进行加密，同时用脱壳dex文件替换原始dex文件？大部分的apk反编译工具（dex2jar、apktools、jui等）都是对dex文件进行反编译，将dex文件反编译成smail，然后再转化成class文件进行阅读和修改。用脱壳dex替换原始dex文件之后，用上面的反编译工具反编译apk文件，只能看到脱壳程序的class文件，看不到apk本身的class文件。对dex文件进行加密，这样即使第三方拿到了dex文件，也无法解密，也就无法对其进行解析和分析。
2、怎么确保apk功能正常运行？加固后的apk启动之后，脱壳dex文件会对加密后的dex文件进行解密，然后基于dexclassload动态加载解密后的dex文件。从用户的角度，加固前后App的功能和体验基本是一样的。这个和插件化的原理是一样的。
3、dex加固主要是防止被静态反编译，进而获取源码并修改。
对App dex进行加固的基本步骤如下：
1、从App原始apk文件里获取到原始dex文件。
2、对原始dex文件进行加密，并将加密后的dex文件和相关的文件存放到assert目录里。
3、用脱壳dex文件替换原始apk文件里的dex文件；脱壳dex文件的作用主要有两个，一个是解密加密后的dex文件；二是基于dexclassloader动态加载解密后的dex文件。
4、因为原始apk文件已经被修改，所以需要删除原始apk的签名信息，即删除META-INF目录下的.RSA、.SF 和MANIFEST.MF文件。
5、生成加固后的apk文件。
6、对加固后的apk文件进行签名，apk加固完成。
大致流程图：
1、源apk：需要加密的apk程序，源dex来自于源apk。
2、壳程序：Android工程，提供壳dex，壳dex主要作为工程入口，解密出源dex，映射到源dex等操作。
3、加密程序：java工程，主要是做对源dex加密且和壳dex合并成新dex的操作。
加固的优点：
1、对App进行加固，可以有效防止移动应用被破解、盗版、二次打包、注入、反编译等，保障程序的安全性、稳定性。对于金融类App，尤其重要。
加固的缺点：
1、无法摆脱对JNI的依赖，存在被记录修复的可能性。
2、由Java转换成等价的C/C++,会导致体积程线性增大，性能有所下降。
附加：（腾讯乐固）
免费版本：使用通用加固策略，保证基本的 App 安全，普遍适用于各种应用，稳定 性和兼容性可靠。
收费版本：是针对于应用自身的特性，及用户需要，专属加固策略，实现更高的 App 安全标准；同时，基于人工的加固策略审核，以及加固后的兼容性测试服务，可以 更好的保证应用加固后的稳定性和兼容性。
加固技术发展历程：
传统App加固技术，前后经历了五代技术变更，保护级别每一代都有所提升，但其固有的安全缺陷和兼容性问题始终未能得到解决。而下一代加固技术—虚机源码保护，适用代码类型更广泛，App保护级别更高，兼容性更强，堪称未来级别的保护方案。
图解：
第一代加固技术：动态加载
描述：用于保护应用的逻辑不被逆向与分析，最早普遍在恶意软件中使用，其主要 基于Java虚拟机提供的动态加载技术。
第二代加固技术：不落地加载
描述：在APK修改方面已经完善，能做到对开发的零干扰。开发过程中不需要对应 用做特殊处理，只需要在最终发布前进行保护即可。而为了实现这个零干扰的流程 ，Loader需要处理好Android的组件的生命周期。
第三代加固技术：指令抽离
描述：由于第二代加固技术仅仅对文件级别进行加密，其带来的问题是内存中的 Payload是连续的，可以被攻击者轻易获取。第三代加固技术对这部分进行了改 进，将保护级别降到了函数级别。
第四代加固技术：指令转换/VMP
描述：第三代加固技术在函数级别的保护，使用Android虚拟机内的解释器执行 代码，带来可能被记录的缺陷，
第四代加固技术使用自己的解释器来避免第三代 的缺陷。而自定义的解释器无法对Android系统内的其他函数进行直接调用，必须 使用JAVA的JNI接口进行调用。
第五代加固技术：虚机源码保护
描述：跟第四代的VMP加固技术，虚机源码保护加固是用虚机技术保护所有的代 码，包括Java，Kotlin，C/C++，Objective-C，Swift等多种代码，具备极高的兼容 性；使App得到更高安全级别的保护，运行更加稳定。
五：通过了解各大应用商店的上架要求，完成Apk的上架
背景：国内目前流量逐渐中心化，而一些还不错的小市场逐渐被各种收购，更加造成了目前这种流量集中的情况。 所以在这种情况下，就没必要花费太多精力上n个市场。一般来讲的话，应用发到百度、小米、vivo、360、应用宝、华为、oppo、魅族、pp助手、豌豆荚这几个市场就可以了。
多渠道打包工具：
1、美团wallehttps://github.com/Meituan-Dianping/walle
2、腾讯VasDollyhttps://github.com/Tencent/VasDolly
一般市场所需其他资质如下：
1、影音娱乐：视频播放器、音乐播放器及电台需要《计算机软件著作权证书》，网络直播及美女主播需要《信息网络传播视听节目许可证》或《网络视听许可证》或《节目制作经营许可证》等相关资质证件。
2、新闻阅读： 《计算机软件著作权证书》或《互联网新闻信息服务许可证》等企业相关经营许可资质。
3、金融理财：
涉及金融产品支付、银行、网贷需要《支付业务许可证》或《金融许可证》或《融资性担保机构经营许可证》或者《资金托管协议》+授权方《支付业务许可证》。
涉及证券、期货、基金需要《中华人民共和国经营证券业务许可证》或《经营期货业务许可证》或《中华人民共和国基金销售业务资格证书》等相关业务许可证书或者《营业执照》(经营范围标明有相关业务许可的)。 涉及彩票需要《彩票中心授权书》+《计算机软件著作权证书》。 涉及金融理财资讯需要《营业执照》(经营范围标明金融信息咨询、证券咨询等相关信息)。
涉及贵金属类需要《计算机软件著作权证书》+《贵金属交易相关授权资质》。
4、医疗健康：涉及支付、医生问诊的应用需提供《互联网医疗保健信息服务审核同意书》或《中华人民共和国互联网药品信息服务资格证书》等相关医疗执业许可证书。
5、学习办公： 有支付项，提供《计算机软件著作权证书》。
6、社交通讯： 涉及支付、同城交友、网络电话、网赚、红包需提供《计算机软件著作权证书》,然后发布到各个市场，等审核就可以了，一般1~5天应用就会上线。
APP上架到各大应用市场技巧：
1、安卓各大应用市场都需要软件著作权，而且基本上都要实名制，实名制的信息得与著作权一致就是公司的完全一致。所以APP开发期间，就应该着手申请著作权，基本上最便宜300块可以搞掂，加急的话几千到上万都可能。一般建议打好提前量。一般易版权各家主流平台认的多些，但是态度不咋地。
2、应用宝及小米，华为市场要求安装之后的APP名字和著作权，提交的名字完全一致，否则会直接拒绝。
3、应用宝要求APP必须要能退出，所以最好在首页连续两秒重复按退出就提示并退出。但是苹果缺禁止任何形式的退出APP的行为，否则直接拒绝。 4、苹果绝对禁止任何形式的更新，哪怕是检测跟应用商店绑定的。苹果认为更新的事情应该由他们来提示用户，而且把升级的权利交给用户。如果你非要加自动升级，那切记千万不要在软件审核期间打开或者提示否则必拒。
5、应用宝可以在微信内直接可以安装，一般我们会视为安卓发布最重要的一步，而且要求最多，如果应用宝获得通过，VIVO/OPPO会自动采集，比较方便。但是应用宝的后台数第一难用，切记每次退回来之后，记得把编译序号加一，上传安装包之后保存之后再刷新，看看是不是最新的。他们的缓存非常严重！
6、如果APP需要登录，应用宝一定要把APP的账号和密码做一张图片，上传到证书栏，不然肯定不能过。
7、苹果没事不要把最小年纪选的太低，尤其有资讯的，有图片的，苹果卡的太严了，最好选17+。图标更加不能更色情，图片和内容最好别跟性扯上关系。
8、H5的应用功能不能太简单，不然很难过小米和苹果。如果栏目有内容，最好都填好。不要控，不然小米很难过。
9、乐视手机不要管了，他们的审核人员都辞职了。根本不会有人搭理你。
10、苹果申请使用摄像头，相册，日历的时候，一定要把plist文件的描述写的非常清楚，不然会直接拒绝，参考范例，因需要拍摄个人头像，请您授权应用使用你的摄像头。
11、APP不要带会造成程序奔溃的BUG，不然一定会被各大应用市场拒绝。尤其是苹果，我在后台监控过，他们当真会把每个APP的功能都点击一遍。。我的APP他们查了20分钟。
12、一般建议提交顺序为先安卓，后苹果。安卓先提交VIVO，OPPO，他们较为容易，而且他们会乱采应用宝的APP，你再上传就要认领APP，很麻烦。再小米，华为，魅族，三星，这几个市场都覆盖的话，基本上安卓各大手机品牌覆盖完了。然后是应用宝，阿里，最后是百度。百度对资质要求最高。可以其他都上传好了再找百度。他们一般会看了别人都上了，那我也上吧。至于苹果，得预留2-3个月的审核时间。
13、应用宝和360要求App必须要加固，但是他们的在线加固不靠谱，经常失败。建议用应用宝的离线版本来加固，速度快多了。
六：扩展阅读
1、https://blog.csdn.net/Qiled/article/details/80984385（APK基本文件结构）
2、https://blog.csdn.net/zxt94/article/details/72764824（ 各大应用商店APP上架指南）
3、https://blog.csdn.net/admans/article/details/83578444（ APP上架到各大应用商店的小总结）
4、https://blog.csdn.net/u010610734/article/details/83104544（Android各大主流 应用市场地址以及素材要求）
5、https://www.jianshu.com/p/b0242614150b（APP上架到各大应用市场技巧）
6、https://www.jianshu.com/p/f982fe73490f（Android安全防护之旅---带你把Apk 混淆成中文语言代码）
7、https://www.cnblogs.com/cute/p/4809386.html（Android中的Apk的加固(加壳) 原理解析和实现）
8、https://blog.csdn.net/tabactivity/article/details/81318036（APP加固技术历程 及未来级别方案：虚机源码保护）
9、https://www.jianshu.com/p/e12f738a81e9（Android签名打包中的jks文件）