在《優酷鴻蒙開發實踐|鴻蒙卡片開發》一文中已經提到,要實現“在優酷主客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/...)
由於混合包要求APP的簽名資訊要與原Android的簽名資訊一致,所以正常情況下用原Android的簽名檔案(jks)就可以了,但鴻蒙為了安全性,提升了簽名的安全性要求:
- 必須使用EC演算法
- 金鑰密碼要”大小寫字母/數字/ 特殊字 符,至少兩種的組合,長度大於等於 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演算法
//生成p12
keytool -genkey -alias [keyname] -keystore [p12.file] -storetype pkcs12 -keyalg EC -keypass [password] -storepass [password]
//生成csr
keytool -certreq -alias [keyname] -keystore [p12.file] -storetype pkcs12 -file [csr.file]
申請下來cer和p7b檔案(需要單獨申請除錯和釋出證照)後,就可以在開發工具中配置簽名檔案了(更多配置詳情也閱覽華為配置簽名幫助文件 https://developer.harmonyos.c...)。
然後通過開發工具DevEco Studio中build -> Build Apps編譯得到產物APP。
工程結構概述:
混合包產物分析
經過上面的一系列流程,就可以生成一個供鴻蒙執行的混合包了。
由於是釋出證照籤名,這個混合包實際上是不能直接手動安裝到Harmony OS上,還需要經過華為平臺側(需要聯絡華為側介面人)簽名,提供轉換之後的安裝包供優酷方面測試使用。
測試完畢之後,可以直接拿這個混合包上架到華為的鴻蒙應用市場。
鴻蒙版本發版經驗總結
- 鴻蒙混合包只有64位包;
- 鴻蒙混合包在鴻蒙市場發版節奏、版本號等最好是跟原安卓發版節奏、版本號等保持一致,不然需要特殊考慮鴻蒙版本的資料定投問題;
- apk和hap在app中實際是物理區分,打包app的時候並不會把apk重新編譯,所以如果apk和hap存在同名的類(因為都是java類),根據雙親委派機制,在執行時將會出現問題;
- 如果原安卓應用包含通訊錄、撥打電話許可權,在華為平臺申請p7b檔案時一定需要勾選申請使用受限許可權,如下圖:
最後,下週《優酷鴻蒙開發實踐》系列第三篇技術文章,我們將以優酷播放中心的技術儲備為切入點,結合鴻蒙系統的映象和流轉特性,詳細介紹普通流轉、自由視角和zoom 等核心能力在鴻蒙上的實踐之路。
感謝關注【阿里巴巴移動技術】,我們下篇技術實踐再見。
關注我們,每週 3 篇移動技術實踐&乾貨給你思考!