apk

问题一： 使用apktool回编译时部分Apk时出现错误。 具体错误为：brut.androlib.AndrolibException: brut.common.BrutException: could not exec: […以下省略若百字…\AndroidManifest.xml] 原因： Apk资源过多 解决： 下载最新的apktool， 下载地址 。 问题二： 使用apktool回编译时Apk时出现错误。 具体错误为： error: No resource identifier found for attribute ‘compileSdkVersion’ in package ‘android’ error: No resource identifier found for attribute ‘compileSdkVersionCodename’ in package ‘android’ 原因： 找不到对应资源 解决： 打开AndroidManifest.xml，删除对应语句就好。 来源： CSDN 作者： yeliang23 链接： https://blog.csdn.net/qq_18704911/article/details/104053283

前景 抓住两个点， 有效的 和 APK下载 。 正常的判断一个url是否有效 解决这个的思路很简单，就是判断建立的HttpURLConnection的返回的HttpCode是否为200。 url带有重定向的情况 如果你提供的网址存在了一个重定向的情况，比如 ，服务器为了安全起见 ，买了SSL证书，以前的http请全部都要走https，这之后肯定就要把http上面做一个https的映射。 实例说明：在浏览器中发送了一个获取apk的资源 url是否是一个有效apk的下载地址 /** * 判断地址是否有效的apk下载地址 * @param apkUrl apk下载的地址 * @return 是否可下载 */ public static boolean urlIsValidForApk ( String apkUrl ) { try { URL url = new URL ( apkUrl ) ; HttpURLConnection connection = ( HttpURLConnection ) url . openConnection ( ) ; int reponseCode = connection . getResponseCode ( ) ; String contentType = connection . getContentType ( ) ; if (

一、APP加固的概念 　　APP加固是指通过一些加固技术对apk进行加固，防止别人反编译我们的apk获取源码和资源文件，大致原理是：先将java语法翻译成c/c++代码，然后将c/c++代码编译成.so库。目前市场主流的APP加固公司有三家，分别是：梆梆加固，360和爱加密。他们的大致流程如下： 　　首先，去对应网站注册帐号； 　　然后，上传已经签名过的app到网站，等待加固完成； 　　最后，加固完成后，下载加固好的apk文件，注意，由于对apk加固会更改apk文件，因此下载下来后，还需要对apk进行重新签名，每个网站都提供了自己的签名工具。 　　APP加固方案的比骄傲总结： 　　总结：梆梆加固和360加固会隐藏应用的包和类，而爱加密会保留包、类及方法，只不过方法都会变成空方法，所以我觉得前两款加固效果更好一些。 来源： https://www.cnblogs.com/yegong0214/p/6502407.html

面试题：都说枚举性能不好，不好在哪里？现在有什么优化的方案如何解决的？ 首先我们可能要了解一下枚举，以前看性能优化的文章，都说不要使用枚举，因为枚举占用内存大，占用apk空间大，但是一直也不知道原因。 1 09年谷歌官方视频有说，使用枚举会让apk比原来要大大约13倍的空间。 有人可能会有疑问，你咋知道是13倍呢？ 大兄弟，消消气，是不是13倍，我们可以自己新建一个工程，然后打包，然后再加入枚举，然后再打包，两个apk进行比较就知道是不是13倍了。 温馨提示：现在jdk普遍都在1.5之上了，枚举性能不好是好多年之前了，所以你如果要测试，最好把jdk安装在1.1版本上，这样才会有效果。 2 使用枚举不仅仅让apk的包变大，也会让内存上涨，谷歌官方视频说使用枚举会比使用常量要多2倍的内存。 那么这个2倍又是怎么计算出来的呢？ 首先我们需要了解我们创建的枚举编译之后是什么样。 public enum SexEnum { MAN , WOMAN ; } 当我们使用javap编译上边文件之后，得到如下的文件 public final class SexEnum extends Enum { public static final SexEnum MAN ; public static final SexEnum WOMAN ; private static final SexEnum

　　最近在做一个android项目，因为非开源，github上也没购有私有库，所以就没有提交github管理。昨天我感觉写到了一定程度，一个小的版本已经出来了，于是就想U盘和网盘都备份一下。结果出现了下面的一幕....... 　　我点了两次重试，没用；再点跳过，然后什么都没有复制。我再看想要复制的文件夹，找不到了........ 　　尼玛坑爹的微软……不让我复制也不要把原来的弄丢啊......无奈之下我赶紧上网搜一下“一个意外错误使你无法复制该文件夹”，发现也有不少人遇到同样的问题，但都没有解决办法。于是我又想试试能不能数据恢复，然后下载了好几个数据恢复软件，不仅扫描过程要很久，而且根本找不到刚刚莫名其妙丢失的文件。 要是丢失的是其他文件，可能到这也就结束了，但丢失的是android项目文件，而且我是用真机调试过的，于是我就想能不能获取手机的安装文件，再想办法恢复源文件。我之前接触过一点反编译，对于没有经过特殊处理的apk，反编译的效果还是非常好的。就算不好也要试一试了，反正已无其他办法..... 1.获取apk 　　要进行反编译，首先要获取目标文件。我一开始想的是如何获取已安装的dex文件，但在手机上安装文件被系统隐藏起来了，没root根本没办法查看。那，只能 root ？ 我又上网搜了各种从已安装程序获取安装包的方法，发现有一个说android系统在安装完程序后

本文源地址 ： 怎样给你的Android 安装文件（APK）瘦身 Android的apk文件越来越大了这已经是一个不争的事实。 在Android 还是最初版本号的时候，一个app的apk文件大小也还仅仅有2 MB左右，到了如今。一个app的apk文件大小已经升级到10MB到20MB这个范围了。apk文件大小的爆炸式增长主要是由于用户对app质量的期待越来越高以及开发人员的开发经验增长，详细体如今下面几个方面： Android设备 dpi 的多样化 ([l|m|tv|h|x|xx|xxx]dpi) Android平台的进化，开发工具的改进以及开源类库生态系统的丰富 用户对高质量UI的期待 其它原因 Android开发人员在设计一个app的时候应该将终于公布一个轻量级app作为一个最佳实践来考虑。为什么？首先这就意味着你拥有了一个简洁。易维护代码基础。 其次。官方应用商店对超过50MB的apk设置了拓展包文件下载选项。apk文件在50MB下面更easy让用户下载。最后，我们的应用程序环境是一个带宽有限，存储空间有限的环境，apk安装文件越小。下载就会越快。安装也会更快，良性循环，最后说不定用户由于这个给好评。 在大部分情况下，apk大小的增长是为了满足消费者的须要和期待。然而。我觉得apk大小的增速已经超过了用户对app期待的增速。所以，非常大程度上

android apk签名（为什么 如何做 验证） 这篇文章其实就是根据自己的疑问然后结合多个文章结合成的 文章引用： http://liangxh2008.blog.163.com/blog/static/112411679201041321646855/ http://www.pgcw.com.cn/Newsdetail.asp?id=257565010 http://www.eoeandroid.com/thread-23010-1-1.html http://pepa.iteye.com/blog/250991 http://dev.10086.cn/cmdn/bbs/viewthread.php?tid=36678 http://blog.csdn.net/wenhaiyan/archive/2010/04/23/5520964.aspx http://jojol-zhou.iteye.com/blog/719428 一、为什么要签名： 1、发送者的身份认证，由于开发商可能通过使用相同的Package Name来混淆替换已经安装的程序，以此保证签名不同的包不被替换 2、保证信息传输的完整性，签名对于包中的每个文件进行处理，以此确保包中内容不被替换，防止交易中的抵赖发生，Market对软件的要求 二、签名的说明： 1、所有的应用程序都必须有数字证书