Upgrade method and apparatus, and electronic device and storage medium

Abstract

The embodiments of the present disclosure relate to the technical field of computers. Disclosed are an upgrade method and apparatus, and an electronic device and a computer-readable storage medium. The method comprises: decoupling target modules in at least one application to obtain a plurality of files corresponding to the target modules; on the basis of the plurality of files corresponding to the target modules, generating initial files corresponding to the target modules; storing the initial files in an upgrade storage area; and in response to receiving an upgrade instruction, acquiring a target initial file from the upgrade storage area, the target initial file being used for upgrading an application to be upgraded. By splitting each application into a plurality of target modules, and decoupling, compressing and combining the target modules of each application, an upgrade process can be simplified without the need for rewriting or large-scale modification of the entire application. A user can choose to upgrade a specific component as needed, rather than the entire application, which provides greater flexibility and selectivity.

Description

Method, device, electronic device and storage medium for upgrading

[0001] The present application claims priority to the Chinese patent application No. 202510179532.4, filed on February 18, 2025, and entitled "Method, device, electronic device and storage medium for upgrading", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] Embodiments of the present disclosure relate to the technical field of computer, in particular to a method, device, electronic device and computer readable storage medium for upgrading. BACKGROUND

[0003] The conventional upgrading method for Android system is OTA (Over-the-Air) upgrading, which is divided into two modes: whole package upgrading and differential package upgrading. When using whole package upgrading, the whole system is installed, which is suitable for upgrading from any version to the latest version. However, the size of the upgrading package is large, which wastes the traffic of customers. When using differential package upgrading, the device needs to download and replace the changed part.

[0004] However, both of the above two upgrading methods need to compile the whole machine software and use the package rule to generate a script file that can be upgraded, which is complex and takes a long time. TECHNICAL SOLUTION

[0005] Embodiments of the present disclosure provide a method, device, electronic device and computer readable storage medium for upgrading, which aims to at least solve one of the technical problems in the related art to some extent.

[0006] In a first aspect, embodiments of the present disclosure provide a method for upgrading, the method comprising:

[0007] decoupling each target module in at least one application to obtain a plurality of files corresponding to the target module;

[0008] generating an initial file corresponding to the target module according to the plurality of files corresponding to the target module;

[0009] storing the initial file in an upgrading storage area;

[0010] in response to receiving an upgrading instruction, obtaining a target initial file from the upgrading storage area, the target initial file being used for upgrading a to-be-upgraded application.

[0011] In a second aspect, embodiments of the present disclosure further provide a device for upgrading, the device comprising:

[0012] A decoupling module is used to decouple various target modules in at least one application to obtain multiple files corresponding to the target modules;

[0013] A generation module is used to generate an initial file corresponding to the target module based on multiple files corresponding to the target module;

[0014] A storage module is used to store the initial file in the upgrade storage area;

[0015] The acquisition module is used to acquire a target initial file from the upgrade storage area in response to receiving an upgrade instruction. The target initial file is used to upgrade the application to be upgraded.

[0016] Thirdly, this disclosure also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the upgrade method described above.

[0017] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the upgrade method described above.

[0018] Fifthly, embodiments of this disclosure also provide a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of embodiments of this disclosure.

[0019] In this embodiment, at least one target module in an application is first decoupled to obtain multiple files corresponding to the target module. Then, based on these multiple files, an initial file corresponding to the target module is generated and stored in an upgrade storage area. Subsequently, in response to receiving an upgrade command, the target initial file is retrieved from the upgrade storage area. This target initial file is used to upgrade the application to be upgraded. Therefore, by splitting the application into multiple target modules and decoupling and compressing the target modules of each application, the upgrade process can be simplified, reducing the time and resources required for the upgrade. Modular design makes application components easier to replace and upgrade without rewriting or extensively modifying the entire application. Users can choose to upgrade specific components instead of the entire application, providing greater flexibility and choice.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this disclosure, the accompanying drawings used in the description of the embodiments 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.

[0022] Figure 1 is a flowchart illustrating the upgrade method provided in the first embodiment of this disclosure;

[0023] Figure 2 is a schematic diagram of mounting an APEX file to the upgrade partition;

[0024] Figure 3 is a flowchart illustrating the upgrade method provided in the second embodiment of this disclosure;

[0025] Figure 4 is an exemplary flowchart of an upgrade method;

[0026] Figure 5 is a schematic diagram of the structure of the upgrade device provided in an embodiment of this disclosure;

[0027] Figure 6 is a schematic diagram of the structure of the electronic device provided in an embodiment of this disclosure.

[0028] Implementation methods of this application

[0029] Some embodiments of this disclosure will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become apparent upon understanding this disclosure, except for operations that must be performed in a particular order. Furthermore, for clarity and brevity, descriptions of features known in the art may be omitted.

[0030] The embodiments described in the following examples of this disclosure are not representative of all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0031] It should be noted that the execution subject of the upgrade method in this embodiment can be an upgrade device, which can be configured in any type of electronic device and is not limited here.

[0032] In this embodiment, the upgrade method will be described using an "upgrade device" as the executing entity, and no limitation is set herein. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0033] Figure 1 is a flowchart illustrating the upgrade method provided according to the first embodiment of this disclosure.

[0034] As shown in Figure 1, the method includes:

[0035] Step 101: Decouple each target module in at least one application to obtain multiple files corresponding to the target modules.

[0036] The application can be of any type.

[0037] The target module can be the module corresponding to the function to be updated. For example, if application A needs to update the startup component and Bluetooth component, and module 1 and module 2 in the application are used to implement the functions of the startup component and Bluetooth component respectively, then module 1 and module 2 are the modules that need to be updated, and module 1 and module 2 can be used as the target modules.

[0038] For example, suppose there is a target module called UserManagement that is responsible for handling the creation, reading, updating, and deletion of user information. The upgrade device can decouple it from this module by decoupling it into the following files:

[0039] User.js: Defines the structure and behavior of user objects.

[0040] UserService.js: Contains user-related business logic, such as verifying user information and creating new users.

[0041] UserRepository.js: Handles interactions with databases or other storage systems for storing and retrieving user data.

[0042] UserController.js: Responsible for handling requests from the frontend or other services and performing corresponding operations.

[0043] In this way, the functionality of the UserManagement target module can be decoupled into multiple smaller, more manageable files, each with a clear purpose and responsibility.

[0044] It should be noted that the number and type of files obtained from decoupling different target modules are usually different, and no limit is imposed here.

[0045] Step 102: Generate the initial file corresponding to the target module based on the multiple files corresponding to the target module.

[0046] Optionally, the target file corresponding to the target module includes at least one of the following:

[0047] Permissions file;

[0048] Configuration file;

[0049] binary file;

[0050] Shared object files; or

[0051] Java archive files.

[0052] Optionally, an initial file corresponding to the target module can be generated based on at least one of the multiple files corresponding to the target module.

[0053] It should be noted that after decoupling the target module, the target file needs to be determined from the multiple files obtained after decoupling. The target file can be any file needed to create the initial file, such as permission files, configuration files, binary files, shared object files, or Java archive files; there are no restrictions here. The number of target files corresponding to different target modules can be different or the same.

[0054] For example, some target modules only need permission files and Java archive files, while others need all target files, that is, permission files, configuration files, binary files, shared object files, or Java archive files. This is not a limitation.

[0055] In this context, the permission file refers to a file or settings that define file or directory access permissions. It should be noted that the permission file in this embodiment is used to implement permission management, encompassing both traditional file access permissions and permission management for SELinux (Security-Enhanced Linux).

[0056] For example, when httpd needs to access a file named fle, and requires permissions for that file from higher-level directories (such as the parent directories or higher-level directories in the file's directory structure), the httpd process needs sufficient operating system permissions to read, execute, and possibly write to the file. Because the configuration file includes SELinux permissions, it allows httpd to access specific resources.

[0057] Configuration files are files used to store settings and parameters for software, systems, or applications. These files are typically in text format, but can also exist in binary format. Configuration files allow developers and users to customize the behavior of software according to specific needs or environments. For example, a database configuration file might contain details about database connections, while a web server configuration file might define how the server responds to client requests.

[0058] A binary file (bin file) is a file containing computer programs or data, whose contents are stored in binary form (i.e., a sequence of 0s and 1s). Unlike text files, binary files are not stored in a human-readable character format. Binary files typically contain machine code (i.e., instructions that a computer can directly execute), or compressed, encrypted, or encoded data.

[0059] Shared object files (.so files) are files containing code and data that can be shared by multiple programs at runtime. Shared object files allow programs to dynamically link to them as needed, rather than statically linking at compile time. The benefits of this include reduced memory footprint (because the same libraries can be shared between multiple programs) and easier updating and replacement of library files (because programs using these libraries do not need to be recompiled).

[0060] Java Archive (JAR) files are packaging tools used to bundle multiple Java class files, resource files (such as images and audio), and metadata (such as manifest files) into a single compressed file. JAR files are part of the Java platform and allow developers to package their applications into a portable, easily distributed format.

[0061] Specifically, when generating the initial file for each target module, it can be formed by combining the target files after decoupling from the target module. For example, some modules need to combine permission files and Java archive files, while some target modules need all target files, that is, permission files, configuration files, binary files, shared object files, or Java archive files. This is not limited here.

[0062] For example, the permission files, configuration files, binary files, shared object files, or Java archive files of a target module can be compressed and combined to generate the initial file corresponding to that target module.

[0063] Understandably, decoupling the target modules within an application makes it easier to identify and manage the files for each module. This modular approach makes the upgrade process more flexible and efficient, as it allows for operations only on the modules that need upgrading, without requiring a full application update. Initial files for the target modules are then generated.

[0064] Alternatively, the target files of each target module corresponding to each application can be compressed and combined to obtain the initial file corresponding to each application.

[0065] The initial file can be a data package used to support the implementation of a specific function, or to support the implementation of multiple functions in the application. In this embodiment of the disclosure, since different target modules of the application correspond to different functions, the initial file obtained by compressing and combining the target files of different target modules can support the implementation of the functions of each target module in the application.

[0066] For example, for application V, there are 5 target modules that need to be updated, and each target module has 3 target files. Therefore, these 15 target files can be compressed and combined together to obtain the initial file for application V. This initial file can then be used to upgrade application V.

[0067] The initial file can also be an APEX file. A detailed description of APEX files can be found in the above embodiments and will not be repeated here. An APEX file is a special installation package format in the Android system, used to update system components that are not suitable for the APK installation process. An APEX file is typically a ZIP archive containing key files such as apex_manifest.json, AndroidManifest.xml, apex_payload.img, and apex_pubkey.

[0068] Understandably, breaking down an application into multiple target modules and decoupling and compressing each module simplifies the upgrade process and reduces the time and resources required. The use of cloud servers and component upgrade lists allows users to quickly select and download the components they need to upgrade, further improving upgrade efficiency. Modular design makes application components easier to replace and upgrade without rewriting or extensively modifying the entire application. Users can choose to upgrade specific components rather than the entire application, providing greater flexibility and choice.

[0069] Step 103: Store the initial file in the upgrade storage area.

[0070] The upgrade storage area can be a pre-created upgrade partition.

[0071] As is understandable, the upgrade partition is a storage space in the Android system used to store updatable components. These partitions typically have specific purposes and attributes, such as read-only or read-write. By mounting initial files to the upgrade partition, the system can update these components when needed.

[0072] As shown in Figure 2, firstly, the modules (target modules) of application A, application B, and application N are decoupled, and the target files (bin file, so file, jar package file, permission file, and configuration file) corresponding to application A, application B, and application N are generated respectively. Then, the target files of each application are compressed and combined into an APEX file (initial file), which can then be verified. After verification, it can be mounted to the upgrade partition, that is, the upgrade storage area.

[0073] Step 104: In response to receiving the upgrade instruction, retrieve the target initial file from the upgrade storage area. The target initial file is used to upgrade the application to be upgraded.

[0074] The upgrade command indicates that there is a need to upgrade the application to be upgraded. After receiving the upgrade command, the upgrade device needs to retrieve the corresponding target initial file from the upgrade storage area.

[0075] Specifically, the upgrade device determines the target initial file associated with the upgrade requirement based on the user's touch operation on the client (such as clicking the icon of the target initial file in the client's display interface). The target initial file can be one or more.

[0076] Furthermore, users can upload the corresponding target initial file to the cloud server based on their upgrade or product requirements. This target initial file can then be used to upgrade the application being upgraded.

[0077] In this embodiment, at least one target module in an application is first decoupled to obtain multiple files corresponding to the target module. Then, based on these multiple files, an initial file corresponding to the target module is generated and stored in an upgrade storage area. Subsequently, in response to an upgrade command, the target initial file is retrieved from the upgrade storage area and used to upgrade the application. Thus, by splitting the application into multiple target modules and decoupling and compressing the target modules of each application, the upgrade process is simplified, reducing the time and resources required for the upgrade. Modular design makes application components easier to replace and upgrade without rewriting or extensively modifying the entire application. Users can choose to upgrade specific components instead of the entire application, providing greater flexibility and choice. Uploading the target initial file to the upgrade storage area provides a reliable backup and distribution channel for subsequent upgrades. This reduces the risk of data loss or corruption during the upgrade process and reduces costs associated with upgrade failures.

[0078] Figure 3 is a flowchart illustrating the upgrade method provided according to the second embodiment of this disclosure.

[0079] As shown in Figure 3, the method includes:

[0080] Step 201: Decouple each target module in at least one application to obtain multiple files corresponding to the target modules.

[0081] Step 202: Generate the initial file corresponding to the target module based on the multiple files corresponding to the target module.

[0082] Step 203: Store the initial file in the upgrade storage area.

[0083] Step 204: In response to receiving the upgrade instruction, retrieve the target initial file from the upgrade storage area. The target initial file is used to upgrade the application to be upgraded.

[0084] It should be noted that the specific implementation of steps 201-204 can be referred to the above embodiments, and will not be repeated here.

[0085] Step 205: Upload the target initial file to the cloud server.

[0086] Step 206: Send the target trigger command to the cloud server.

[0087] The target trigger command notifies the cloud server to prepare for an upgrade, allowing the cloud server to return a list of components to be upgraded associated with the uploaded target initial file. This list can include all components that are currently eligible for upgrade.

[0088] As one possible approach, after the upgrade device uploads the initial target file to the cloud server, the user can send a target trigger command to the cloud server through the upgrade device. The cloud server can then return a list of components to be upgraded to the upgrade device, from which the user can select the components to be upgraded.

[0089] Step 207: Receive the component upgrade list returned by the cloud server and display the component upgrade list on the client. The component upgrade list is associated with the initial file.

[0090] Specifically, the upgrade device can receive a list of component upgrades returned by the cloud server, and then display the list on the client's interface. Optionally, the upgrade device can also simultaneously receive the upgrade files corresponding to the component upgrade list.

[0091] Step 208: Based on the user's first selection operation in the client, determine the components to be upgraded from the component upgrade list.

[0092] The components to be upgraded can be those that the user currently wants to upgrade, such as the system user interface component, the launcher component, the Bluetooth component, the wireless network component, the settings component, the high-definition multimedia interface component, the audio playback component, etc., without any limitations.

[0093] It should be noted that the components to be upgraded require corresponding upgrade files to update or replace them in order to improve performance, add new features, or fix security vulnerabilities, thereby achieving optimized updates.

[0094] As one possible implementation, the user can select one or more components as the components to be upgraded in the specified operation interface, or the upgrade device can automatically determine the components to be upgraded, without any limitation.

[0095] The first selection operation is the user's operation of selecting the component to be upgraded on the client, such as clicking the icon of the component to be upgraded on the client's display interface, which is not limited here.

[0096] Step 209: Upgrade the application based on the components to be upgraded.

[0097] Optionally, you can first obtain the upgrade file based on the component to be upgraded, then store the upgrade file in a temporary directory and restart the system. Then copy the upgrade file in the temporary directory to the startup directory of the application to be upgraded, and then upgrade the application.

[0098] Specifically, users can upload the corresponding initial files to the cloud server based on their upgrade or product requirements. The upgrade file can be a single file package containing various data required for upgrading each component.

[0099] Specifically, the upgrade device can download the corresponding upgrade file based on the identifier of the component to be upgraded. The upgrade file can be an APEX file, which can be obtained from a cloud server.

[0100] APEX is a system module management tool that allows system components to be packaged into individual modules and updated independently of the entire system image. An APEX file is typically a ZIP archive containing multiple files and directories that describe and store updates to system components.

[0101] It should be noted that if the upgrade file is an APEX file, subsequent upgrades using the APEX file can be applied without restarting the device or on the next restart, thereby reducing downtime caused by system updates and speeding up the system upgrade process.

[0102] As one possible approach, the upgrade device can download the upgrade files corresponding to each component to be upgraded from a cloud server and verify the signature of the upgrade files, thereby ensuring the integrity and security of the upgrade files.

[0103] The temporary directory can be a special directory within the upgrade device's operating system used to store temporary files, such as temporary results or support for the normal operation of the program. It should be noted that the upgrade device can pre-create a folder on a non-system drive as a temporary directory to store upgrade files.

[0104] Specifically, after storing the upgrade files in a temporary directory, you can restart the system.

[0105] It's important to note that restarting the system can clear any residual information from older versions of programs or components in memory, thus avoiding version conflicts or data inconsistencies during the upgrade process. Restarting the system also ensures that all running services and processes are shut down, which helps reduce interference and uncertainty during the upgrade process. In some cases, running applications or services may be using files or resources that are about to be upgraded. Restarting the system ensures that these files or resources are unused before the upgrade, thereby avoiding potential conflicts.

[0106] The application to be upgraded can be the application that the user is currently preparing to upgrade. The number of applications to be upgraded can be one or more, and there is no limit to this.

[0107] The startup directory is the basic path for the application to be upgraded to find resource files, configuration files, etc. When the application to be upgraded is running, it usually locates these files based on the startup directory.

[0108] One possible approach is to first check the files in the temporary directory to ensure that the necessary upgrade files are prepared there. Then, the corresponding application to be upgraded can be determined based on the upgrade files. It should be noted that an application to be upgraded can have one or more upgrade files.

[0109] For example, if there is only one upgrade file for the application to be upgraded, then the upgrade file can be used to upgrade the entire application, such as updating one or more updatable features of the application.

[0110] If there are multiple upgrade files for the application to be upgraded, each upgrade file may be used to update a corresponding function. For example, upgrade file A may be used to update the startup function of application M to be upgraded, and upgrade file B may be used to update the location function of application M to be upgraded. This is not limited here.

[0111] Therefore, if there is only one upgrade file for the application to be upgraded, the upgrade file can be copied from the temporary directory to the startup directory of the application to be upgraded, and then the entire application to be upgraded can be directly upgraded based on the upgrade file.

[0112] If there are multiple upgrade files for the application to be upgraded, one upgrade file can be copied to the application's startup directory at a time. Then, a specific function of the application to be upgraded is upgraded based on that upgrade file. After that, the other upgrade files are copied to the application's startup directory in sequence. In this way, each function of the application to be upgraded can be upgraded sequentially.

[0113] Optionally, there may be one or more applications to be upgraded, and each upgrade file has a corresponding initial file.

[0114] One possible approach is to first launch the application to be upgraded before upgrading it. If the application launches successfully, the upgrade file corresponding to the application in the temporary directory can be deleted. If the application fails to launch, the upgrade file in the launch directory can be replaced with the corresponding initial file.

[0115] The initial file can be the original file corresponding to the upgrade file. For example, if the upgrade file is used to update the Bluetooth function, the initial file can be the relevant files for implementing the Bluetooth function before the upgrade, containing relevant data for implementing the Bluetooth function, such as configuration parameters, etc.

[0116] Specifically, you can first start the application to be upgraded to verify whether the application can still run normally in the current state.

[0117] If the application to be upgraded starts successfully and runs normally, then the current upgrade file can be considered compatible with the current version of the application. In this case, it is safe to delete the upgrade file corresponding to the application in the temporary directory.

[0118] It should be noted that before deleting files, the upgrade device needs to ensure that these files are no longer needed and that no other processes are using them.

[0119] If the application to be upgraded fails to launch, it may be due to incompatibility between the upgrade files and the current version of the application, or an error occurring during the upgrade process. In this case, you need to replace the upgrade files in the launch directory with the corresponding initial files, i.e., the files before the upgrade. Then, you can replace the upgrade files in the launch directory with the initial files. During the replacement process, ensure that only files that truly need to be replaced are replaced to avoid unnecessary interference with other parts of the application. After replacing the files, you need to try launching the application to ensure that the rollback operation was successful and that the application can run normally.

[0120] It's important to note that by clearly identifying the components to be upgraded and obtaining the corresponding upgrade files, only the components requiring updates need to be upgraded, significantly reducing the upgrade package size. This eliminates the need for a complete reinstallation and package creation, improving upgrade efficiency. Since the upgrade files are directly stored in a temporary directory after acquisition, this process simplifies the complex compilation and packaging steps of traditional upgrade methods, reducing upgrade time. After restarting the system, the upgrade files are copied to the startup directory of the corresponding application to be upgraded, without waiting for the entire system to be recompiled or installed, greatly shortening upgrade time. During the upgrade process, the upgrade files are stored in a temporary directory and copied to the startup directory of the application to be upgraded after the system restarts. This design reduces the risk of upgrade failure because even if problems occur during the upgrade process, the original application and data can still be preserved. The component-based upgrade approach also reduces compatibility issues that may be introduced by upgrading the entire application. The fast upgrade speed and flexible upgrade options can improve user satisfaction and loyalty.

[0121] As shown in Figure 4, the client first sends a component upgrade request, then obtains a list of upgradable components, then selects the module to be upgraded, downloads the selected component, places the component in a temporary directory, restarts the system, and then copies the temporary directory files to the module's startup directory. If the application starts successfully, the temporary directory is deleted; if the application fails to start successfully, the initial version of the APEX file is decompressed and copied to the startup directory.

[0122] In this embodiment, at least one target module in an application is first decoupled to obtain multiple files corresponding to the target module. Then, based on these files, an initial file for each target module is generated and stored in an upgrade storage area. Upon receiving an upgrade command, the target initial file is retrieved from the upgrade storage area. This initial file is used to upgrade the application to be upgraded. The target initial file is then uploaded to a cloud server, and a target trigger command is sent to the cloud server. The cloud server then returns a component upgrade list, which is displayed on the client. This list is associated with the initial file. Based on the user's first selection in the client, the components to be upgraded are determined from the upgrade list. Finally, the application to be upgraded is upgraded based on these components. Thus, the user can intuitively see the component upgrade list on the client and select the components to be upgraded according to their needs. This interactive method makes the upgrade process more user-friendly, increasing user participation and satisfaction. By decoupling the application into multiple target modules, each module can be upgraded independently without requiring a full application update, thereby improving the targeting and efficiency of the upgrade. The generated initial files are stored in the upgrade storage area for easy management and quick access, reducing data retrieval time during the upgrade process. Uploading the target initial files to the cloud server leverages the cloud's storage and computing power to efficiently handle large-scale data transfers and upgrade requests. The cloud server, acting as a relay station for upgrade files, verifies and encrypts the uploaded initial files, ensuring their integrity and security. The component upgrade list returned by the cloud server further verifies the correctness and applicability of the upgrade content, preventing system crashes or functional malfunctions caused by improper upgrades.

[0123] To facilitate better implementation of the upgrade method of this disclosure, this disclosure also provides an upgrade apparatus based on the above-described upgrade method. The meanings of the terms used are the same as in the upgrade method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0124] Please refer to Figure 5, which is a schematic diagram of the structure of the upgrade device 500 provided in this embodiment of the present disclosure. The upgrade device 500 includes:

[0125] Decoupling module 510 is used to decouple each target module in at least one application to obtain multiple files corresponding to the target modules;

[0126] The generation module 520 is used to generate an initial file corresponding to the target module based on multiple files corresponding to the target module;

[0127] Storage module 530 is used to store the initial file in the upgrade storage area;

[0128] The acquisition module 540 is configured to, in response to receiving an upgrade instruction, acquire a target initial file from the upgrade storage area, the target initial file being used to upgrade the application to be upgraded.

[0129] Optionally, the generation module is specifically used for:

[0130] Generate an initial file corresponding to the target module based on at least one target file from among multiple files corresponding to the target module;

[0131] or,

[0132] The target files of each target module corresponding to each application are compressed and combined to obtain the initial file corresponding to each application.

[0133] The target file corresponding to the target module includes at least one of the following:

[0134] Permissions file;

[0135] Configuration file;

[0136] binary file;

[0137] Shared object files; or

[0138] Java archive files.

[0139] Optionally, the acquisition module may also include:

[0140] An upload unit is used to upload the target initial file to a cloud server;

[0141] The sending unit is used to send a target triggering command to the cloud server;

[0142] A receiving unit is configured to receive a component upgrade list returned by the cloud server and display the component upgrade list on the client, wherein the component upgrade list is associated with the initial file;

[0143] A determining unit is configured to determine the component to be upgraded from the component upgrade list based on the user's first selection operation in the client.

[0144] The upgrade unit is used to upgrade the application to be upgraded based on the component to be upgraded.

[0145] Optional upgrade units include:

[0146] The acquisition subunit is used to obtain the upgrade file based on the component to be upgraded;

[0147] A storage subunit is used to store the upgrade file in a temporary directory and then restart the system;

[0148] The copying subunit is used to copy the upgrade file in the temporary directory to the startup directory of the application to be upgraded;

[0149] The upgrade subunit is used to upgrade the application to be upgraded.

[0150] Optionally, the transmitting unit is also used for:

[0151] Receive the upgrade file corresponding to the component upgrade list.

[0152] Optionally, there is one or more applications to be upgraded, and the upgrade file has a corresponding initial file. The upgrade subunit is specifically used for:

[0153] Launch the application to be upgraded;

[0154] If the application to be upgraded starts successfully, delete the upgrade file corresponding to the application to be upgraded in the temporary directory;

[0155] If the application to be upgraded fails to start, the upgrade file in the startup directory will be replaced with the corresponding initial file.

[0156] In this embodiment, at least one target module in an application is first decoupled to obtain multiple files corresponding to the target module. Then, based on these multiple files, an initial file corresponding to the target module is generated and stored in an upgrade storage area. Subsequently, in response to receiving an upgrade command, the target initial file is retrieved from the upgrade storage area. This target initial file is used to upgrade the application to be upgraded. Therefore, by splitting the application into multiple target modules and decoupling and compressing the target modules of each application, the upgrade process can be simplified, reducing the time and resources required for the upgrade. Modular design makes application components easier to replace and upgrade without rewriting or extensively modifying the entire application. Users can choose to upgrade specific components instead of the entire application, providing greater flexibility and choice.

[0157] In addition, this disclosure also provides an electronic device, as shown in FIG6, which illustrates a structural schematic diagram of the electronic device involved in this disclosure, specifically:

[0158] The electronic device may include components such as a processor 601 with one or more processing cores, a memory 602 with one or more computer-readable storage media, a power supply 603, and an input unit 604. Those skilled in the art will understand that the electronic device structure shown in FIG6 does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0159] The processor 601 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, thereby providing overall monitoring of the electronic device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0160] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.

[0161] The electronic device also includes a power supply 603 that supplies power to the various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0162] The electronic device may also include an input unit 604, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0163] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 602 according to the following instructions, and the processor 601 runs the applications stored in the memory 602, thereby implementing the steps in any of the upgrade methods provided in the embodiments of this disclosure.

[0164] In this embodiment, at least one target module in an application is first decoupled to obtain multiple files corresponding to the target module. Then, based on these multiple files, an initial file corresponding to the target module is generated and stored in an upgrade storage area. Subsequently, in response to receiving an upgrade command, the target initial file is retrieved from the upgrade storage area. This target initial file is used to upgrade the application to be upgraded. Therefore, by splitting the application into multiple target modules and decoupling and compressing the target modules of each application, the upgrade process can be simplified, reducing the time and resources required for the upgrade. Modular design makes application components easier to replace and upgrade without rewriting or extensively modifying the entire application. Users can choose to upgrade specific components instead of the entire application, providing greater flexibility and choice.

[0165] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0166] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0167] To this end, the present disclosure provides a computer-readable storage medium storing a computer program that can be loaded by a processor to perform the steps of any of the upgrade methods provided in the present disclosure.

[0168] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0169] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0170] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the upgrade methods provided in this disclosure, the beneficial effects that any of the upgrade methods provided in this disclosure can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0171] The above provides a detailed description of an upgrade method, apparatus, electronic device, and computer-readable storage medium provided in this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An upgrade method, wherein, include: Decouple each target module in at least one application to obtain multiple files corresponding to the target modules; Based on the multiple files corresponding to the target module, generate the initial file corresponding to the target module; The initial file is stored in the upgrade storage area; In response to receiving an upgrade instruction, a target initial file is retrieved from the upgrade storage area. The target initial file is used to upgrade the application to be upgraded.

2. The method according to claim 1, wherein, The step of generating an initial file corresponding to the target module based on multiple files corresponding to the target module includes: Generate an initial file corresponding to the target module based on at least one target file from among multiple files corresponding to the target module; or, The target files of each target module corresponding to each application are compressed and combined to obtain the initial file corresponding to each application.

3. The method according to claim 2, wherein, The target file corresponding to the target module includes at least one of the following: Permissions file; Configuration file; binary file; Shared object files; or Java archive files.

4. The method according to claim 1, wherein, After retrieving the target initial file from the upgrade storage area in response to receiving the upgrade instruction, the method further includes: Upload the target initial file to the cloud server; Send the target trigger command to the cloud server; Receive the component upgrade list returned by the cloud server and display the component upgrade list on the client. The component upgrade list is associated with the initial file. Based on the user's first selection operation in the client, determine the component to be upgraded from the component upgrade list; Based on the components to be upgraded, the application to be upgraded is upgraded.

5. The method according to claim 4, wherein, The first selection operation is the user's operation of selecting the component to be upgraded on the client.

6. The method according to claim 4, wherein, The upgrade of the application to be upgraded based on the component to be upgraded includes: Obtain the upgrade file based on the component to be upgraded; After storing the upgrade file in a temporary directory, restart the system. Copy the upgrade file from the temporary directory to the startup directory of the application to be upgraded; Upgrade the application to be upgraded.

7. The method according to claim 6, wherein, The step of obtaining the upgrade file based on the component to be upgraded includes: Download the corresponding upgrade file based on the identifier of the component to be upgraded.

8. The method according to claim 4, wherein, After sending the target trigger command to the cloud server, the method further includes: Receive the upgrade file corresponding to the component upgrade list.

9. The method according to claim 6, wherein, in, The application to be upgraded is one or more, the upgrade file has a corresponding initial file, and the upgrade of the application to be upgraded includes: Launch the application to be upgraded; If the application to be upgraded starts successfully, delete the upgrade file corresponding to the application to be upgraded in the temporary directory; If the application to be upgraded fails to start, the upgrade file in the startup directory will be replaced with the corresponding initial file.

10. An upgrading device, wherein, include: A decoupling module is used to decouple various target modules in at least one application to obtain multiple files corresponding to the target modules; A generation module is used to generate an initial file corresponding to the target module based on multiple files corresponding to the target module. A storage module is used to store the initial file in the upgrade storage area; The acquisition module is used to acquire a target initial file from the upgrade storage area in response to receiving an upgrade instruction. The target initial file is used to upgrade the application to be upgraded.

11. The apparatus according to claim 10, wherein, The generation module is specifically used for: Generate an initial file corresponding to the target module based on at least one target file from among multiple files corresponding to the target module; or, The target files of each target module corresponding to each application are compressed and combined to obtain the initial file corresponding to each application.

12. The apparatus according to claim 11, wherein, The target file corresponding to the target module in the generation module includes at least one of the following: Permissions file; Configuration file; binary file; Shared object files; or Java archive files.

13. The apparatus according to claim 10, wherein, The acquisition module, specifically configured to, after acquiring the target initial file from the upgrade storage area in response to receiving an upgrade instruction, further include: Upload the target initial file to the cloud server; Send the target trigger command to the cloud server; Receive the component upgrade list returned by the cloud server and display the component upgrade list on the client. The component upgrade list is associated with the initial file. Based on the user's first selection operation in the client, determine the component to be upgraded from the component upgrade list; Based on the components to be upgraded, the application to be upgraded is upgraded.

14. The apparatus according to claim 13, wherein, The first selection operation in the acquisition module is the user's operation of selecting the component to be upgraded on the client.

15. The apparatus according to claim 13, wherein, The acquisition module is specifically used to upgrade the application to be upgraded based on the component to be upgraded, including: Obtain the upgrade file based on the component to be upgraded; After storing the upgrade file in a temporary directory, restart the system. Copy the upgrade file from the temporary directory to the startup directory of the application to be upgraded; Upgrade the application to be upgraded.

16. The apparatus according to claim 15, wherein, The acquisition module is specifically used to acquire upgrade files based on the component to be upgraded, including: Download the corresponding upgrade file based on the identifier of the component to be upgraded.

17. The apparatus according to claim 13, wherein, The acquisition module, specifically after sending the target triggering command to the cloud server, further includes: Receive the upgrade file corresponding to the component upgrade list.

18. The apparatus according to claim 15, wherein, The acquisition module contains one or more upgrade applications, the upgrade file has a corresponding initial file, and the upgrade of the application to be upgraded includes: Launch the application to be upgraded; If the application to be upgraded starts successfully, delete the upgrade file corresponding to the application to be upgraded in the temporary directory; If the application to be upgraded fails to start, the upgrade file in the startup directory will be replaced with the corresponding initial file.

19. An electronic device, wherein, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1-9.

20. A computer-readable storage medium, wherein, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1-9.

Images