android编译不签名

⑴ 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了。

⑵ 安卓开发 导出apk文件 一定要设置签名吗

不需要签名的

生成apk最懒惰的方法是：
只要你运行过android项目，到工作目录的bin文件夹下就能找到与项目同名的apk文件，这种apk默认是已经使用debug用户签名的。

如果想要自己给apk签名：

1. 签名的意义
   为了保证每个应用程序开发商合法ID，防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序，我们需要对我们发布的APK文件进行唯一签名，保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。
   2.签名的步骤
   a.创建key
   b.使用步骤a中产生的key对apk签名
   3.具体操作
   方法一： 命令行下对apk签名（原理）
   创建key，需要用到keytool.exe (位于jdk1.6.0_24jrein目录下)，使用产生的key对apk签名用到的是jarsigner.exe (位于jdk1.6.0_24in目录下)，把上两个软件所在的目录添加到环境变量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 输出签名的详细信息 -keystoredemo.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，非常方便，推荐使用，步骤如下：
   第一步：导出。

   
   

2. 

   
   第六步：Next,Next,结束！
   方法三：使用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之间的访问和共享，如下：
   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中需要共享一些特定的功能的情况下。

   ⑶ android studio生成原包后需要签名吗

   默认Android Studio签名生成apk文件或不签名的apk文件
   

   点击“Build——>Build APK”生成默认签名和默认不签名的两种文件

   点击“Build——>General Signed apk”指定自定义签名文件后，生成发布版本的签名文件，如果没有签名文件，先创建一个

   

   ⑷ Android Studio 之签名

   通过签名可以确保数据来源的可靠性和数据的不可篡改性

   对 Apk 进行签名，也就是在 Apk 中写入一个指纹，写入指纹后，Apk 中有任何修改，都会导致这个指纹无效，Android 系统在安装 Apk 进行签名校验时就会不通过，进而无法安装该 Apk

   如上图：

   通常的签名验签过程中，接收方收到消息后，会先向 CA 机构验证证书的合法性，再进行签名校验。但 Apk 的证书通常由开发者自己制作，没有向 CA 机构申请，Android 系统在安装 Apk 时也并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，因此，如果对第三方 Apk 重新签名，也能安装到没有安装过这个 Apk 的系统中

   keystore 文件包含私钥、公钥和数字证书，分为很多种，Android 使用的是 java 标准 keystore 格式 JKS(Java Key Storage)

   Android App Bundle：用于通过 Google Play 发布的应用，需要升级到AS 3.2 以上版本才支持App Bundle 格式；
   APK：用于创建可部署到设备上的签名 APK

   点击 Finish 就会生成签名文件与签名后的 Apk

   当我们需要升级 Apk 版本的时候，需要再次对 Apk 文件进行签名，可以通过配置 build.gradle 让其自动生成签名后的 Apk

   如果你的项目是开源的，需要把你的签名信息写在 local.properties 中，然后在 .gitignore 配置文件中加入 local.properties ，这样 local.properties 就不会提交到开源项目中，签名信息也就不会被人获取

   local.properties：

   app/build.gradle:

   有时候我们的 apk 中某些功能需要系统签名，例如静默安装。测试系统签名的 apk，需要 root 权限，而带 Google APIs 的模拟器不能 root，因此要注意不能选择带 Google APIs 的模拟器

   下面执行的操作都是在 linux 中，如果 apk 是 window 中生成的，需要拷贝到 linux 操作，再将生成的系统签名过得 apk 再拷贝到 window，比较麻烦，可以考虑后面的自动系统签名，还是需要在 linux 操作一次，不过之后就可以只在 window 操作了

   这两个文件在目录 aosp/build/target/proct/security 下，如下图

   在目录 aosp/prebuilts/sdk/tools/lib 下，如下图

   将前面获取的 platform.pk8 、 platform.x509.pem 和 signapk.jar 文件放到需要签名的 apk 同一个目录，执行以下命令

   如果出现上面的错误：Failed to load any of the given libraries: [conscrypt_openjdk_jni-linux-x86_64, conscrypt_openjdk_jni-linux-x86_64-fedora, conscrypt_openjdk_jni]

   解决方法：

   到目录 aosp/prebuilts/sdk/tools/linux/lib64 下，复制 libconscrypt_openjdk_jni.so 文件到需要签名 apk 的同一个目录，并将命令改为

   自动进行系统签名的原理是：先生成一个 system.jks 文件，使用 keytool-importkeypair 对 system.jks 文件进行系统签名，再 build.gradle 和 local.properties 进行配置，直接使用带有系统签名的 system.jks 对 apk 进行签名，这样编译生成的apk文件就自带系统签名了

   按照前面的方法，生成一个 system.jks 文件，此时是在 window 系统中操作的

   进入 keytool-importkeypair 目录，将 system.jks、platform.pk8、platform.x509.pem 文件拷贝进来，拷贝之后的目录结构为

   使用 linux 中修改过的带有系统签名的 system.jks 文件将 window 中最开始生成的 system.jks 覆盖掉，再像前面的自动签名部分一样，修改 build.gradle 和 local.properties 的配置，之后生成的 apk 就是系统签名过的了

   测试方法是，在 AndroidManifest.xml 中添加 android:sharedUserId="android.uid.system" 后安装到 非 Google APIs 的模拟器上 ， Google APIs 的模拟器不能 root，无法安装

   会发现只有使用 system.jks 文件签名后才能安装，否则安装失败，会报以下的错误：

   ⑸ android 打成没签名的包 安装不了吗 为什么编译后在bin文件夹下又可以安装

   没签名是不能安装的，系统bin目录下的安装包是自动生成的，是签过名的，默认签名文件在eclipse 中可以选择。一般都在c盘 user下

   ⑹ 在android系统中，怎么反编译系统APK文件而不破坏以前的签名就是不需要在重新编译后签名。

   ApkDec-Release-0.1 试试这个工具

   ⑺ APK反编译成功后为什么不能签名

   图片在android编译时是自动生成的索引，图片改了对应的索引就不正确，肯定会失败

   ⑻ 怎样能让android不验证签名安装apk

   Android在安装某个应用时，提示程序未安装由以下原因造成：

   1、手机已经安装了一个包名相同的应用。

   2、当前手机操作系统不满足程序包要求的系统版本。

   3、手机存储空间不足。

   4、安装包已经损坏。

   解决办法：

   1、查看本机是否有安装，如果有直接卸载掉。

   2、查看一下程序包的版本，与当前手机是否一致。

   3、卸载手机一些无用或者很少用的应用，释放手机存储空间。

   4、重新下载安装包。

   ⑼ Android app签名不成功的方法

   直接通过Open Mole Settings设置的Android Studio签名配置，每次编译后签名和已经内置在system/spp目录下的已签名应用不同。
   
   解决的方法：参考下面链接的第一种方法。
   
   https://www.jianshu.com/p/400df0d3d882?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

   ⑽ 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的方法。