​（以下內容來自開發者分享，不代表 OpenHarmony 專案群工作委員會觀點）​

石磊

隨著社會的不斷髮展，人們逐漸注重更加高效、舒適、便捷、有趣的生活和工作體驗。

OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）作為面向下一代的分散式作業系統，具有全場景、多裝置、自然互動、便捷精準的技術特點，為行業數字化轉型的高速發展提供領先的技術基礎，為使用者體驗的創新滿足提供了新思路。

為了讓大家深入瞭解 OpenHarmony 的技術特點，本期對 OpenHarmony HAP 包安裝實現進行剖析。

​​一、HAP包介紹​​

HAP 包是由程式碼、資源、第三方庫以及應用配置檔案打包生成的模組包，主要分為兩種型別：entry 和 feature。

• ​entry：​應用的主模組，作為 OpenHarmony 應用的入口，提供了應用的基礎功能。
• ​feature：​應用的動態特性模組，作為應用能力的擴充套件，可以根據使用者的需求和裝置的型別進行選擇性安裝。

OpenHarmony 使用者應用程式包可以只包含一個基礎的 entry 包，也可以包含一個基礎的 entry 包和一個或多個功能型的 feature 包。

HAP 包的型別你 get 了嗎？接下來咱們對 HAP 包的安裝實現進行深度剖析。

​​二、HAP包的安裝流程簡介​​

首先我們來看看在正常場景下，HAP 包的安裝流程。如圖 1：

圖1 HAP包安裝流程

1. 端側裝置（如平板、大屏、車機、PC、手錶和手機等）從 CDN（ Content Delivery Network）雲端伺服器下載需要安裝的 HAP 包。

2. 由裝置上的包管理服務來對 HAP 包進行校驗，包括 HAP 包檔案合法性校驗、HAP 包簽名信息校驗和 HAP 包配置資訊校驗。

3. 安裝 HAP 包，包括建立 HAP 包的安裝目錄、將 HAP 包解壓並拷貝到安裝目錄和將應用資訊資料存入資料庫和快取。

以上是 HAP 包從下載到安裝的整個流程，接下來對 HAP 包安裝實現進行詳解！

​​三、HAP包安裝實現詳解​​

​​1）HAP包檔案合法性校驗​​

當端側裝置完成從各種渠道下載 HAP 包檔案之後，launcher （桌面應用）會獲得該HAP檔案的儲存路徑，隨後 launcher 將該路徑傳遞給包管理服務。

包管理服務獲取了所有要安裝的 HAP 包檔案路徑之後，開始對 HAP 包檔案合法性進行校驗。

校驗的內容主要包括以下幾項：

• HAP 包檔案是否存在
• HAP 包檔名的合法性，要求檔名的長度不能超過 256 個位元組
• HAP 包檔案型別的合法性，要求檔案必須以 .hap 作為字尾
• HAP 包檔案路徑的型別
• HAP 包檔案的大小，要求單個 HAP 檔案的大小不能超過 4GB
• 磁碟是否有足夠的空間來安裝 HAP 包檔案

​​2）HAP包簽名信息校驗​​

為了確保應用的釋出者來自於同一個組織或個人，防止應用的資訊被他人惡意篡改，因此需要在 HAP 包的安裝或升級過程中對 HAP 包簽名信息進行校驗。安裝過程中需要保證同一應用不同 HAP 包簽名信息一致，升級過程中需要保證同一應用中待安裝的 HAP 包和已安裝的 HAP 包簽名信息一致。

簽名信息校驗時，包管理服務呼叫安全子系統的介面，獲取 HAP 包的簽名信息，校驗簽名信息中的 appId 字串（該字串經過雜湊演算法的處理，可以保證一個應用對應唯一的一個 appId 字串）。通過判斷同一應用不同 HAP 包簽名信息中 appId 字串是否一致來判斷 HAP 包的簽名信息的一致性。

​​3）HAP包配置資訊校驗​​

在安裝過程中需要校驗所有的 HAP 包中 config.json 檔案中 APP 物件內部的配置資訊是否一致。

config.json 檔案中 APP 物件內部配置資訊示例如下：

"app": {
        "bundleName": "com.example.13jsdemo",
        "vendor": "huawei",
        "version": {
            "code": 1000000, 
            "name": "1.0.0"
        },
        "apiVersion": {
            "compatible": 4, 
            "releaseType": "Release", 
            "target": 5            
        }
    },

通過 config.json 檔案配置資訊例項可以看出 HAP 包配置資訊具體包括如下幾項：

• 應用的包名
• 供應商
• 版本號
• 釋出方式
• 適用的裝置型別
• 相容的 API 的版本資訊

若同一應用的多個 HAP 包的 config.json 檔案中的配置資訊一致，則繼續接下來的安裝。若不一致，則終止安裝。

​​4）安裝HAP包​​

包管理服務通過建立 HAP 包的安裝目錄、解壓 HAP 包檔案及應用資訊資料存入資料庫和快取三個步驟完成 HAP 包的安裝。

由於系統檔案的管控導致包管理服務並沒有許可權來建立目錄，也不能將從 HAP 包中解壓出來的檔案拷貝到指定的目錄，因此藉助系統的常駐程序——installd 程序來建立檔案目錄，及完成目錄下檔案的 IO 操作（input/output 縮寫，指代讀寫操作）。

具體操作如圖 2 所示：

圖2 安裝HAP包

1. 包管理服務通過 IPC（Inter-Process Communication）跨程序通訊，通知 installd 程序。

2. Installd 程序先通過呼叫核心的介面 mkdir 來建立目錄，再通過檔案操作（將檔案轉換成位元組流的操作）將檔案寫到目錄下。

3. Installd 程序將建立成功與否的結果以錯誤碼的形式返回給包管理服務。返回的錯誤碼包括：

• ERR_APPEXECFWK_INSTALLD_CREATE_DIR_FAILED，代表建立目錄失敗
• ERR_APPEXECFWK_INSTALLD_REMOVE_DIR_FAILED，代表移除目錄失敗
• ERR_OK，代表目錄建立或者刪除操作成功

4. 包管理服務將 HAP 包資訊儲存在服務快取中，同時為了防止包資訊的丟失，將這部分的內容寫入到資料庫。

​說明：​

雖然 installd 程序擁有建立和刪除目錄的許可權，但是 installd 的許可權也是有限的，它只有在應用目錄的上級目錄下建立和刪除的許可權。

經過對 HAP 包檔案合法性校驗、HAP 包簽名信息校驗、HAP 包配置資訊校驗和安裝 HAP 包的層層剖析之後，是不是對 HAP 包整個安裝過程瞭然於胸了，接下來咱們一起來探究下 HAP 包的升級安裝策略吧。

​​四、升級安裝策略​​

升級安裝時需要考慮已經安裝的 HAP 包和待安裝的 HAP 包的版本相容性。如果開發者在新版本的 HAP 包中迭代了某些新功能和特性，這些變化對於低版本的 HAP 包可能是不能相容的。如果一個應用的部分 HAP 包升級到更高的版本之後還依然保留著部分低版本的 HAP 包，將造成低版本的 HAP 包無法正常使用。因此，制定合理的升級策略是保證應用正常執行的基礎。

HAP 包的升級策略總結為以下幾點：

• 不允許安裝比已安裝應用版本號更低的 HAP 包。
• 在安裝了 entry 型別的 HAP 包的前提下，安裝的 feature 型別 HAP 包必須和 entry 型別 HAP 包的版本號一致。當升級安裝更高版本的 entry 型別 HAP 包，需要將已安裝的低版本 feature 型別 HAP 包在升級結束之後解除安裝，再重新安裝高版本 feature 型別 HAP 包。
• 在未安裝 entry 型別 HAP 包的前提下，可以升級安裝更高版本的 feature 型別 HAP 包，但是需要保證在升級結束之後，低版本的 HAP 包被解除安裝。

​​五、安裝異常處理​​

按部就班完成以上操作之後仍然安裝失敗怎麼辦？當前提供瞭如下常見問題供開發者進行查詢。

​​問題現象1：​​當已經完成部分HAP包的安裝時，其中某個HAP包建立目錄失敗導致該HAP包安裝失敗。

​解決措施：​在安裝流程結束之前，系統解除安裝安裝好的HAP包，刪除已建立的安裝目錄和資料目錄，同時刪除包管理服務和資料庫中的包資訊，再重新安裝。

​​問題現象2​​：在HAP包安裝的過程中，裝置突然重啟，導致HAP包安裝中斷。

​解決措施：​在裝置重啟後，首先包管理服務檢查應用的安裝狀態，若狀態正常則系統將資料庫中資訊恢復到包管理服務的快取中。若狀態異常則系統將刪除包資訊、殘留的包檔案、安裝目錄和資料目錄，再重新安裝。

​​問題現象3：​​在HAP包升級安裝過程中，裝置重啟。

​解決措施：​在裝置重啟後，包管理服務刪除已建立的臨時安裝目錄。

​​問題現象4：​​在安裝過程中，包管理服務突然重啟。

​解決措施：​包管理服務突然重啟，且不會返回任何結果。此時IPC提供的死亡監聽機制將會告知安裝裝置，包管理服務已經死亡。等待數秒，包管理服務會自動重啟，使用者只需要重新安裝。

掃碼新增開發者小助手微信  

獲取更多OpenHarmony開發資源和開發者活動資訊