KeyStore

---

上一篇中有一个遗留的问题，就是使用Eclipse的keystore问题，事实证明是可以直接使用的。需要注意的是，在Eclipse中设置Custom debug keystore时是不需要输入密码等信息的，这可能会产生误导。其实每个keystore生成时都需要设定密码等信息的。而在AS中，设置keystore时输入密码变成了必要步骤。

使用已有keystore

• 点击File->Project Structure，在Modules部分选中要签名的module，进入右侧Signing的tab栏，点击“+”号新建一个配置。

新建配置

• Name随意填写；Store File选择已有keystore路径；其余的填写生成此keystore时的对应信息。这里提一下，Android自动生成的keystore信息如下：
  Keystore name: “debug.keystore”
  Keystore password: “android”
  Key alias: “androiddebugkey”
  Key password: “android”
  CN: “CN=Android Debug,O=Android,C=US”

• 完成后切换到Build Types的tab中，在这里配置debug版和release版分别使用的keystore。其余不用管，只要在Signing Config中选择刚刚配置好的签名信息的名称即可。完成后sync gradle，会发现相关信息已然添加到对应module的build.gradle中了。

  
  使用签名

module打包形式

---

项目最终的形态是库文件，为了开发和展示方便，是需要一个demo，然后demo引用我们的库文件这种形式。为了表述方便，下文称此库文件为mylib。原先在eclipse中，mylib是以应用项目的形式存在的，即可以直接生成apk来测试mylib的正确性，然后通过ant脚本把测试用activity之类的排除，将必要的类打成jar包。但在AS中，我暂时还没找到实现类似效果的方法。探索过程如下：

• 打包成aar需要apply plugin ' com.android.library'，而打包成apk需要apply plugin ' com.android.application'，而理论和实验同时表明二者无法共存。因此不太可能基于同一build.gradle打包成两种形态。
• 这样一来，自然而然想到，新写一个脚本，也放在模块下，当然名称不可为build.gradle。当需要打成aar时，用命令行单独指定脚本打包。确实有这样的命令gradlew -b 【脚本路径（基于项目根目录）】 :app:assemble。然而运行过后发现，如果指定脚本，那么就不会隐式包含根目录中的settings、local.property等文件了。就是说如果想运行非build.gradle来打包项目，那么所有根目录中的配置都要拷贝一份到新脚本中，说不定还不止于此。因此便放弃这种方式。
• 还有种想法是，准备两份脚本，分别打aar和apk。再写一个脚本，通过参数等控制，需要打哪种类型，就将哪种的脚本改名为build.gradle拷贝到module下，然后再build module。这是比较通用的，因为要打两种类型，可能AndroidManifest.xml也要两种，可能也需要这么做。不过想想就麻烦，毕竟也不是非得一个项目打成两种，这只是为了少几个module而已。

module间依赖

---

既然没法一module两用，那么就先一module是library，另一module是apk这样。在moduleA中更改好library的功能，然后在moduleB中测试效果。这样就涉及module间依赖。在moduleB的build.gradle中的dependencies中添加compile project(':moduleA')，这样就可以直接在B中调用A中的功能了。这种方式注意两个module的sdkVersion应当一样，否则会报找不到类的错误。

这时其实会想到，也许直接依赖模块和依赖生成好的aar库文件可能会有不同，发包前肯定要直接使用aar测试下。依赖其实也可以分debug版和release版，设定debug的时候直接依赖模块，release时使用aar即可：

debugCompile project(':moduleA')
releaseCompile (name:'moduleA', ext:'aar')

这里注意，即使仅生成debug版，release版依赖的包也都应存在，反之亦然。否则会报错。

不过仅仅是这样的话，还是需要先打包moduleA，再将aar拷贝到moduleB，比较麻烦。希望能实现在build moduleB时自动打包拷贝moduleA。解决方案探索过程如下：

• 猜想有没有assemble project这种，如果有的话再配置下moduleA的assemble的task依赖。然而并没找到。
• 使用task间的依赖，令moduleB的build依赖于moduleA的assemble及结果拷贝。但是发现模块间的task是没法互相依赖的。如果在moduleA中新建一个task，然后在moduleB中调用，是无法找到此task的。
• 在根目录的脚本中进行配置。没有找到简便的配置方法。

自定义task

---

暂且接受需要手动构建moduleA的现状。但是构建完成后自动将aar拷贝到moduleB的libs下还是可以做到的。也就是说在moduleA assemble完成后，自动清理下moduleB的libs，然后将位于moduleA/build/outputs/aar下的aar拷贝过去，而且由于生成的aar统一叫app-release/app-debug，在拷贝过去后还得改下名。这就要建立一个copy task和delete task，并实现rename，方法如下：

• copy task：我查到的方式都是需要新建一个task，然后传入type:Copy，没有说能在其他task中直接实现copy的。而且注意，在module下的task的路径都是相对于此module的，所以要使用其他module的路径，注意用“../”

task copyTask(type:Copy){
    from 'build/outputs/aar/app-release.aar'
    into '../moduleB/libs'
    rename{
      String fileName->
      fileName.replace("app-release","moduleA")
    }
}

• delete task:

task deleteTask(type:Delete){
    delete '../moduleB/libs/moduleA.aar'
}

当然实现这两个task的方式还有很多，具体可以网上再查下。然后设定copy依赖于delete，保证操作顺序：

copyTask.dependsOn deleteTask

之后就是要设定copyTask和assemble的依赖关系了，希望是在assemble执行完成后进行copyTask。目前我查到的，task的调用都是通过依赖的方式，如果A依赖B，那么gradle A，自然会唤起对B的调用。暂时没有发现像函数那样，在一个task的实现中调用另一个task的方式。因此没法说在assemble.doLast{}中调用下copyTask这样。这样的话有两种方法：

• copyTask.dependsOn assemble，然后直接gradle copyTask
• assemble.doLast{}.dependsOn copyTask，这样gradle assemble即可

零散问题

---

以下是迁移过程中遇到的一些问题

• 无法复制app-debug-.aar：直接在libs中使用app-debug.aar导致，将其改为其他名称即可。错误原因未知。直接使用app-release.aar不会出问题。

  
  无法复制app-debug-.aar
• 在模块中dependsOn时，不可以dependsOn assembleRelease，只能dependsOn assemble。所以不是所有可在gradle命令中使用的task都可以dependsOn。

• 在gradlew :app:assemble的过程中，出现“failed to fetch URL……”，并卡在这步很久。这个迷惑性很大，让你觉得是网络出了问题，而且是一直在尝试联网的状态，需要等很久才报错。这期间很可能没耐心等待盲目去查网络状况。然而实际等错误报出来，其实就是找不到依赖的库。猜想应该是本地找不到就会联网去找。然而可能就是开发者忘记导入了而已。

  
  找不到库文件

• 如果minifyEnabled为false（不混淆），而zipAlignEnabled和shrinkResourcces为true，则会报各种exception：当模式为library时，会在transformNativeLibsWithSyncJniLibsForRelease报error；当模式为application时，在packageRelease处报resources找不到。

  
  library模式混淆配置错误

application模式混淆配置错误

• 删除module，需要先在settings.gradle中移除对于相关module的声明，移除后sync，对应module会变灰，然后就会出现delete键，此时删除即可。
• 根据官网说明，AndroidManifest中的versionCode、versionName等版本信息应移至build.gradle中。