
Android系统要求,所有的程序经过数字签名后才能安装。Android系统使用这个证书来识别应用程序的作者,并且建立程序间的信任关系。证书不是用于用户控制哪些程序可以安装。证书不需要授权中心来签名:Android应用程序上使用自己签名的证书是完全允许且普遍的。
理解Android应用程序签名有以下几个重要点:
·所有的应用程序都必须签名。系统不会安装任何一个不签名的程序。
·你可以使用自己的证书来签名。不需要任何授权中心。
·当你要为最终用户发布你的应用程序的时候,你必须签入一个合适的密钥。你不可以发布程序的时候还使用SDK工具签入的DebugKey。
·系统只在安装应用程序的时候检测证书的有效期。如果应用程序在安装之后证书失效了,那么,应用程序还是可以正常工作。
·你可以使用标准工具——Keytool和Jarsigner——生成Key并签名apk文件。
·一旦你为应用程序签名了,一定要使用zipalign工具来优化最终的APK包。
Android系统不会安装和运行没有正确签名的应用程序。这条规则适用于任何运行Android系统的地方,不管是真机还是模拟器。正是由于这个原因,你必须在模拟器或真机上运行/调试程序之前对程序进行签名。
当你调试应用程序时,AndroidSDK工具替你对应用程序进行了签名。Eclipse的ADT插件和Ant编译工具都提供了两种签名模式——Debug模式和Release模式。
·当开发和测试时,你可以使用Debug模式。在Debug模式下,编译工具使用内嵌在JDK中的Keytool工具来创建一个keystore和一个key(包含公认的名字和密码)。在每次编译的时候,使用这个DebugKey来为apk文件签名。由于密码是公认的,在每次编译的时候,也不需要提示你输入keystore和key密码。
·当你的程序准备发布时,你必须在Release模式下,使用密钥来为apk文件签名。有以下两种方式可以做到:
1命令行中使用Keytool和Jarsigner。在这个方法中,首先需要编译出一个未签名的apk。然后使用Jarsigner(或相似的工具),用你的密钥为apk手动签名。如果你没有合适的密钥,你可以运行Keytool来手动生成自己的keystore/key。
2使用ADT导出向导。如果你使用Eclipse/ADT插件进行开发,你可以使用导出向导来编译程序,生成密钥(如果需要),并为apk签名,所有这些 *** 作都在导出向导中。一旦你的程序签名了,别忘了运行zipalign来为apk进行额外的优化。
签名策略
应用程序签名的某些方面可能会影响应用程序的开发,特别是你打算一起发布多个应用程序的时候。一般来说,推荐的策略是在整个应用程序寿命内,所有的程序签上相同的证书。
以下有几个应该这么做的原因:
·应用程序升级——当你对应用程序进行升级时,如果你想用户平稳的升级,那么,你就需要签上相同的证书。当系统安装一个升级应用程序时,如果新版本的证书与老版本的证书有匹配的话,那么,系统才会允许进行升级。如果你没有为版本签上合适的证书,当你安装时,你需要给应用程序指定一个新的包名——在这种情况下,用户安装的新版本,被当作是一个全新的应用程序。
·应用程序模块化——如果应用程序请求的话,Android系统允许签有相同证书的应用程序运行在相同的进程里,这样,系统就会把它们看作是一个单一的应用程序。用这种方法配置应用程序,用户可以选择更新每个独立的模块。
·代码/数据权限共享——Android系统提供了基于签名的权限检查,因此,如果应用程序间签有特定的证书,那么,它们之间可以共享功能。通过多个程序签有相同的证书并且使用基于签名的权限检查,你的程序可以以一种安全的方式共享代码和数据。还有一个决定签名策略的重要因素是:如何设定key的有效期。
·如果你计划支持单个应用程序的升级,你需要确保你的key拥有一个超过期望的应用程序生命周期的有效期。推荐使用25年或更多的有效期。当你的key过期了,用户也就不能平稳的更新到新版本了。
·如果你想给多个无关的应用程序签上相同的key,那么,你必须确保key的有效期超过所有应用程序所有版本的生命周期,包括将来有可能添加到这一阵营的程序。
·如果你想在AndroidMarket上发布你的程序,key的有效期必须在20331022以后。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。然后,这个Debugkey会自动用于apk的签名,这样,你不需要使用你自己的key来为应用程序包签名。
SDK工具使用预先定义好的名字/密码来创建Debugkeystore/key:
·Keystore名字:“debugkeysotre”
·Keystore密码:“android”
·Key别名:“androiddebugkey”
·Key密码:“android”
·CN:“CN=AndroidDebug,O=Android,C=US”
如果需要的话,你可以改变Debugkeystore/key的位置和名字,或者提供一个自定义的Debugkeysotre/key。然而,任何自定义的Debugkeystore/key必须使用和默认Debugkey(上面描述的)相同的名字和密码。(在Eclipse/ADT中, *** 作Windows>Preferences>Android>Build实现。)
注意:你不能将签有Debug证书的应用程序发布给公众。
Eclipse用户
如果你在Eclipse/ADT下开发(并且已经按照上面描述的“签名的基本设定”配置了Keytool),Debug模式下签名默认是开启的。当你运行或是调试应用程序时,ADT会使用Debug证书进行签名,并运行zipalign,然后安装到选择的模拟器或是连接上的设备。整个过程不需要你参与,前提是ADT能访问Keytool。
Ant用户
如果你使用Ant来编译你的apk文件,需要在ant命令中添加debug选项来开启Debug签名模式(假设你正在使用由android工具生成buildxml文件)。当你运行antdebug来编译你的程序时,编译脚本会生成一个keystore/key,并为apk进行签名。然后脚本会使用zipalign工具对apk进行对齐处理。整个过程不需要你参与。阅读“其它IDE下开发:Debug模式编译”来了解更多的信息。
Debug证书过期
Debug模式下签名用的证书(默认是Eclipse/ADT和Ant编译)自从它创建之日起,1年后就会失效。
当证书失效时,你会得到一个编译错误,在Ant编译上,
错误如下:
debug:
[echo]Packagingbin/samples-debugapk,andsigningitwithadebugkey
[exec]DebugCertificateexpiredon8/4/083:43PM
在Eclipse/ADT中,Android控制台上你将会看到一个相似的错误。
为了解决这个问题,只需要删掉debugkeystore文件即可。AVD默认存储的位置在:~/android/avd(OSX和Linux),C:DocumentsandSettings\android(WindowsXP),C:Users\android(WindowsVista)。
当下一次编译的时候,编译工具会重新生成一个新的keystore和Debugkey。
Release模式下签名
当你的程序准备好释放给其它用户时,你必须:
1获取一个合适的密钥
2在Release模式下编译程序
3使用密钥签名程序
4对齐APK包
如果你是使用Eclipse/ADT插件开发,你可以使用导出向导来完成编译、签名和对齐等 *** 作。在整个过程中,导出向导甚至还可以生成一个新的keystore和密钥。因此,如果你使用Eclipse,你可以直接跳到“使用EclipseADT编译和签名”。
获取一个合适的密钥为了进行程序的签名,首先,你必须有一个合适的密钥。密钥指:
·个人持有。
·代表个人、公司或组织实体的身份。
·拥有一个有效期。有效期推荐超过25年。
如果你在AndroidMarket上发布你的程序,需要注意一点的是:程序的有效期需要在20331022之后。你不能上传一个应用程序,而它的key的有效期是在这个日期之前。
·不是由AndroidSDK工具生成的Debugkey。
如果你没有一个合适的key,你一定要使用Keytool来生成一个。如“基本设定”中描述的,确保Keytool可用。
为了用Keytool生成一个key,使用keytool命令并传入一些可选参数,如下表所示。
警告:确保密钥的安全。一定要阅读“安全储存你的密钥”中讨论如何确保你的密钥的安全以及这对你和用户为何如此重要。尤其是,当你生成你的密钥时,一定要为keystore和key使用强密码。
Android 9 新增了对 APK Signature Scheme v3 的支持。该架构提供的选择可以在其签名块中为每个签名证书加入一条轮转证据记录。 利用此功能,应用可以通过将 APK 文件过去的签名证书链接到现在签署应用时使用的证书,从而使用新签名证书来签署应用。
轮替签名证书世系或新签名序列的语法如下:
详细了解如何使用 apksigner 轮转密钥。
Android 9 支持 APK 密钥轮替 ,这使应用能够在 APK 更新过程中更改其签名密钥。为了实现轮替, APK 必须指示新旧签名密钥之间的信任级别。为了支持密钥轮替,我们将 APK 签名方案 从 v2 更新为 v3 ,以允许使用新旧密钥。 v3 在 APK 签名分块中添加了有关受支持的 SDK 版本和 proof-of-rotation 结构的信息。
为了保持与 v1 APK 格式的向后兼容性, v2 和 v3 APK 签名存储在 “APK 签名分块” 内紧邻 ZIP Central Directory 前面。
v3 APK 签名分块 的格式与 v2 相同。 APK 的 v3 签名会存储为一个 “ID-值” 对,其中 ID 为 0xf05368c0 。
“APK 签名分块” 的格式如下(所有数字字段均采用小端字节序):
在解析 APK 时,首先要通过以下方法找到 “ZIP 中央目录” 的起始位置:在文件末尾找到 “ZIP 中央目录结尾” 记录,然后从该记录中读取 “中央目录” 的起始偏移量。通过 magic 值,可以快速确定 “中央目录” 前方可能是 “APK 签名分块” 。然后,通过 size of block 值,可以高效地找到该分块在文件中的起始位置。
v3 方案的设计与 v2 方案 非常相似,它们采用相同的常规格式,并支持相同的 签名算法 ID 、密钥大小和 EC 曲线。
但是, v3 方案增添了有关受支持的 SDK 版本和 proof-of-rotation 结构的信息。
“APK 签名方案 v2 分块” 存储在 “APK 签名分块” 内, ID 为 0xf05368c0 。
“APK 签名方案 v3 分块” 采用 v2 的格式:
proof-of-rotation 结构允许应用轮替其签名证书,而不会使这些证书在与这些应用通信的其他应用上被屏蔽。为此,应用签名需包含两个新数据块:
签名数据部分中的 proof-of-rotation 属性包含一个单链表,其中每个节点都包含用于为之前版本的应用签名的签名证书。此属性旨在包含概念性 proof-of-rotation 和 self-trusted-old-certs 数据结构。该单链表按版本排序,最旧的签名证书对应于根节点。在构建 proof-of-rotation 数据结构时,系统会让每个节点中的证书为列表中的下一个证书签名,从而为每个新密钥提供证据来证明它应该与旧密钥一样可信。
在构造 self-trusted-old-certs 数据结构时,系统会向每个节点添加标记来指示它在组中的成员资格和属性。例如,可能存在一个标记,指示给定节点上的签名证书可信,可获得 Android 签名权限。此标记允许由旧证书签名的其他应用仍被授予由使用新签名证书签名的应用所定义的签名权限。由于整个 proof-of-rotation 属性都位于 v3 signer 字段的签名数据部分中,因此用于为所含 APK 签名的密钥会保护该属性。
此格式排除了 多个签名密钥 的情况和将 不同祖先签名证书 收敛到一个证书的情况(多个起始节点指向一个通用接收器)。
proof-of-rotation 存储在 “APK 签名方案 v3 分块” 内, ID 为 0x3ba06f8c 。其格式为:
Android 目前将使用多个证书签名的 APK 视为具有与所含证书不同的签名身份。因此,签名数据部分中的 proof-of-rotation 属性构成了一个有向无环图,最好将其视为单链表,其中给定版本的每组签名者都表示一个节点。这为 proof-of-rotation 结构(下面的多签名者版本)带来了额外的复杂性。排序成为一个特别突出的问题。更重要的是,无法再单独为 APK 签名,因为 proof-of-rotation 结构必须让旧签名证书为新的证书集签名,而不是逐个签名。
例如,如果希望由两个新密钥 B 和 C 签名的 APK 是由密钥 A 签名的,则它不能让 B 签名者仅包含 A 或 B 的签名,因为这是与 B 和 C 不同的签名身份。这意味着签名者必须在构建此类结构之前进行协调。
多个签名者 proof-of-rotation 属性
v3 方案也无法处理两个不同密钥轮替到同一个应用的同一签名密钥的情形。这不同于收购情形,在收购情形中,收购公司希望转移收购的应用以使用其签名密钥来共享权限。收购被视为受支持的用例,因为新应用将通过其软件包名称来区分,并且可以包含自己的 proof-of-rotation 结构。不受支持的用例是,同一应用有两个不同的路径指向相同的证书,这打破了在密钥轮替设计中做出的许多假设。
在 Android 9 及更高版本中,可以根据 APK 签名方案 v3、v2 或 v1 验证 APK 。较旧的平台会忽略 v3 签名而尝试验证 v2 签名,然后尝试验证 v1 签名。
在Android81上面继续参考>
签名的apk自己无法查看,是安装的时候android系统验证用的。
1签名的意义
为了保证每个应用程序开发商合法ID,防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序,我们需要对我们发布的APK文件进行唯一签名,保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。
2签名的步骤
a创建key
b使用步骤a中产生的key对apk签名
3具体 *** 作, 命令行下对apk签名(原理)
创建key,需要用到keytoolexe (位于jdk160_24\jre\bin目录下),使用产生的key对apk签名用到的是jarsignerexe (位于jdk160_24\bin目录下),把上两个软件所在的目录添加到环境变量path后,打开cmd输入
D:\>keytool -genkey -alias demokeystore -keyalg RSA -validity 40000 -keystore demokeystore/说明:-genkey 产生密钥 -alias demokeystore 别名 demokeystore -keyalg RSA 使用RSA算法对签名加密 -validity 40000 有效期限4000天 -keystore demokeystore /D:\>jarsigner -verbose -keystore demokeystore -signedjar demo_signedapk demoapk demokeystore/说明:-verbose 输出签名的详细信息 -keystore demokeystore 密钥库位置 -signedjar demor_signedapk demoapk demokeystore 正式签名,三个参数中依次为签名后产生的文件demo_signed,要签名的文件demoapk和密钥库demokeystore/
注意事项:android工程的bin目录下的demoapk默认是已经使用debug用户签名的,所以不能使用上述步骤对此文件再次签名。正确步骤应该是:在工程点击右键->Anroid Tools-Export Unsigned Application Package导出的apk采用上述步骤签名。
两种方式,一种开发工具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签名的文件将无法安装或覆盖老的版本,这样可以防止你已安装的应用被恶意的第三方覆盖或替换掉。
当我们有需求对原apk更改签名时,可采用如下方式
有key的可跳到第2步,没有的在android studio中新建key
用rar等软件打开apk文件,然后删除“META-INF”文件夹即可。
其中 -keystore 后面是自己的key名称;
-storepass 和 -keypass 对应上面新建key的两个密码;
-signedjar 第一个参数是添加签名后的apk名称,后面是原apk名称;
key0 是上面新建key的Alias名称;
-tsa >
根据这个页面提供的一个工具 签名生成工具
>
以上就是关于如何发布android 应用程序,app增加签名证书全部的内容,包括:如何发布android 应用程序,app增加签名证书、APK 签名方案 v3、Android8.1源码下对APK进行系统签名等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)