優酷鴻蒙開發實踐|優酷 Android 與HarmonyOS Hap 混合打包

語言: CN / TW / HK

《優酷鴻蒙開發實踐|鴻蒙卡片開發》一文中已經提到,要實現“在優酷主客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中新增用於鴻蒙相容性屬性如下:

```

```

將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演算法

``` //生成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.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 篇移動技術實踐&乾貨給你思考!