在Android系统中,要求所有应用程序必须经过数字签名后才能安装。Android系统使用这个证书来识别应用程序的作者,并建立程序间的信任关系。 证书并不用让于用户控制可以安装哪些程序,证书也不需要授权中心来签名。在Android系统中,应用程序使用自己签名的证书是完全允许而且是很普遍的。
关于Android应用程序签名主要有以下几个重点:
在调试应用程序时,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进行额外的优化。
应用程序签名的某些方面可能会影响应用程序的开发,特别是打算一起发布多个应用程序的时候。一般来说,推荐的策略是在整个应用程序寿命内,所有的程序都用相同的证书签名。主要出于以下几点考虑:
在设计应用程序时,一定要考虑以上这些,并使用一个合适的证书来为应用程序签名。
首先要保证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中。
Android编译工具提供了Debug签名模式,使得开发和调试应用程序更加容易,而且还满足Android系统的签名要求。在使用Debug模式编译 app时,SDK工具会调用Keytool工具自动创建一个Debug的keystore和key。然后这个Debug key会自动用于apk的签名,这样就不需要手动为应用程序包签名了。
关于SDK工具使用的keystore:
如果需要可以改变Debug keystore/key的位置和名字,或者提供一个自定义的Debug keysotre/key(在Eclipse/ADT中,通过修改 Windows>Preferences>Android>Build配置实现)。但是任何自定义的Debug keystore/key必须使用和默认Debug key(上面描述的)相同的名字和密码。
注意:不能将签有Debug证书的应用程序发布给最终用户。
如果在Eclipse/ADT下开发(并且已经按照上面的描述配置了Keytool),Debug模式下签名默认是开启的。运行或是调试应用程序 时,ADT会使用Debug证书进行签名,并运行zipalign,然后安装到选择的模拟器或是已连接的设备。整个过程不需要人工干预。
如果使用Ant来编译apk文件,则需要在ant命令中添加debug选项来开启Debug签名模式(假设正在使用由android工具生成 build.xml文件)。运行ant debug编译程序时,编译脚本会生成一个keystore/key,并为apk进行签名。然后脚本会使用zipalign工具对apk进行对齐处理。整 个过程不需要人工干预。
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文件即可。该文件默认存储的位置在:
删除后,在下一次编译的时候,编译工具会重新生成一个新的keystore和Debug key。
应用程序准备发布给其它用户时,需要:
如果使用Eclipse ADT插件开发,可以使用导出向导来完成编译、签名和对齐等操作。整个过程中,导出向导还可以生成一个新的keystore和密钥。
为了进行程序签名,必须有一个合适的密钥。这个密钥应有以下特征:
如果没有合适的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之间的访问和共享,如下:
其中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.输入私钥文件所需信息,并创建: