⑴ android studio删除后不能再安装，是哪里的问题
它报的错误是安装完整性校验失败，说白了就是你的安装包已损坏，无法安装。请你重新下载一份你再安装
⑵ Android V1及V2签名原理简析
Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：
签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：
再看下只有V2签名的APK包样式：
同时具有V1 V2签名：
可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内， 签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改 ，如下图：
而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：
V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在.rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，
如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFEST.MF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校验就可以绕过。
CERT.SF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFEST.MF一样，.SF校验也很容易被绕过。
CERT.RSA与CERT.SF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERT.RSA文件内容：
CERT.RSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERT.SF的摘要信息，其严格的格式如下：
从CERT.RSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：
除了CERT.RSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFEST.MF与CERT.SF都是一样的，不同的只有CERT.RSA签名文件。也就是说前两者主要保证各个文件的完整性，CERT.RSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？
前面说过V1签名中文件的完整性很容易被绕过，可以理解 单个文件完整性校验的意义并不是很大 ，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是 针对APK进行校验 ，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。
也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。
APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。
而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。
知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：
其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSigner.java的sign函数，函数比较长，分几步分析
先来看这一步，ApkUtils.findZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，
ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：
获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，
可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名
先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。
第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：
步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：
这里特殊提一下重复签名的问题： 对一个已经V1签名的APK再次V1签名不会有任何问题 ，原理就是：再次签名的时候，会排除之前的签名文件。
可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。
V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：
签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，7.0以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于7.0以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：
校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验
这里只关心证书部分：
Android V1及V2签名签名原理简析
仅供参考，欢迎指正
⑶ Android 低功耗蓝牙(Ble) 开发总结
Android 从 4.3(API Level 18) 开始支持低功耗蓝牙，但是只支持作为中心设备（Central）模式，这就意味着 Android 设备只能主动扫描和链接其他外围设备（Peripheral）。从 Android 5.0(API Level 21) 开始两种模式都支持。
低功耗蓝牙开发算是较偏技术,实际开发中坑是比较多的,网上有很多文章介绍使用和经验总结,但是有些问题答案不好找,甚至有些误导人,比如 :获取已经连接的蓝牙,有的是通过反射,一大堆判断,然而并不是对所有手机有用,关于Ble传输速率问题的解决,都是默认Android每次只能发送20个字节,然而也并不是,,,下面进入正文。
这里用的是 Android5.0 新增的扫描API，
这里说一下，如果做蓝牙设备管理页面，可能区分是否是已连接的设备,网上又通过反射或其他挺麻烦的操作,也不见得获取到,官方Api 就有提供
与外围设备交互经常每次发的数据大于 mtu的，需要做分包处理，接收数据也要判断数据的完整性最后才返回原数据做处理，所以一般交互最少包含包长度，和包校验码和原数据。当然也可以加包头，指令还有其他完整性校验。下面分享几个公用方法:
我自己封装的一个BleUtil ，因为涉及跟公司业务关联性太强（主要是传输包的协议不同）就先不开源出来了，如果这边文章对大家有帮助反馈不错，我会考虑上传个demo到github供大家使用，
在这先给大家推荐一个不错 Demo ，里面除了没有分包，协议，和传输速率。基本的功能都有，而且调试数据到打印到界面上了。最主要是它可以用两个个手机一个当中心设备一个当外围设备调试。
首先传输速率优化有两个方向，1 外围设备传输到Android 。2 Android传输到外围设备。
我在开发中首先先使用上面那位仁兄的demo调试，两个Android 设备调试不延时，上一个成功马上下一个，最多一秒发11个20字节的包。
后来和我们的蓝牙设备调试时发现发送特别快，但是数据不完整，他蓝牙模块接收成功了，但是透传数据到芯片处理时发现不完整，我们的硬件小伙伴说因为 波特率 限制（差不多每10字节透传要耗时1ms）和蓝牙模块的buff （打印时是最多100byte，100打印的）限制，就算蓝牙模块每包都告诉你接收成功，也是没透传完就又接收了。后来通过调试每次发20K数据，最后是 Android 发是 20字节/130ms 稳定。给Android 发是 20字节/ 8ms 。 （天杀的20字节，网上都是说20字节最多了）
后来看了国外一家物联网公司总结的 Ble 吞吐量的文章（上面有连接），知道Android 每个延时是可以连续接收6个包的。就改为 120字节/ 16ms (为啥是16ms，不是每次间隔要6个包吗，怎么像间隔两次，这时因为波特率影响，多了5个包100字节，差不多 我们的单片机透传到蓝牙模块要多耗时不到10ms )
而Android 发数据可以申请 我们设备的mtu 来得到最多每次能发多少字节。延时还是130ms，即：241字节/ 130ms 提高12倍，这个速度还可以。
根据蓝牙BLE协议， 物理层physical layer的传输速率是1Mbps，相当于每秒125K字节。事实上，其只是基准传输速率，协议规定BLE不能连续不断地传输数据包，否则就不能称为低功耗蓝牙了。连续传输自然会带来高功耗。所以，蓝牙的最高传输速率并不由物理层的工作频率决定的。
在实际的操作过程中，如果主机连线不断地发送数据包，要么丢包严重要么连接出现异常而断开。
在BLE里面，传输速度受其连接参数所影响。连接参数定义如下：
1）连接间隔。蓝牙基带是跳频工作的，主机和从机会商定多长时间进行跳频连接，连接上才能进行数据传输。这个连接和广播状态和连接状态的连接不是一样的意思。主机在从机广播时进行连接是应用层的主动软件行为。而跳频过程中的连接是蓝牙基带协议的规定，完全由硬件控制，对应用层透明。明显，如果这个连接间隔时间越短，那么传输的速度就增大。连接上传完数据后，蓝牙基带即进入休眠状态，保证低功耗。其是1.25毫秒一个单位。
2）连接延迟。其是为了低功耗考虑，允许从机在跳频过程中不理会主机的跳频指令，继续睡眠一段时间。而主机不能因为从机睡眠而认为其断开连接了。其是1.25毫秒一个单位。明显，这个数值越小，传输速度也高。
蓝牙BLE协议规定连接参数最小是5，即7.25毫秒；而Android手机规定连接参数最小是8，即10毫秒。iOS规定是16，即20毫秒。
连接参数完全由主机决定，但从机可以发出更新参数申请，主机可以接受也可以拒绝。android手机一部接受，而ios比较严格，拒绝的概率比较高。
参考:
在iOS和Android上最大化BLE吞吐量
最大化BLE吞吐量第2部分：使用更大的ATT MTU
⑷ Android之dropbox 分析
简介
adb查询
app接口
dropbox启动
dropbox日志路径：/data/system/dropbox
记录的系统错误
1.系统正常启动后的自检工作
1)SYSTEM_BOOT
开机一次，记录一次
2)SYSTEM_RESTART
如果system_server在设备运行过程中异常，则会有记录
3)SYSTEM_LAST_KMSG
kernel异常。
pstore是persistent storage的缩写，内核发生异常通过此把异常日志记录下来，方便定位问题。
ramoops指的是采用ram保存oops信息(kernel 异常信息)的一个功能，利用pstore技术实现。
4)SYSTEM_TOMBSTONE
TOMBSTONE 是 Android 用来记录 native 进程崩溃的 core mp 日志, 系统服务在启动完成后会增加一个 Observer 来侦测 tombstone 日志文件的变化, 每当生成新的 tombstone 文件, 就会增加一条 SYSTEM_TOMBSTONE 记录到 DropBoxManager 中.
5)SYSTEM_RECOVERY_LOG/SYSTEM_RECOVERY_KMSG
SYSTEM_RECOVERY_KMSG：recovery kerenl日志
SYSTEM_RECOVERY_LOG：recovery 升级或恢复出厂设置等等日志
6)SYSTEM_FSCK
文件系统完整性校验日志
7)SYSTEM_AUDIT
kernel 异常信息的查漏补缺日志
2.java/native crash。-- crash/native_crash
java/亏纯native层异常的区分在于eventType:crash/native_crash
3.anr 异常。-- anr
这里涉及广播、Service、Provider等组件的anr以及触摸按键事件的anr
4.wtf(What a Terrible Failure)。--- wtf
android.util.Log.wtf(String, String)，应用可调用布局异常点
5.strict mode。---**_strictmode
严格模式，主要为性能监测使用
StrictMode (严格模式), 顾名思义, 就是在比正常模式检测得更严格, 通常用来监测不应当在主线程执行的网络, 文件等操作. 任何 StrictMode 违例都会被 ActivityManagerService 在 DropBoxManager 中记录为一次 strict_mode 违例.
6.lowmem。低内存报告
7.watchdog
如果 WatchDog 监测到系统进程(system_server)出现问题, 会增加一条 watchdog 记录到 DropBoxManager 中, 并终止系统进程的执行.
8.其他
1)netstats_error/netstats_mp
NetworkStatsService 负责收集并持久化存储网络状态的统计数据, 当遇到明显的网络状态错误时, 它会亩哪增加一条 netstats_error 记录到 DropBoxManager.
2)BATTERY_DISCHARGE_INFO
BatteryService 负责检测充电状态, 并更新手机电池信息. 当遇到明显的 discharge 事件, 它会增加一条 BATTERY_DISCHARGE_INFO 记销耐咐录到 DropBoxManager.
3)storage_benchmark/storage_trim
StorageManagerService 负责存储设备管理，例如sdcard或usb mass storage
fstrim提升磁盘性能，缓解Android卡顿
4)network_watchlist_report
NetworkWatchlistService
5)incident
frameworks/base/cmds/incidentd
6)keymaster
system/security/keystore
参考学习
⑸ 什么是android apk加固
加固的过程中需要三个对象：1、需要加密的Apk(源Apk)2、壳程序Apk(负责解密Apk工作)3、加密工具(将源Apk进行加密和壳Dex合并成新的Dex)主要步骤：我们拿到需要加密的Apk和自己的壳程序Apk，然后用加密算法对源Apk进行加密在将壳Apk进行合并得到新的Dex文件，最后替换壳程序中的dex文件即可，得到新的Apk,那么这个新的Apk我们也叫作脱壳程序Apk.他已经不是一个完整意义上的Apk程序了，他的主要工作是：负责解密源Apk.然后加载Apk,让其正常运行起来。
⑹ Android | 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 签名机制
这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~
数字签名（Digital Signature）也叫作数字指纹（Digital Fingerprint），它是消息摘要算法和非对称加密算法的结合体，能够验证数据的完整性，并且认证数据的来源 。
数据签名算法的模型分为两个主要阶段：
需要注意的是，Android 目前不对应用证书进行 CA 认证，应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。
应用 APK 其实是一种特殊的 Zip 压缩包，无法避免恶意破解者解压 / 反编译修改内容，针对这个问题有何解决方案呢？他山之石，可以攻玉 ——数字签名算法。应用签名正是数字签名算法的应用场景之一，与其他应用场景类似，目的无非是：
Android 平台上运行的每个应用都必须有开发者的签名。在慧唤安装应用时，软件包管理器会验证 APK 是否已经过适当签名，安装程序会拒绝没有获得签名就尝试安装的应用。
软件包管理器在安装应用前会验证应用摘要，如果破解者修改了 apk 里的内容，那么摘要就不再匹配，验证失败（验证流程见下文方案）。
截止至 Android 11，Android 支持以下三种应用签名方案：
为了提高兼容性，必须按照 v1、v2、v3 的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在 APK 中添加的额外数据。
v1 签名方案是基于 Jar 的签名。
首先，我们先来分析其签名产物。 v1 签名后会增加 META-INF 文件夹 ，其中会有如下三个文件。考虑到使用不同的证书和签名方式，得到的文件名可能不同，因此你只要留意文件的后缀即可：
v1 签名流程如下：
MANIFEST.MF（Message Digest File，摘要文件）
*.SF（Signature File，签名文件）
验证流程可以分为验证签名和验证完整性两个步骤：
验证签名步骤：
如果上述签名验证结果正确，才会验证完整性：
以上任何步骤验证失败，则整个 APK 验证失败。
为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。
v2 签名方案是一种 全文件签名方案 ，该方案能够发现对 APK 的受保护部分进行的所有更改，相对于 v1 签名方案验证速度更快，完整性覆盖范围更广。
在分析 v2 签名方案之前，我们先简单了解一下 Zip 文件格式：
首先，我们先来分析其签名产物。v2 签名后会在 “条目内容区”和“中央目录区”之间插入“APK 签名分块（APK Signing Block）” 。
从左到右边，我们定义为区块 1~4。
相对与 v1 签名方案，v2 签名方案不再以文件为单位计算摘要了，而敬坦是以 1 MB 为单位将文件拆分为多个连续的块（chunk），每个分区的最后一个块可能会小于 1 MB。
v2 签亮碧桐名流程如下：
验证流程可以分为验证签名和验证完整性两个步骤：
签名方案 v3 支持密钥轮换，应用能够在 APK 更新过程中更改其签名密钥。
【累了，后面先不写了...】
这一节，我们介绍基于 Android 应用签名机制的衍生应用场景。
在 v1 方案中， MANIFEST.MF 和 *.SF 这两个文件会记录大量的文件名和文件摘要。如果 apk 中文件数很多，而且文件名很长，那么这两个文件会变得很大。使用 AndResGuard 工具，可以将文件名转换为短路径文件名，从而减少这两个文件的大小。
在实际生产中，往往需要生成多个渠道的 APK 包，传统的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，这一类多渠道打包方案的缺点是耗时严重。随着 Android 应用签名方案的演进，演变出了不同的多渠道打包方案：
在 v1 方案中，我们提到了完整性校验不覆盖到 META-INF 文件夹的问题。有些多渠道打包方案就是利用了这个问题，在 META-INF 文件夹下添加空文件， 用空文件的名称来作为渠道的唯一标识 ，就可以节省打包的时间，提高打渠道包的速度。
除了添加空文件的方法，还可以向 APK 添加 Zip Comment 来生成多渠道包（APK 本身就是特殊的 Zip 包）。
在 v2 签名方案中，几乎整个 APK 都纳入保护范围，如果向 APK 添加空文件或 Zip Comment 的话，在安装时会报以下错误：
新背景下的多渠道打包方案，则是利用了 APK 签名分块（区块 2）不受保护 & 字段可扩展的特点 ，向区块中添加多渠道信息（ID-Value），例如 美团多渠道打包方案 Walle 。
⑺ Android每日一题：v3签名key和v2还有v1有什么区别
答：在v1版本的签名中，签名以文件的形式存在于apk包中，这个版本的apk包就是一个标准的zip包，V2和V1的差别是V2是对整个zip包进行签名，而且在zip包中增加了一个apk signature block，里面保存槐侍签名信息。
v2版本签名块（APK Signing Block）本身又主要分成三部分:
SignerData（签名者数据）：主要包兄明培括签名者的证书，整个APK完整性校验hash，以及一些必要信息
Signature（签名）：开发者对SignerData部分数据的签名数据
PublicKey（公钥）：用于验签的公钥数据
v3版本签名块也分成同样的三部分，与v2不同羡唯的是在SignerData部分，v3新增了attr块，其中是由更小的level块组成。每个level块中可以存储一个证书信息。前一个level块证书验证下一个level证书，以此类推。最后一个level块的证书，要符合SignerData中本身的证书，即用来签名整个APK的公钥所属于的证书
⑻ android 360上架会不会自动加固
不会自动加固的,需要自己手动去处理,参考内容:
360加固保基于360核心加密技术，对安卓应用进行加固保护，能有效避免应用被恶意破解、反编译、二次打包、内存抓取等。同时给应用提供数据加密、签名校验、防内存修改、完整性校验、盗版监测等保护功能，给予安卓应用最强保护，从源头消灭恶意盗版应用。作为移动互联网安全服务行业的领跑者，360加固保将持续关注手机应用安全的发展，不断完善加固保服务，切实保护开发者收入和权益。
⑼ android应用程序中包含的哪些文件不会被证书校验完整性
生成CA私钥圆穗文件ca.key：opensslgenrsa-outca.key1024生成X.509证书签名请求文件ca.csr：opensslreq-new-keyca_private.key-outca.csr在生成ca.csr的过程中，会让输入一些组织信滑腔亩息等。生信森成X.509格式的CA根证书ca_public.crt（公钥证书）：opensslx509-req-inca.csr-signkeyca_private.key-outca_public.crt
⑽ 如何检查android应用被篡改
Android APK如何防篡改？现智能手机逐渐成为大家生活的必备品，手机应用成为手机里的必需品，随之而来的手机应用安全问题则成为了广大用户和开发者最关心的问题。一款好的Android应用一旦获得成功，往往接下来面对的就是各种破解版的疯狂轰炸，那么Android APK如何防止被破解篡改？
方法/步骤
据统计现在中国的独立APP数量已逼近50万，APP开发市场日渐火热，而打包党通过破解、反编译APK，插入广告或收费代码等不法手段来获取巨额利润。Android APK被篡改的主要原因是开发者在防止Android APK篡改、反编译方面重视不够或者技术不完善。由于Android系统的开放性，再加之，业内常用的防止APK篡改、反编译的技术很透明，导致安卓APK能够被轻易篡改破解。盗版APP制造者的行为严重影响了原创APP开发者的利益和APP开发行业健康发展。
据了解，目前不少开发者都在爱加密平台获得了免费保护服务，爱加密是一个针对 Android应用APK进行安全加密保护的服务平台，加密前先会对APK应用进行一个基本的安全检测，然后通过专业的安全加密技术对APK文件进行加壳保护，整体的逻辑构架非常严谨。爱加密目前提出的三层加密保护：DEX加壳保护，DEX指行蚂令动态加载保护，高级混淆保护，可以保证APP的动态安全和静态安全，黑客将没有机会进行任何破解。爱加密更在年前推出了SO库保护，C/C++层面的代码得到了专业保护，让APK包无懈可击。此外，爱加密在服务方面也很是到位，为客户提供精确地APK安全分析检测，并可根据APP开发者的不同要求进行定制 保护，以满足不同APK开发者的需求。
爱加密目前加密应用涉及互联网金融、学习、游戏、生渣纤活休闲等各类应用，如史上最坑爹的游戏、铜板街、WIFI伴侣、JAVA学习手册、史诗塔防、真三国斗地主、美食杰、3D宝软桌面等均使用爱加密的加密服务，经开发者验证爱加密的加密服务确实在防止Android应用如带仿APK篡改、APK反编译、APK动态破解等成效显着。
4
如何帮助更多开发者防止Android APK篡改，这需要一个长期的过程，首先需要开发者增加对Android应用篡改、APK反编译、盗版APP的重视，其次需要开发者从技术手段上加强对自有APK安全的保护，如通过第三方服务平台爱加密进行加密保护。同时，也需要政府加大对盗版篡改的监测和打击，建立一个良好的产业环境。