When an HTML5 app or a mini program needs to be updated, the developer uploads an update package for this HTML5 app/mini program through the mPaaS offline package distribution platform and assigns a new version number. On the client-side, the app will actively ask the server whether the offline package of a certain HTML5 app or mini program has a version update. If so, the server will inform the client of the details of the updated package. The client can actively download the new resource package to the local area according to the information and decompress it to overwrite the previous offline resource file, thus realizing the update of offline resources. If the offline package cannot be updated, it has a greater impact on the user experience.
A developer releases a new HTML5 app offline package or a new mini program package through MDS (Mobile Delivery Service). However, it still has the old version of content and does not meet expectations when the client opens the HTML5 app or mini program.
If the developer is not very clear about the direction of troubleshooting for the offline package update, we recommend referring to Troubleshooting through HTTP packet to capture HTTP packets and analyze the troubleshooting of update issues based on the behavior in HTTP packets.
1.Make sure that the version of the target offline package is in the release status.
If not in the release status, click Create a Release to create a release task for a specific version.
2.Check the range of client versions covered by the Release a task.
For the target offline package version, click View to view the details:
Check the range of client versions covered by the release:
The version number in the client version range refers to that of the iOS or Android native application based on the mPaaS framework.
Specifically, the version number value for the iOS client is not the version number of the Xcode project, but the value of the
Production Version field in
The version number value of the Android client is the value of the
versionName field in
3.[Optional] For an offline package or mini program package, try to keep the release tasks streamlined enough (one to two). For stale offline package version release tasks, stop or delete the release task if it is no longer in use to avoid abnormalities in the MDS cache.
- Confirm the update code logic.
The development frameworks of both mPaaS iOS and Android clients provide APIs for offline package active updates. Normally, every time you open an offline package, the framework itself will also actively check for the availability of updates. Confirm whether the mPaaS framework, HTML5 container and offline package components are correctly accessed and whether the API is correctly used.
If the active update API is called, confirm the timing of the call and check if requestAllNebulaApp(iOS)/updataAll(Android) is called correctly.
- Verify that the client number is within the release of the offline package/mini program package.
- For iOS devices, check if the
Production Versionfield value in
info.plistis within the release scope of the offline package or mini program package.
- For Android devices, check whether the value of the
build.gradleis within the release of the offline package or mini program package.
- Check whether the RPC request for update is responded normally.
Check in the console whether the response to the RPC request issued upon calling update api is correct.
Usually, the normal update process for a single offline package is as follows:
- The client sends a request to the MDS server with the ID and local version number of the target HTML5 app that needs to be updated.
- The server returns the relevant update information for this offline package, if it exists.
- The client actively downloads the amr file of the updated package according to the
incremental package addressin the returned message and in combination with the
download configuration parametersin the return message. (If there is no incremental package address, the full package is downloaded according to the
Request offline package information.
The returned offline package update information.
The client downloads the corresponding amr file according to the URL of the incremental packet obtained in the previous step.
Example of offline package update log: 2-offline-package-update-example.chls.zip
Both iOS and Android platforms provide APIs to request the updated information of all offline packages at once, with the following process:
- The client sends a request to the MDS server with IDs and local version numbers of all HTML5 apps that have been locally installed, and a special app ID:
- The server returns information about all offline packages that conform to the requirement (offline packages beyond the range of client versions are not returned).
- The client takes the initiative to download the full or incremental amr files based on the returned information content.
Request offline package information.
The returned information about offline packages that conform to the requirement.
The client downloads all the amr files according to the URL obtained in the previous step.
Example of all offline package update log: 2-offline-package-update-all-example.chls.zip
View the client version number in the Offline package update information request body. Check whether the client version number is in the range of client versions that are supported by this offline package.
Check whether the Offline package update information request body contains the
App ID of the target packageor a
Check whether the returned data of the offline package update information request contains the target offline package and related information, such as amr address, fallback address.
Check whether the download process of the amr file is normal.