An updating method, readable storage medium, program product and electronic device

Abstract

The application relates to the technical field of data processing, and discloses an updating method, a readable storage medium, a program product and an electronic device. In the case that a plurality of versions of a first resource file are stored in the electronic device, after the electronic device updates the version of the first resource file to a new version based on one of the plurality of versions, the electronic device can preload the new version of the first resource file and delete all versions of the first resource file except the preset version of the operating system of the electronic device. In this way, the non-preset version of the first resource file which is not effective can be prevented from occupying the storage space of the electronic device.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to an updating method, a readable storage medium, a program product and an electronic device. BACKGROUND

[0002] A terminal device can update an application program in the terminal device and a resource file (such as an artificial intelligence model, a virus library, etc.) relied on by the application program or an operating system through over-the-air technology (OTA).

[0003] In some scenarios, after the terminal device updates the resource file from one version to another version, the terminal device can store multiple versions of the resource file. As a result, the multiple versions of the resource file can occupy too much storage space. SUMMARY

[0004] Embodiments of the present application provide an updating method, a readable storage medium, a program product and an electronic device.

[0005] In a first aspect, an updating method is provided, which is applied to an electronic device and includes: detecting that an updating condition is met, obtaining a first updating file of a first resource file, wherein the first updating file is an updating file of an mth version of the first resource file relative to an nth version of the first resource file, m and n are positive integers, and m is greater than n; generating and storing the mth version of the first resource file based on the updating file; and determining that the electronic device stores a kth version of the first resource file, and the kth version is not a preset version of an operating system of the electronic device, and deleting the kth version, wherein k is a positive integer less than m.

[0006] In the method, the nth version and the kth version of the first resource file are already stored in the electronic device, and after the first resource file is updated from the nth version to the mth version, the electronic device can delete the kth version. Based on this, the kth version of the first resource file can be prevented from occupying the storage space of the electronic device in the case that the electronic device already stores multiple versions of the first resource file.

[0007] Optionally, the updating condition can include any one of the following conditions: a preset updating period is reached, an operation of updating the resource file by a user is detected, an updating instruction sent by another electronic device (such as an OTA server) is received, or an updating instruction sent by a business module relying on the first resource file is detected.

[0008] It should be noted that in the versions of the first resource file, an ith version is newer than an (i+1)th version (i is a positive integer).

[0009] In a possible implementation of the first aspect, the method further includes: deleting the mth version of the first resource file in a case where the mth version of the first resource file is not a preset version of an operating system of the electronic device.

[0010] In a possible implementation of the first aspect, the nth version of the first resource file is a preset version of an operating system of the electronic device.

[0011] In a possible implementation of the first aspect, the generating and storing, by the electronic device, the mth version of the first resource file based on the first update file includes: in a case where the first update file includes all data of the mth version of the first resource file, storing the mth version of the first resource file in the first update file in the first directory; in a case where the first update file includes incremental data of the mth version of the first resource file relative to the nth version of the first resource file, merging the first update file and the nth version of the first resource file to obtain the mth version of the first resource file, and storing the mth version of the first resource file in the first directory.

[0012] In some embodiments, the first directory can be a directory under a "res" directory in a data partition of the electronic device.

[0013] In a possible implementation of the first aspect, the first resource file is of a first type, the first directory is configured to store non-preset versions of resource files of the first type, and the first resource file is a resource file relied on by a first service module; and the deleting, by the electronic device, the kth version of the first resource file in a case where the electronic device stores the kth version of the first resource file and the kth version is not a preset version of an operating system of the electronic device includes: after storing the mth version of the first resource file in the first directory, invoking the first service module to preload the mth version of the first resource file, and preloading the first service module to switch a currently effective version of the first resource file in the first service module to the mth version; and after the first service module preloads the mth version of the first resource file, deleting the kth version of the first resource file in the first directory.

[0014] In the method, the electronic device can invoke the first service module to preload the mth version of the first resource file, and then delete the kth version of the first resource file. In this way, the electronic device can avoid the situation that the kth version of the first resource file cannot be deleted because the kth version of the first resource file is invoked by the first service module.

[0015] In a possible implementation of the first aspect, the electronic device includes at least one second service module dependent on the first type of resource file, and the at least one second service module includes the first service module; and after the first service module preloads the mth version of the first resource file, deleting the kth version in the first directory includes: obtaining a currently effective version of the first type of resource file dependent on the second service module and a version of the first type of resource file in an installation process dependent on the second service module; and deleting, from the first directory, other versions of the first type of resource file except the currently effective version of the first type of resource file dependent on the second service module and the version of the first type of resource file in the installation process dependent on the second service module.

[0016] In the method, the electronic device deletes the kth version of the first resource file in the following manner: deleting, from the first directory, other versions of the first type of resource file except a currently effective version (that is, a currently effective version) of the first type of resource file dependent on all second service modules and a version of the first type of resource file in an updating process (or an installation process). In this way, even if the mth version of the first resource file is not the same branch of resource files as the kth version of the first resource file, the kth version of the first resource file can be deleted.

[0017] In some cases, the second service module can also include only the first service module.

[0018] In a possible implementation of the first aspect, the first type includes any one of the following types: a large language model, an image semantic understanding large model, an image generation model, a video generation model, a speech recognition model, a speech synthesis model, a personalized audio model, a semantic model, a virus library, an application white list, an application black list, information about a holiday, and a parameter of the electronic device in an old age mode.

[0019] In a second aspect, an electronic device is provided, including: one or more processors; one or more memories; and the one or more memories storing one or more computer programs including instructions that, when executed by the one or more processors, cause the electronic device to perform the method according to any implementation manner of the first aspect to the third aspect.

[0020] In a third aspect, a computer-readable storage medium is provided, and the computer-readable storage medium stores computer-executable program instructions that, when executed on a computer, cause the computer to perform the method according to any implementation manner of the first aspect to the second aspect.

[0021] In a fourth aspect, a computer program product is provided, which comprises computer program code which, when run on a computer, causes the computer to perform the method according to any implementation form of the first aspect to the second aspect.

[0022] It should be understood that the advantages of the above-mentioned second aspect to the fourth aspect can be referred to the description of the first aspect and the second aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0023] FIG. 1A According to some embodiments of the present application, a process schematic diagram of a terminal device updating LLM 01 is shown.

[0024] FIG. 1B According to some embodiments of the present application, another process schematic diagram of a terminal device updating LLM 01 is shown.

[0025] FIG. 2A According to some embodiments of the present application, a flow schematic diagram of a terminal device updating a resource file is shown.

[0026] FIG. 2B According to some embodiments of the present application, a schematic diagram of a terminal device deleting a resource file after updating the resource file is shown.

[0027] FIG. 3 According to some embodiments of the present application, an interaction flow schematic diagram of another updating method is shown.

[0028] FIG. 4 According to some embodiments of the present application, a flow schematic diagram of an updating method is shown.

[0029] FIG. 5A According to some embodiments of the present application, a process schematic diagram of an updating method is shown.

[0030] FIG. 5B According to some embodiments of the present application, a process schematic diagram of another updating method is shown.

[0031] FIG. 6 According to some embodiments of the present application, an interaction flow schematic diagram of another updating method is shown.

[0032] FIG. 7 According to some embodiments of the present application, a flow schematic diagram of another updating method is shown.

[0033] FIG. 8 According to some embodiments of the present application, a structure schematic diagram of a terminal device 10 is shown. DETAILED DESCRIPTION

[0034] The embodiments of the present application include but are not limited to an updating method, a readable storage medium, a program product and a terminal device.

[0035] For ease of understanding, first, the terms involved in the present application are introduced.

[0036] (1) Resource file

[0037] The resource file can be a file relied on by the operating system or application program of the terminal device to realize the related function.

[0038] Illustratively, the terminal device can realize the related function through an artificial intelligence model, and therefore the resource file can include an artificial intelligence model. For example, the terminal device can process an image in the terminal device or an image collected / acquired by the terminal device, or process other forms of data (such as audio, text, etc.) through a large language model (LLM), an image semantic understanding large model, an image generation model, a video generation model, a speech recognition model, a speech synthesis model, a personalized audio model, a semantic model, etc.

[0039] Illustratively, the terminal device security-related application or service can manage the security of the files in the terminal device based on a virus library, and therefore the resource file can include a virus library.

[0040] Illustratively, the communication management application or service in the terminal device can rely on a communication blacklist to manage and control incoming calls, messages, etc. to avoid users being harassed by numbers in the communication blacklist, etc. Therefore, the resource file can include a communication blacklist.

[0041] Illustratively, the terminal device can manage the permissions of the application programs in the terminal device (such as limiting the management of some applications that excessively seek permissions in the terminal device, etc.), resource scheduling (such as improving the priority of the application programs in the application whitelist, improving the hardware resource configuration of the applications in the application whitelist, performance improvement (such as accelerating the application programs in the application whitelist, etc.); reducing the priority of the application programs in the application blacklist, reducing the hardware resource configuration of the applications in the application blacklist, etc.) based on an application whitelist or an application blacklist, and therefore the resource file can include an application whitelist, an application blacklist, etc.

[0042] Illustratively, the terminal device can display information of holidays in different regions. Based on this, the resource file can also include information of holidays in different regions (such as the dates of holidays, introductions of holidays (such as introduction texts, introduction pictures, etc.), etc.).

[0043] Exemplarily, the terminal device can configure the terminal device or an application of the terminal device with different parameters for different user groups. For example, the terminal device can be configured with an old mode suitable for an old user group, and the resource file can include parameters (such as a font file, a font size, a font color, and the like) of the terminal device in the old mode.

[0044] It should be noted that the resource file can also be other resource files, which are not limited herein.

[0045] (2) Pre-installed version

[0046] The pre-installed version is a version of a resource file carried by an operating system of the terminal device. An application in the operating system of the terminal device does not have the permission to delete the pre-installed version of the resource file. When the version of the operating system is updated, the operating system can replace the pre-installed version of the resource file in the old version of the operating system with the pre-installed version of the resource file in the new version of the operating system. In the case that the electronic device updates the resource file but not the operating system, the pre-installed version of the resource file cannot be deleted.

[0047] The technical solutions of the present application will be described below with reference to the accompanying drawings.

[0048] It should be noted that the updating method provided in the embodiments of the present application can be applied to any terminal device that can be updated through OTA. For example, the terminal device can also be referred to as a terminal, a user equipment (UE), a mobile station (MS), a mobile terminal (MT), and the like. The terminal device can be a mobile phone, a smart television, a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in self driving, a wireless terminal in remote medical surgery, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, and the like. The embodiments of the present application do not limit the specific form of the terminal device.

[0049] As described in the background, in some scenarios, the terminal device may store multiple versions of a resource file after updating the resource file from one version to another version. Thus, the multiple versions of the resource file may occupy too much storage space.

[0050] To reduce the storage space occupied by the resource file, in some embodiments, after updating the A version of the resource file to the B version, the terminal device can delete the A version of the resource file if the A version of the resource file is not a preset version. Thus, the A version of the resource file can be avoided from occupying the storage space of the terminal device.

[0051] However, in some embodiments, if the terminal device still stores the C version of the resource file before updating the resource file from the A version to the B version, only deleting the A version of the resource file can cause the C version of the resource file to occupy the storage space of the terminal device.

[0052] For example, in the case where the terminal device stores a preset version and a non-preset version of a resource file (the version of the non-preset version of the resource file is newer than the version of the preset version of the resource file). If the user clears the cache of the service module corresponding to the resource file before updating the resource file, the terminal device will update based on the preset version of the resource file. Thus, after the update is completed, the terminal device will not delete the preset version of the resource file nor the non-preset version of the resource file, causing the non-preset version of the resource file to occupy the storage space of the terminal device.

[0053] Exemplarily, FIG. 1A A process diagram of updating the LLM 01 by the terminal device is shown.

[0054] Reference FIG. 1A :

[0055] Before the terminal device performs the first update at date D1, the version of the LLM 01 in the terminal device is 1.0.1. The first update can be to update the version of the LLM 01 from the 1.0.1 version (as the A version) to the 1.0.2 version (as the B version), where the 1.0.1 version is a preset version. During the process of updating the LLM 01 from the 1.0.1 version to the 1.0.2 version by the terminal device based on the process shown in FIG. 2, since the 1.0.1 version of the LLM 01 is a preset version, the terminal device will not delete the 1.0.1 version of the LLM 01, so that the terminal device can store the 1.0.1 version and the 1.0.2 version of the LLM 01.

[0056] Before the terminal device performs the second update at date D2, the current version of LLM 01 in the terminal device is 1.0.2, and the second update can be updating the version of LLM 01 to 1.0.3 version (as B version). During the process of updating LLM 01 to 1.0.3 version, the cached data of service module B1 is cleared, and service module B1 is updated based on the preset version (1.0.1 version, as A version) of LLM 01 (i.e., taking 1.0.1 version as old version). Since 1.0.1 version of LLM 01 is the preset version, the terminal device will not delete 1.0.1 version of LLM 01, and the terminal device will not delete 1.0.2 version (as C version) of LLM 01. In this way, the terminal device stores 1.0.1 version, 1.0.2 version and 1.0.3 version of LLM 01.

[0057] Before the terminal device performs the third update at date D3, the current version of LLM 01 in the terminal device is 1.0.3. The third update can be updating the version of LLM 01 from 1.0.3 version (as A version) to 1.0.4 version (B version). During the process of updating LLM 01 from 1.0.3 version to 1.0.4 version, since 1.0.3 version of LLM 01 is not the preset version, the terminal device will delete 1.0.3 version of LLM 01, and the terminal device will not delete 1.0.2 version (as C version) of LLM 01. In this way, the terminal device stores 1.0.1 version, 1.0.2 version (as C version) and 1.0.4 version of LLM 01.

[0058] In the above process, after the second update, 1.0.2 version (as C version) of LLM 01 is stored in the terminal device as invalid data (service module B1 will not call 1.0.2 version of LLM 01), which occupies the storage space of the terminal device.

[0059] For another example, in some embodiments, when the operating system of the terminal device is updated, the preset version of the resource file carried by the new version of the operating system will replace the preset version of the resource file already stored in the terminal device, and the non-preset version of the resource file will not be deleted. After the operating system is updated, if the resource file is updated through OTA, the version of the currently effective resource file of the terminal device is the preset version of the new version of the operating system, and the terminal device will not delete the non-preset version of the resource file, which causes excessive occupation of the storage space of the terminal device.

[0060] For example, FIG. 1B Another process diagram of updating LLM 01 by a terminal device is shown.

[0061] Before the terminal device performs the first update at date D1, the current version of LLM 01 in the terminal device is 1.0.1. The first update can be to update the version of LLM 01 from 1.0.1 (as version A) to 1.0.2 (as version B), where the 1.0.1 version of LLM 01 is a preset version. During the process of updating LLM 01 from 1.0.1 to 1.0.2, since the 1.0.1 version is a preset version, the terminal device does not delete the 1.0.1 version of LLM 01, so that the terminal device can store both the 1.0.1 and 1.0.2 versions of LLM 01.

[0062] At date D4, the terminal device performs the fourth update, which is to update the operating system, and the version of LLM 01 carried in the new version of the operating system is 1.0.5 (as a preset version). During the process of updating the operating system, the terminal device replaces the preset version of LLM 01 from 1.0.1 to 1.0.5, and does not delete the 1.0.2 version of LLM 01, so that the terminal device can store both the 1.0.5 and 1.0.2 versions of LLM 01.

[0063] Before the terminal device performs the fifth update at date D5, the current version of LLM 01 in the terminal device is 1.0.5. The fifth update can be to update the version of LLM 01 from 1.0.5 (as version A) to 1.0.6 (as version B). During the process of updating LLM 01 from 1.0.5 to 1.0.6, since the 1.0.5 version of LLM 01 is a preset version, the terminal device does not delete the 1.0.5 version of LLM 01, and the terminal device also does not delete the 1.0.2 version (as version C) of LLM 01. In this way, the terminal device stores the 1.0.2, 1.0.5, and 1.0.6 versions of LLM 01.

[0064] Before the terminal device performs the sixth update at date D6, the current version of LLM 01 in the terminal device is 1.0.6. The sixth update can be to update the version of LLM 01 from 1.0.6 (as version A) to 1.0.7 (as version B). During the process of updating LLM 01 from 1.0.6 to 1.0.7, since the 1.0.6 version of LLM 01 is not a preset version, the terminal device can delete the 1.0.6 version of LLM 01, and the terminal device does not delete the 1.0.2 version (as version C) of LLM 01. In this way, the terminal device stores the 1.0.2, 1.0.5, and 1.0.7 versions of LLM 01.

[0065] From the above process, it can be known that after the fifth update, in addition to the preset version of the resource file (version 1.0.5 of LLM) and the currently effective version in the terminal device, there is also an invalid resource file (version 1.0.2 of LLM 01), which occupies the storage space of the terminal device.

[0066] For ease of understanding, a process of updating a resource file by a terminal device is introduced below.

[0067] Exemplarily, FIG. 2A According to some embodiments of the present application, a flowchart of a terminal device updating a resource file is shown.

[0068] As FIG. 2A shown, a developer can transmit a developed new version of a resource file to an OTA server through a version release new platform. A service module (for example, an application, a service or other module that depends on or calls a resource file) in a terminal device can provide a version information of an old version of a resource file that the service module depends on to a resource update software development kit (SDK) in a manner of registering an update to the resource update SDK. A software update application can obtain the version information of the old version of the resource file from the resource update SDK when an update condition is met, search and download a new version update resource (for example, incremental update data of a new version of a resource file (for example, a version B of a resource file) relative to an old version of a resource file, or all data of the new version of the resource file) of the corresponding old version of the resource file from the OTA server, and install the downloaded update resource. Secondly, the software update application can install the new version update resource to obtain the new version of the resource file. Finally, referring to FIG. 2B , the software update application can trigger the service module to load the new version of the resource file, and delete the old version of the resource file in a case that the old version of the resource file is not a preset version after loading the new version of the resource file.

[0069] It should be noted that the service module can be any application, service or other module in the terminal device that needs to depend on or call a resource file. Exemplarily, the service module can include but is not limited to YOYO suggestion, intelligent voice, intelligent vision, intelligent input method, system manager, mobile phone manager and the like.

[0070] It should be noted that the service module can select a version (a preset version or a non-preset version) of a resource file that it depends on from a plurality of versions of the resource file stored.

[0071] It should be noted that the resource update SDK can be an SDK provided by a developer of the software update application or a developer of the terminal device to a developer of the business module, and the SDK can be used for interaction between the business module and the software update application. The resource update SDK can be embedded in the business module or can be a functional module or service independent of the business module. For example, the resource update SDK can obtain resource parameters of the business module (such as types, branches, versions of resource files relied on, identifiers of the business module, etc.), send resource parameters of the business module to the software update application in response to a call of the software update application, etc.

[0072] It should be noted that the software update application can be an application program or service in the operating system of the terminal device for updating resource files or the operating system. The software update application can obtain resource parameters of the business module from the business module, obtain new versions of resource files from the OTA server, download / decompress / authenticate / difference merge / store resource files, delete resource files, etc.

[0073] In some embodiments, the business module and the software update application can be located in an application layer of the operating system of the terminal device.

[0074] Exemplarily, a process of a resource update method is introduced below taking an example of a case where the business module B1 updates a resource file from a resource file type1_branch1_V1 (a resource file of type type1, branch branch1, and version V1) to a resource file type1_branch1_V2 (a resource file of type type1, branch branch1, and version V2), and the business module B2 updates a resource file from a resource file type1_branch2_V3 (a resource file of type type1, branch branch2, and version V3) to a resource file type1_branch2_V4 (a resource file of type type1, branch branch2, and version V4).

[0075] It should be noted that the type is used to indicate the kind of the resource file, such as LLM, image semantic understanding large model, image generation model, video generation model, speech recognition model, speech synthesis model, personalized audio model, semantic model, virus library, application whitelist, application blacklist, information of holidays, parameters of the terminal device in an old age mode, etc., and one type of resource file can have multiple types. The branch is used to indicate resource files with different functions or called by different business modules in one type of resource file, for example, for LLM type resource files, LLM for image processing (as a branch of LLM), LLM for audio processing (as a branch of LLM), etc. In addition, based on the type, branch, and version, a resource file can be uniquely determined.

[0076] Specifically, FIG. 3 According to some embodiments of the present application, a flowchart of an updating method is shown. As shown in FIG. 2, the method comprises the following steps:

[0077] S301, the business module B1 sets resource parameters to the resource updating SDK.

[0078] In some embodiments, the business module B1 can set resource parameters to the resource updating SDK when starting or installing, and the resource parameters can comprise the type, branch, version, storage path of the resource file relied on by the business module B1, the identification of the business module B1, the version of the business module B1, and the like.

[0079] It should be noted that the business module B1 or the business module B2 hereinafter can be any application program, service or module that relies on or calls resource files.

[0080] S302, the business module B2 sets resource parameters to the resource updating SDK.

[0081] In some embodiments, the business module B2 can set resource parameters to the resource updating SDK when starting or installing, and the resource parameters can comprise the type, branch, version, storage path of the resource file relied on by the business module B2, the identification of the business module B2, the version of the business module B2, and the like.

[0082] S303, the software updating application detects that the updating condition is met, and calls the provider interface of the business module B1 to obtain the resource parameters of the business module B1.

[0083] The software updating application can call the provider interface of the business module B1 to obtain the resource parameters of the business module B1 when detecting that the updating condition (for example, reaching the preset updating period, or detecting the updating operation of the user, or receiving the updating instruction sent by the OTA server) is met.

[0084] It should be noted that the provider interface can be an interface provided by the business module (or the resource updating SDK) and capable of interacting with the business module (or the resource updating SDK), and other applications or modules can obtain the resource parameters of the business module through the provider interface. In some embodiments, the provider interface can also be other interfaces with the same or similar functions.

[0085] S304, the business module B1 sends the resource parameters of the resource file type1_branch1_V1 to the software updating application in response to the calling of the software updating application.

[0086] The business module B1 can send the resource parameters, such as the resource parameter type1_branch1_V1 of the resource file type1_branch1_V1, to the software update application in response to the call of the provider interface by the software update application.

[0087] S305, the software update application detects that the update condition is met, and calls the provider interface of the business module B2 to obtain the resource parameters of the business module B2.

[0088] The software update application can call the provider interface of the business module B2 to obtain the resource parameters of the business module B2 when detecting that the update condition is met.

[0089] It should be noted that the step S305 can be executed in parallel with the step S303, or can be executed before or between the step S304 and the step S305.

[0090] S306, the business module B2 sends the resource parameter of the resource file type1_branch2_V3 to the software update application in response to the call of the software update application.

[0091] The business module B2 can send the resource parameters, such as the resource parameter type1_branch2_V3 of the resource file type1_branch2_V3, to the software update application in response to the call of the provider interface by the software update application.

[0092] S307, the software update application sends an update request to the OTA server.

[0093] The software update application can send an update request to the OTA server after receiving the resource parameters provided by the business modules, and the update request can include the resource parameters of the business modules.

[0094] S308, the OTA server sends version information of a new version resource file to the software update application.

[0095] The OTA server can send the version information of the new version resource file to the software update application when there is a resource file of a newer version than the version of the resource file indicated in the update request.

[0096] For example, the OTA server can send the software update application version information (V2) of the resource file type1_branch1_V2 corresponding to the update version of the resource file type1_branch1_V1 of the service module B1, and version information (V4) of the resource file type1_branch2_V4 corresponding to the update version of the resource file type1_branch2_V3 of the service module B2.

[0097] S309, the software update application downloads the new version update resource from the OTA server.

[0098] After receiving the version information of the new version resource file, the software update application can download the new version update resource from the OTA server. For example, the software update application can download the update resource corresponding to the resource file type1_branch1_V2 and the update resource corresponding to the resource file type1_branch2_V4 from the OTA server.

[0099] It should be noted that the new version capital update resource can be a full file of the new version resource file, or an incremental file of the new version resource file relative to the old version resource file obtained by the software update application from the service module.

[0100] S310, the software update application authenticates, decompresses, and differentially merges the resource file type1_branch1_V2, and grants the service module B1 access to the resource file type1_branch1_V2.

[0101] After downloading the update resource corresponding to the resource file type1_branch1_V2, the software update application can authenticate, decompress (or can also include differential merging (combining the update resource of the resource file type1_branch1_V2 with the resource file type1_branch1_V1)) the update resource corresponding to the resource file type1_branch1_V2, obtain and store the resource file type1_branch1_V2, and grant the service module B1 access to the resource file type1_branch1_V2.

[0102] It should be noted that differential merging refers to a case where only part of the data of the new version resource file is included in the update resource, and another part of the data in the new version resource file is the same as in the old version resource file. In this case, the old version resource file or the other part of the data is combined with the part of the data to obtain the new version resource file.

[0103] S311, the software update application authenticates, decompresses, and differentially combines the resource file type1_branch2_V4, and grants the service module B2 access to the resource file type1_branch2_V4.

[0104] After downloading the update resource corresponding to the resource file type1_branch2_V4, the software update application can authenticate and decompress (or can also include differential combination (combining the update resource of the resource file type1_branch2_V4 with the resource file type1_branch2_V3)) the update resource corresponding to the resource file type1_branch2_V4, obtain and store the resource file type1_branch2_V4, and grant the service module B2 access to the resource file type1_branch2_V4.

[0105] It should be noted that the execution order of step S311 and steps S310, S312 to S317 can be changed or executed in parallel, and is not limited herein.

[0106] S312, the software update application sends a preloading broadcast to the service module B1.

[0107] After granting the service module B1 access to the resource file type1_branch1_V2, the software update application can send a preloading broadcast to the service module B1 to enable the service module B1 to load the resource file type1_branch1_V2. In some embodiments, the preloading broadcast can include resource parameters (type, branch, version, etc.) of the resource file that the service module B1 needs to pre-load.

[0108] S313, the service module B1 preloads the resource file type1_branch1_V2.

[0109] The service module B1 can pre-load the resource file type1_branch1_V2 in response to the pre-loading broadcast of the software update application.

[0110] S314, the service module B1 updates the resource parameter of the resource file type1_branch1_V2 to the resource update SDK.

[0111] After preloading the resource file type1_branch1_V2, the service module B1 can update the resource parameter of the resource file type1_branch1_V2 to the resource update SDK, so that the resource update SDK can provide the resource parameter type1_branch1_V2 to other modules when the provider interface is called.

[0112] S315, the software update application invokes the provider interface to obtain the resource parameter of the service module B1.

[0113] S316, the service module B1 sends the resource parameter of the resource file type1_branch1_V2 to the software update application.

[0114] The service module B1 sends the resource parameter type1_branch1_V2 of the resource file type1_branch1_V2 to the software update application in response to the invocation of the provider interface by the software update application.

[0115] S317, the software update application deletes the resource file type1_branch1_V1 based on the resource parameter of the resource file type1_branch1_V2.

[0116] The software update application can determine that the resource file type1_branch1_V2 has been updated completely after receiving the resource parameter type1_branch1_V2, and delete the resource file (resource file type1_branch1_V1) corresponding to the resource parameter received in the foregoing step S304.

[0117] It should be noted that if the resource file corresponding to the resource parameter received in the foregoing step S304 is a preset version of the resource file, no deletion is performed.

[0118] S318, the software update application sends a preloading broadcast to the service module B2.

[0119] The software update application can send a preloading broadcast to the service module B2 after granting the service module B2 the access right to the resource file type1_branch2_V4, so as to enable the service module B2 to load the resource file type1_branch2_V4.

[0120] S319, the service module B2 preloads the resource file type1_branch2_V4.

[0121] The service module B2 can preload the resource file type1_branch2_V4 in response to the preloading broadcast of the software update application.

[0122] S320, the service module B2 updates the resource parameter of the resource file type1_branch2_V4 to the resource update SDK.

[0123] After preloading the resource file type1_branch2_V4, the business module B2 can update the resource parameter of the resource file type1_branch2_V4 to the resource update SDK, so that the resource update SDK can provide the resource parameter type1_branch2_V4 to other modules when the provider interface is called.

[0124] S321, the software update application calls the provider interface of the business module B2 to obtain the resource parameter of the business module B2.

[0125] S322, the business module B2 sends the resource parameter of the resource file type1_branch2_V4 to the software update application.

[0126] The business module B2 sends the resource parameter type1_branch2_V4 of the resource file type1_branch2_V4 to the software update application in response to the call of the provider interface by the software update application.

[0127] S323, the software update application deletes the resource file type2_branch1_V3 based on the resource parameter of the resource file type2_branch2_V4.

[0128] After receiving the resource parameter type1_branch2_V4, the software update application can determine that the resource file type1_branch2_V4 has been updated, and delete the resource file (the resource file type1_branch2_V3) corresponding to the resource parameter received in the foregoing step S306.

[0129] It should be noted that steps S318 to S323 can be executed in parallel with steps S312 to S317, which is not limited herein.

[0130] Based on the above process, taking updating the resource file of the business module B1 as an example, after updating the version of the resource file, the terminal device will only delete the version of the resource file corresponding to the resource parameter transmitted by the business module B1 to the software update application in step S304. If there are multiple versions of the resource file of the business module B1 stored in the terminal device before updating (for example, in addition to the resource file type1_branch1_V1, the resource file type1_branch1_V0 is also stored), it may cause the software update application to save the resource file type1_branch1_V0 after deleting the resource file type1_branch1_V1, resulting in additional occupation of the storage space of the terminal device.

[0131] For example, for the foregoing FIG. 1AIn the shown case, in the process of the second update, the resource file type1_branch1_V1 can be version 1.0.1 of LLM 01, the resource file type1_branch1_V2 can be version 1.0.3 of LLM 01, and the resource file type1_branch1_V0 can be version 1.0.2 of LLM 01. In the process of the third update, the resource file type1_branch1_V1 can be version 1.0.3 of LLM 01, the resource file type1_branch1_V2 can be version 1.0.4 of LLM 01, and the resource file type1_branch1_V0 can be version 1.0.2 of LLM 01. After the update, the terminal device does not delete the resource file type1_branch1_V0 (version 1.0.2 of LLM 01), which causes excessive occupation of the storage space of the terminal device.

[0132] For example, for the foregoing FIG. 1B In the shown case, in the process of the fifth update, the resource file type1_branch1_V1 can be version 1.0.5 of LLM 01, the resource file type1_branch1_V2 can be version 1.0.6 of LLM 01, and the resource file type1_branch1_V0 can be version 1.0.2 of LLM 01. In the process of the sixth update, the resource file type1_branch1_V1 can be version 1.0.6 of LLM 01, the resource file type1_branch1_V2 can be version 1.0.7 of LLM 01, and the resource file type1_branch1_V0 can be version 1.0.2 of LLM 01. After the update, the terminal device does not delete the resource file type1_branch1_V0 (version 1.0.2 of LLM 01), which causes excessive occupation of the storage space of the terminal device.

[0133] Therefore, the embodiment of the present application provides an updating method. In the case that a first resource file is updated from an old version to a new version, the terminal device can delete other versions except the preset version and the new version of the first resource file. In this way, the non-pre-set version of the first resource file that is not effective can be avoided to be stored, and the storage space occupied by the first resource file can be reduced.

[0134] Exemplarily, before the updating, the first terminal device stores the first version and the second version of the first resource file, and the first version is the preset version. In the case that the currently effective version of the first resource file is the first version (as an old version), the first terminal device can delete the second version of the first resource file after updating the first resource file from the first version to the third version (as a new version). In the case that the currently effective version of the first resource file is the second version (as an old version), the first terminal device can delete the second version of the first resource file after updating the first resource file from the second version to the third version (as a new version).

[0135] For example, for the case shown in FIG. 1A After the second updating is completed (or in the process of the second updating), the terminal device can delete the versions of the LLM 01 other than the 1.0.1 version (as a preset version) and the 1.0.3 version (as a new version), that is, delete the 1.0.2 version of the LLM 01. In this way, the terminal device only needs to store the 1.0.1 version and the 1.0.3 version of the LLM 01 without storing the 1.0.2 version of the LLM 01, which is conducive to reducing the storage space occupied by the LLM 01.

[0136] For example, for the case shown in FIG. 1B After the fifth updating is completed (or in the process of the fifth updating), the terminal device can delete the versions of the LLM 01 other than the 1.0.5 version (as a preset version) and the 1.0.6 version (as a new version), that is, delete the 1.0.2 version of the LLM 01. In this way, the terminal device only needs to store the 1.0.5 version and the 1.0.6 version of the LLM 01 without storing the 1.0.2 version of the LLM 01, which is conducive to reducing the storage space occupied by the LLM 01.

[0137] It should be noted that the first resource file can be any type of resource file, such as an LLM, an image semantic understanding large model, an image generation model, a video generation model, a speech recognition model, a speech synthesis model, a personalized audio model, a semantic model, a virus library, an application whitelist, an application blacklist, information of holidays, parameters of a terminal device in an old age mode, etc.

[0138] Next, the technical solutions of the present application will be described in detail in combination with FIG. 4 to FIG. 8 The technical solutions of the present application will be described in detail in combination with

[0139] Exemplarily, FIG. 4 According to some embodiments of the present application, a flowchart of an updating method is shown. The execution subject of the flowchart is a terminal device, as shown in FIG. 4 The method comprises the following steps:

[0140] S401, detecting that an update condition is met, obtaining an update resource of a third version of the first resource file relative to an old version from an OTA server.

[0141] The terminal device can obtain the update resource of the third version of the first resource file relative to the old version from the OTA server when detecting that the update condition is met. The update resource of the old version can be a currently effective version of the first resource file in the terminal device, or a preset version of the first resource file.

[0142] In some embodiments, the third version can be the latest version of the first resource file in the OTA server suitable for the terminal device.

[0143] For example, the terminal device can send version information of the old version to the OTA server, so that the OTA server determines a difference file (as an update resource) of the third version (new version) of the first resource file relative to the old version of the first resource file. Then, the OTA server can send the update resource to the terminal device. In this case, the terminal device only needs to download the incremental file of the third version of the first resource file relative to the old version, which can reduce the amount of data downloaded.

[0144] For example, the terminal device can also send version information of the old version to the OTA server, so that the OTA server determines the third version (new version) of the first resource file and sends version information of the third version to the terminal device. Then, the terminal device can download the third version of the first resource file (as an update resource) from the OTA server.

[0145] In some embodiments, the update condition can include: reaching a preset update period, detecting a user operation of updating a resource file, detecting an instruction of a service module to update a resource file, and receiving update information sent by the OTA server.

[0146] S402, storing the third version of the first resource file based on the obtained update resource.

[0147] After obtaining the update resource, the terminal device can store the third version of the first resource file in a storage path of the first resource file.

[0148] For example, when the update resource is all data of the third version of the first resource file, the terminal device can directly store the third version of the first resource file in the storage path of the first resource file.

[0149] For example, in a case that the update resource is incremental data of the third version of the first resource file relative to the old version, the terminal device can merge the update resource with the old version of the first resource file to obtain the third version of the first resource file, and store the obtained third version of the first resource file in the storage path of the first resource file.

[0150] It should be noted that in some other embodiments, the terminal device can further perform decompression, authentication, etc. on the update resource before storing the third version of the first resource file.

[0151] For example, in some embodiments, the storage path of the terminal device for storing the resource file can be “data / res” (res folder in the data partition), which can include multiple folders, each of which is used to store a type of resource file. For example, the “LLM” folder under the storage path “data / res” can be used to store resource files of the type LLM, the “viruslib” folder under the storage path “data / res” can be used to store resource files of the type virus library, the “whitelist_app” folder under the storage path “ / data / res” can be used to store resource files of the type application whitelist, the “blacklist_app” folder under the storage path “ / data / res” can be used to store resource files of the type application blacklist, and so on.

[0152] It should be noted that the above storage path is only an example, and in some other embodiments, the storage path of the resource file can be any other path, which is not limited herein.

[0153] S403, deleting other versions of the first resource file except the third version and the preset version.

[0154] For example, after the terminal device stores the third version of the first resource file in the storage path of the first resource file, the terminal device can delete other versions of the first resource file except the third version and the preset version.

[0155] For example, after the terminal device stores the third version of the first resource file in the storage path of the first resource file, the terminal device can call a service module (hereinafter referred to as an associated service module of the first resource file) dependent on the first resource file to preload the third version of the first resource file, so as to avoid that the first resource file whose version is being called by the associated service module of the first resource file cannot be deleted. Then, after the associated service module of the first resource file preloads the third version of the first resource file, the terminal device can delete other versions of the first resource file except the third version and the preset version.

[0156] In some embodiments, the first resource file can be a resource file relied on by the first service module, and the first resource file can be a first type of resource file. The terminal device can first invoke the first service module to preload the third version of the first resource file, and obtain the current effective version of the first type of resource file relied on by the associated service module of the first type of resource file (the service module whose relied-on resource file includes the first type of resource file), and the version of the first type of resource file being installed by the terminal device. Then, the terminal device can delete the first type of resource file other than the current effective version of the first type of resource file relied on by the associated service module of the first type of resource file and the version of the first type of resource file being installed by the terminal device in the directory storing the first type of resource file. For details, reference can be made to the embodiments in the following FIG. 5A to FIG. 7 Without repetition here. Based on the method, the terminal device can be prevented from storing the old version of the first resource file in the case that the third version and the old version of the first resource file belong to different branches of the first type.

[0157] Based on the above method, the terminal device can be prevented from storing other versions of the first resource file except the third version and the preset version after updating the version of the first resource file to the third version, which is beneficial to saving the storage space of the terminal device.

[0158] Hereinafter, taking the first resource file including type1_branch1 (the associated service module is service module B1) and type1_branch2 (the associated service module is service module B2), the versions of the first resource file stored in the terminal device including v1 version of type1_branch1 (type1_branch1_v1, preset version), v2 version of type1_branch1 (type1_branch1_v2, current effective version), v3 version of type1_branch2 (type1_branch2_v3, preset version), and v4 version of type1_branch2 (type1_branch2_v4, current effective version), and the new version of the first resource file being v5 version of type1_branch1 (type1_branch1_v5) and v6 version of type1_branch2 (type1_branch1_v6) as an example, the technical scheme of the present application is introduced.

[0159] Exemplarily, FIG. 5A According to some embodiments of the present application, a process schematic diagram of an updating method is shown.

[0160] As FIG. 5AAs shown, before the update, the path "data / res / type1" for storing the resource files of type1 type stores the v2 version of the resource file type1_branch1 and the v4 version of the resource file type1_branch2, and the v2 version of type1_branch1 is the currently effective version of the service module B1, and the v4 version of type1_branch2 is the currently effective version of the service module B2. In addition, the path in the terminal device for storing the preset version of the resource file also stores the v1 version of the resource file type1_branch1 and the v3 version of the resource file type1_branch2.

[0161] When the update condition is met, the terminal device can download the new version of the resource file as the v5 version of type1_branch1 and the v6 version of type1_branch2 from the OTA server. Then, the terminal device can perform authentication, decompression, differential merging, authorization and the like on the v5 version of the resource file type1_branch1 and the v6 version of the resource file type1_branch2 in parallel, so as to store the v5 version of the resource file type1_branch1 and the v6 version of the resource file type1_branch2 in the path "data / res / type1". Next, the terminal device can preload the v5 version of the resource file type1_branch1 through the service module B1 and preload the v6 version of the resource file type1_branch2 through the service module B2.

[0162] After the service module B1 successfully preloads the v5 version of the resource file type1_branch1, the service module B2 has not preloaded the v6 version of the resource file type1_branch2, the terminal device can keep the currently effective version (the v5 version of type1_branch1 currently effective for the service module B1 and the v4 version of type1_branch2 currently effective for the service module B2) and the resource file of type1 type of the version being installed (i.e., the v6 version of type1_branch2), and delete the resource file of type1 type of other versions except the currently effective version and the version being installed (i.e., delete the v2 version of type1_branch1).

[0163] After the business module B2 successfully preloads the v6 version of the resource file type1_branch2, the terminal device can retain the currently effective versions (the v5 version of type1_branch1 which is currently effective for the business module B1 and the v6 version of type1_branch2 which is currently effective for the business module B2) and the type of the resource file being installed (none) for type1, delete the type of the resource file for type1 except the currently effective version and the version being installed (i.e., delete the v4 version of type1_branch2).

[0164] Thus, after the update, the versions of the first resource files stored by the terminal device include the v1 version of type1_branch1 (the preset version), the v5 version of type1_branch1 (the currently effective version), the v3 version of type1_branch2 (the preset version), and the v6 version of type1_branch2 (the currently effective version), avoiding the storage of the v2 version of type1_branch1 and the v4 version of type1_branch2, and reducing the number of stored resource files.

[0165] Next, an example is described in which, after the update process of the foregoing FIG. 5A is completed, the terminal device updates the preset version of type1_branch1 from the v1 version to the v7 version and the preset version of type1_branch2 from the v3 version to the v8 version through the operating system, and then performs the update. In this case, the first resource files include type1_branch1 (the associated business module is the business module B1) and type1_branch2 (the associated business module is the business module B2), the versions of the first resource files stored in the terminal device include the v7 version of type1_branch1 (type1_branch1_v7, the preset version, the currently effective version), the v5 version of type1_branch1 (type1_branch1_v5), the v8 version of type1_branch2 (type1_branch2_v8, the preset version, the currently effective version), and the v6 version of type1_branch2 (type1_branch2_v6), and the new versions of the first resource files are the v9 version of type1_branch1 (type1_branch1_v9) and the v10 version of type1_branch2 (type1_branch1_v10), which are taken as examples to introduce the technical solutions of the present application.

[0166] Exemplarily, FIG. 5B According to some embodiments of the present application, another process diagram of an update method is shown.

[0167] As shown in FIG. 6, before the update, the path "data / res / type1" for storing the resource files of type1 type stores the v5 version of the resource file type1_branch1 and the v6 version of the resource file type1_branch2. In addition, the path in the terminal device for storing the preset version of the resource file also stores the v7 version (the current effective version) of the resource file type1_branch1 and the v8 version (the current effective version) of the resource file type1_branch2. FIG. 5B

[0168] When the update condition is met, the terminal device can download the new version of the resource file, the v9 version of type1_branch1 and the v10 version of type1_branch2, from the OTA server. Then, the terminal device can perform the authentication, decompression, differential merging, authorization, etc. on the v9 version of the resource file type1_branch1 and the v10 version of the resource file type1_branch2 in parallel, to store the v9 version of the resource file type1_branch1 and the v10 version of the resource file type1_branch2 in the path "data / res / type1". Next, the terminal device can preload the v9 version of the resource file type1_branch1 through the service module B1 and preload the v10 version of the resource file type1_branch2 through the service module B2.

[0169] After the service module B1 successfully preloads the v9 version of the resource file type1_branch1, the service module B2 has not preloaded the v10 version of the resource file type1_branch2, the terminal device can keep the current effective version (the v9 version of type1_branch1 currently effective for the service module B1 and the v8 version of type1_branch2 currently effective for the service module B2) and the resource file of type1 type in the installation version (i.e. the v10 version of type1_branch2), and delete the resource file of type1 type in other versions except the current effective version and the installation version (i.e. delete the v5 version of type1_branch1 and the v6 version of type1_branch2).

[0170] ​After the business module B2 successfully preloads the v10 version of the resource file type1_branch2, the terminal device can retain the currently effective versions (the v9 version of type1_branch1 which is currently effective for the business module B1 and the v10 version of type1_branch2 which is currently effective for the business module B2) and the type of the resource file being installed (none) of type1, delete the type of the resource file (none) of type1 except the currently effective versions and the version being installed.

[0171] Thus, after the update, the versions of the first resource files stored by the terminal device include the v7 version of type1_branch1 (the preset version), the v9 version of type1_branch1 (the currently effective version), the v8 version of type1_branch2 (the preset version), and the v10 version of type1_branch2 (the currently effective version), avoiding storing the v5 version of the resource file type1_branch1 and the v6 version of the resource file type1_branch2, and reducing the number of stored resource files.

[0172] Next, the technical solutions of the present application are described in conjunction with the case shown in FIG. 5A

[0173] Exemplarily, FIG. 6 According to some embodiments of the present application, an interaction flow diagram of an updating method is shown. As shown in FIG. 6 The method includes the following steps:

[0174] S601, the business module B1 sets resource parameters to the resource updating SDK.

[0175] In some embodiments, the business module B1 can set resource parameters to the resource updating SDK when starting or installing, and the resource parameters can include the type, branch, version (for example, the currently effective version, the preset version, etc.), storage path of the resource file depended by the business module B1, the identifier of the business module B1, the version of the business module B1, and other information.

[0176] It should be noted that the business module B1 or the business module B2 in the following can be any application program, service or module that depends on or calls resource files.

[0177] For example, for the case shown in FIG. 5A The business module B1 can configure type1_branch1_v2 to the resource updating SDK to indicate that the type of the resource file depended by the business module B1 is type1, the branch is branch1, and the currently effective version is v2.

[0178] ​S602, the service module B1 sets the type of the resource file as type1 in the application manifest data.

[0179] It should be noted that the application manifest data is used to record parameters such as the type of the resource file relied on by the service module. For example, the application manifest data can include a RES_TYPE field, which is used to record the type of the resource file relied on by the service module.

[0180] The service module B1 can adjust the value of the RES_TYPE field of the application manifest data in the resource updating SDK of the service module B1 to type1, to indicate the type of the resource file relied on by the service module B1. For example, if type1 is LLM, the service module B1 can adjust the value of the RES_TYPE field to “LLM”.

[0181] It should be noted that in some other embodiments, the service module B1 can also record the type of the resource file relied on by the service module B1 through other fields, which are not limited herein.

[0182] In some embodiments, the type of the resource file relied on by the service module B1 can be one or more, and accordingly, the value of the RES_TYPE field can also be one or more.

[0183] In some embodiments, the step S601 and the step S602 can be combined into one step, which is not limited herein.

[0184] S603, the service module B2 sets the resource parameter to the resource updating SDK.

[0185] In some embodiments, the service module B2 can set the resource parameter to the resource updating SDK when starting or installing. The resource parameter can include the type, branch, version (for example, the currently effective version, the preset version, etc.), storage path of the resource file relied on by the service module B2, the identifier of the service module B2, the version of the service module B2, and the like.

[0186] For example, for the case shown in FIG. 6B, the service module B2 can configure type1_branch2_v4 to the resource updating SDK, to indicate that the type of the resource file relied on by the service module B2 is type1, the branch is branch2, and the currently effective version is v4. FIG. 5A

[0187] S604, the service module B2 sets the type of the resource file as type1 in the application manifest data.

[0188] ​It should be noted that the application manifest data is used to record the type of resource file relied on by the business module and the like. For example, the RES_TYPE field can be included in the application manifest data, which is used to record the type of resource file relied on by the business module.

[0189] The business module B2 can adjust the value of the RES_TYPE field of the application manifest data in the resource updating SDK of the business module B2 to type1, to indicate the type of resource file relied on by the business module B2. For example, if type1 is LLM, the business module B2 can adjust the value of the RES_TYPE field to "LLM".

[0190] It should be noted that in some other embodiments, the business module B2 can also record the type of resource file relied on by the business module B1 through other fields, which are not limited herein.

[0191] In some embodiments, the type of resource file relied on by the business module B2 can be one or more, and accordingly, the value of the RES_TYPE field can also be one or more.

[0192] It should be noted that the steps S603 and S604 can be performed before the steps S601 and S602, or performed in parallel with the steps S601 and S602, which are not limited herein.

[0193] S605, the software updating application detects that the update condition is met, and calls the provider interface of the business module B1 to obtain the resource parameter of the business module B1.

[0194] The software updating application can call the provider interface of the business module B1 to obtain the resource parameter of the business module B1 when detecting that the update condition (such as reaching a preset update period, or detecting a user update operation, or receiving an update instruction sent by an OTA server) is met.

[0195] It should be noted that the provider interface can be an interface provided by the business module (or the resource updating SDK) and capable of interacting with the business module (or the resource updating SDK), and other applications or modules can obtain the resource parameter of the business module through the provider interface. In some embodiments, the provider interface can also be other interfaces with the same or similar functions.

[0196] S606, the business module B1 sends the resource parameter of the resource file type1_branch1_v2 to the software updating application in response to the calling of the software updating application.

[0197] The business module B1 can send the resource parameter to the software update application in response to the call of the provider interface by the software update application. For example, for the case shown in FIG. 5A The resource parameter sent by the business module B1 can be the resource parameter type1_branch1_v2 of the resource file type1_branch1_v2.

[0198] It should be noted that in some scenarios, for example, in the scenario where the cache of the business module B1 is cleaned, the business module B1 can also send the resource parameter of the resource file type1_branch1_v1 to the software update application.

[0199] S607, the software update application detects that the update condition is met, and calls the provider interface of the business module B2 to obtain the resource parameter of the business module B2.

[0200] The software update application can call the provider interface of the business module B2 to obtain the resource parameter of the business module B2 when detecting that the update condition is met.

[0201] It should be noted that step S607 can be executed in parallel with step S605, or can be executed before or between step S606 and step S607.

[0202] S608, the business module B2 sends the resource parameter of the resource file type1_branch2_v4 to the software update application in response to the call of the software update application.

[0203] The business module B2 can send the currently effective version resource parameter to the software update application in response to the call of the provider interface by the software update application. For example, for the case shown in FIG. 5A The resource parameter sent by the business module B2 can be the resource parameter type1_branch2_v4 of the resource file type1_branch2_v4.

[0204] It should be noted that in some scenarios, for example, in the scenario where the cache of the business module B2 is cleaned, the business module B2 can also send the resource parameter of the resource file type1_branch2_v3 to the software update application.

[0205] S609, the software update application sends an update request to the OTA server.

[0206] The software update application can send an update request to the OTA server after receiving the resource parameters provided by each business module. The update request can include the resource parameters of each business module, such as the type, branch, and version of the resource file.

[0207] For example, for the case shown in FIG. 6B, the update request can include the resource parameter type1_branch1_v2 of the service module B1 and the resource parameter type1_branch2_v4 of the service module B2. FIG. 5A

[0208] S610, the OTA server sends the version information of the new version resource file to the software update application.

[0209] After receiving the update request, the OTA server can send the version information of the new version resource file to the software update application in the case that there is a version of the resource file that is newer than the version of the resource file indicated by the update request.

[0210] For example, for the case shown in FIG. 6B, the OTA server can send the software update application the version information (v5) of the resource file type1_branch1_v5 that is updated from the resource file type1_branch1_v2 corresponding to the service module B1, and the version information (v6) of the resource file type1_branch2_v6 that is updated from the resource file type1_branch2_v4 corresponding to the service module B2. FIG. 5A

[0211] S611, the software update application downloads the new version update resource from the OTA server.

[0212] After receiving the version information of the new version resource file, the software update application can download the new version update resource from the OTA server. For example, the software update application can download the update resource corresponding to the resource file type1_branch1_v5 (the incremental data or full data of the resource file type1_branch1_v5 relative to the resource file type1_branch1_v2) and the update resource corresponding to the resource file type1_branch2_v6 (the incremental data or full data of the resource file type1_branch1_v6 relative to the resource file type1_branch2_v4) from the OTA server.

[0213] It should be noted that the new version update resource can be the full data of the new version resource file, or the incremental data of the new version resource file relative to the old version resource file obtained by the software update application from the service module.

[0214] ​​It should be noted that in some scenarios, if the software update application receives the resource parameter of the resource file type1_branch1_v1, the software update application can download the update resource (full data or incremental data) of the resource file type1_branch1_v5 relative to the resource file type1_branch1_v1.

[0215] It should be noted that in some scenarios, if the software update application receives the resource parameter of the resource file type1_branch2_v3, the software update application can download the update resource (full data or incremental data) of the resource file type1_branch1_v6 relative to the resource file type1_branch2_v3.

[0216] S612, the software update application authenticates, decompresses and differentially combines the resource file type1_branch1_v5, and grants the business module B1 access to the resource file type1_branch1_v5.

[0217] After downloading the update resource corresponding to the resource file type1_branch1_v5, the software update application can authenticate, decompress (or also include differential combination (combine the update resource of the resource file type1_branch1_v5 with the resource file type1_branch1_v2)) the update resource corresponding to the resource file type1_branch1_v5, obtain and store the resource file type1_branch1_v5, and grant the business module B1 access to the resource file type1_branch1_v5.

[0218] S613, the software update application authenticates, decompresses and differentially combines the resource file type1_branch2_v6, and grants the business module B2 access to the resource file type1_branch2_v6.

[0219] After downloading the update resource corresponding to the resource file type1_branch2_v6, the software update application can authenticate, decompress (or also include differential combination (combine the update resource of the resource file type1_branch2_v6 with the resource file type1_branch2_v4)) the update resource corresponding to the resource file type1_branch2_v6, obtain and store the resource file type1_branch2_v6, and grant the business module B2 access to the resource file type1_branch2_v6.

[0220] S614, the software update application sends a preloading broadcast to the business module B1.

[0221] The software update application can send a pre-load broadcast to the business module Bl to enable the business module Bl to load the resource file type1_branch1_v5 after granting the business module Bl access to the resource file type1_branch1_v5. In some embodiments, the pre-load broadcast can include the resource parameters (type, branch, version, etc.) of the resource file that the business module Bl needs to pre-load.

[0222] In some embodiments, the resource file type1_branch1_v5 that the business module Bl pre-loads is also relied on by other business modules.

[0223] In some embodiments, the business module Bl can also send a pre-load broadcast to pre-load type1_branch1_v5 to all business modules that rely on resource files of type type1, such as business module B2.

[0224] S615, the business module Bl pre-loads the resource file type1_branch1_v5.

[0225] The business module Bl can pre-load the resource file type1_branch1_v5 in response to the pre-load broadcast from the software update application.

[0226] S616, the business module Bl updates the resource parameters of the resource file type1_branch1_v5 to the resource update SDK.

[0227] The business module Bl can update the resource parameters of the resource file type1_branch1_v5 to the resource update SDK after pre-loading the resource file type1_branch1_v5, so that the resource update SDK can provide the resource parameters type1_branch1_v5 to other modules when the provider interface is invoked.

[0228] S617, the software update application determines the associated business modules of the resource file of type type1.

[0229] The software update application can determine the associated business modules of the resource file of type type1, i.e., the business modules that rely on the resource file of type type1. For example, for the scenario shown in FIG. 6A, the associated business modules of the resource file of type type1 include the business module Bl and the business module B2. FIG. 5A

[0230] ​It should be noted that step S617 can be executed in parallel with step S615 and step S616, or prior to step S615, which is not limited herein.

[0231] It should be noted that in some embodiments, the software update application can call the provider interface of the associated business module of the resource file of type type1 to obtain the resource parameters of the part of the business module.

[0232] S618, the software update application calls the provider interface of the business module B1 to obtain the resource parameters of the business module B1.

[0233] S619, the business module B1 sends the resource parameters of the resource file type1_branch1_v5 to the software update application.

[0234] The business module B1 sends the resource parameters type1_branch1_v5 of the resource file type1_branch1_v5 to the software update application in response to the call of the provider interface by the software update application.

[0235] S620, the software update application calls the provider interface of the business module B2 to obtain the resource parameters of the business module B2.

[0236] S621, the business module B2 sends the resource parameters of the resource file type1_branch2_v4 to the software update application.

[0237] The business module B2 sends the resource parameters type1_branch1_v4 of the resource file type1_branch1_v4 to the software update application in response to the call of the provider interface by the software update application.

[0238] S622, the software update application obtains the resource parameters of the resource file of type type1 being installed.

[0239] For example, for the case shown in FIG. 8, before the v6 version of the resource file type1_branch2 is installed, the software update application obtaining the resource parameters of the resource file of type type1 being installed can include type1_branch2_v6 (the v6 version of type1_branch2). FIG. 5A

[0240] S623, the software update application deletes the resource files of type type1 except for the currently effective version and the version being installed.

[0241] ​After obtaining the resource parameter of the associated service module of the resource file of type 1 (the resource file of type 1 corresponding to the current effective version) and the resource parameter of the resource file of type 1 being installed (the resource file of type 1 corresponding to the version being installed), the software update application can delete the resource files of type 1 other than the current effective version and the version being installed.

[0242] For example, as shown in the case FIG. 5A The software update application can delete the resource file of type 1 (the resource file type1_branch1_v2) other than the v5 version of the resource file type1_branch1 (as the current effective version of the service module B1), the v4 version of the resource file type1_branch2 (as the current effective version of the service module B2), and the v6 version of the resource file type1_branch2 (as the version being installed) under the path "res / data / type1".

[0243] It should be noted that the software update application does not delete the v1 version of the resource file type1_branch1 and the v3 version of the resource file type1_branch2 because they are preset versions.

[0244] Based on this method, even if the resource parameter set by the service module B1 to the resource update SDK in the foregoing step S601 is the resource parameter of the resource file type1_branch1_v1, and the resource parameter sent by the service module B1 to the software update application in the foregoing step S606 is the resource parameter of the resource file type1_branch1_v1, the v2 version of the foregoing resource file type1_branch1 can also be deleted in this step.

[0245] S624, the software update application sends a preloading broadcast to the service module B2.

[0246] After granting the service module B2 the access right to the resource file type1_branch2_v6, the software update application can send a preloading broadcast to the service module B2 to enable the service module B2 to load the resource file type1_branch2_v6.

[0247] S625, the service module B2 preloads the resource file type1_branch2_v6.

[0248] The service module B2 can preload the resource file type1_branch2_v6 in response to the preloading broadcast of the software update application.

[0249] S626, the service module B2 updates the resource parameter of the resource file type1_branch2_v6 to the resource update SDK.

[0250] After preloading the resource file type1_branch2_v6, the service module B2 can update the resource parameter of the resource file type1_branch2_v6 to the resource update SDK, so that the resource update SDK can provide the resource parameter type1_branch2_v6 to other modules when the provider interface is called.

[0251] S627, the software update application determines the associated service module of the resource file of type type1.

[0252] The software update application can determine the associated service module of the resource file of type type1, that is, the service module that depends on the resource file of type type1. For example, for the case shown in FIG. 6, the associated service module of the resource file of type type1 includes the service module B1 and the service module B2. FIG. 5A

[0253] It should be noted that step S627 can be executed in parallel with step S624 and step S625, or before step S624, which is not limited herein.

[0254] It should be noted that in some embodiments, the software update application can call the provider interface of the associated service module of the resource file of type type1 to obtain the resource parameter of the part of the service module.

[0255] In some embodiments, the software update application can determine the associated service module of the resource file of type type1 according to the value of the RES_TYPE field in the application manifest data of each service module. If the value of the RES_TYPE field of a service module is type1, the service module is determined as the associated service module of the resource file of type type1.

[0256] S628, the software update application calls the provider interface of the service module B1 to obtain the resource parameter of the service module B1.

[0257] S629, the service module B1 sends the resource parameter of the resource file type1_branch1_v5 to the software update application.

[0258] The service module B1 sends the resource parameter type1_branch1_v5 of the resource file type1_branch1_v5 to the software update application in response to the call of the software update application to the provider interface.​

[0259] S630, the software update application calls the provider interface of business module B2 to obtain the resource parameters of business module B2.

[0260] S631, Business module B2 sends the resource parameters of resource file type1_branch2_v6 to the software update application.

[0261] In response to the software update application's call to the provider interface, business module B2 sends the resource parameter type1_branch2_v6 of resource file type1_branch2_v6 to the software update application.

[0262] S632, the software update application obtains resource parameters for a resource file of type 1 that is being installed.

[0263] For example, for FIG. 5A As shown, after the v6 version of resource file type1_branch2 has been preloaded, the resource file of type 1 that is being installed no longer exists.

[0264] S633, Software update application deletes resource files of type 1, excluding the currently effective version and the version being installed.

[0265] After obtaining the resource parameters of the associated business module of the resource file of type 1 (corresponding to the resource file of type 1 in the current effective version) and the resource parameters of the type 1 being installed (corresponding to the resource file of type 1 in the version being installed), the software update application can delete the resource files of other versions besides the current effective version and the version being installed from the resource file of type 1.

[0266] For example, corresponding FIG. 7 As shown, after business module B2 preloads resource file type1_branch2_v6, all resource files are updated (i.e., there are no resource files of type 1 being installed). The software update application can delete all resource files of type 1 (resource file type1_branch2 version 4) under the path "res / data / type1", except for resource file type1_branch1 version 5 (the currently effective version of business module B1) and resource file type1_branch2 version 6 (the currently effective version of business module B2).

[0267] Based on the method, even if the resource parameter set by the service module B2 to the resource update SDK in the foregoing step S603 is the resource parameter of the resource file type1_branch2_v3, and the resource parameter sent by the service module B2 to the software update application in the foregoing step S608 is the resource parameter of the resource file type1_branch2_v3, the v4 version of the foregoing resource file type1_branch2 can also be deleted in this step.

[0268] It should be noted that, since the v1 version of the resource file type1_branch1 and the v3 version of the resource file type1_branch2 are preset versions, the software update application does not delete the two versions.

[0269] Based on the above method, in the process of updating the resource file of the service module by the terminal device, after enabling the service module to preload the new version of the resource file, all versions of the resource file of the same type as the resource file of the service module can be deleted, except for the version being effective and the version being installed. In this way, the terminal device can be prevented from storing the non-preset version of the resource file that is not effective, which is not limited herein. In addition, the terminal device can also be prevented from storing the old version of the resource file due to the difference between the branches before and after the update of the resource file.

[0270] The embodiment of the application further provides an updating method, applied to a terminal device.

[0271] Exemplarily, FIG. 7 According to some embodiments of the application, a flowchart of an updating method is shown. The execution subject of the method is a terminal device. As shown in the figure, FIG. 5A The method includes the following steps:

[0272] S701, detecting that an updating condition is met, and obtaining an updating resource of a third version of a first resource file of a first type dependent on a first service module relative to an old version.

[0273] The terminal device can obtain the updating resource of the third version (as a new version of the resource file) of the first resource file relative to the old version from the OTA server when detecting that the updating condition is met. The updating resource can be all data of the third version of the first resource file, or incremental data of the third version of the first resource file relative to the old version.

[0274] For example, for FIG. 6 and FIG. 5BFor the case shown, in the case that the first service module is service module B1: the first type is type1, the first resource file is the resource file of branch1 in type1 (resource file type1_branch1), the third version is v9, and the old version is v7. In the case that the first service module is service module B2: the first type is type1, the first resource file is the resource file of branch2 in type1 (resource file type1_branch2), the third version is v10, and the old version is v8.

[0275] For example, for the case shown, in the case that the first service module is service module B1: the first type is type1, the first resource file is the resource file of branch1 in type1 (resource file type1_branch1), the third version is v5, and the old version is v2. In the case that the first service module is service module B2: the first type is type1, the first resource file is the resource file of branch2 in type1 (resource file type1_branch2), the third version is v6, and the old version is v4. FIG. 5A

[0276] In some embodiments, the old version can be the first version or the second version. The second version can be newer than the first version or older than the first version. The first version can be a preset version or a non-preset version.

[0277] For example, for the case shown, in the case that the first service module is service module B1: the first version is v1, and the second version is v2. In the case that the first service module is service module B2: the first version is v3, and the second version is v4. FIG. 6 FIG. 5B For example, for the case shown, in the case that the first service module is service module B1: the first version is v1, and the second version is v2. In the case that the first service module is service module B2: the first version is v3, and the second version is v4.

[0278] For example, for the case shown, in the case that the first service module is service module B1: the first version is v1, and the second version is v2. In the case that the first service module is service module B2: the first version is v3, and the second version is v4. FIG. 1A

[0279] For example, for the case shown, in the case that the first service module is service module B1: the first version is v1, and the second version is v2. In the case that the first service module is service module B2: the first version is v3, and the second version is v4. FIG. 1B For the case of the second update in the case shown, the first version can be 1.0.2, the second version can be 1.0.1, and the old version can be the second version. For the case of the fifth update in the case shown, the first version can be 1.0.2, the second version can be 1.0.5, and the old version can be the second version. FIG. 5A

[0280] ​​​​S702, store the third version of the first resource file in the storage path of the first type of resource file based on the obtained update resource.

[0281] After obtaining the update resource of the third version of the first resource file relative to the old version, the terminal device can perform operations such as authentication, decompression, differential merging, etc. on the obtained update resource to obtain the third version of the first resource file, and store the third version of the first resource file in the storage path of the first type of resource file.

[0282] Exemplarily, assuming that the storage path of the resource file is "data / res", and the first type is type1, the storage path of the first type of resource file can be "data / res / type1". The terminal device can store the third version of the first resource file in "data / res / type1" in the case of storing all data of the update resource of the third version of the first resource file. Alternatively, the terminal device can merge the update resource and the old version of the first resource file to obtain the third version of the first resource file in the case that the update resource is the incremental data of the third version of the first resource file relative to the old version, and store the obtained third version of the first resource file in "data / res / type1".

[0283] For example, for the case shown in FIG. 6 and FIG. 5B In the case that the first service module is service module B1, the terminal device can store the resource file type1_branch1_v5 in the path "data / res / type1". In the case that the first service module is service module B2, the terminal device can store the resource file type1_branch2_v6 in the path "data / res / type1".

[0284] For another example, for the case shown in FIG. 5A In the case that the first service module is service module B1, the terminal device can store the resource file type1_branch1_v9 in the path "data / res / type1". In the case that the first service module is service module B2, the terminal device can store the resource file type1_branch2_v10 in the path "data / res / type1".

[0285] S703, invoke the first service module to preload the third version of the first resource file.

[0286] After storing the third version of the first resource file in the storage path of the first type of resource file, the terminal device can call the first service module to preload the third version of the first resource file. It should be noted that after the first service module preloads the third version of the first resource file, the current effective version of the first resource file in the first service module changes to the third version.

[0287] For example, for the case shown in FIG. 6 and FIG. 5B , when the first service module is service module B1, the terminal device can call service module B1 to preload the v5 version of resource file type1_branch1. When the first service module is service module B2, the terminal device can call service module B2 to preload the v6 version of resource file type1_branch2.

[0288] For another example, for the case shown in FIG. 5A , when the first service module is service module B1, the terminal device can call service module B1 to preload the v9 version of resource file type1_branch1. When the first service module is service module B2, the terminal device can call service module B2 to preload the v10 version of resource file type1_branch2.

[0289] S704, obtaining the current effective version of the first type of resource file in the corresponding associated service module and the version of the first type of resource file being installed.

[0290] After the first service module preloads the third version of the first resource file, the terminal device can obtain the current effective version of the first type of resource file in the corresponding associated service module and the version of the first type of resource file being installed.

[0291] For example, for the case shown in FIG. 6 and FIG. 5A , when the first service module is service module B1: the current effective version of the first type of resource file in the corresponding associated service module includes the v5 version of type1_branch1 effective in service module B1 and the v4 version of type1_branch2 effective in service module B2 (service module B2 has not preloaded resource file type1_branch2_v6); the version of the first type of resource file being installed can include the v6 version of resource file type1_branch2 being installed by service module B2.

[0292] For another example, for the case shown in FIG. 6 and FIG. 5BIn the case where the first service module is service module B2, the current effective version of the first type of resource file in the corresponding associated service module includes the v5 version of type1_branch1 that is effective in service module B1 (service module B1 has preloaded resource file type1_branch1_v5) and the v6 version of type1_branch2 that is effective in service module B2; and there is no version of the first type of resource file being installed.

[0293] For example, for FIG. 5B In the case where the first service module is service module B1, the current effective version of the first type of resource file in the corresponding associated service module includes the v9 version of type1_branch1 that is effective in service module B1 and the v8 version of type1_branch2 that is effective in service module B2 (service module B2 has not preloaded resource file type1_branch2_v10); the version of the first type of resource file being installed can include the v10 version of resource file type1_branch2 that service module B2 is installing.

[0294] For example, for FIG. 5A In the case where the first service module is service module B2, the current effective version of the first type of resource file in the corresponding associated service module includes the v9 version of type1_branch1 that is effective in service module B1 (service module B1 has preloaded resource file type1_branch1_v9) and the v10 version of type1_branch2 that is effective in service module B2; and there is no version of the first type of resource file being installed.

[0295] S705, delete, in the storage directory of the first type of resource file, the other versions of the first type of resource file except for the current effective version of the first type of resource file in the corresponding associated service module and the version of the first type of resource file being installed.

[0296] After obtaining the current effective version of the first type of resource file in the corresponding associated service module and the version of the first type of resource file being installed, the terminal device can delete, in the storage directory of the first type of resource file, the other versions of the first type of resource file except for the current effective version of the first type of resource file in the corresponding associated service module and the version of the first type of resource file being installed.

[0297] For example, for FIG. 5BIn the illustrated case, in the case that the first service module is service module B1, the terminal device can delete the v2 version of resource file type1_branch1 in storage path "data / res / type1". In the case that the first service module is service module B2, the terminal device can delete the v4 version of resource file type1_branch2 in storage path "data / res / type1".

[0298] For example, for the case of the second update in Table 1, the terminal device can delete the 1.0.2 version of LLM 01. FIG. 1A In the illustrated case, in the case that the first service module is service module B1, the terminal device can delete the v5 version of resource file type1_branch1 and the v6 version of resource file type1_branch1 in storage path "data / res / type1". In the case that the first service module is service module B2, there is no need to delete other versions in storage path "data / res / type1" except for the current effective version of the first type of resource file in the corresponding associated service module and the version of the first type of resource file being installed.

[0299] For example, for the case of the second update in Table 1, the terminal device can delete the 1.0.2 version of LLM 01. FIG. 1B For example, for the case of the fifth update in Table 1, the terminal device can delete the 1.0.2 version of LLM 01. FIG. 8

[0300] Since the resource file relied on by the service module can be updated from a branch of a type of resource file to another branch of the type of resource file in the updating process, deleting the old version of the resource file based on the above method can avoid the resource file of the a branch occupying the storage space after the resource file is updated from the a branch to the b branch.

[0301] Based on the above method, the terminal device can timely delete the non-preset version of the first resource file that is not effective, thereby avoiding excessive occupation of the storage space of the terminal device.

[0302] In some embodiments, the terminal device can perform the above steps S704 to S705 to delete the non-preset version of the first resource file that is not effective, corresponding to each updated resource file service module.

[0303] ​In some embodiments, the versions of the resource files can be sequentially released, for example, in the order of a first version, a second version, a third version, …, and an Nth version. The ith version is newer than the (i-1)th version. Based on this, in the foregoing embodiments, the third version can be the mth version, the second version can be the nth version, and the first version can be the kth version, or the third version can be the mth version, the first version can be the nth version, and the second version can be the kth version, where n is less than m.

[0304] The embodiments of the present application further provide a program product, which, when executed on an electronic device, can enable the electronic device to implement the updating method provided in the foregoing embodiments.

[0305] The embodiments of the present application further provide a readable storage medium, which stores one or more programs / instructions, and the one or more programs / instructions, when executed by an electronic device, enable the electronic device to implement the updating method provided in the foregoing embodiments.

[0306] Further, ​ According to some embodiments of the present application, a structural schematic diagram of a terminal device 10 is shown.

[0307] The terminal device 10 can include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a loudspeaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0308] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the terminal device 10. In some other embodiments of the present application, the terminal device 10 can include more or fewer components than shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware. In addition, the interface connection relationship between the modules shown in the embodiments of the present application is instructive and does not constitute a limitation on the structure of the terminal device 10. In some other embodiments of the present application, the terminal device 10 can also use different interface connection modes or a combination of multiple interface connection modes.

[0309] The processor 110 can include one or more processing units, e.g., the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices or integrated in one or more processors.

[0310] The processor 110 can be the nerve center and command center of the terminal device 10. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.

[0311] The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory can save instructions or data that the processor 110 has just used or repeatedly uses. If the processor 110 needs to use the instructions or data again, it can be directly called from the memory. This avoids repeated access and reduces the waiting time of the processor 110, thus improving the efficiency of the system.

[0312] In some embodiments, the processor 110 can be used to execute the instructions of the updating method provided in the foregoing embodiments.

[0313] The charging management module 140 is configured to receive charging input from a charger. The power management module 141 is configured to connect a battery 142 and the charging management module 140. The power management module 141 receives input of the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, and the wireless communication module 160, etc. The power management module 141 can also be configured to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be arranged in the processor 110. In some other embodiments, the power management module 141 and the charging management module 140 can also be arranged in the same device.

[0314] The wireless communication function of the terminal device 10 can be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor, the baseband processor, and the like.

[0315] The antenna 1 and the antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal device 10 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example, the antenna 1 can be multiplexed as a diversity antenna of a wireless local area network. In some other embodiments, the antennas can be used in combination with a tuning switch.

[0316] The mobile communication module 150 can provide a solution including 2G / 3G / 4G / 5G wireless communication applied to the terminal device 10.

[0317] The wireless communication module 160 can provide a solution including wireless local area network (WLAN) (such as a wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, and the like, applied to the terminal device 10. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive signals to be sent from the processor 110, perform frequency modulation and amplification on the signals, and convert the signals into electromagnetic wave radiation via the antenna 2.

[0318] In some embodiments, the antenna 1 of the terminal device 10 is coupled with the mobile communication module 150, and the antenna 2 is coupled with the wireless communication module 160, so that the terminal device 10 can communicate with a network and other devices through wireless communication technology.

[0319] The terminal device 10 implements a display function by a GPU, a display screen 194, an application processor, and the like. The display screen 194 is used to display images, videos, and the like.

[0320] The external memory interface 120 can be used to connect an external memory card to extend the storage capacity of the terminal device 10. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are stored in the external memory card.

[0321] The internal memory 121 can be used to store computer executable program codes including instructions. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), and the like. The data storage area can store data created during use of the terminal device 10 (such as audio data, a phonebook, etc.). In addition, the internal memory 121 can include a high-speed random access memory, and can also include a non-volatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various function applications and data processing of the terminal device 10 by running instructions stored in the internal memory 121 and / or instructions stored in a memory disposed in the processor.

[0322] The terminal device 10 can implement an audio function through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, an application processor, etc. For example, music playing, recording, etc.

[0323] It should be noted that the terms used in the part of the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; "and / or" in this paper is only a description of the association relationship between the associated obstacles, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two, "at least one" and "one or more" means one, two or more than two.

[0324] It should be noted that the terms "first", "second" are only used for description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the "first", "second" features can explicitly or implicitly include one or more features.

[0325] In this specification, the phrase "one embodiment" or "some embodiments" etc. means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in one embodiment", "in some embodiments", "in other embodiments", "in additional embodiments" and so on, in various places in the specification are not necessarily all referring to the same embodiment, unless otherwise specifically specified. The terms "comprising", "including", "having" and their conjugates, mean "including but not limited to" unless otherwise expressly specified.

[0326] In the embodiments described above, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the application are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer readable storage medium or transmitted by the computer readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.). The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disk, hard disk, magnetic tape), optical media, or semiconductor media, etc.

[0327] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by a computer program to instruct the relevant hardware to complete. The program can be stored in a computer readable storage medium, and the program can include the processes of the above-mentioned method embodiments when executed. The storage medium mentioned above includes read-only memory or random access memory, magnetic disk or optical disk, and various media that can store program codes.

[0328] The above is only a specific implementation of the embodiments of the application, but the protection scope of the embodiments of the application is not limited thereto. Any change or replacement within the technical scope disclosed in the embodiments of the application should be covered in the protection scope of the embodiments of the application. Therefore, the protection scope of the embodiments of the application should be subject to the protection scope of the claims.

Claims

1. An update method applied to an electronic device, characterized in that, The method comprises: detecting that an update condition is met, and obtaining a first update file of a first resource file, wherein the first update file is an update file of an mth version of the first resource file relative to an nth version of the first resource file, the nth version of the first resource file is a preset version of an operating system of the electronic device, m and n are positive integers, and m is greater than n; generating and storing the mth version of the first resource file based on the first update file; determining that the electronic device stores a kth version of the first resource file, and the kth version is not the preset version of the operating system of the electronic device, and deleting the kth version, wherein k is a positive integer less than m; the generating and storing the mth version of the first resource file based on the first update file comprises: in a case where the first update file comprises incremental data of the mth version of the first resource file relative to the nth version of the first resource file, merging the first update file and the nth version of the first resource file to obtain the mth version of the first resource file, and storing the mth version of the first resource file in a first directory.

2. The method of claim 1, wherein, The method further comprises: in a case where the mth version of the first resource file is not the preset version of the operating system of the electronic device, deleting the mth version.

3. The method of claim 1 or 2, the generating and storing the mth version of the first resource file based on the first update file comprises: in a case where the first update file comprises all data of the mth version of the first resource file, storing the mth version of the first resource file in the first update file in a first directory.

4. The method of claim 3, wherein, The first resource file is of a first type, the first directory is used to store non-preset versions of resource files of the first type, the first resource file is a resource file relied on by a first service module; and the determining that the electronic device stores the kth version of the first resource file, and the kth version is not the preset version of the operating system of the electronic device, and the deleting the kth version comprises: after storing the mth version of the first resource file in the first directory, calling the first service module to preload the mth version of the first resource file, the preloading being used to switch a currently effective version of the first resource file in the first service module to the mth version; after the first service module preloads the mth version of the first resource file, deleting the kth version in the first directory.

5. The method of claim 4, the electronic device comprising at least one second service module relying on resource files of the first type, the at least one second service module comprising the first service module; and the deleting the kth version in the first directory after the first service module preloads the mth version of the first resource file comprises: obtain a currently effective version of the resource file of the first type relied on by the second service module and a version in an installation process of the resource file of the first type relied on by the second service module; delete, from the first directory, the resource file of the first type other than the currently effective version of the resource file of the first type relied on by the second service module and the version in the installation process of the resource file of the first type relied on by the second service module.

6. The method of claim 4, wherein, The first type includes any one of the following types: a large language model, an image semantic understanding large model, an image generation model, a video generation model, a speech recognition model, a speech synthesis model, a personalized audio model, a semantic model, a virus library, an application whitelist, an application blacklist, information of a holiday, and a parameter of the electronic device in an old age mode.

7. An electronic device, comprising: comprise: one or more processors; one or more memories; The one or more memories store one or more computer programs comprising instructions that, when executed by the one or more processors, cause the electronic device to implement the updating method of any one of claims 1 to 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable program instructions that, when executed on a computer, cause the computer to implement the updating method of any one of claims 1 to 6.

9. A computer program product comprising computer program code that, when executed on a computer, causes the computer to implement the updating method of any one of claims 1 to 6.

Images