androidminisdk

A. android 中minSdkVersion 14和minSdkVersion 11的区别

适配的手机sdk最低版本，现在手机大多数都9.0了，但是还是有部分低的，一般minSdkVersion 19差不多适配了95%以上手机

B. 关于Android L最小的sdk版本是什么解决方法

MiniMum Required SDK:最低支持的android api版本，低于这个版本的android手机不能安装你的应用

Target SDK：你的应用最高支持android api版本

Compile With：哪个版本的android
SDK(1.5~4.2)编译你的工程，也就是最适合的，最原生支持你的应用的android版本。

Theme ：这个随意，主题选择

说白了：就是最小，最大，和最适合的问题。
10种技巧可提升Android应用运行效果

技巧1：从优秀的编程开始

要采用已为用户所接受的运算法则和标准的设计样式，这些被人们长期使用的编程法则也同样适用于Android应用，尤其当这些应用使用内在设备服务时。

比如，假设你编写的应用需要以地理定位服务为基础。只需要在必要时开始注册进行位置更新，在无需更新信息时，确保应用停止更新进程。这会帮助节省设备的电量和系统处理器的负担。

技巧2：保持应用的灵活性

通过使用AsyncTask、IntentService或自定义背景服务来保持应用的灵活性。使用加载器来简化加载时间较长数据的状态管理，比如光标。不可让应用在其他进程进行时显得缓慢或完全静止。

如果某些操作需要一定的时间和资源，应当将这个进程单独分离出来异步处理，这样你的应用才能够保持流畅的运行。可以运用这种方法的操作包括：磁盘读写，访问内容供应方、数据库和网络，其他需要较长时间的任务。

技巧3：使用最新的Android SDK版本和API

保持应用的更新，使用Android平台提供的最新内容。随着Android平台的发展，它也在逐步改善中。某些功能被移除，或者替换成更好的选项。其核心API中的漏洞已修复，整个API性能已得到提升。该平台已引入装载器之类的新API，帮助开发者编写更为稳定和反应灵敏的应用。

Android
3.0应用支持硬件加速，你可以加以应用。应当理解的是，最佳的表现情况会随着时间逐渐改变。睿智的开发者会更新平台发布的最新内容和API。

技巧4：检查Strict Mode

你可以使用称为“StrictMode”的Android
API来查找编程中的问题。StrictMode会帮助你识别应用是否正在耗费内存，也可以帮你检查应用是否正在尝试开展漫长的模块化操作。

StrictMode类(注：即android.os.StrictMode)与Android 2.3同期发布。

技巧5：在发布之前停用或最小化调试和诊断

你在Android应用的开发中可能会将某些调试代码构建其中。在应用发布之前确保这些功能被最小化或完全停用。

接下来，让我们来讨论如何用优秀的用户界面设计原则让你的应用加载速度更快。

技巧6：保持布局简洁自然

简洁自然的布局会加快加载速度。不要让屏幕布局中充斥过多不必要的内容。花点时间开发用户可以有效使用的简洁用户界面，不要将过多的功能性内容塞入单个屏幕中。这不仅对应用表现有帮助，而且会帮助用户更有效地使用应用。

分割内容可以帮助划分用户界面功能性，同时不牺牲应用在各种不同设备上的灵活性。

技巧7：根据目标设备调整应用资源

根据特定的设备配置来调整资源，这样它们就能够有效地加载。在图像资源方面，这个显得尤为重要。如果你的应用中有大型的图片资源需要加载，那么要做好调整。

另一个技巧是，当以许多种设备为目标时，保持应用包文件大小合适，只需要在其中包含应用运行所需的核心资源即可，然后让用户根据具体设备下载应用其他内容。

技巧8：使用Hierarchy Viewer工具

Hierarchy
Viewer工具可以帮助你解除应用布局中的漏洞。它还提供了许多有价值的信息，比如每个View控制需要多长的时间。找到问题所属领域，这样解决问题会更加简单。

技巧9：使用layoutopt工具

layoutopt工具是个简单的命令行工具，可以帮助你识别不必要的控制和其他让你布局资源崩溃的事项，提升其性能。它可以帮助你找到不必要的多余布局控制。较少和较浅布局可优化应用运行性能。

最后，在自认为应用达到最好状况时，对其进行测试。

技巧10：使用Traceview和其他Android应用压缩工具

Android SDK中有许多可以压缩应用的工具。可能最流行的工具就是Traceview，这个图像工具可以帮助你调试和找到应用的性能问题。

C. 最近用小米手机在Android studio调试，安装不了程序，怎么解决

用小米来调试确实比较坑，需要注意的地方要多一点

首先，usb调试就不多说了，这是根本
然后，usb调试的地方下面有个usb安装，这个也要打开
最后在设置页面有个系统安全，里面的允许安装未知来源也要打开

D. 如何修改Android项目运行时需要的SDK版本

工具/原料：

adt-bundle-windows-x86_64-20140702

方法/步骤：

一、打开工程，如“HelloJni”

E. 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签名签名原理简析

仅供参考，欢迎指正