Android应用程序签名(官方文档中文版)(上)

概览

Android要求全部已安装的应用程序都使用数字证书作数字签名, 数字证书的私钥由应用开发者持有. Android使用证书做为标识应用程序做者的一种方式, 并在应用程序之间创建信任关系. 证书并不用来控制用户可否安装哪一个应用. 证书不须要由证书认证中心签名: 彻底可使用自签名证书(self-signed certificates). android

理解Android应用签名的要点有: 安全

  • 全部应用程序都必须签名. 系统将不会安装一个没签名的应用.
  • 能够用自签名证书来签名应用程序. 并不须要证书认证中心.
  • 当准备好向最终用户发布应用时, 必须用一个合适的私钥对其签名. 不能发布用SDK工具生成的debug key签名的应用.
  • 系统仅在安装时检查签名者的证书的过时时间. 若是应用程序签名者的证书在安装后的时间过时, 该应用将仍然正常工做.
  • 可使用标准工具 — Keytool 和 Jarsigner — 生成key并为应用的 .apk 文件签名.
  • 当应用签名完成, 使用 zipalign 工具来优化最终的 APK 包.

没有正确签名的应用, Android系统不会安装或运行. 此规则适用于在任何地方运行的Android系统, 不论是在模拟器仍是真实设备上. 由于这个缘由, 在真机或模拟器上运行或者调试应用前, 必须为其设置好签名. 服务器

在调试期间, Androi SDK工具协助你为应用作好签名工做. Eclipse的ADT插件和Ant build工具都提供2种签名模式 – debug 模式和 release 模式. app

  • 开发和调试的时候, 可在debug模式下编译. 在debug模式下, build工具使用Keytool工具, 它被包含在JDK中, 用于建立一个keystore和key, 别名和密码. 在每一个编译过程当中, 工具使用debug key来签名应用的.apk文件. 由于事先知道密码, 因此在每一次编译keystore/key须要密码的时候不会提示.
  • 当应用准备好发布时, 必须在release模式下编译,而后用你的私钥对.apk文件签名.
  • 有2种方法:
    • 在命令行下使用 Keytool 和 Jarsigner.
    • 使用此方法, 首先须要将应用编译成一个未签名的 .apk . 而后必须手动使用Jarsigner(或相似工具)和你的私钥为.apk签名. 若是没有合适的私钥, 能够手动运行Keytool来生成你本身的 keystore/key ,而后用Jarsigner给应用签名.
    • 使用ADT的Export Wizard.
    • 若是在Eclipse下使用ADT插件开发, 可使用Export Wizard来编译应用, 生成私钥(若是有必要), 以及为.apk签名, 使用Export Wizard能够简单地在几个步骤中完成全部的事情.

一旦应用完成签名, 不要忘了为APK运行zipalign来完成额外的优化. 模块化

签名策略

应用程序签名的一些方面可能会影响应用程序的开发过程, 尤为是当你计划发布多个应用时. 一般状况下, 对于全部开发者而言, 推荐的策略是:在应用程序的整个生命周期,全部的应用程序使用相同的证书签名. 工具

为何这么作的缘由: 优化

  • 应用程序升级 – 当发布应用的更新时, 若是想让用户无缝地升级到新版本, 须要继续使用相同的某个或者某一套证书来签名更新包. 当系统安装应用的更新时, 它会比较现有版本和新版本的证书. 若是证书吻合, 包括证书数据和顺序都吻合, 那么系统容许更新. 若是新版本所作的签名不是匹配的, 那么将须要给应用起一个不一样的包名 — 在这种状况下, 用户至关于安装了一个彻底的新程序.
  • 应用程序模块化 – Android容许由相同证书签名的应用程序运行在相同的进程中, 此时系统会将它们做为单个应用程序对待. 在这种方式中, 能够按模块化的方式部署应用, 用户能够根据须要独立地更新每个模块.
  • 代码/数据 的受权共享 – Android 提供模式匹配的权限控制机制, 所以一个应用能够暴露功能给另外一个用指定证书签名的应用. 经过用相同证书签名多个应用,以及使用模式匹配的权限检查, 应用程序能够以安全的方式共享代码和数据.

另外一个影响签名策略的重要考量是, 如何设置签名应用的key的有效期. ui

  • 若是计划为某个单独的应用程序提供更新支持, 那么应该确认key的有效期要比应用的寿命长. 推荐25年或者更长的有效期. 当key的有效期过时, 用户将不再能无缝地更新到应用程序的新版本.
  • 若是要使用相同的key为多个不一样的应用签名, 应当确认key的有效期比全部这些应用的全部版本的生命周期还长, 包括要比未来加到这个套件中的额外的关联应用的生命周期更长.
  • 若是计划将应用程序发布到Android Market, 为应用签名的key的有效期必须在2033年10月22日之后. Market服务器强制执行这个规则, 来保证当新版本可用时, 用户能够无缝地更新Market应用.

当设计的时候, 须牢记这些要点, 以确保使用合适的证书来签名应用程序. spa

签名基础设置.

在开始以前, 应当确保Keytool对 SDK build tools 可用. 在大多数状况下, 咱们能够经过设置JAVA_HOME环境变量来引用一个合适的JDK, 告诉SDK build tools如何找到Keytool. 或者, 能够添加 Keytool的JDK版本到 PATH 环境变量. 插件

若是在某个自带GNU Java编译器版本的Linux下开发, 请确认系统使用的是JDK版本的Keytool, 而不是 gcj 版本. 若是 Keytool 已经存在于 PATH, 它可能会指向一个 /usr/bin/keytool 的符号连接. 在这种状况下, 检查符号连接目标, 确保它指向JDK中的Keytool.

若是将公开发布应用程序, 还须要 Jarsigner 工具. Jarsigner 和 Keytool 都包含在 JDK 中.

Debug模式下的签名

Android build tools 提供了debug签名模式, 帮助简化应用的开发和调试, 而仍然符合Android系统签名.apk的需求. 当使用debug模式来构建app时, SDK 工具调用 Keytool来自动建立一个用于debug的 keystore 和 key. 而后这个debug key被用来自动签名 .apk, 因此没必要用本身的key来签名包.

SDK 工具使用预约义的 名称/密码 来建立keystore/key :

  • Keystore name: "debug.keystore"
  • Keystore password: "android"
  • Key alias: "androiddebugkey"
  • Key password: "android"
  • CN: "CN=Android Debug,O=Android,C=US"

若有必要, 能够更改 debug keystore/key 的 location/name 或本身提供一个自定义的 debug keystore/key. 然而, 任何自定义的debug keystore/key必须使用和默认debug key(如以前所述)相同的debug keystore/key 名称和密码. (Eclipse/ADT中, Windows > Preferences > Android > Build)

注意: 当用debug证书签名时, 应用程序不能对外发布.

Eclipse用户

若是使用 Eclipse/ADT (而且根据以前"签名基础设置"一节所述设置好了Keytool), debug模式下的签名是默认开启的. 运行或者调试程序时, ADT自动使用debug证书对.apk进行签名, 并对安装包使用zipalign, 而后将它安装到选定的模拟器或者链接的设备上. 这一切不用咱们亲自动手, ADT能够自行访问Keytool.

Ant用户

若是使用Ant来构建.apk文件, debug签名模式经过ant命令(假设使用由android tool生成的build.xml文件)下使用debug选项开启. 当运行ant debug来编译app时, build脚本生成一个 keystore/key 并为.apk作签名. 而后脚本也会使用zipalign工具优化.apk. 仍然不须要你作额外的事情.

相关文章
相关标签/搜索