做好的apk文件，被检测工具检测出一大堆风险问题，是不是感觉自己的付出白费了，今天咱就聊聊android的安全防范问题。
一，先说安全检查方面的吧
1，源文件安全问题方面
1.1篡改和二次打包风险
1.2应用签名未校验风险
1.3Java代码反编译风险检测
1.4代码未混淆风险检测
1.5资源文件泄露风险检测
2，数据存储安全问题方面
2.1 WebView明文存储密码风险检测
2.2Internal Storage数据全局可读写风险检测
3.3加密算法不安全使用风险
4.4日志数据泄露风险
4.5URL硬编码风险
3，组件风险
3.1Activity组件导出风险
3.2Service组件导出风险
3.3Content Provider组件导出风险
3.4Broadcast Receiver组件导出风险
3.5WebView远程代码执行漏洞
3.6Intent Scheme URL攻击风险
4，安全防护能力
4.1Java层代码动态调试风险
4.2C层代码动态调试风险
4.3动态注入攻击风险
4.4模拟器运行风险
4.5启动隐藏服务风险
4.6Root设备运行风险
5，内容风险
5.1自定义词汇
5.2敏感文本
5.3敏感图片
这种类型的风险存在于发布文章类或信息类应用，“涉黄”，“赌博”等词汇与图片需要进行敏感内容识别或过滤。为了节约成本，可以人工审核信息来完成，当然，这样工作量太大，要是有Money的话可以介入专业的
检测公司API，来让应用的内容安全做的更严密些。
二，在自己没钱的情况下，看我们能做哪些事吧
1，打包应用，基本要加的就是混淆了，当然，我们还要再创建一个签名文件
2，要是我们应用体积大了，还可以再压缩一下资源文件，我用 的是 AndResGuard
3，没钱，没办法啊，那就来个免费的加固服务吧。
做到这些，是不是大家都觉得，我也是这样做的。是的，一般我们程序都会做这些基本的操作，但是我们还可以再做些什么？
情况1，应用被反编译后二次打包了----apk在正式打包后生成hash签名保存在服务端。应用每次启动后校验当前应用hash与服务端保存的是不是一致，以此来校验应用是不是合法的。嘿嘿，是不是解决问题的一种方法了
上代码：
/**
* 根据apk MD5摘要获取对应的哈希值
*
* @param context
* @return
*/
public static String getApkHashValue(Context context) {
String apkPath = context.getPackageCodePath(); // 获取Apk包存储路径
try {
MessageDigest dexDigest = MessageDigest.getInstance("MD5");
byte[] bytes = new byte[1024];
int byteCount;
FileInputStream fis = new FileInputStream(new File(apkPath)); // 读取apk文件
while ((byteCount = fis.read(bytes)) != -1) {
dexDigest.update(bytes, 0, byteCount);
}
/* BigInteger bigInteger = new BigInteger(1, dexDigest.digest()); // 计算apk文件的哈希值
String sha = bigInteger.toString(16);*/
//解决MD5在特殊情况下丢失0的情况
StringBuffer buf = new StringBuffer();
byte[] b = dexDigest.digest();
int i;
for (int offset = 0; offset < b.length; offset ) {
i = b[offset];
if (i < 0) {
i = 256;
}
if (i < 16) {
buf.append("0");
}
buf.append(Integer.toHexString(i));
}
fis.close();
return buf.toString();
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
return "";
} catch (FileNotFoundException e) {
e.printStackTrace();
return "";
} catch (IOException e) {
e.printStackTrace();
return "";
}
}
情况2；很多时候apk被反编译或被破坏，多通过模拟器或者获取root权限来操作
没办法，只能给模拟器说再见了。正式发布程序后，代码检测运行设备是否是模拟器，如果是的话，就不让运行了，root 设备一样的验证逻辑，简单粗暴!!!
但是root或模拟器检测并没有官方的或权威的检测代码，谁让android品牌太多太杂了捏，没办法。真遇到这种兼容性问题的话，没事，我们可以再做检查逻辑时，留一手服务端验证，
由服务端来控制这个版本或者某个用户走不走这部分验证逻辑额~~~~~，后边的可以自行发挥解决。
情况3，动态调试，内存读取......
和情况2思路一致，均是通过代码来检测是否有调试等工具在调试程序，然后做出相应的判断处理
其他情况都比较常见了，随便百度就能找到解决方法，这里就不啰嗦了。嘿嘿
最后，要是你们公司很有钱，那就不考虑那么多了，来个专业机构加密，一下风险就降到最低，只要有money~
没有绝对的安全，我们能做的就是把安全风险降到最低，欧力给！
以上就是浅谈Android安全风险与防范措施的详细内容，更多关于Android安全风险与防范措施的资料请关注Devmax其它相关文章！