安卓打造安装包（应用打包、规范处理安装包、安全加固）_apk打包

本章介绍应用安装包的基本制作规范，主要包括：如何导出既美观又精简的APK文件、如何按照上线规范调整App的相关设置、如何对APK文件进行安全加固以防止安装包被破解。

应用打包

本节介绍APK安装包的打包过程，包括：如何利用Android Studio导出APK格式的安装包、如何利用Android Studio制作App的个性化图标、如何通过个中国瘦身手段压缩APK文件的大小。

导出APK安装包

开发过程中运行App，都是先由数据线连接手机和计算机，再通过Android Studio的Run菜单把App安装到手机上。这种方式只能在自己手机上调试应用，如果想在别人手机上安装应用，就得把App打包成APK文件（该文件就是App的安装包），然后把APK传给其他人安装。
下面是使用Android Studio打包APK的具体步骤说明：

1. 依次选择菜单Build->Generate Signed Bundle/APK…，弹出对话框如下图所示。
   

2. 选中该窗口左下方的APK选项，再单击Next按钮，进入APK签名对话框，如下图所示。
   

3. 在该窗口选择待打包的模块名（如chapter10），以及密钥文件的路径，如果原来有密钥文件，就单击Choose existing…按钮，在弹出的文件对话框选择密钥文件。如果首次打包没有密钥文件，就单击Create new…按钮，弹出密钥创建对话框，如下图所示。
   

4. 单击该Key store path:对话框最右侧的文件夹按钮，弹出如下图的文件对话框，在此可选择密钥文件的保存路径。
   

5. 在文件对话框中选择文件保存路径，并在下方的File name输入框中填写密钥文件的名字，然后单击OK按钮回到密钥创建对话框。在该对话框依次填写密码（Password）、确认密码（Confirm）、别名（Alias）、别名密码（Password）、别名的确认密码（Confirm），修改密钥文件的有效期限（Validity）。对话框下半部分的输入框只有姓名（First and Last Name）是必填的，填完后的对话框如下图。
   

6. 单击OK按钮回到APK签名对话框，此时Android Studio自动把密码和别名都填上了，如下图所示。如果一开始选择已存在的密钥文件，这里就要手工输入密码和别名。
   

7. 单击Next按钮进入下一个打包对话框，如下图所示。对话框上方可选择APK文件的保存路径，对话框中部可选择编译变量（Build Variants），如果是调试用，则编译变量选择release。最后单击Create按钮，等待Android Studio生成AKP安装包。
   

若无编译问题，片刻之后会在APK保存路径下看到release目录，打开该目录找到名为app-release.apk的安装包文件。把该文件通过QQ或微信传给他人，对方手机收到APK文件，点击APK即可安装应用。
如果APK文件安装失败，则可能是以下原因导致的：

1. App只能升级不能降级，假如安装包的版本号小于已安装App的版本号，就无法正常安装。版本号在build.gradle.kts中的versionCode节点配置。
2. 倘若新、旧App的签名不一致，也会造成安装失败。比如该手机之前安装了debug类型的App，现在又要安装release类型的版本，就会出现签名冲突。

制作App图标

新建一个App工程，默认的应用图标都是机器人，如果要发布正规的App，肯定得更换更醒目得专享图标。可是res目录下又好几种分辨率得mipmap-***目录，每种分辨率又有圆角矩形和圆形两类图标，加起来要做十几个图标，倘若每个图标都手工制作，是在要累得够呛。辛好Android Studio早早提供了专门得图标制作插件，只要简简单单几个步骤，即可自动生成所有规格的应用图标。该插件的具体使用步骤如下。

1. 右击项目结构的模块名称，在右键菜单中依次选择菜单New->ImageAsset，弹出如下图所示的图标制作对话框。
   

2. 上图所示的对话框左侧是图标的配置选项，右侧是各规格图标的展示效果。在对话框左侧中间找到Path区域，单击路径输入框右边的文件夹图标，在弹出的文件窗口中选择新图标的素材图片，再回到图标制作窗口，此时该对话框的界面如下图所示。
   

3. 由上图可见，对话框右侧展示区域一下子全部换成了新的图标，完全自动加工好了。接着单击窗口下方的Next按钮，跳转到如下图所示的下一页对话框。
   

4. 单击下一页窗口中的Finished按钮，借宿图标制作操作，然后再mipmap-***目录下就能看到各种规格的新图标了。

给APK瘦身

App不但要求功能完善，其他方面也得综合考虑，比如APK安装包的文件大小就是很重要的参考因素。具备同样功能的两个安装包，一个很大很占空间，另一个较小不怎么占空间，用户的选择结果自然不言而喻。如何压缩打包后的APK文件大小，也就是所谓的给APK瘦身，这涉及很多技术手段，最常用的主要有3种：去冗余功能、精简无用资源、压缩图片大小。分别介绍如下：

1.去除冗余功能

每当开发者创建新的Android项目，打开模块的AndroidManifest.xml，看到默认的application节点是下面这样的：

<application
    android:allowBackup="true"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:roundIcon="@mipmap/ic_launcher_round"
    android:supportsRtl="true"
    android:theme="@style/Theme.Chapter10">
1
2
3
4
5
6
7

注意application节点有两个属性allowBackup和supportsRtl，且都被设置为true，它俩到底是干什么用的呢？
首先看allowBackup，该属性若设为true，则允许用户备份APK安装包和应用数据，以便在刷机或者数据丢失后恢复应用。这里其实隐含着高危漏洞，因为备份后的应用数据可能被人复制到其他设备，如此一来用户的隐私就会泄露出去，账号密码、聊天记录等均可遭窃。所以还是赶紧关闭这个鸡肋功能吧，把allowBackup属性值由默认的true改为false。
然后看supportsRtl，该属性名称当中的Rtl为“Right-to-Left”（从右到左）的缩写，像中东的阿拉伯语、希伯来文等都是从右到左书写，supportsRtl属性值为true时表示支持这种从右向左的文字系统。可是常用的中文、英文都是从左往右书写，根本用不着从右到左的倒排共嗯那个，因此若无特殊情况可把supportsRtl属性值由默认的true改为false。
关闭备份与倒排功能之后，application节点变成了下面这样：

<application
    android:allowBackup="false"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:roundIcon="@mipmap/ic_launcher_round"
    android:supportsRtl="false"
    android:theme="@style/Theme.Chapter10">
1
2
3
4
5
6
7

2.精简无用资源

同样打开新项目种模块级别的build.gradle.kts，发现buildTypes节点下面是这样的：

buildTypes {
    release {
        isMinifyEnabled = false
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}
1
2
3
4
5
6
7
8
9

可见有个isMinifyEnabled 属性，默认值false，该属性的字面意思为是否启用最小化，如果将它设置为true，则Android Studio在打包APK时会惊醒以下代码处理：

1. 压缩代码，移除各种无用的实体，包括类、接口、方法、属性、临时变量等。
2. 混淆代码，把类名、属性名、方法名、实例名、变量名替换为简短且无意义的名称，例如Student类的名称可能改为a，方法getName的名称可能改为b等。

App的Java代码经过压缩和混淆之后，打包生成的APK文件会随着变小。除了代码之外，应用项目还包括各种资源文件，若想移除无用的资源文件（包括XML布局和图片），就要引入新属性shrinkResources，并将该属性值设置为true，这样Android Studio在打包APK时会自动移除无用的资源文件。同时开启代码压缩和资源压缩的buildTypes节点示例如下：

buildTypes {
    release {
        isMinifyEnabled = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}
1
2
3
4
5
6
7
8
9

3.压缩图片大小

由于手机屏幕的尺寸有限，原始的高清图片与有损压缩后的图片在视觉上没有太大差别，因此适当压缩图片质量也是减少APK体积的一个重要途径。App传统的资源图片主要有JPG和PNG两种格式，
对于JPG图片来说，利用Photoshop打开图片。然后将图片另存，即可选择一个合适的压缩率保存即可。
对于PNG图片，利用Photoshop打开图片。然后将图片另存，选择“存储为Web所用格式”，在打开的对话框中的右上角选择保存格式为“PNG-8”，然后保存文件即可完成图片压缩。

规范处理

本节介绍App上线前必做的准备工作，包括：如何正确设置App的版本编号和版本名称、如何把App从调试模式切换到发布模式、如何给多个渠道同时打包APK文件。

版本设置

每个App都有3个基础信息：第一个App的图标，图标文件为res/mipmap-***目录下的ic_launcher.png；第二个是App的名称，名称文字保存在res/values/strings.xml的app_name当中；第三个是App的版本号，版本信息包括build.gradle.kts的versionCode与versionName两个参数，其中versionCode为纯数字的版本编号，versionCode为带点号的字符串，格式如“数字.数字.数字”。
App图标和App名称都好理解，在手机桌面上也能看到App的图标和名称，那么为什么App还需要版本编号与版本名称这样的版本信息呢？这是因为App需要经常升级，但不允许App降级，也就是说，一旦安装了某个版本的App，那么之后只能安装版本更新的同名App，不能安装版本更旧的同名App。这种只能升级不能降级的判断，就依赖于每个APK设定的版本号versionCode，versionCode的数值越大，表示该安装包的版本越高；versionCode的数值越小，表示该安装包的版本越低。依据当前App的版本号与待安装APK的版本号，系统方能比较得知是否允许升级App。
至于版本名称versionName，则用来标识每次App升级的改动程度，按照通常的版本名称格式“数字.数字.数字”，第一个数字为大版本号，每当有页面改版或代码重构等重大升级时，大版本号要加1，后面两个数字清零；第二个数字为中版本号，每当要更新局部页面或添加新功能时，中版本号要加1，第三个数字清零；第三个数字为小版本号，每当界面有微调或问题修复时，小版本号加1。
每次App升级重新导出APK的时候，versionCode与versionName都要一起更改，不能只改其中一个。并且升级后的versionCode与versionName只能比原来的大，不能原来小。如果没有按照规范修改版本号，就产生以下问题：

• 版本号比已安装的版本号小，在安装时系统直接提示失败，因为App只能做升级操作，不能做降级操作。
• 在升级系统应用（手机厂商内置的应用，非普通应用）时，如果只修改versionName，没修改versionCode，重启手机后会发现更新丢失，该应用被还原到升级前的版本。这是因为：对于系统应用，Android会检查versionCode的数值，如果versionCode不大于当前已安装的版本号，本次更新就被忽略了。

除了系统要求检查应用的基础信息，App又是也需要获取自身信息，比如应用图标可以从资源图片获取，应用名称可调用getString方法来获取。其他像应用包名、应用版本等信息，可以编译配置工具defaultConfig获取，该类提供了几个配置属性说明如下：

• applicationId：应用包名。
• buildTypes：编译类型。为debug表示这是调试包，为release表示这是发布包。
• versionCode：应用的版本编号。
• versionName：应用的版本名称。

下面是获取App基础信息的代码例子：

public class AppVersionActivity extends AppCompatActivity {
    private static final String TAG = "AppVersionActivity";
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_app_version);
        ImageView iv_icon = findViewById(R.id.iv_icon);
        iv_icon.setImageResource(R.mipmap.ic_launcher); // 应用图标取自ic_launcher
        TextView tv_desc = findViewById(R.id.tv_desc);
        try {
            PackageManager packageManager = getPackageManager();
            PackageInfo packageInfo = packageManager.getPackageInfo(getPackageName(), 0);
            // 应用名称取自app_name，应用包名、版本号、版本名称均来自BuildConfig
            String desc = String.format("App名称为：%s\nApp包名为：%s\n" +
                            "App版本号为：%d\nApp版本名称为：%s",
                    getString(R.string.app_name), packageInfo.packageName,
                    packageInfo.getLongVersionCode(), packageInfo.versionName);
            tv_desc.setText(desc);
        } catch (PackageManager.NameNotFoundException e) {
            e.printStackTrace();
            Log.d(TAG, "exception:" + e.getMessage());
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

运行App，看到App版本信息的获取页面如下图所示，可见分别展示了App的图标、名称、包名，以及版本编号和版本名称。

发布模式

为了编码调试方便，开发者经常在代码里添加日志，还在页面上弹出各种提示。这样固然有利于发现bug、提高软件质量，不过调试信息过多往往容易泄露敏感信息，例如用户的账号密码、业务流程的逻辑等。从保密角度考虑，App在上线必须去掉多余的调试信息，也就是生成发布模式的安装包，与之相对的时开发阶段的调试模式。
建立发布模式拥有下列两点优势：

1. 保护用户的铭感账户信息不被泄露。
2. 保护业务逻辑与流程处理的交互数据不被泄露。

发布模式与调试模式的安装包很区分，通过菜单Generate Signed Bundle/APK…导出安装包的打包对话框，在Build Variants一栏即可选择安装包类型。选中release时表示生成发布模式的安装包，选中debug时表示生成调试模式的安装包。

发布模式不是直接删掉调试代码，而是通过某个开关控制是否调试信息，因为App后续还得修改、更新、重新发布，这个迭代过程要不断调试，从而实现并验证新功能。App代码可通过代码boolean isDebuggable = (0!= (getApplicationContext().getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE));判断当前是发布模式还是调试模式，此值为false表示处于发布模式，为true表示处于调试模式。于是利用此方法能够控制是否打开日志，在开发阶段导出调试包，在上架阶段导出发布包，这样日志只会在调试包中打印日志，不会在发布包中打印。
控制调试信息的工具类主要有两种，分别对Log工具和Toast工具加以封装，说明如下：

1.Log日志

Log工具用于打印调试日志。在App运行过程中，日志信息会输出到Logcat窗口。因为最终用户不关心App日志，所以除非特殊情况，发布上线的App应屏蔽所有日志信息。下面是封装了调试模式的Log工具代码：

public class LogUtil {
    public static boolean isDebug = false; // 标志位需要在启动App时同步

    public static void v(String tag, String msg) {
        if (isDebug) {
            Log.v(tag, msg); // 打印冗余日志
        }
    }

    public static void d(String tag, String msg) {
        if (isDebug) {
            Log.d(tag, msg); // 打印调试日志
        }
    }

    public static void i(String tag, String msg) {
        if (isDebug) {
            Log.i(tag, msg); // 打印一般日志
        }
    }

    public static void w(String tag, String msg) {
        if (isDebug) {
            Log.w(tag, msg); // 打印警告日志
        }
    }

    public static void e(String tag, String msg) {
        if (isDebug) {
            Log.e(tag, msg); // 打印错误日志
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

2.提示Toast

Toast工具在界面下方弹出小窗，给用户一两句话的提示，小窗暂停一会后消失。由于Toast窗口无交互动作，样式也基本固定，因此除了少数弹窗在发布时予以保留，其他弹窗都应在发布时屏蔽。下面是封装了调试模式的Toast工具代码：

public class ToastUtil {
    public static boolean isDebug = false; // 标志位需要在启动App时同步

    // 不管发布模式还是调试模式，都弹出提示文字
    public static void show(Context ctx, String desc) {
        Toast.makeText(ctx, desc, Toast.LENGTH_SHORT).show();
    }

    // 调试模式下弹出短暂提示
    public static void showShort(Context ctx, String desc) {
        if (isDebug) {
            Toast.makeText(ctx, desc, Toast.LENGTH_SHORT).show();
        }
    }

    // 调试模式下弹出长久提示
    public static void showLong(Context ctx, String desc) {
        if (isDebug) {
            Toast.makeText(ctx, desc, Toast.LENGTH_LONG).show();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

除此之外，AndroidManifest.xml也要区分发布模式与调试模式。应用上架之后，若无特殊情况，开发者都不希望activity和service对外部开放，所以要在activity和service标签下分别添加属性android:exported="false"，表示该组件不允许对外开放。

多渠道打包

对于很对大型App来说，针对不同渠道进行精细化运营是必不可少的，并且客观上也要求对App分渠道管理。这里所谓的渠道，指的是提供App下载的各大应用商店，尤其是各大手机厂商预装的自家应用商店，包括荣耀、小米、OPPO、vivo等品牌。根据不同渠道打造对应的App安装包，带来的好处包括但不限于以下几点：

1. 各厂商的底层系统有着不同的适配要求，需要分别加以定制。
2. 有助于统计各家渠道的App下载量、用户数量以及业务交易量。
3. 有助于统计各家厂商的App用户分别展开精准营销活动。

那么应该如何应对App分渠道打包呢？倘若每打开一个安装包，就要手工改配置手工导出APK，无疑费力费神。其实略施小计，通过修改build.gradle.kts，即可实现自动划分渠道打包的功能。
我们只需给android节点添加flavorDimensions与productFlavors配置，指定风味维度与产品风味，表示开启多渠道打包功能。配置如下：

android {
	// ......
	flavorDimensions += "version"
	productFlavors {
	    create("honor") {
	        dimension = "version"
	        applicationIdSuffix = ".honor"
	        versionNameSuffix = "-honor"
	    }
	    create("xiaomi") {
	        dimension = "version"
	        applicationIdSuffix = ".xiaomi"
	        versionNameSuffix = "-xiaomi"
	    }
	    create("oppo") {
	        dimension = "version"
	        applicationIdSuffix = ".oppo"
	        versionNameSuffix = "-oppo"
	    }
	    create("vivo") {
	        dimension = "version"
	        applicationIdSuffix = ".vivo"
	        versionNameSuffix = "-vivo"
	    }
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

点击同步按钮，然后依次选择菜单Build->Generate Singned Bundle/APK…，在最后一页的打包对话框中看到多个渠道名称，如下图：

选中列表中的小米Debug和Release两个版本，然后点击Create按钮开始打包。稍等片刻，即可在设置的目标路径看到打包好的各渠道安装包了，安装包文件名形如app-xiaomi-release.apk这样。

安全加固

本节介绍如何对APK安装包进行安全加固：首先通过反编译工具成功破解App源码，从而表明对APK实施安全防护的必要性；然后说明代码混淆的开关配置，并演示代码混淆如何加大源码破解的难度；最后描述怎样利用第三方加固网站对APK进行加固，以及如何对加固包进行重签名。

反编译

编译是把代码编译为程序，反编译是把程序破解为代码。
谁都不想自己的劳动成果被别人窃取，何况是辛辛苦苦敲出来的App代码。然而由于Java语言的特性，Java写的程序往往很容易被破解，只要获得App的安装包，就能通过反编译工具破解出改App的完整源码。开发者绞尽脑汁上架一个App，结果这个App却被他人从届满到代码都“山寨”了，那可是欲哭无泪。为了说明代码安全的重要性，下面详细介绍反编译的完整过程，警醒开发者防火、防盗、防破解。
首先准备反编译的3个工具，分别是apktool、dex2jar、jd-gui，注意下载它们的最新版本。下面是这3个工具的简要说明。

• apktool：对APK文件解包，主要用来解析res资源和AndroidManifest.xml。
• dex2jar：将APK包中的classes.dex转为JAR包，JAR包就是Java代码的编译文件。
• jd-gui：将JAR包反编译为Java源码。

以Windows环境为例，下面是反编译APK的具体步骤。

1. 依次选择开始菜单->Windows系统->命令提示符，打开命令窗口，进入apktool所在目录，运行命令“apktool.bat d -f 解包后的保存目录 待处理的APK文件名”，等待反编译过程，如下图所示。
   
   反编译完成，即可在apktool目录下看到破解目录。apktool的用途是解析出res资源，包括AndroidManifest.xml和res/layout、res/values、res/drawable等目录下的资源文件。
2. 用压缩软件（如WinRAR）打开APK文件，发现APK安装包其实是一个压缩文件，使用WinRAR打开的APK文件的目录结构如下图。
   
   先从APK包中解出classes.dex文件，并打开classes.dex将dex开头改为036（据了解dex2jar-2.0版本的工具只支持dex开头字节为035和036的Android版本，由于高版本的Android编译生成的dex开头字节不同，如Android 7.0的dex开头字节是037，Android 8.0的dex开头字节是038，Android9.0的dex的开头字节是039）。
   再进入dex2jar所在的目录，运行命令.\d2j-dex2jar.bat classes.dex，等待转换过程，如下图。
   
   转换完毕即可在dex2jar目录下看到新文件classes-dex2jar.jar，该JAR包即为Java源码的编译文件。
3. 双击打开jd-gui.exe，用鼠标把第二步生成的classes-dex2jar.jar拖到jd-gui界面中，程序就会自动将JAR包反编译为Java源码，反编译后的Java源码目录结构如下：
   

在jd-gui界面依次选择菜单File->Save All Source，输入保存路径再单击保存按钮，即可在指定目录下生成ZIP文件，解压ZIP文件就能看到反编译后的全部Java代码了。
由此可见，反编译过程不但破解了Java代码，而且res目录下的资源文件也被一起破解了，所以，如果App不采取以下保护措施，整个工程源码就会暴露在大庭广众之下。

代码混淆

前面讲到反编译就能够破解App的工程源码，因此有必要对App源码采取防护措施，代码混淆就是保护代码安全的措施之一。Android Studio已经自带混淆器ProGuard，它的用途主要有下列两点：

1. 压缩APK包的大小，删除无用代码，并简化部分类名和方法名。
2. 加大破解源码的难度，部分类名和方法名被重命名使得程序逻辑变得难以理解。

代码混淆的配置文件其实一直存在，每次在Android Studio新建一个模块，该模块的根目录下会自动生成文件proguard-rules.pro。打开build.gradle.kts，在android->buildTypes->release节点下可以看到两行编译配置，其中便用到了proguard-rules.pro：

isMinifyEnabled = false
proguardFiles(
    getDefaultProguardFile("proguard-android-optimize.txt"),
    "proguard-rules.pro"
)
1
2
3
4
5

由于Android Studio默认不做代码混淆，因此上面第一行的isMinifyEnabled 为false，表示关闭混淆功能，要把该参数改为true才能开启混淆功能。上面第四行指定了proguard-rules.pro作为本模块的混淆规则文件，该文件保存着各种详细的代码混淆规则。
对于初学者来说，采用Android Studio默认的混淆规则即可，所以无需改动proguard-rules.pro，只要把build.gradle.kts里的isMinifyEnabled改为true，Android Studio就会按照默认的混淆规则对App代码进行混淆处理。
经过代码混淆后重新生成的APK安装包，再用反编译工具破解APK文件，反编译后的Java源码结构如下所示：

从图中可以看出，混淆后的包名与类名都变成了a、b、c、d这样的名称，无疑加大了黑客理解源码的难度。

第三方加固及重签名

App经过代码混淆后初步结束了裸奔的状态，但代码混淆只能加大源码破译的难度，并不能完全阻止被破解。除了代码破解外，App还存在其他安全风险，比如二次打包、篡改内存、漏洞暴露等情况。对于这些安全风险，Android Studio基本无能为力。因此，鉴于术业有专攻，不妨把APK为文件交给专业网站进行加固处理。例如360加固，其网址是https://jiagu.360.com/。开发者要先注册并购买服务后才能使用。
APK加固后可能会破坏原来的签名，也就无法在手机上安装，此时要对该文件进行重签名，才能成为合法的APK安装包。重签名可使用专门的签名软件，比如爱加密的APKSign等。

工程源码

文章涉及的所有代码可点击工程源码下载。