在《优酷鸿蒙开发实践｜鸿蒙卡片开发》一文中已经提到，要实现“在优酷主客 ICON 向上滑动，呼出优酷鸿蒙卡片”，需要卡片的实现代码与优酷主客做混合打包。下面的小节简单介绍了如何实现 Android/鸿蒙混合打包的流程。

当前，将大型 Android 应用(下图图 1)全部使用鸿蒙 API 改写是不现实的，所以华为设计了上述的演进路线。希望将 App 中的功能由 Android 模块逐步替换为鸿蒙 FA/PA, 并混合打包在一起进行分发(下图图 2)，最终抵达 100% Pure 鸿蒙的最终形态(下图图 3)。

目前，我们将优酷 Android 主客和鸿蒙 HAP 混合打包为一个产物，也就是图中 “安卓 App 平滑演进及互操作”的中间态。

刚才已经提到，当前的优酷鸿蒙专版包含 Android APK 主体，以及桌面 Widget HAP， 多屏互动 HAP。

因此，鸿蒙版优酷不仅拥有 Android 版优酷的的所有功能, 还拥有 Android 版不具备的一些特殊功能。

优酷鸿蒙版是在早期吃螃蟹,和华为一起合作开发鸿蒙版 App 先行者之一,解决了大量实际工程难题，并且与华为共同解决了大量开发环境和运行时的 Bug，最终顺利地让优酷鸿蒙混合包上架华为应用商店。

打包方案 Battle

分包方案

将原 Android Apk 应用和 Harmony Hap（Hap 为 Harmony 应用编译产物，跟 Apk 角色一致）应用分别上架应用市场。

• 优点：Apk 和 Hap 可以不同包名，单独控制版本上架

• 缺点：用户需要同时下载安装 2 次才可以体验完整功能

混合包方案

将原 Android Apk 和 Harmony Hap 混合打包成 App 上架应用市场。

• 优点：用户下载安装 1 次即可体验完整功能，不必担心 2 个应用版本差异

• 缺点：打包生产相对麻烦，对 apk 和 hap 有同包名限制

对比下，分包方案需要安装 2 次才可以完成整体功能体验，这显然是硬伤，合包方案虽然在开发生产侧麻烦一些，但可以给用户带来较好的体验，所以选择了混合包方案。

混合包

什么是混合包？

Android 的产物是 Apk，Harmony 的产物是 Hap，将 Apk 和 Hap 混合打成一个总产物包称作为混合包（APP）。

混合包使用场景

场景 1：当 Harmony 版应用并不是一个完整的功能，而只是作为原有 Android 应用的能力补充和增强时，需要将 apk 和 hap 打包成一个整应用。

场景 2：Android 应用短时间内无法全部迁移成 Harmony 版，分节奏迁移过程中可采用此方案进行混合打包作为一个供 Harmony 系统可运行的应用。

混合包打包流程

名词解释：

• legacyApk：在原有正常 Android 工程和混合打包插件编译出的 apk 产物，此 apk 不能独立安装和运行，仅用于生产鸿蒙最终 app 的中间产物。如上图：混合打包流程实际就是将 legacyApk（经过加工的原 Android Apk 产物）和鸿蒙应用产物 Hap 打包成一个 App 包（zip）的过程。

混合包要求及限制

名词解释：

• 鸿蒙 entry： 对应 Android 的 application；

• 鸿蒙 feature： 对应 Android 的 module 或 bundle。

限制：

• 鸿蒙工程 entry 中将作为 apk 的父容器，所以不能包含任何代码和资源，需将所有的代码和资源移到 feature 中；

• 鸿蒙 entry 和 feature 们的 config.json 中必须保持一致，并且与 Android 的 versionCode versionName 保持一致；

• Android 应用（legacyApk）必须为 64 位包，不能包含 32 位的 so。

要求：

• 鸿蒙应用必须与原 Android 应用同包名；

• 混合打包要求 hap（类 Android 的 agp）版本 >= 2.4.2.2，apiVersion（类 Android 的 targetSdkVersion）需要>=5；

• 鸿蒙应用启动时实际还是单独应用，为了保持跟原 Android 技术品牌一致，需要保持 entry 中的 config.json 中的 label 和 icon 与原安卓应用中一致。

生成步骤

第一步：原 Android Apk 侧修改

为了干预原 Apk 的启动流程，增加鸿蒙应用的启动入口，需要干预 Android 的 application。鸿蒙侧提供了工程侧打包编译的 plugin，但由于优酷是组件化开发模式，application 作为一个单独的 aar 模块存在，所以混合编译 plugin 并不是适用。

方案：通过了解混合编译 plugin 的职责，直接在 application 模块手动修改父类为 AceHarmonyApplication（ohos.ace.ability.AceHarmonyApplication，此类在鸿蒙提供 abilityshell.jar 中），并手动在 manifest 中添加用于鸿蒙兼容性属性如下：

<!--鸿蒙兼容性属性--> <uses-feature android:name="zidane.software.ability"      android:required="false" />          <meta-data android:name="permZA" android:value="true" />              <meta-data android:name="multiFrameworkBundle" android:value="true" />

将 application 模块集成进 Android 工程，编译后得到产物 legacyApk。

第二步：鸿蒙工程侧修改

1、配置工程参数

build.gradle：entry 和所有 feature 中的 build.gradle 的 compileSdkVersion、compatibleSdkVersion 改成 5（混合包最小支持版本要求为 5）；

config.json：

• entry 和所有 feature 中的 config.json 的 apiVersion 中的 compatible 和 target 改成 5；

• entry 和所有 feature 中添加 originalName 属性并保持跟 bundleName 一致；

• entry 和所有 feature 中添加 version，并保持子属性 code 等于 Apk 中的 versionCode，子属性等于 Apk 中的 versionName；

• entry 和所有 feature 中的 vendor 保持一致，config.json 中的 code 和 name 有要求，name 推荐为三段式"a.b.c" Code 值为 a1000000+b1000+c。如 Name 为 1.001.003，Code 值为 1001003。

{   “app”:{             "bundleName”:”包名”, //这是鸿蒙应用包名，混合包要求必须与Apk包名一致        "vendor”:”xxx”,//entry和feature中要一致        "version":{            "code":xxx,//对应Android VersionCode要求高于apk版本，并且根据name拼接而成            "name”:”xxx” //对应Android VersionName        },        "apiVersion":{            "compatible":5,//5才支持混合包            "target":5,            "releaseType":"Release"        }        }}

2、在 entry 模块添加 legacyApkOptions 配置

apply plugin: 'com.huawei.ohos.hap'ohos {      ...    legacyApkOptions {        legacyApk"..\..\legacy_entry.apk" //指向legecyApk文件，并且必须以entry.apk结尾        legacyVersionCode "499" // 与 legacyApk 的 AndroidManifest.xml 中配置的android:versionCode 保持一致        legacyVersionName "9.15.2" // 与 legacyApk 的 AndroidManifest.xml 中配置的android:versionName 保持一致     }}

3、entry 修改

将 entry 中的所有代码和资源移到 feature 中（鸿蒙工程允许有一个 entry，可以有多个 feature）；添加一个空的 Ability 页面，并修改 icon 和 label 与原 Android 应用一致。

第三步：签名

签名是混合打包中最麻烦的一步，这也是鸿蒙开发最特殊的一步，需要拿原签名文件(jks 或者 p12)用 DevEco Studio 生成 csr，然后去华为应用市场申请签名的证书（cer）文件和 Profile（p7b）文件，更多详情也参考华为帮助文档（https://developer.huawei.com/consumer/cn/doc/distribution/app/agc-help-harmonyos-debugapp-0000001058642113）

由于混合包要求 APP 的签名信息要与原 Android 的签名信息一致，所以正常情况下用原 Android 的签名文件（jks）就可以了，但鸿蒙为了安全性，提升了签名的安全性要求：

1. 必须使用 EC 算法

2. 密钥密码要”大小写字母/数字/ 特殊字 符，至少两种的组合，长度大于等于 8

如果签名文件构建的时间比较早，这两个要求都不符合的话，华为侧提供了如下解决方案：

1、可以使用原 Android 签名文件单独配置 shell Apk 签名

apply plugin: 'com.huawei.ohos.hap'ohos {    ...   legacyApkOptions {    ...     signConfig {        storeFile file("..\legacyApkJks.jks") // 单独配置的 shell apk 签名材料    }    ...   }}

2、使用 keytool 命令行生成 p12 文件和 csr 文件，但要求别名和秘钥跟原 Android 签名保持一致，并且使用 EC 算法

//生成p12keytool -genkey -alias [keyname] -keystore [p12.file] -storetype pkcs12 -keyalg EC -keypass [password] -storepass [password]
//生成csrkeytool -certreq -alias [keyname] -keystore [p12.file] -storetype pkcs12 -file [csr.file]

申请下来 cer 和 p7b 文件（需要单独申请调试和发布证书）后，就可以在开发工具中配置签名文件了（更多配置详情也阅览华为配置签名帮助文档 https://developer.harmonyos.com/cn/docs/documentation/doc-guides/publish_app-0000001053223745#ZH-CN_TOPIC_0000001058015911__section9752152162813）。

然后通过开发工具 DevEco Studio 中 build -> Build Apps 编译得到产物 APP。

工程结构概述：

混合包产物分析

经过上面的一系列流程，就可以生成一个供鸿蒙运行的混合包了。

由于是发布证书签名，这个混合包实际上是不能直接手动安装到 Harmony OS 上，还需要经过华为平台侧（需要联系华为侧接口人）签名，提供转换之后的安装包供优酷方面测试使用。

测试完毕之后，可以直接拿这个混合包上架到华为的鸿蒙应用市场。

鸿蒙版本发版经验总结

• 鸿蒙混合包只有 64 位包；

• 鸿蒙混合包在鸿蒙市场发版节奏、版本号等最好是跟原安卓发版节奏、版本号等保持一致，不然需要特殊考虑鸿蒙版本的数据定投问题；

• apk 和 hap 在 app 中实际是物理区分，打包 app 的时候并不会把 apk 重新编译，所以如果 apk 和 hap 存在同名的类（因为都是 java 类），根据双亲委派机制，在运行时将会出现问题；

• 如果原安卓应用包含通讯录、拨打电话权限，在华为平台申请 p7b 文件时一定需要勾选申请使用受限权限，如下图：

最后，下周《优酷鸿蒙开发实践》系列第三篇技术文章，我们将以优酷播放中心的技术储备为切入点，结合鸿蒙系统的镜像和流转特性，详细介绍普通流转、自由视角和 zoom 等核心能力在鸿蒙上的实践之路。

感谢关注【阿里巴巴移动技术】，我们下篇技术实践再见。

关注我们，每周 3 篇移动技术实践 &干货给你思考！