android包,android包括华为吗

Android 打包流程

打包后的apk是一个压缩包,解压之后,内容如下:

详细可参考 apk签名原理

无论我们怎么配置gradle文件去自定义打包，但是都是要走上图所画的七个流程。七个深绿色的椭圆代表了七个不可或缺的打包步骤，并且每一个步骤都一个打包工具

所用到的工具:

zipalign 字节对齐：

为什么要以4字节整数倍为起始偏移?

在文件对齐后, 就可以使用mmap来直接读写apk文件

mmap映射

上面涉及到的Android打包流程是以gradle task链的形式串联起来的。

下面看一下常见的task

件

我可以想到的:

Transform API

相关问答

Q1: Android APK打包流程备忘

APK文件的组成部分及apk打包流程是Android开发中的基础知识点，做一个简单的记录。

apk文件是Android应用包文件格式，其本质是一个压缩文件。将apk文件拖动到Android Studio中即可查看里面的内容，如下图：

从上图中可以看到apk包里的几个重要组成部分：

打包流程的经典流程图如下：

其中七个椭圆形内容对应了打包流程中的七个重要步骤，也对应着打包中的七个重要工具，具体如下：

对上面七个重要的打包流程进一步说明。

aapt打包资源文件，生成R.java文件，resources.arsc等文件。

aapt在打包资源文件之前会检测 AndroidManifest.xml 文件的合法性，对res目录下的资源目录进行扫描合法性，因此资源命名有问题时会在编译阶段就会直接报错。

需要注意的是xml文件会被编译为二进制的，因此我们并不能直接打开apk包中的xml文件。

AIDL是Android接口定义语言，是Android进程间通讯的一种实现方式。

此步骤中会对aidl文件进行处理，生成java文件。

通过javaCompiler对java文件进行编译，生成class文件。

dx工具将class文件转变为Android系统Dalvik虚拟机可执行的Dex文件。

将classes.dex，res文件夹等所有文件打包成apk文件。

生成APK包之后还需要进行签名处理，Release签名需要我们自己去进行配置。

常用的签名方式有两种：jarsigner和apksigner。

Zipalign是Android平台上APK文件对齐的整理工具，能够对APK中未压缩的数据进行4字节对齐。

需要注意的是根据采用签名方式的不同，对齐处理的先后顺序有所区别。

APK打包流程备忘。

Q2: Android 安装包要从 APK 变成 AAB 格式了？事情可能并非你想的那样

玩过王者荣耀的朋友，几乎无人不晓「鲁班七号」这个英雄。

作为 Android 的应用程序包，「APK」对于资深 Android 用户来说，知名度并不亚于前者。

Google 宣布，从 2021 年 8 月开始，Google Play 商店将要求开发者使用 Android App Bundle（AAB）发布新应用。这将取代 APK 作为标准发布格式。

消息一出，一些用户开始猜测甚至担忧：「以后还能借一部 APK 说话吗」？「Google 是不是在故意为难国产品牌」？

实际上，有这些疑问的朋友，大概率误解 Google 的这个动作了。

这次舆论漩涡的中心，就是 AAB 格式。所以首先我们要搞清楚，AAB 是什么。

在 2018 年 5 月举行的 Google 开发者大会上，Google 就已公布了 Android App Bundle（AAB）格式，并称这是其现代化开发的一部分。

Google 介绍道，开发者在上传应用至 Google Play 时，需采用 AAB 格式。Google Play 将负责生成 APK 文件及签名。

这句话有两个重点。

一是 AAB 只是上传时应用的格式，用户下载时，获取的依旧是 APK。

对于开发者来说，从 APK 转战到 AAB 没什么痛点。AAB 是一种开源格式，在构建时，选择相关的工具或引擎即可。

用户这边更不必担忧，因为我们在终端设备上看到的，依旧是 APK 格式。

二是生成 APK 的工作，将由 Google Play 完成。

Google Play 将根据用户设备的配置，从 AAB「源文件」里提取、组装适合该用户设备的代码及资源，从而生成 APK 安装包。

也就是说，这时用户下载的应用，已经过 Google Play 优化，以确保该应用可在当前设备上以最佳状态运行。

换种说法，方便你理解：AAB 就像是一袋方便面，里面有各种口味的调料包。Google Play 就是大厨，它会根据你设备的喜好，来判断面要煮多久、放什么调料包。

最终煮好的面，就是 APK 了。

Google 之所以要「强硬」地推行 AAB 格式，很大原因是 AAB 相比 APK 有着多种先天优势。

第一点，是体积轻盈。

上文说到，Google Play 会从 AAB 里，个性化地生成并优化 APK，以针对不同配置的设备、语言进行分发。

举个例子：假设你的手机是 2K 屏幕，首选语言是中文。那么 Google Play 在拼装 APK 时，就会只把 2K 分辨率、中文字符包的资源放进 APK 里。

而传统的 APK，开发者会将各种分辨率和语言包，打包在一起。用户下载下来，手机需要从中挑出适合自己的资源安装运行。

随着机型的不断增加，开发者需要在 APK 文件里塞上越来越多的资源，来提高适配性。因此，App 越来越大，动辄上百 MB。

那么 AAB 的应用，相当于「把复杂留给 Google Play，把简单留给用户」。用户下载的 APK，是经过 Google 精简过的，因此体积会小一些。

那么会小多少呢？根据 Google 的说法，此举可将 APK 的体积压缩 15%。

不过实际情况可能要好于这一预期。例如爱彼迎在拥抱 AAB 后，体积减少了 22%。Netflix 更甚，达到了 57%。

所以对于用户来说，可感知的一点就是安装包变小了，下载、安装的速度会更快。

其次，AAB 使得用户下载的应用，最大程度地符合设备配置，因此运行起来或许会更流畅。某种程度上算是提升了设备性能。

第二点，是应用模块化。

AAB 允许开发者将应用的功能拆分开来。让有需要的用户，自行下载。

我们继续举例子。假设开发者现在要做一个拍照 app，我的手机是单摄，你的手机是双摄。为了减小应用初始的大小，开发者可以把某些功能，设置为按需下载。

比如你想用这款 app 里，针对双摄手机推出的功能，你就下载额外的资料包即可。

开发者还可以决定什么时间，向什么机型推送应用的新功能。相当于自定义和掌控各类用户的体验。

「你我用着同一个 app，但享受着不同功能」的情况，或在将来成为常态。

第三点，是免下载体验。

AAB 的免安装分发特性，可让用户在 Google Play 里，无需下载应用，便可体验到应用的某些功能。

比如有一款 游戏 ，我们不确定是否值得下载，就可以点击「立即体验」，试玩前几个关卡，且不用下载该应用。

这有点像 iOS 14 新增的 App Clip 功能，可以被看作完整版应用的快捷方式，当中会包含应用的一部分功能。

iOS 14 的 App Clip 功能

所以对于用户来说，AAB 格式的推广，我们是可以感知到的，且会有更好的体验。

光打用户体验牌肯定不行，还得考虑开发者的感受。为了让他们有动力转战 AAB 格式，Google 给出了多个理由：

不感兴趣也没关系，那就来「硬的」：8 月起，应用程序包不改成 AAB 格式，就不许上传，逼迫着开发者进行转变。

这足以见得 AAB 对于 Google Play 未来规划的重要性。

推广 AAB 格式，对于大众用户来说绝对是一件好事。谁不希望自己下载的应用，体积又小、适配又好呢？

不过，Google 只是要求 Google Play 这样做，没有强制其他应用商店跟进。

也就是说，如果你没有在使用 Google Play，那么这个改动暂时是感知不到的。

但 AAB 格式的优点这么多，我们有理由相信，国内的应用商店会逐步跟上 Google 的步伐，拥抱 AAB。

而且我们上文说到，用户下载的安装包，依旧会以 APK 格式呈现。因此那些「Google 此举是为了针对国内厂商」的谣言，也就不攻自破了。

何况华为等应用商店，从前两年开始，就已经支持开发者上传 AAB 格式的应用。所以用户们大可放宽心，静等 AAB 格式推广的红利即可。

Q3: Android常用类库包都有哪些

Android 类库中，各种包写成android.*的方式，重要包的介绍如下：

android.app：提供高层的程序模型、提供基本的运行环境。

android.content：包含各种的对设备上的数据进行访问和发布的类。

android.database：通过内容提供者浏览和操作数据库。

android.graphics：底层的图形库，包含画布，颜色过滤，点，矩形，可以将他们直接绘制到屏幕上。

android.location：定位和相关服务的类。

android.media：提供一些类管理多种音频、视频的媒体接口。

android.net：提供帮助网络访问的类，超过通常的java.net.*接口。

android.os：提供了系统服务、消息传输、IPC 机制。

android.opengl：提供OpenGL 的工具，3D 加速。

android.provider：提供类访问Android 的内容提供者。

android.telephony：提供与拨打电话相关的API交互。

android.view ：提供基础的用户界面接口框架。

android.util：工具性的方法，例如时间日期的操作。

android.webkit：默认浏览器操作接口。 android.widget：包含各种UI 元素(大部分是可见的)在应用程序的屏幕中使用。

Q4: Android包冲突等问题

Android冲突一般是com.android.support不一致和第三方库的冲突居多，常见解决方法有以下两种

1.统一版本号，在app的build.gradle

```

android {

configurations.all {

resolutionStrategy.eachDependency { DependencyResolveDetails details -

def requested = details.requested

if (requested.group =='com.android.support') {

if (!requested.name.startsWith("multidex")) {

details.useVersion'27.0.1'

            }

}

}

}

}

```

意思是除了multidex之外com.android.support的包版本都统一设置成27.0.1

2.一般设置统一包版本之后，一般是第三方包冲突，还有studio3.0的问题

首先在Terminal运行（提前设置一下gradle环境）

gradle -q dependencies app:dependencies --configuration compile

查看日志阐述的问题能逐个找到答案比如：

google()低版本不兼容问题，改成

maven { url''}

注意：第三方库多的话，建议一个个查问题，不要把全部不兼容高版本的第三方库导入进去，如果一直报奇怪的错误，先删掉app里.build再同步试下，希望能帮助到大家