Android App的签名打包（晋级篇）

概述

在Android系统中，要求所有应用程序必须经过数字签名后才能安装。Android系统使用这个证书来识别应用程序的作者，并建立程序间的信任关系。 证书并不用让于用户控制可以安装哪些程序，证书也不需要授权中心来签名。在Android系统中，应用程序使用自己签名的证书是完全允许而且是很普遍的。

关于Android应用程序签名主要有以下几个重点：

• 所有的应用程序都必须签名。系统不会安装任何一个没有签名的程序。这条规则适用于任何运行Android系统的地方，不管是真机还是模拟器。因此必须在模拟器或真机上运行/调试程序之前对程序进行签名。
• 可以使用自己的证书来签名。不需要任何授权中心。
• 要为最终用户发布应用程序的时候，必须签入一个合适的密钥。不可以发布程序的时候还使用SDK工具签入的Debug Key。
• 系统只在安装应用程序的时候检测证书的有效期。如果应用程序在安装之后证书失效了，应用程序依然可以正常工作。
• 可以使用标准工具——Keytool和Jarsigner生成Key并签名apk文件。
• 一旦为应用程序签名了，一定要使用zipalign工具来优化最终的APK包。

Debug Key和Release Key

在调试应用程序时，Android SDK工具会自动对应用程序进行了签名。Eclipse的ADT插件和Ant编译工具都提供了两种签名模式——Debug模式和Release模式。 在开发和测试时，可以使用Debug模式。Debug模式下，编译工具使用内嵌在JDK中的Keytool工具来创建一个keystore和一个 key（包含公认的名字和密码）。在每次编译的时候，会使用这个Debug Key来为apk文件签名。由于密码是公认的所以每次编译的时候，并不需要提示你输入keystore和key密码。

当程序准备发布时，必须在Release模式下使用密钥来为apk文件签名。有以下两种方式可以做到：

1、命令行中使用Keytool和Jarsigner。

这个方法中，首先需要编译出一个未签名的apk。然后使用Jarsigner（或类似的工具），用密钥为apk手动签名。如果没有合适的密钥，可以运行Keytool来手动生成自己的keystore/key。

2、使用ADT导出向导。 如果使用Eclipse/ADT插件进行开发，可以使用导出向导来编译程序，生成密钥（如果需要），并为apk签名，所有这些操作都在导出向导中。一旦程序签名了，别忘了运行zipalign来为apk进行额外的优化。

关于签名策略

应用程序签名的某些方面可能会影响应用程序的开发，特别是打算一起发布多个应用程序的时候。一般来说，推荐的策略是在整个应用程序寿命内，所有的程序都用相同的证书签名。主要出于以下几点考虑：

• 应用程序升级——在应用程序进行升级时，如果想用户平稳的升级，那么就需要签上相同的证书。当系统安装一个升级应用程序时，如果新版本的证书与老版本的证 书有匹配的话，那么，系统才会允许进行升级。如果没有为新版本程序签上合适的证书，那么在安装时需要给应用程序指定一个新的包名。这种情况下，用户安装的 新版本将当作是一个全新的应用程序。
• 应用程序模块化——如果应用程序声明，Android系统允许签有相同证书的应用程序运行在相同的进程里。这样系统将会把它们看作是一个单一的应用程序。用这种方法配置应用程序，用户可以选择更新每个独立的模块。
• 代码/数据权限共享——Android系统提供了基于签名的权限检查，因此如果应用程序间签有特定的证书，它们之间可以共享功能。通过多个程序签有相同的证书，并且使用基于签名的权限检查，程序可以以一种安全的方式共享代码和数据。
• 如果计划支持单个应用程序的升级，需要确保key拥有一个超过期望的应用程序生命周期的有效期。推荐使用25年或更长的有效期。当key过期后，用户也就不能平稳的更新到新的版本了。
• 如果给多个无关的应用程序签上了相同的key，那么应确保key的有效期超过所有应用程序所有版本的生命周期，包括将来有可能添加到这一阵营的程序。
• 如果想在Android Market上发布程序，key的有效期必须在2033.10.22以后。Market服务器强制这一要求，目的是保证用户可以平稳的更新他们的程序。

在设计应用程序时，一定要考虑以上这些，并使用一个合适的证书来为应用程序签名。

配置签名环境

首先要保证Keytool对SDK编译工具来说是可利用的。一般可以通过设置JAVA_HOME环境变量来告诉SDK编译工具如何找到Keytool。另 外还可以添加JDK中Keytool的路径到PATH的变量里。 如果在Linux上开发，并且使用GNU编译器来编译Java，那么要确保系统是使用JDK中的Keytool，而不是gcj。如果Keytool已经在 PATH中，它有可能是对/usr/bin/keytool的符号链接。这种情况下，要检查符号链接的目标，确保它是指向JDK中的Keytool。

如果要发布应用程序，还需要Jarsigner工具。Jarsigner和Keytool都包含在JDK中。

Debug模式下签名

Android编译工具提供了Debug签名模式，使得开发和调试应用程序更加容易，而且还满足Android系统的签名要求。在使用Debug模式编译 app时，SDK工具会调用Keytool工具自动创建一个Debug的keystore和key。然后这个Debug key会自动用于apk的签名，这样就不需要手动为应用程序包签名了。

关于SDK工具使用的keystore：

• Keystore名字：“debug.keysotre”
• Keystore密码：“android”
• Key别名：“androiddebugkey”
• Key密码：“android”
• CN：“CN=Android Debug,O=Android,C=US”

如果需要可以改变Debug keystore/key的位置和名字，或者提供一个自定义的Debug keysotre/key（在Eclipse/ADT中，通过修改 Windows>Preferences>Android>Build配置实现）。但是任何自定义的Debug keystore/key必须使用和默认Debug key（上面描述的）相同的名字和密码。

注意：不能将签有Debug证书的应用程序发布给最终用户。

Eclipse用户

如果在Eclipse/ADT下开发（并且已经按照上面的描述配置了Keytool），Debug模式下签名默认是开启的。运行或是调试应用程序 时，ADT会使用Debug证书进行签名，并运行zipalign，然后安装到选择的模拟器或是已连接的设备。整个过程不需要人工干预。

Ant用户

如果使用Ant来编译apk文件，则需要在ant命令中添加debug选项来开启Debug签名模式（假设正在使用由android工具生成 build.xml文件）。运行ant debug编译程序时，编译脚本会生成一个keystore/key，并为apk进行签名。然后脚本会使用zipalign工具对apk进行对齐处理。整 个过程不需要人工干预。

Debug证书过期

Debug模式下签名用的证书自从它创建之日起，1年后就会失效。当证书失效时，会得到一个编译错误，Ant上错误如下：

debug: [echo] Packaging bin/samples-debug.apk, and signing it with a debug key... [exec] Debug Certificate expired on 8/4/08 3:43 PM

在Eclipse ADT中，Android控制台上也将会看到一个类似的错误。

要解决这个问题，只需删掉debug.keystore文件即可。该文件默认存储的位置在：

• OS X和Linux：~/.android/
• Windows XP：C:/Documents and Settings/.android/
• Windows Vista：C:/Users/.android/

删除后，在下一次编译的时候，编译工具会重新生成一个新的keystore和Debug key。

Release模式下签名

应用程序准备发布给其它用户时，需要：

• 获取一个合适的密钥
• 在Release模式下编译程序
• 使用密钥签名程序
• 对齐APK包

如果使用Eclipse ADT插件开发，可以使用导出向导来完成编译、签名和对齐等操作。整个过程中，导出向导还可以生成一个新的keystore和密钥。

关于密钥的生成

为了进行程序签名，必须有一个合适的密钥。这个密钥应有以下特征：

• 个人持有。
• 代表个人、公司或组织实体的身份。
• 有一个有效期。有效期推荐超过25年。在Android Market上发布程序时需要注意：程序的有效期需要在2033.10.22之后。不能上传一个应用程序而它的key的有效期是在这个日期之前。
• 不是由Android SDK工具生成的Debug key。

如果没有合适的key，则需要使用Keytool来生成一个。用Keytool生成一个key，可使用keytool命令并传入一些可选参数。

Andriod应用程序如果要在手机或模拟器上安装，必须要有签名！ 

1.签名的意义
　　为了保证每个应用程序开发商合法ID，防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序，我们需要对我们发布的APK文件进行唯一签名，保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。

2.签名的步骤
　　a.创建key
　　b.使用步骤a中产生的key对apk签名

3.具体操作

　　方法一： 命令行下对apk签名（原理）
　　创建key，需要用到keytool.exe (位于jdk1.6.0_24jre\bin目录下)，使用产生的key对apk签名用到的是jarsigner.exe (位于jdk1.6.0_24\bin目录下)，把上两个软件所在的目录添加到环境变量path后，打开cmd输入

         D:>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000

        -keystore demo.keystore
       /*说明：-genkey 产生密钥
             -alias demo.keystore 别名 demo.keystore
           -keyalg RSA 使用RSA算法对签名加密
             -validity 40000 有效期限4000天
             -keystore demo.keystore */
         D:>jarsigner -verbose -keystore demo.keystore -signedjar demo_signed.apk 

         demo.apk demo.keystore
        /*说明：-verbose 输出签名的详细信息
            -keystore  demo.keystore 密钥库位置
            -signedjar demor_signed.apk demo.apk demo.keystore 正式签名，三个参数中

依次为签名后产生的文件demo_signed，要签名的文件demo.apk和密钥库demo.keystore.*/

　　注意事项：android工程的bin目录下的demo.apk默认是已经使用debug用户签名的，所以不能使用上述步骤对此文件再次签名。正确步骤应该是:在工程点击右键->Anroid Tools-Export Unsigned Application Package导出的apk采用上述步骤签名。

　　方法二：使用Eclipse导出带签名的apk
　　Eclipse直接能导出带签名的最终apk，非常方便，推荐使用，步骤如下：
　　第一步：导出。
 
　　第二步：创建密钥库keystore,输入密钥库导出位置和密码，记住密码，下次Use existing keystore会用到。
 
　　第三步：填写密钥库信息，填写一些apk文件的密码，使用期限和组织单位的信息。

　　第四步：生成带签名的apk文件，到此就结束了。

　　第五步：如果下次发布版本的时候，使用前面生成的keystore再签名。

　　第六步：下一步，下一步，然后就OK了！

　　方法三：使用IntelliJ IDEA导出带签名的apk 
　　方法步骤基本和Eclipse相同，大概操作路径是：菜单Tools->Andrdoid->Export signed apk。

4.签名之后，用zipalign(压缩对齐)优化你的APK文件。
　　未签名的apk不能使用，也不能优化。签名之后的apk谷歌推荐使用zipalign.exe(位于android-sdk-windows ools目录下)工具对其优化：

       D:>zipalign -v 4 demo_signed.apk final.apk

　　如上，zipalign能够使apk文件中未压缩的数据在4个字节边界上对齐（4个字节是一个性能很好的值），这样android系统就可以使用mmap()(请自行查阅这个函数的用途)函数读取文件，可以在读取资源上获得较高的性能，
　　PS:1.在4个字节边界上对齐的意思就是，一般来说，是指编译器吧4个字节作为一个单位来进行读取的结果，这样的话，CPU能够对变量进行高效、快速的访问（较之前不对齐）。
          2.对齐的根源：android系统中的Davlik虚拟机使用自己专有的格式DEX，DEX的结构是紧凑的，为了让运行时的性能更好，可以进一步用"对齐"进一步优化，但是大小一般会有所增加。

5.签名对你的App的影响。
　　 你不可能只做一个APP，你可能有一个宏伟的战略工程，想要在生活，服务，游戏，系统各个领域都想插足的话，你不可能只做一个APP，谷歌建议你把你所有的APP都使用同一个签名证书。
　　 使用你自己的同一个签名证书，就没有人能够覆盖你的应用程序，即使包名相同，所以影响有：
　　1) App升级。 使用相同签名的升级软件可以正常覆盖老版本的软件，否则系统比较发现新版本的签名证书和老版本的签名证书不一致，不会允许新版本安装成功的。
　　2) App模块化。android系统允许具有相同的App运行在同一个进程中，如果运行在同一个进程中，则他们相当于同一个App，但是你可以单独对他们升级更新，这是一种App级别的模块化思路。
　　3) 允许代码和数据共享。android中提供了一个基于签名的Permission标签。通过允许的设置，我们可以实现对不同App之间的访问和共享，如下：

[html]  view plain copy print ?

1. AndroidManifest.xml：<permission android:protectionLevel="normal" />  

其中protectionLevel标签有4种值：normal(缺省值),dangerous, signature,signatureOrSystem。简单来说，normal是低风险的，所有的App不能访问和共享此App。dangerous是高风险的，所有的App都能访问和共享此App。signature是指具有相同签名的App可以访问和共享此App。signatureOrSystem是指系统image中App和具有相同签名的App可以访问和共享此App，谷歌建议不要使用这个选项，因为签名就足够了，一般这个许可会被用在在一个image中需要共享一些特定的功能的情况下。

详细图片解释步骤：

1.Eclipse工程中右键工程，弹出选项中选择 android工具-生成签名应用包： 

 


2.选择需要打包的android项目工程： 

 


3.如果已有私钥文件，选择私钥文件 输入密码，如果没有私钥文件见 第6和7步创建私钥文件： 

 



4.输入私钥别名和密码： 

 


5.选择APK存储的位置，并完成设置 开始生成： 

 


6.没有私钥文件的情况，创建私钥文件： 

 


7.输入私钥文件所需信息，并创建：