Gradle 实现 Android 多渠道定制化打包

最新推荐文章于 2023-03-29 16:46:02 发布
原创 最新推荐文章于 2023-03-29 16:46:02 发布 · 362 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文详细介绍使用Gradle实现Android应用多渠道打包的过程，包括如何配置不同渠道的应用标识、动态替换资源文件、独立签名及构建版本号的自动化修改。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

最近在项目中遇到需要实现 Apk 多渠道、定制化打包， Google 、百度查找了一些资料，成功实现了上述功能，在此记录以备不时之需，温故而知新，可以为师矣~

需求可以总结如下：

如何实现多个 Apk 安装在同一设备

在之前的印象中，同一个应用在同一设备上只能安装一个，除非手动修改 AndroidManifest.xml 文件中的包名（ package ），但这么做的后果就是新的应用真的是新的应用，旧版应用再也收不到更新。而现在你通过 Gradle，你可以轻松构建多个不同版本的应用，并且在同一设备上安装使用。


这里要用到 productFlavors ，productFlavors 可以用来自定义应用构建版本，我们可以用其 applicationId 属性来实现多个 Apk 安装在同一设备上。


build.gradle 中部分配置代码如下：

android {
    compileSdkVersion 24
    buildToolsVersion "24.0.1"

    //默认配置,所有 productFlavors 都会继承 defaultConfig 中配置的属性
    defaultConfig {
        //默认的 applicationId,一般与 AndroidManifest.xml 文件 package属性相同
        applicationId "com.littlejie.multichannel"
        minSdkVersion 15
        targetSdkVersion 24
        versionCode 1
        versionName "1.0"
    }

    // productFlavors 定义了一个应用的自定义构建版本
    //一个单一的项目可以同时定义多个不同的 flavor 来改变应用的输出。
    // productFlavors 这个概念是为了解决不同的版本之间的差异非常小的情况，通常用于区分同一个应用的不同渠道/客户等，可包含少量业务功能差别。
    // productFlavors 中的 flavor 不能跟 buildType 中的一样,否则会报: "ProductFlavor names cannot collide with BuildType names"
    productFlavors {

        //默认版本,不设置 applicationId ,继承 defaultConfig 中的配置
        flavors_default {
        }

        //开发版本, applicationId 替换为 com.littlejie.multichannel.dev
        flavors_dev {
            applicationId "com.littlejie.multichannel.dev"
        }

        //发布版本, applicationId 替换为 com.littlejie.multichannel.release
        flavors_release {
            applicationId "com.littlejie.multichannel.release"
        }
    }
}

MainActivity.java:

public class MainActivity extends Activity {

    private static final String TAG = MainActivity.class.getSimpleName();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Log.d(TAG, "package name = " + this.getPackageName());
    }
}

在 Android Studio 中执行如下命令：

//打 debug 包，gradle 命令会在后面 `gradle task`中详细讲述
gradle clean assembleDebug

打包完成后，将 Apk 安装到模拟器(adb install name.apk)，运行，log 如下：

flavors_default:

09-17 22:43:55.390 19747-19747/com.littlejie.multichannel D/MainActivity: package name = com.littlejie.multichannel

flavors_dev:

09-17 22:11:30.860 2638-2638/com.littlejie.multichannel.dev D/MainActivity: package name = com.littlejie.multichannel.dev

flavors_release:

09-17 22:44:55.610 20650-20650/com.littlejie.multichannel.release D/MainActivity: package name = com.littlejie.multichannel.release

从这里可以看出，不同 flavor 的 package name 被 applicationId 替换掉了，而且同一个模拟器上可以同时安装以上三个应用。

下面我们再看看 AndroidManifest.xml 中发生了什么变化。这里需要用到 aapt 来查看 AndroidManifest.xml 的信息：

//输出 apk 的 AndroidManifest.xml 文件的信息
aapt dump xmltree ***.apk AndroidManifest.xml

关于 aapt 使用的更多用法，可以阅读这篇博文：使用 aapt 查看 apk 的各种信息

下面是 flavors_dev 版本的信息，可以看出 Java 源文件的包名并没有发生改变，而 package 属性的值被替换为 applicationId了。


如果在申请第三方 SDK 接入，则对应的包名应该填 applicationId ，而不是 AndroidManifest.xml 中的默认值

lishengjiedeMacBook-Pro:apk littlejie$ aapt dump xmltree multichannel-flavors_dev-debug.apk AndroidManifest.xml
N: android=http://schemas.android.com/apk/res/android
  E: manifest (line=2)
    A: android:versionCode(0x0101021b)=(type 0x10)0x1
    A: android:versionName(0x0101021c)="1.0" (Raw: "1.0")
    //此处 package 的值已替换成 applicationId 的值
    A: package="com.littlejie.multichannel.dev" (Raw: "com.littlejie.multichannel.dev")
    A: platformBuildVersionCode=(type 0x10)0x18 (Raw: "24")
    A: platformBuildVersionName=(type 0x4)0x40e00000 (Raw: "7.0")
    E: uses-sdk (line=7)
      A: android:minSdkVersion(0x0101020c)=(type 0x10)0xf
      A: android:targetSdkVersion(0x01010270)=(type 0x10)0x18
    E: application (line=11)
      A: android:theme(0x01010000)=@0x7f08008e
      A: android:label(0x01010001)=@0x7f060020
      A: android:icon(0x01010002)=@0x7f030000
      A: android:debuggable(0x0101000f)=(type 0x12)0xffffffff
      A: android:allowBackup(0x01010280)=(type 0x12)0xffffffff
      A: android:supportsRtl(0x010103af)=(type 0x12)0xffffffff
      // Activity 的包名还是原来 AndroidManifest.xml 中申明的
      E: activity (line=17)
        A: android:name(0x01010003)="com.littlejie.multichannel.MainActivity" (Raw: "com.littlejie.multichannel.MainActivity")
        E: intent-filter (line=18)
          E: action (line=19)
            A: android:name(0x01010003)="android.intent.action.MAIN" (Raw: "android.intent.action.MAIN")
          E: category (line=21)
            A: android:name(0x01010003)="android.intent.category.LAUNCHER" (Raw: "android.intent.category.LAUNCHER")

applicationId 的原理可以理解为在 gradle 打包的时，动态合并属性，将 package 替换为 applicationId 指定的值，但并不会替换 Java 文件的包名，包括生成的 R 文件(可以去对应 module 下的 build/generated 目录下查看对应 flavor 的 R 文件)。


另外，由于最终生成的包中 AndroidManifest.xml 文件中的 package 属性被 applicationId 替换掉，故对于某些第三方 SDK ，如：微信、高德地图等需要验证包名的，就会碰到相当蛋疼的事，每个包都需要重新去生成 APPID 和 APPKEY，如果渠道很多，那么像微信就会出现问题微信账号申请的应用数就会超出微信的限制。


Android 官方文档原文如下：

Therefore, we have decoupled the two usages of package name:

The final package that is used in your built .apk’s manifest, and is the package your app is known as > on your device and in the Google Play store, is the “application id”.

The package that is used in your source code to refer to your R class, and to resolve any relative activity/service registrations, continues to be called the “package”.

补充：ApplicationId versus PackageName

替换 AndroidManifest.xml 中的属性

这里可以参考友盟统计 SDK 中使用的方案。该方案通过在 AndroidManifest.xml 文件中 application 标签下指定 <mate-data> 设置占位符来实现动态替换属性值。

<meta-data android:name="UMENG_CHANNEL" android:value="${UMENG_CHANNEL}" />

占位符形如${name}，在最终执行 AndroidManifest.xml 文件合并的时候，占位符会被 build.gradle 中对应值取代。 build.gradle 的配置需要用到上节讲到的 productFlavors 的 manifestPlaceholders 属性， manifestPlaceholders 属性直译过来就是清单文件占位符。

下面是 build.gradle 的节选代码：

productFlavors {

   //将 AndroidManifest.xml 文件中的 ${UMENG_CHANNEL} 替换为 default
   flavors_default {
       manifestPlaceholders = [UMENG_CHANNEL: "defalut"]
   }

   flavors_dev {
       applicationId "com.littlejie.multichannel.dev"
       manifestPlaceholders = [UMENG_CHANNEL: "dev"]
   }

   flavors_release {
       applicationId "com.littlejie.multichannel.release"
       manifestPlaceholders = [UMENG_CHANNEL: "release"]
   }

}

如果你要替换多个属性，则只需要将 manifestPlaceholders 的写法如下：

manifestPlaceholders = [VALUE_NAME1 : "value" , VALUE_NAME2 : "value"]

补充：关于 AndroidManifest 文件合并规则可以查看 官方文档

替换资源文件

多渠道打包的时候可能会碰到这种情况：每个应用市场的启动页图标、应用名称可能会有点小出入，更有甚者，连布局都不一样。这时候我们该怎么办呢？


有一种解决办法就是：在代码里进行判断，根据渠道的不一样，加载不同的图片和布局，这是一种解决办法。但是当渠道有很多时，代码就会变得很难维护，而且指定渠道用到的资源文件都会被打入所有 Apk 中。所以这个方法并不值得推荐。那么，有什么好的解决办法呢？


办法 Google 早就给我们想好了，而且相当简单，那就是：在 main 的同级目录下创建以渠道名命名的文件夹，然后创建资源文件（路径要与 main 中的一致），然后打包的时候 gradle 就会自己替换或者合并资源。


例如， App 的默认 icon 路径为 main\res\mipmap-hdpi\ic_launcher.png ，那么 flavors_dev的路径就为 flavors_dev\res\mipmap-hdpi\ic_launcher.png ，打包 flavors_dev 渠道的时候会自动替换图片。


对于资源合并，如果在 main 下的 strings.xml 内容为：

<resources>
    <string name="app_name">MultiChannel</string>
    <string name="string_merge">我是string,我暂时没被合并</string>
</resources>

在 flavors_dev 下的 strings.xml 内容为：

<resources>
    <string name="string_merge">我是dev_string,我会把string合并</string>
</resources>

当打 flavors_dev 渠道包时，最终 strings.xml 会变成：

<resources>
    <string name="app_name">MultiChannel</string>
    <string name="string_merge">我是dev_string,我会把string合并</string>
</resources>

以上特性可以用来替换 Apk 的应用名称和应用图标，这比使用前面讲到的占位符方便很多。同理，替换图片和合并颜色的原理也相似。

多渠道使用独立签名

多渠道打包的时候，可能每个渠道包的签名都必须不一样，真正做到定制化，那么，怎么实现每个渠道包使用指定的签名呢？


平时我们打包的时候是这样的：

signingConfigs {
   release {
       storeFile file("签名文件路径")
       storePassword "storePassword"
       keyAlias "keyAlias"
       keyPassword "keyPassword"
   }

}

buildTypes {
   release {
       minifyEnabled true
       proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
       shrinkResources true
       //指定打 release 包时使用的签名文件
       signingConfig signingConfigs.release
   }

   //如果 debug 包需要测试诸如微信、地图等第三方 sdk ，则可以指定 debug 包使用 release 包的签名
   //debug {
   //    signingConfig signingConfigs.release
   //}
}

而给每个渠道包指定签名其实也差不多。

Google 官方原话：

This enables either having all release packages share the same SigningConfig, by setting android.buildTypes.release.signingConfig, or have each release package use their own SigningConfig by setting each android.productFlavors.*.signingConfig objects separately.

大意就是，在 buildType 下指定签名的具体属性，形如 android.productFlavors.* .signingConfig signingConfigs.*，前一个* 指代在 productFlavors 中定义的 flavor ，后一个* 指代在 signingConfigs 定义的属性。值得注意的是，signingConfigs 必须定义在 buildType 之前。


以下是 build.gradle 的配置节选：

//定义签名属性
signingConfigs {
   flavors_default {
       //如果签名文件在项目的根目录下,则可以这么写
       storeFile file("../littlejie.jks")
       storePassword "******"
       keyAlias "******"
       keyPassword "*****"
   }

   flavors_dev {
       storeFile file("../littlejie_dev.jks")
       storePassword "*****"
       keyAlias "*****"
       keyPassword "*****"
   }
}

buildTypes {
   release {
       minifyEnabled true
       proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
       shrinkResources true

       //多个 flavor ,指定 flavor 使用指定 签名
       productFlavors.flavors_default.signingConfig signingConfigs.flavors_default
       productFlavors.flavors_dev.signingConfig signingConfigs.flavors_dev
   }

   //如果 debug 包需要测试诸如微信、地图等第三方 sdk ，则可以指定 debug 包使用 release 包的签名
   //debug 并不能设置多个签名
   //debug {
   //   productFlavors.flavors_default.signingConfig signingConfigs.flavors_default
   //   productFlavors.flavors_dev.signingConfig signingConfigs.flavors_dev
   //}
}

下面我们来验证下生成的包的签名是否正确，查看签名我们会用到如下两个命令：

//查看签名文件的属性
keytool -list -keystore 签名文件

//查看 apk 的签名，需要提前解压 apk ，获取 CERT.RSA（位于解压目录下 /META-INF 下）
//以下命令行是在 apk 解压目录下执行
keytool -printcert -file META-INF/CERT.RSA

更多 keytool 命令使用可以查看 官方文档

首先，我们来看下 littlejie.jks 的信息：

lishengjiedeMacBook-Pro:AndroidDemo littlejie$ keytool -list -keystore littlejie.jks
输入密钥库口令:

密钥库类型: JKS
密钥库提供方: SUN

您的密钥库包含 1 个条目

littlejie, 2016-9-18, PrivateKeyEntry,
证书指纹 (SHA1): A2:B1:BF:BF:F1:F3:26:F4:FD:0C:94:95:B5:32:90:69:24:F7:99:84

解压 multichannel-flavors_default-release.apk ，查看 CERT.RSA 信息

lishengjiedeMacBook-Pro:apk littlejie$ keytool -printcert -file multichannel-flavors_default-release/META-INF/CERT.RSA
所有者: CN=littlejie
发布者: CN=littlejie
序列号: 71693e05
有效期开始日期: Sun Sep 18 17:20:34 CST 2016, 截止日期: Thu Sep 12 17:20:34 CST 2041
证书指纹:
     MD5: AC:12:83:51:44:FC:82:68:8B:23:7B:E9:12:24:AE:52
     SHA1: A2:B1:BF:BF:F1:F3:26:F4:FD:0C:94:95:B5:32:90:69:24:F7:99:84
     SHA256: AD:04:19:5F:92:00:0D:FA:7C:E5:8A:12:57:72:4C:1E:0E:2E:FC:0D:92:28:05:D0:CC:42:FC:93:95:44:88:88
     签名算法名称: SHA256withRSA
     版本: 3

可以发现两者的 SHA1 值是相等的。

同理，可以查看 littlejie_dev.jks 和 multichannel-flavors_dev-release.apk 的签名信息

//littlejie_dev.jks 的签名信息
lishengjiedeMacBook-Pro:AndroidDemo littlejie$ keytool -list -keystore littlejie_dev.jks
输入密钥库口令:

密钥库类型: JKS
密钥库提供方: SUN

您的密钥库包含 1 个条目

littlejie, 2016-9-18, PrivateKeyEntry,
证书指纹 (SHA1): B4:25:67:A5:9F:8C:1F:12:BD:85:6B:2D:FE:71:62:57:8A:CC:AE:E2

//multichannel-flavors_dev-release.apk 的签名信息
lishengjiedeMacBook-Pro:apk littlejie$ keytool -printcert -file multichannel-flavors_dev-release/META-INF/CERT.RSA
所有者: CN=littlejie
发布者: CN=littlejie
序列号: 48346e15
有效期开始日期: Sun Sep 18 17:21:23 CST 2016, 截止日期: Thu Sep 12 17:21:23 CST 2041
证书指纹:
     MD5: 15:E9:E1:67:AB:33:8B:04:A4:C3:D0:05:8F:A6:35:37
     SHA1: B4:25:67:A5:9F:8C:1F:12:BD:85:6B:2D:FE:71:62:57:8A:CC:AE:E2
     SHA256: 96:A5:14:EC:28:25:32:0D:3E:D0:DB:D0:84:06:E7:9C:17:D7:91:83:A4:51:93:AB:34:3E:D9:FD:C5:FA:A1:8E
     签名算法名称: SHA256withRSA
     版本: 3

但是这里有个问题，就是这种给某个 flavor 指定签名的方法对 debug 无效，有兴趣的同学可以看上述注释掉的 debug 签名部分配置。简单来说，debug 签名只能指定一个或者使用默认的 debug 签名。

若哪位大神有解决方案，欢迎指出~


这里再做几点补充：

        1.多渠道使用独立签名，打包时千万不要使用 Android Studio 中 Build 菜单下的 Generate Signed APK，因为当你使用这个打包的时候， Android Studio 会让你指定使用的签名文件， so 你就等着哭吧~楼主因为这个折腾了半天。解决方法就是使用 gradle tasks。传送门：Android Gradle Build Tasks


        2.鉴于第一点中的传送门需要FQ，所以在这里简单介绍一下 Android Gradle Build Tasks 的使用。


  • 打全部包： gradle assemble

  • 打全部 Debug 包： gradle assembleDebug ，可以简写为 gradle aD ，前提是没有相同缩写的参数

  • 打全部 Release 包： gradle assembleRelease，可以简写为 gradle aR

  • 打指定 flavor 包： gradle assemble(flavor)(Debug|Release)

  • 打包完成后安装（设备上没有安装该 apk ，否则会失败，而且只能指定 flavor ，不然也会失败）： gradle install(flavor)（Debug|Release）

  • 打包前先 clean 一下(在测试的时候很必要，如果不 clean 的话，可能会导致某些小修改不会及时打入新包)： gradle clean assembleDebug

利用 Gradle 修改构建版本号

楼主表示对 Groovy 不是很熟，所以利用 Gradle 自动修改构建版本这个就先留着，我先去研究几天~

补充

有童鞋在评论中说：使用 productFlavors 打包效率太低，的确是这样， gradle 好用是好用，就是打包效率低。如果只是单纯生成渠道包，建议使用美团多渠道打包方案，另外 360 加固也是一种不错的选择，效率都比使用 gradle 来的高。但如果需要替换 Apk 中的图片、字符串、应用的 applicationId 、给指定渠道的包使用指定的签名，那么只能乖乖使用 gradle 打包了，慢你也得忍着~


之前刚开始调研的时候，发现 Github 上有个 ApkCustomizationTool 项目，它是通过对 Apk 解包，替换图片、字符串，然后重新签名，不过这毕竟是事后诸葛亮，控制在打包的源头总是毕竟好的，有兴趣的同学可以去研究下。


不知大家有没有这种感受，每次发版上传渠道的时候想死有没有？o(╯□╰)o

总结

以上就是自己在使用 Gradle 实现 Android 多渠道打包时碰到的问题， Android 官方关于使用 Gradle 的文档已经很详细了，自己总结的只是一点皮毛，有时间要去自习研读下。

工作一年多，愣是没有写博客做总结，好多东西都是用过就忘，下次要用再找，没有成体系的 Android 知识结构，对工资不满意，可就连想跳槽面试都没底气。这次写这篇博客画了思维导图，自以为逻辑清晰了，可是真正要把这些东西讲述清楚，还真是一件麻烦的事~看来，自己还有很长的路要走~

【Android】多渠道打包配置
宾有为的博客
10-24 1621
多渠道打包 是指在打包一个 Android 应用时，一次编译生成多个 APK 文件，每个 APK 文件针对一个特定的渠道。不同的渠道可能代表不同的应用商店、推广合作伙伴、地区等。每个渠道可能有不同的配置，例如不同的包名、资源、应用 ID、签名信息等。
android gradle 多渠道打包分发
wangsfine的博客
12-31 550
本文转载自：http://blog.youkuaiyun.com/catoop/article/details/50435431 安卓开发完成，对于一个开放应用而言，我们需要发布到不同的应用市场，同时我们也需要统计不同市场的用户下载量。（通过启动应用后获取不同市场apk中的不同值来区分） 下面用一个具体的实例来说明：  1、在AndroidManifest.xml的application内添
Android 多渠道定制化打包
眼要看远，脚要近迈
04-20 511
这里要用到 productFlavors ，productFlavors 可以用来自定义应用构建版本
Gradle实现Android多渠道定制化打包
qq_42483967的博客
06-20 599
最近在项目中遇到需要实现 Apk 多渠道、定制化打包， Google 、百度查找了一些资料，成功实现了上述功能，在此记录以备不时之需，温故而知新，可以为师矣~需求可以总结如下：如何实现多个 Apk 安装在同一设备在之前的印象中，同一个应用在同一设备上只能安装一个，除非手动修改 AndroidManifest.xml 文件中的包名( package )，但这么做的后果就是新的应用真的是新的应用，旧版...
Gradle实现Android多渠道打包的实战技巧
- **定制化**：不同渠道可能有不同的推广需求，通过多渠道打包可以提供更加定制化的产品体验。 - **节省资源**：避免为每个渠道创建独立的项目，通过动态配置即可快速生成对应渠道的应用包。 #### 2. 动态设定App...
AndroidStudio Gradle基于友盟的多渠道打包方法
08-29
本文将详细讲解如何在Android Studio中利用Gradle结合友盟实现多渠道打包。 首先，让我们了解Android Studio和Gradle的优势。Gradle作为Android Studio的默认构建系统，提供了强大的自动化构建能力，包括第三方库的...
利用Android Studio Gradle实现友盟多渠道打包：签名与渠道管理详解
在Android开发中，使用Android Studio和Gradle进行友盟多渠道打包是一项重要的任务，特别是在需要对多个应用市场进行统计分析的项目中。本文将深入探讨如何利用Gradle工具来实现这一目标。 首先，理解应用的打包和...
[置顶]Gradle 实现 Android 多渠道定制化打包
I_wait_for_you的专栏
04-19 996
Gradle 实现 Android 多渠道定制化打包 版权声明：本文为博主原创文章，未经博主允许不得转载。 最近在项目中遇到需要实现 Apk 多渠道、定制化打包， Google 、百度查找了一些资料，成功实现了上述功能，在此记录以备不时之需，温故而知新，可以为师矣~ 需求可以总结如下：  如何实现多个 Apk 安装在同一设备 在之前的印象中，同一个应用在同一设备上只能安装一个，除非手动修改
Gradle实现多渠道打包(不同资源文件打不同的包)
Android小码农的博客
05-14 7041
在日常开发中，我们或多或少都会碰到多渠道打包的一些问题，有些是同一个版本要上传到不同的平台，有些是要提供给不同的代理商，中间可能需要改动里面的图片或其他的一些资源文件，对于版本比较少的我们可以简单的替换，但是遇到很多版本时，相信再通过手动替换会令人吐血~ 废话不说，先来看下效果图，下面是根据不同平台需要打包出来的两个apk apk界面展示效果如下(为了方便展示我在productFlavors里用了...
android gradle 多渠道打包
fengchen118的专栏
09-30 442
1：标准Android studio 目录，直接在main 同级页面新增渠道文件夹即可 2：Ecplise 迁移的工程目录，需要在src 下面创建渠道文件夹，代码框架看着比较奇怪。 3：渠道文件夹只写渠道差异的资源文件即 关于打包命令： $gradle build   打全渠道即所有flavor；且含所有buildTypes $gradle assemble[flavor][bu
android 项目 自动 构建项目，指定apk输出名称
唐僧的专栏
03-18 3441
记得之前搞过一次，结果忘接了：在这里记录下： // 一定要写在android节点中 android.applicationVariants.all { variant -> variant.outputs.each { output -> // 生成路径 variant.getPackageApplicationProvider().get().outputDirectory = new File("${roo.
深入理解gradle编译-Android进阶篇
weixin_34313182的博客
10-14 507
2019独角兽企业重金招聘Python工程师标准>>> ...
android7.0 多渠道打包和gradle打包常见问题
peirato_的博客
04-21 1519
在android7.0中谷歌更新了签名的方式 导致使用多渠道打包工具在7.0的设备上安装失败，所以要对多渠道打包的方式进行更新 1.使用多渠道打包配置 使用  packer-ng-plugin 工具来进行多渠道打包 https://github.com/mcxiaoke/packer-ng-plugin 按照地址中的说明来配置插件 在这我们使用grad
Android多渠道打包方案
如果人生就像一场梦，那就希望你做个好梦！
03-29 2103
很多时候我们需要根据不同的渠道生成不同的安装包，这时候我们就需要用到多渠道打包配置。4.执行打包Build->Generate Signed Bundle / APK。这个就是我们需要的安装包啦，这样就可以根据不同平台的审核规则去修改配置了。
Android 手把手完美教你美团wally（瓦力）多渠道打包 3种方法（针对签名V1和V2都会有很详细的介绍）
深南大盗的博客
05-02 3238
APK的生成步骤： 大家从图中可以看出，大体分为以下 7 个大步： 1、打包资源文件，生成 R.java 文件 2、处理 aidl 文件，生成相应 java 文件 3、编译工程源代码，生成相应 class 文件 4、转换所有 class 文件，生成 classes.dex 文件 5、打包生成 apk 6、对 apk 文件进行签名 7、对签名的 apk 进行 zipalig...
Gradle 构建 android 应用常见问题解决指南
故作坚强的专栏
06-09 1876
转载地址：http://www.cnblogs.com/youxilua/p/3348162.html 前言 android gradle 插件已经发展到0.5.7,同时gradle 本身也到了1.8,相比两个月前,android gradle 更快,更完善,也更好用了,为了让各位androider 早日用上gradle这样的神器,特地写一篇关于gradle一些奇葩
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值