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模式混淆配置错误
- 删除module，需要先在settings.gradle中移除对于相关module的声明，移除后sync，对应module会变灰，然后就会出现delete键，此时删除即可。
- 根据官网说明，AndroidManifest中的versionCode、versionName等版本信息应移至build.gradle中。
