Android application installation method based on resource preloading

Abstract

The invention is applicable to the technical field of application installation, and provides a resource preloading-based Android application installation method, which comprises the following steps that: a construction end constructs a complete installation directory mirror image of a target Android application through resource preloading, and stores the complete installation directory mirror image in an NFS (Network File System) shared memory; mounting the complete installation directory mirror image in the NFS shared memory to a local temporary directory by the running end, and mounting the local temporary directory, a write-in layer directory and a working directory required by the OverlayFS to a standard installation directory of the target Android application; when an operation end receives an installation request of a target Android application, scanning a standard installation directory of the target Android application through the PMS to obtain an installation package of the target Android application; and injecting the application information analyzed from the installation package of the target Android application into a PMS database, and sending a broadcast to an Android system of a running end to activate the target Android application. According to the method, the installation duration of the Android application in the cloud mobile phone scene can be shortened.

Description

Technical Field

[0001] This application belongs to the field of application installation technology, and in particular relates to an Android application installation method based on resource preloading. Background Technology

[0002] In traditional cloud phone scenarios, the Android application installation process includes steps such as APK transfer, signature verification, resource parsing, DEX optimization (i.e., using dex2oat to compile and optimize DEX files into native machine code; dex2oat is a core tool in the installation system), and post-installation broadcasting. Among these, the dex2oat stage is the most time-consuming in the entire installation process because it requires converting DEX bytecode into native machine code and writing it to the optimized file directory.

[0003] In summary, Android applications in cloud phone scenarios currently suffer from poor user experience due to long installation times. Summary of the Invention

[0004] This application provides an Android application installation method based on resource preloading, which can solve the problem of long installation time for Android applications in cloud phone scenarios.

[0005] This application provides an Android application installation method based on resource preloading, including:

[0006] The build process preloads resources to create a complete installation directory image of the target Android application and stores the complete installation directory image in NFS shared storage; the complete installation directory image contains all the files required to run the target Android application directly.

[0007] The runtime mounts the complete installation directory image in NFS shared storage to the local temporary directory, and mounts the local temporary directory, the created write layer directory, and the working directory required by OverlayFS to the standard installation directory of the target Android application.

[0008] When the runtime receives an installation request for the target Android application, it scans the standard installation directory of the target Android application through PMS to obtain the installation package of the target Android application.

[0009] The runtime injects the application information parsed from the installation package of the target Android application into the PMS database and sends a broadcast to the Android system of the runtime to activate the target Android application.

[0010] Optionally, the build process preloads resources to build a complete installation directory image of the target Android application, including:

[0011] The build process uses the Android standard tool dex2oat to pre-compile the DEX files in the installation package of the target Android application, resulting in optimized files for the target Android application.

[0012] The build process creates a standard installation directory, and the installation package, optimization files, and native library files of the target Android application are placed in the standard installation directory created by the build process in accordance with Android system specifications.

[0013] Package the standard installation directory containing the target Android application's installation package, optimization files, and native library files into a complete installation directory image.

[0014] Optionally, the full installation directory image can be in Ext4 format.

[0015] Optionally, the runtime will mount the complete installation directory image from NFS shared storage to a local temporary directory, including:

[0016] The runtime obtains the complete installation directory image by accessing NFS shared storage and mounts the obtained complete installation directory image to a local temporary directory.

[0017] Optionally, the write layer directory is used to record editing operations on the optimized files in the full installation directory image.

[0018] Optionally, the working directory is the OverlayFS cache directory, used to record temporary operations of OverlayFS.

[0019] Optionally, before the step of scanning the standard installation directory of the target Android application via PMS, the Android application installation method may also include:

[0020] The runtime uses PMS to check whether the preloaded image pool contains the complete installation directory image of the target Android application; the preloaded image pool is used to store the complete installation directory images of multiple Android applications.

[0021] When the runtime detects that the preloaded image pool of the runtime contains a complete installation directory image of the target Android application, it proceeds to the step of scanning the standard installation directory of the target Android application through PMS.

[0022] Optionally, the build site can be a device that already has the target Android application installed.

[0023] Optionally, the runtime environment is a cloud phone that needs to have the target Android application installed.

[0024] The above-mentioned solution in this application has the following beneficial effects:

[0025] In the embodiments of this application, the build end pre-compiles the Android application's installation package to construct a complete installation directory image of the Android application, and stores the complete installation directory image of the Android application in NFS shared storage, so that each running end shares a read-only complete installation directory image, reducing storage costs. Meanwhile, for the running end, by mounting the complete installation directory image of the Android application, during the installation of the Android application, the running end obtains the Android application's installation package from the complete installation directory image, injects the application information parsed from the installation package into the PMS database, and then sends a broadcast to the Android system of the running end to activate the Android application. Compared with the traditional installation process, this skips APK transmission, signature verification, and DEX optimization. Therefore, the Android application installation method of this application can significantly shorten the installation time of Android applications in cloud phone scenarios.

[0026] Other beneficial effects of this application will be described in detail in the following detailed description section. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A flowchart illustrating an embodiment of this application provides an Android application installation method based on resource preloading. Detailed Implementation

[0029] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0030] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0031] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0032] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0033] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0034] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0035] To address the issue of long installation times for Android applications in cloud phone scenarios, this application provides an Android application installation method based on resource preloading. In this method, the build end pre-compiles the Android application's installation package to construct a complete installation directory image of the Android application. This image is then stored in NFS shared storage, allowing each running end to share a single read-only complete installation directory image, reducing storage costs. Simultaneously, for the running end, by mounting the complete installation directory image, during Android application installation, the running end obtains the Android application's installation package from the complete installation directory image, injects the application information parsed from the package into the PMS database, and then sends a broadcast to the running end's Android system to activate the Android application. Compared to the traditional installation process, this skips APK transmission, signature verification, and DEX optimization. Therefore, this Android application installation method significantly shortens the installation time of Android applications in cloud phone scenarios.

[0036] The following describes the Android application installation method based on resource preloading provided in this application by way of specific embodiments.

[0037] like Figure 1As shown in the embodiments of this application, the Android application installation method based on resource preloading includes the following steps:

[0038] Step 11: The build end preloads resources to build a complete installation directory image of the target Android application and stores the complete installation directory image in NFS shared storage. This complete installation directory image contains all the files required to run the target Android application directly.

[0039] In some embodiments of this application, the aforementioned build terminal is a device that has the target Android application already installed, which can generate a complete installation directory image of the target Android application. As an optional example, the build terminal can be a personal computer (PC) or a cloud phone, and the target Android application is an Android application that the cloud phone needs to install, which can be a game application, such as the game Honor of Kings.

[0040] In some embodiments of this application, the specific implementation process of the build end preloading resources to build the complete installation directory image of the target Android application is as follows:

[0041] Step 11.1: The build team uses the Android standard tool dex2oat to pre-compile the DEX files in the installation package of the target Android application to obtain the optimized files of the target Android application.

[0042] Specifically, in a continuous integration and continuous delivery / deployment (CI / CD) pipeline, the Android standard dex2oat tool is used to perform Ahead-of-Time (AOT) compilation on the DEX files in the APK, generating optimized files for the corresponding architecture. These optimized files are typically in .odex or .oat format.

[0043] Step 11.2: The build team creates a standard installation directory and places the target Android application's installation package, optimization files, and native library files into the standard installation directory created by the build team, in accordance with Android system specifications.

[0044] In some embodiments of this application, after pre-compilation, the build end will construct a standard installation directory structure and place the installation package, optimization files, and native library files (generally lib library files, which are mainly used to store reusable code, data, or resources, and are linked into the program during compilation to achieve functional expansion or system runtime dependencies) of the target Android application into the standard installation directory created by the build end in accordance with the Android system specifications.

[0045] Step 11.3: Package the standard installation directory containing the target Android application's installation package, optimization files, and native library files into a complete installation directory image.

[0046] In some embodiments of this application, a complete standard installation directory containing the installation package, optimization files, and native library files of the target Android application can be packaged into a complete installation directory image. As a preferred example, the format of this complete installation directory image can be Ext4 format, such as defined as a sgame.img file system image.

[0047] In some embodiments of this application, in order to simplify the extraction process, pre-generated files and directory structures can be directly extracted from a device that has the target Android application installed for image building.

[0048] It should be noted that the complete installation directory image mentioned above contains all the files required to run the target Android application directly, such as the installation package, optimization files, and native library files of the target Android application.

[0049] In some embodiments of this application, after the build end has built the complete installation directory image, it stores the complete installation directory image in a Network File System (NFS) shared storage so that each running end can share this read-only complete installation directory image, thereby distributing the complete installation directory image to each running end and reducing storage costs while reducing bandwidth consumption.

[0050] Step 12: The runtime mounts the complete installation directory image from the NFS shared storage to the local temporary directory, and mounts the local temporary directory, the created write layer directory, and the working directory required by OverlayFS to the standard installation directory of the target Android application.

[0051] The aforementioned runtime environment can be a cloud phone that needs to install the target Android application.

[0052] In some embodiments of this application, the runtime can obtain a complete installation directory image (i.e., a complete installation directory image of the target Android application) by accessing NFS shared storage, and mount the obtained complete installation directory image to a local temporary directory. Simultaneously, the runtime will also create a write layer directory and the working directory required by OverlayFS.

[0053] The aforementioned write layer directory is used to record editing operations on optimized files in the complete installation directory image, such as adding, modifying, or deleting optimized files. The aforementioned working directory is the OverlayFS cache directory, used to record temporary operations within OverlayFS, such as copying whitelisted files.

[0054] In some embodiments of this application, the runtime completes the mounting by mounting the local temporary directory, the write layer directory, and the working directory to the standard installation directory of the target Android application (which is built on the runtime side). Specifically, the OverlayFS driver of Linux (Linux is an operating system) can be used to merge and map the above three directories (i.e., the local temporary directory, the write layer directory, and the working directory) to the standard installation path of the Android application (i.e., the standard installation directory). All write operations are redirected to the write layer directory, and the original image (i.e., the complete installation directory image obtained from NFS shared storage) remains read-only.

[0055] Overall, the complete installation directory image of the target Android application is distributed to each runtime environment via NFS shared storage. The runtime environment maps the complete installation directory image path to a local directory (i.e., the aforementioned local temporary directory) via NFS mounting, and uses OverlayFS (a Linux-oriented file system service that implements a union mount for other file systems) to mount a copy-on-write layer, forming a merged view that isolates the read-only image layer from write-time operations, thereby achieving runtime write isolation and protection of the image content.

[0056] It should be noted that the core functions of OverlayFS are as follows: (1) Resource sharing: Multiple cloud phone instances share the same read-only image, reducing storage costs; (2) Write isolation: Each cloud phone's personalized data (such as game saves) is stored in an independent write layer directory; (3) Second-level expansion: Adding a new cloud phone only requires mounting the image, without the need for repeated installation.

[0057] Step 13: When the runtime receives the installation request of the target Android application, it scans the standard installation directory of the target Android application through PMS to obtain the installation package of the target Android application.

[0058] In some embodiments of this application, the installation request may be sent by the system (such as a cloud phone control platform) to the runtime.

[0059] Understandably, before scanning the standard installation directory of the target Android application through PMS (PMS is a core service of the Android system, responsible for managing the installation, uninstallation, permission control, and component registration of APKs), the above Android application installation method also includes the following detection steps: the runtime checks whether the preloaded image pool of the runtime contains a complete installation directory image of the target Android application through PMS; when the runtime detects that the preloaded image pool of the runtime contains a complete installation directory image of the target Android application, it proceeds to the step of scanning the standard installation directory of the target Android application through PMS; if the preloaded image pool of the runtime does not contain a complete installation directory image of the target Android application, the target Android application is installed according to the traditional installation process.

[0060] The aforementioned preloaded image pool is used to store complete installation directory images of multiple Android applications. It is understood that all complete installation directory images of Android applications in the NFS shared storage can be mounted by the runtime, so that the runtime's preloaded image pool contains a large number of complete installation directory images of Android applications.

[0061] In some embodiments of this application, when the runtime detects that the preloaded image pool of the runtime contains a complete installation directory image of the target Android application, it can scan the standard installation directory of the target Android application (the standard installation directory refers to the standard installation directory built on the runtime side, i.e., the standard installation directory in step 12) through PMS to obtain the installation package of the target Android application.

[0062] It should be noted that the security and compatibility of the modified PMS have the following advantages: (1) Trust chain transfer: Signature verification is completed in the pipeline at the build end, and the running end trusts the trusted mirror source; (2) Seamless integration: The standard installation directory structure is retained, and the application is unaware of it when running; (3) Downgrade compatibility: Automatically rolls back the traditional installation process for non-preloaded applications.

[0063] Step 14: The runtime injects the application information parsed from the installation package of the target Android application into the PMS database and sends a broadcast to the Android system of the runtime to activate the target Android application.

[0064] It's important to note that since the target Android application's optimized files and native library files are already mounted on the runtime environment, the runtime can skip the three processes of APK transfer (which can also be understood as APK file copying), signature verification, and DEX optimization during the installation of the target Android application. It only needs to inject the application information (package name, permissions, etc.) parsed from the target Android application's installation package into the PMS database and send a broadcast to the Android system on the runtime environment to activate the target Android application. This broadcast refers to the application installation broadcast, which is the same as the traditional installation process. This application installation broadcast typically includes the package name of the application to be installed and the user account (ID) assigned to the application by the Android system.

[0065] Overall, during the installation process, the runtime mounts the application image to the system installation directory through OverlayFS (unified mount file system), modifies PMS to bypass the traditional application installation process, and saves time-consuming steps such as APK copying, signature verification and dex2oat compilation, thereby greatly shortening the installation time of Android applications in cloud phone scenarios.

[0066] Based on this, the installation method of this application can reduce the installation time from several seconds to tens of seconds to milliseconds, completely eliminating the need for runtime dex2oat compilation and large file copying. It allows for the reuse of the same pre-installed image, achieving resource sharing and cost savings. Simultaneously, it is compatible with native PMS and can be seamlessly integrated into existing Android systems and cloud gaming platforms. Specifically, the comparison of the effects of the installation method of this application with traditional installation methods is shown in Table 1 below.

[0067] Table 1

[0068]

[0069] The following example uses the deployment process of the cloud gaming platform "Honor of Kings" to illustrate the above Android application installation method.

[0070] I. Preloading Phase of the Builder

[0071] Input preparation

[0072] Obtain the target APK (i.e., the APK of Honor of Kings) and its corresponding device architecture (e.g., arm64).

[0073] Pre-compilation and image building

[0074] Step 1: AOT pre-compilation

[0075] The Android standard tool dex2oat is used to pre-compile the DEX files within the APK, generating optimized files (such as .odex / .oat) for the corresponding architecture.

[0076] Step 2: Directory Structure Organization

[0077] Create a standard installation directory, and place the original APK, pre-compiled .odex file, and native library files into the corresponding subdirectories of the standard installation directory according to Android system specifications.

[0078] Step 3: Generate a read-only image

[0079] Package the complete standard installation directory into an Ext4 format file system image. This image contains all the files needed for a ready-to-run application.

[0080] II. Runtime Mounting and Deployment Phase

[0081] Mirror distribution

[0082] The pre-built image file is stored in NFS shared storage and is accessible to all running devices.

[0083] OverlayFS mounting implementation

[0084] Step 1: Mount the NFS shared image

[0085] When the runtime starts, it mounts the file system image in the NFS shared storage to a local temporary path (such as / mnt / nfs / sgame).

[0086] Step 2: Build the OverlayFS merged view

[0087] 1. Prepare a dedicated write layer (upperdir)

[0088] Create a write layer directory, such as / data / overlay / sgame / upper, where all additions, modifications, or deletions of files will be recorded.

[0089] 2. Prepare the working directory (workdir)

[0090] Create a working directory / data / overlay / sgame / work as required by OverlayFS for internal temporary operations (such as copying whitelisted files).

[0091] 3. Specify the mount point for the merged view.

[0092] Define a target mount point from which users and game processes will access the final files.

[0093] Step 3: Mounting takes effect

[0094] Using Linux's OverlayFS driver, the three directories mentioned above are merged and mapped to the standard installation path of Android applications. All write operations are redirected to the upperdir, and the original image remains read-only.

[0095] III. Key Modifications to the Runtime PMS (Package Manager Service)

[0096] Installation process hijacking

[0097] When the system triggers an application installation request, PMS first checks if the target application (i.e., Honor of Kings) exists in the preloaded image pool. If it exists (e.g., the complete installation directory image of Honor of Kings is detected to be mounted via OverlayFS), the traditional installation process is skipped.

[0098] Preloading application registration mechanism

[0099] Step 1: Directory Scan

[0100] PMS directly scans the mounted standard installation directory and parses APK application information (package name, permissions, etc.).

[0101] Step 2: Skip redundant operations

[0102] Signature-free verification: The verification process has been completed by the trust building end;

[0103] File copying is not required: the file has already been mounted via mirror.

[0104] No dex2oat compilation required: Directly use pre-compiled optimized files.

[0105] Step 3: Quick Registration

[0106] Inject application information into the PMS database and send an application installation broadcast notification to the system to activate the application.

[0107] In summary, the Android application installation method of this application replaces the traditional installation process with "pre-compilation + image mounting" and, combined with the lightweight registration of PMS, enables large-scale instantaneous deployment of Android applications in the cloud. It can reduce installation time from minutes to seconds, eliminate user waiting, improve user experience, reduce bandwidth consumption by 90% (no repeated APK downloads), reduce storage pressure, and support cloud-native environments such as containerization / virtual machines. It is also compatible with mainstream Android versions, making it particularly suitable for high-concurrency scenarios such as cloud gaming and enterprise batch installation.

[0108] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An Android application installation method based on resource preloading, characterized in that, include: The build process preloads resources to build a complete installation directory image of the target Android application and stores the complete installation directory image in NFS shared storage. The complete installation directory image contains all the files required to run the target Android application directly. The runtime mounts the complete installation directory image in the NFS shared storage to the local temporary directory, and mounts the local temporary directory, the created write layer directory, and the working directory required by OverlayFS to the standard installation directory of the target Android application. When the runtime receives the installation request of the target Android application, it scans the standard installation directory of the target Android application through PMS to obtain the installation package of the target Android application. The runtime terminal injects the application information parsed from the installation package of the target Android application into the PMS database, and sends a broadcast to the Android system of the runtime terminal to activate the target Android application.

2. The Android application installation method according to claim 1, characterized in that, The build process preloads resources to build a complete installation directory image of the target Android application, including: The build process uses the Android standard tool dex2oat to pre-compile the DEX files in the installation package of the target Android application, thereby obtaining the optimized files of the target Android application. The build process creates a standard installation directory, and places the installation package of the target Android application, the optimization files, and the native library files into the standard installation directory created by the build process in accordance with Android system specifications. The standard installation directory containing the installation package of the target Android application, the optimization files, and the native library files is packaged into a complete installation directory image.

3. The Android application installation method according to claim 2, characterized in that, The complete installation directory image is in Ext4 format.

4. The Android application installation method according to claim 1, characterized in that, The runtime environment mounts the complete installation directory image from the NFS shared storage to a local temporary directory, including: The running terminal obtains the complete installation directory image by accessing the NFS shared storage, and mounts the obtained complete installation directory image to a local temporary directory.

5. The Android application installation method according to claim 2, characterized in that, The write layer directory is used to record editing operations on the optimized files in the complete installation directory image.

6. The Android application installation method according to claim 1, characterized in that, The working directory is the cache directory of OverlayFS, used to record temporary operations of OverlayFS.

7. The Android application installation method according to claim 1, characterized in that, Prior to the step of scanning the standard installation directory of the target Android application via PMS, the Android application installation method further includes: The runtime system uses PMS to detect whether the preloaded image pool of the runtime system contains the complete installation directory image of the target Android application; the preloaded image pool is used to store the complete installation directory images of multiple Android applications. When the runtime detects that the preloaded image pool of the runtime contains the complete installation directory image of the target Android application, it proceeds to the step of scanning the standard installation directory of the target Android application through PMS.

8. The Android application installation method according to claim 1, characterized in that, The build end is a device that already has the target Android application installed.

9. The Android application installation method according to claim 1, characterized in that, The runtime environment is a cloud phone that needs to install the target Android application.

Images