1. 如何生成android签名文件
工具/原料Win7 x64adt-bundle-windows-x86_64-20140702方法/步骤新建一个工程命名为“HelloWorld”，操作如下图所示， 处前两个界面外，其他的界面都点击默认值即可；通过 “右键工程->Run As…->Android Application”， 在 工程目录的 bin/HelloWorld.apk 会生成一个apk文件点击 “Use the Export Wizard”，如下图所示：点击 Next， 如下图所示：1、选择 "Create New Keystore"，2、输入将要保存的数字签名文件，如“D:\Android\key\HelloWorld.key”3、输入密码，如：HelloWorld4、输入确认码，如 HelloWorld5、点击 Next效果如下：输入昵称，密码，确认码，期限，名字后，点击next，如下图所示：输入需要签名的apk包，点击Finish后，就完成了对apk包的数字签名同时也会生成数字签名用的文件，如：“"D:\Android\key\HelloWorld.key"”
2. 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签名签名原理简析
仅供参考，欢迎指正
3. 怎样查看android的apk文件的签名
以下介绍查看自己的应用签名及三方APK或系统APK签名信息，包含其中的MD5、SHA1、SHA256值和签名算法等内信息。容
1、查看自己的应用签名可以通过两种方式查看(1) debug的apk通过Eclipse查看，如下图：
可以查看签名的MD5、SHA1、SHA256值及签名算法
4. android 怎么查看签名文件
以下介抄绍查看自己袭的应用签名及三方APK或系统APK签名信息，包含其中的MD5、SHA1、SHA256值和签名算法等信息。1、查看自己的应用签名可以通过两种方式查看(1) debug的apk通过Eclipse查看，如下图：(2) 某个keystore签名的应用，通过以下命令查看keytool -list -keystore E:\Trinea\keystore\appsearch.keystore，会要求输入签名密码，默认为android，如下图：2、查看三方应用或是系统应用签名用winrar打开待查看的apk，将其中META-INF文件夹解压出来，得到其中的CERT.RSA文件，通过keytool -printcert -file META-INF/CERT.RSA命令打印证书信息，如微信证书信息如下图：可以查看签名的MD5、SHA1、SHA256值及签名算法
5. Android系统签名
有时候，我们开发的apk需要用到系统权限，需要在AndroidManifest.xml中添加共享系统进程属性： 这时候apk的签名就需要是系统签名(platform、shared或media)才能正常使用。 常用系统签名方式 这种方式比较麻烦，你需要有编译过的源码环境，并按如下步骤： 1、拷贝App源码到Android源码的packages/apps/目录下，且App源码是普通(Eclipse)格式的 2、配置Android.mk，在其中添加 3、使用mm编译App，生成的apk即系统签名 这种方式比在源码环境下签名简单，App可以在Eclipse或Android Studio下编译，然后给apk重新签名即可。 但这种方式在频繁调试的时候比较痛苦，即使写成脚本，也需要重复一样的操作。 相关文件 platform.x509.pem、platform.pk8、signapk.jar 文件位置 platform.x509.pem、platform.pk8: signapk.jar: signapk源码路径: 签名命令 步骤 1、将相关文件及源apk文件置于同一路径下 2、检查源apk包，去掉META-INF/CERT.SF 和 META-INF/CERT.RSA 文件 3、执行签名命令即可 让Android Studio集成系统签名，需要用到一个工具 keytool-importkeypair ，详见下文。 这个工具的作用是将系统签名的相关信息导入到已有的签名文件里。 工具的使用方法可以通过–help或README.textile来寻求帮助 platform.x509.pem、platform.pk8、keytool-importkeypair、demo.jks、signature.sh 我的做法是在App根目录新建Signature文件夹专门存放签名相关文件。 步骤 1、生成demo.jks签名文件 2、编写签名脚本signature.sh，内容如下： 为脚本文件添加可执行权限： 执行脚本： 3、配置builde.gradle 在android区域下(与defaultConfig同级)添加配置： 这样debug或release apk就带有系统签名了。 如果想直接Run app就是release版且带系统签名的apk，还需修改： 这样直接Run app就是带系统签名的release版apk了。
6. android 系统签名
也有提到怎么单独给一个apk签名，这里补充一下android的签名权限控制机制。 android的标准签名key有： testkey media latform hared 以上的四种，可以在源码的/build/target/proct/security里面看到对应的密钥，其中shared.pk8代表私钥，shared.x509.pem公钥，一定是成对出现的。 其中testkey是作为android编译的时候默认的签名key，如果系统中的apk的android.mk中没有设置LOCAL_CERTIFICATE的值，就默认使用testkey。 而如果设置成： LOCAL_CERTIFICATE := platform 就代表使用platform来签名，这样的话这个apk就拥有了和system相同的签名，因为系统级别的签名也是使用的platform来签名，此时使用android:sharedUserId="android.uid.system"才有用！ 在/build/target/proct/security目录下有个README，里面有说怎么制作这些key以及使用问题（android4.2）： 从上面可以看出来在源码下的/development/tools目录下有个make_key的脚本，通过传入两个参数就可以生成一对签名用的key。 其中第一个为key的名字，一般都默认成android本身有的，因为很多地方都默认使用了这些名字，我们自定义的话只需要对第二个参数动手脚，定义如下： C —> Country Name (2 letter code) ST —> State or Province Name (full name) L —> Locality Name (eg, city) O —> Organization Name (eg, company) OU —> Organizational Unit Name (eg, section) CN —> Common Name (eg, your name or your server’s hostname) emailAddress —> Contact email addre 另外在使用上面的make_key脚本生成key的过程中会提示输入password，我的处理是不输入，直接enter，不要密码！后面解释，用自定义的key替换/security下面的。 可以看到android源码里面的key使用的第二个参数就是上面README里面的，是公开的，所以要release版本的系统的话，肯定要有自己的签名key才能起到一个安全控制作用。 在上面提到如果apk中的编译选项LOCAL_CERTIFICATE没有设置的话，就会使用默认的testkey作为签名key，我们可以修改成自己想要的key，按照上面的步骤制作一个releasekey，修改android配置在/build/core/config.mk中定义变量： 在主makefile文件里面： ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey) BUILD_VERSION_TAGS += release-key 这样的话默认的所有签名将会使用releasekey。 修改完之后就要编译了，如果上面的这些key在制作的时候输入了password就会出现如下错误： 我在网上找到了合理的解释： 其实会出现这个错误的最根本的原因是多线程的问题。在编译的时候为了加速一般都会执行make -jxxx，这样本来需要手动输入密码的时候，由于其它线程的运行，就会导致影响当前的输入终端，所以就会导致密码无法输入的情况！ 再编译完成之后也可以在build.prop中查看到变量： 这样处理了之后编译出来的都是签名过的了，系统才算是release版本 我发现我这样处理之后，整个系统的算是全部按照我的要求签名了。 网上看到还有另外的签名release办法，但是应该是针对另外的版本的，借用学习一下： make -j4 PRODUCT-proct_mol-user dist 这个怎么跟平时的编译不一样,后面多了两个参数PRODUCT-proct_mol-user 和 dist. 编译完成之后回在源码/out/dist/目录内生成个proct_mol-target_files开头的zip文件.这就是我们需要进行签名的文件系统. 我的proct_mol 是full_gotechcn,后面加“-user”代表的是最终用户版本，关于这个命名以及proct_mol等可参考http://blog.csdn.net/jscese/article/details/23931159 编译出需要签名的zip压缩包之后，就是利用/security下面的准备的key进行签名了： ./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security out/dist/full_gotechcn-target_files.zip out/dist/signed_target_files.zi 签名目标文件 输出成signed_target_files.zi 如果出现某些apk出错，可以通过在full_gotechcn-target_files.zip前面加参数"-e =" 来过滤这些apk. 然后再通过image的脚本生成imag的zip文件，这种方式不适用与我目前的工程源码，没有做过多验证！ Android签名机制可划分为两部分：（1）ROM签名机制；（2）第三方APK签名机制。 Android APK实际上是一个jar包，而jar包又是一个zip包。APK包的签名实际上使用的是jar包的签名机制：在zip中添加一个META的子目录，其中存放签名信息；而签名方法是为zip包中的每个文件计算其HASH值，得到签名文件(*.sf)，然后对签名文件(.sf)进行签名并把签名保存在签名块文件(*.dsa)中。 在编译Android源码生成ROM的过程中，会使用build/target/proct/security目录中的4个key（media, platform, shared, testkey）来对apk进行签名。其中，*.pk8是二进制形式（DER）的私钥，*.x509.pem是对应的X509公钥证书（BASE64编码）。build/target/proct/security目录中的这几个默认key是没有密码保护的，只能用于debug版本的ROM。 要生成Release版本的ROM，可先生成TargetFiles，再使用带密码的key对TargetFiles重新签名，最后由重签名的TargetFiles来生成最终的ROM。 可以使用Android源码树中自带的工具“development/tools/make_key”来生成带密码的RSA公私钥对（实际上是通过openssl来生成的）: $ development/tools/make_key media ‘/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName’ 上面的命令将生成一个二进制形式（DER）的私钥文件“media.pk8”和一个对应的X509公钥证书文件“media.x509.pem”。其中，/C表示“Country Code”，/ST表示“State or Province”，/L表示“City or Locality”，/O表示“Organization”，/OU表示“Organizational Unit”，/CN表示“Name”。前面的命令生成的RSA公钥的e值为3，可以修改development/tools/make_key脚本来使用F4 (0×10001)作为e值（openssl genrsa的-3参数改为-f4）。 也可以使用JDK中的keytool来生成公私钥对，第三方APK签名一般都是通过keytool来生成公私钥对的。 可以使用openssl x509命令来查看公钥证书的详细信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout 还可以使用JDK中的keytool来查看公钥证书内容，但其输出内容没有openssl x509全面： $ keytool -printcert -v -file media.x509.pem 有了key之后，可以使用工具“build/tools/releasetools/sign_target_files”来对TargetFiles重新签名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目录中需要有四个key（media, platform, shared, releasekey）。注意：这里的releasekey将代替默认的testkey（请参考build/tools/releasetools/sign_target_files脚本实现），也就是说，如果某个apk的Android.mk文件中的LOCAL_CERTIFICATE为testkey，那么在生成TargetFiles时是使用的build/target/proct/security/testkey来签名的，这里重新签名时将使用new_keys_dir/releasekey来签名。 uild/tools/releasetools/sign_target_files_apks是通过host/linux-x86/framework/signapk.jar来完成签名的。也可以直接使用host/linux-x86/framework/signapk.jar来对某个apk进行签名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，”-w”表示还对整个apk包(zip包）进行签名，并把签名放在zip包的comment中。 对于第三方应用开发者而言，对APK签名相对要简单得多。第三方应用开发一般采用JDK中的keytool和jarsigner来完成签名密钥的管理和APK的签名。 使用keytool来生成存储有公私钥对的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000 查看生成的密钥信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （注：获取Base64格式的公钥证书，RFC 1421） 导出公钥证书： $ keytool -export -keystore mystore -alias mykey -file my.der （注：二进制格式公钥证书，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （注：Base64格式公钥证书，PEM） 对APK进行签名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey 验证签名： $ jarsigner -verify -verbose -certs my_application.apk 在进行Android二次开发时，有时需要把build/target/proct/security下面的公私钥对转换为keystore的形式，可以参考这篇文章：把Android源码中的密码对转换为keystore的方法。
7. android 创建的签名文件在哪
两种方式，一种开发工具eclipse，还有就是用apktool工具。I、只要Run As Android Application 过，到工作目录专的bin文件夹下就能找属到与项目同名的apk文件。II、 A.选中项目，右键＝》Andoid Tools＝》Export Unsigned Application Package，直接保存，未签名的。 B.选中项目，右键＝》Andoid Tools＝》Export Signed Application Package，后面一步步的去做，签过名的。 APK签名主要有两种:1. 使用特殊的key签名可以获取到一些不同的权限。2. APK如果使用一个key签名，发布时另一个key签名的文件将无法安装或覆盖老的版本，这样可以防止你已安装的应用被恶意的第三方覆盖或替换掉。
8. android 怎样生成签名文件
首先，要想生成Android App的签名文件必须先配好Android开发环境，因为签名文件的生成需要进入jdk中的bin目录，如果还未配好开发环境，请自行网络。
下面，我们开始生成自己的签名文件，
第一步，打开cmd，进入到jdk的bin目录,这样的话,android.keystore文件就会生成在这个目录下；
第二步，在bin目录下输入命令 keytool，回车；
网页链接
9. android 怎么查看签名文件
方法/步骤对apk的签名需要把项目导入到androidstudio软件中，进行点击菜单中“build”选项，弹出的下拉菜单中的“generatesignedapk”.进入到generatesignedapk中界面框中，因第一次对apk的签名，就需要先创建签名文件钥匙，点击”createnew“的按钮。进行选择钥匙保存的位置，指定到磁盘的位置，然后在文件昵称填入，点击“ok”的选项。进入到newkeystore的界面中，根据界面中提示信息输入内容信息，输入完成之后点击“ok”。钥匙创建完成之后，进行点击"next下一步"操作。在进入到这个界面中选择apk生成保存的位置，然后在buildtype中选择release的选项，然后点击“finish”的选项，这样就生成到apk的保存路径中。
10. 安卓app开发签名文件是什么意思
所有的Android应用程序都要求开发人员用一个证书进行数字签名，anroid系统不会安装没有进行签名的由于程序。
平时我们的程序可以在模拟器上安装并运行，是因为在应用程序开发期间，由于是以Debug面试进行编译的，因此ADT根据会自动用默认的密钥和证书来进行签名，而在以发布模式编译时，apk文件就不会得到自动签名，这样就需要进行手工签名。
给apk签名可以带来以下好处：
1. 应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！
2.应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块
3.代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。
不同的应用程序之间，想共享数据，或者共享代码，那么要让他们运行在同一个进程中，而且要让他们用相同的证书签名。
未经允许不得转载：山九号 » android系统签名文件|怎样查看android的apk文件的签名
