Application update method, electronic device, readable medium, and program product

Abstract

The application provides an application updating method, an electronic device includes a first application and a second application, the first application and the second application both include a first function module, a plug-in file corresponding to the first function module is not coupled with an installation package file corresponding to the first application, and is not coupled with an installation package file corresponding to the second application, and the method comprises the following steps: when the first function module of the first application is updated, the electronic device acquires the plug-in file corresponding to the first function module of the first application, and updates the first function module of the second application based on the plug-in file corresponding to the first function module of the first application, so that the synchronous updating of the first function modules of the first application and the second application is realized, and the problem that the first function modules in the two applications can be synchronously modified.

Description

Technical Field

[0001] This application relates to the field of software update technology, and more particularly to an application update method, electronic device, computer program product, and computer-readable storage medium. Background Technology

[0002] Multiple applications in an electronic device may include functional modules with the same purpose. However, due to inconsistent update schedules across different applications, these modules cannot be updated synchronously. This is especially problematic when a module malfunctions; the disparity in update schedules across applications prevents timely and synchronized fixes for that issue.

[0003] For example, an electronic device includes a first application and a second application. Both applications include a first functional module. A problem with the first functional module causes both the first and second applications to malfunction during operation. If the first application is updated but the second application is not, the problem with the first functional module of the first application is fixed, and the first application can run normally. However, the problem with the first functional module of the second application is not fixed, and the second application still cannot run normally. Summary of the Invention

[0004] This application provides an application update method, electronic device, computer program product, and computer-readable storage medium that can synchronously update common functional modules of multiple applications.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] In a first aspect, this application provides a method for updating an application applied to an electronic device. The electronic device includes a first application and a second application. Both the first application and the second application include a first functional module. The plug-in file corresponding to the first functional module is not coupled with the installation package file corresponding to the first application and is also not coupled with the installation package file corresponding to the second application. The plug-in file corresponding to the first functional module is used to update the first functional module, the installation package file corresponding to the first application is used to update the first application, and the installation package file corresponding to the second application is used to update the second application. The method for updating the application includes: when the first functional module of the first application is updated, the electronic device obtains the plug-in file corresponding to the first functional module of the first application and updates the first functional module of the second application based on the plug-in file corresponding to the first functional module of the first application.

[0007] As can be seen from the above, when the first functional module of the first application is updated, that is, when the electronic device detects the update package of the first functional module of the first application and updates the first functional module of the first application based on the update package, the electronic device can obtain the plugin file corresponding to the first functional module of the first application, and update the first functional module of the second application based on the plugin file. In this way, the synchronous update of the first functional modules of the first application and the second application is achieved, and the problem of synchronous modification of the first functional modules of the two applications can be solved.

[0008] In some embodiments, the first application is typically a non-system-level application, while the second application is typically a system-level application. The plugin file corresponding to the first functional module is not coupled with the installation package file corresponding to the first application, nor is it coupled with the installation package file corresponding to the second application, indicating that the first functional module is an independently decoupled functional module.

[0009] Based on the first aspect, in one possible implementation, the electronic device updates the first functional module of the first application by: the electronic device obtaining the updated first functional module of the first application; the electronic device compiling the updated first functional module of the first application to obtain a plugin file corresponding to the first functional module of the first application, and obtaining an installation package file corresponding to the first application based on the plugin file corresponding to the first functional module of the first application; and the electronic device updating the first application based on the installation package file corresponding to the first application, so as to realize the update of the first application and thus the first functional module of the first application through the installation package file corresponding to the first application.

[0010] Based on the first aspect, in one possible implementation, the plug-in file corresponding to the first functional module of the first application compiled by the electronic device is stored in a preset directory, and the files stored in the preset directory are not recompiled by the electronic device; wherein, the electronic device obtaining the plug-in file corresponding to the first functional module of the first application includes: the electronic device obtaining the plug-in file corresponding to the first functional module of the first application in the preset directory.

[0011] In some embodiments, the default directory is the HostManager's Assets directory, where files will not be compiled by the compiler. This avoids problems caused by recompiling already compiled plugin files.

[0012] Based on the first aspect, in one possible implementation, the electronic device compiles the updated first functional module of the first application to obtain a plugin file corresponding to the first functional module of the first application. This includes: compiling the updated first functional module of the first application to obtain a plugin file corresponding to the first functional module of the first application whose bytecode is a first type of file; the bytecode of the updated first functional module of the first application is a second type of file; the operating system of the electronic device supports recognizing the first type of file but does not support recognizing the second type of file. In some embodiments, the first type of file is a dex file, and the second type of file is a class file.

[0013] Based on the first aspect, in one possible implementation, after the electronic device updates the first application based on the plugin file corresponding to the first application and the installation package file corresponding to the first application, it further includes: when the electronic device runs the first functional module of the first application to use the first capability of the first functional module, the electronic device obtains an instance of the corresponding class of the first capability, and runs the instance of the corresponding class of the first capability by calling the capability method of the corresponding class of the first capability based on reflection mechanism, wherein the instance of the corresponding class of the first capability is loaded from the plugin file corresponding to the first functional module of the first application.

[0014] Based on the first aspect, in one possible implementation, the electronic device updates the first functional module of the second application based on the plug-in file corresponding to the first functional module of the first application, including: the electronic device transmits the plug-in file corresponding to the first functional module of the first application to the second application in a cross-process file transfer manner, and replaces the plug-in file corresponding to the first functional module stored in the second application.

[0015] Based on the first aspect, in one possible implementation, the electronic device transmits the plug-in file corresponding to the first functional module of the first application to the second application based on the cross-process file transfer method, including: the electronic device transmits the plug-in file corresponding to the first functional module of the first application to the second application using a file descriptor based on the cross-process file transfer method, which can save resources and reduce overhead.

[0016] Based on the first aspect, in one possible implementation, it further includes: when the electronic device runs the first functional module of the second application to use the second capability of the first functional module of the second application, the electronic device obtains an instance of the corresponding class of the second capability from the plug-in file corresponding to the first functional module of the first application; the electronic device runs the instance of the corresponding class of the second capability by calling the capability method of the corresponding class of the second capability based on the reflection mechanism.

[0017] Based on the first aspect, in one possible implementation, the electronic device obtains an instance of the corresponding class of the second capability from the plug-in file corresponding to the first functional module of the first application, including: the electronic device calls the second interface through the first interface using a cross-process call interface method, and obtains an instance of the corresponding class of the second capability from the plug-in file corresponding to the first functional module of the first application through the second interface, wherein the first interface is an interface provided by the first functional module of the second application, and the second interface is an interface provided by the first functional module of the first application.

[0018] Based on the first aspect, in one possible implementation, the first functional module refers to a module that is called by the electronic device more frequently than a threshold during the runtime of the first or second application. The frequently called first functional module is independently decoupled, ensuring that it can be used immediately without introducing other dependencies.

[0019] Based on the first aspect, in one possible implementation, the first functional module includes a second functional module, the second functional module is dependent on the first functional module, and when the first functional module is running, the second functional module is called more frequently than a threshold.

[0020] In some embodiments, the second functional module is not a common module of multiple applications; that is, the first application includes the second functional module, but the second application does not. Furthermore, the second functional module is called frequently, meaning it is a high-frequency call. In scenarios where the second functional module is not a common module, the first functional module includes the second functional module, meaning the first and second functional modules are coupled. Thus, after the electronic device updates the first functional module of the second application based on the plugin file corresponding to the first functional module, the second application also includes and updates the second functional module, ensuring that the second functional module provides a dependency on the first functional module. Secondly, this application provides an electronic device including: one or more processors, a memory, and a display screen; the memory and display screen are coupled to one or more processors, the memory storing computer program code including computer instructions, and when one or more processors execute the computer instructions, the electronic device executes the application update method as described in any one of the first aspects.

[0021] Thirdly, this application provides a computer-readable storage medium for storing a computer program, which, when executed, is specifically used to implement the update method of the application as described in any one of the first aspects.

[0022] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform an application update method as described in any of the first aspects. Attached Figure Description

[0023] Figure 1 A schematic diagram illustrating the construction of a trust loop for multiple electronic devices provided in the embodiments of this application;

[0024] Figure 2 A schematic diagram of the modules involved in the outgoing and in-terminal scenarios provided in the embodiments of this application;

[0025] Figure 3 This is a screenshot illustrating how the inconsistent update schedules of the Sports & Health APP and the MagicLink module prevented the timely fixing of issues with the functional modules.

[0026] Figure 4 A diagram illustrating the calling of functional modules provided in the embodiments of this application;

[0027] Figure 5 This is a diagram illustrating the compilation and packaging of the plugin provided in an embodiment of this application.

[0028] Figure 6 A flowchart illustrating the loading of plugin files for a sports and health app, as provided in this application embodiment;

[0029] Figure 7 A flowchart illustrating the inter-application plugin file transfer provided in this application embodiment;

[0030] Figure 8 A flowchart illustrating the loading of plugin files for the MagicLink module provided in this application embodiment;

[0031] Figure 9 This is a hardware structure diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions "a," "an," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the embodiments of this application, "one or more" refers to one, two, or more; "and / or" describes the relationship between related objects, indicating that three relationships may exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

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

[0034] The "multiple" mentioned in the embodiments of this application refers to two or more. It should be noted that in the description of the embodiments of this application, terms such as "first" and "second" are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0035] Trust relationships are established between two or more electronic devices through trusted authentication, forming a trust loop.

[0036] Taking watches as an example, watches and other electronic devices typically establish trust relationships and form trust loops through far-field communication (such as mobile networks). This trust loop can be called a far-field trust loop, which requires the watch to support eSIM card activation. To enable watches and other electronic devices without eSIM card activation to form trust loops, a near-field trust loop scheme is proposed, as follows:

[0037] Taking a mobile phone and a watch as an example, the mobile phone has a fitness app, which allows it to connect to the watch via Bluetooth. After establishing a Bluetooth connection, the watch can automatically or manually log in to its account. Since both the watch and the phone are logged into the same account, they form a trust loop, which is a near-field trust loop. This can be understood as electronic devices under the same account trusting each other.

[0038] For example, such as Figure 1 As shown, watch 103 and mobile phone 102 can form a far-field trust loop based on far-field communication (e.g., mobile network), and watch 103, mobile phone 101 and tablet computer 104 can also form a near-field trust loop based on near-field communication.

[0039] Taking mobile phones 103 and 101 as examples, the process of forming a near-field trust loop with watches and other electronic devices can be described as follows:

[0040] 1) Discover the equipment

[0041] Launch the Health app on your phone (phone 101), tap "Add Device" on the app's device page, and scan for nearby Bluetooth devices, such as watch 103.

[0042] 2) Pairing connection

[0043] After the phone 101 discovers the watch 103, the phone 101 and the watch 103 will pair and connect via Bluetooth under the user's control.

[0044] 3) Equipment certification

[0045] After the Bluetooth channel is established, the mobile phone 101 needs to authenticate the watch 103.

[0046] 4) Account Login

[0047] After successful legality verification, the 101 phone synchronizes its account to the 103 watch via the Sports Health APP, and the 103 watch then logs in to the account.

[0048] 5) Add a trust ring

[0049] After the first four steps are completed, the Sports & Health APP will notify the device information of the watch 103 (such as device model, SN, MAC address) to the MagicLink module of the phone 101. The MagicLink module of the phone 101 will communicate with the MagicLink module of the watch 103 through the Bluetooth channel established between the Sports & Health APP and the watch 103 to perform loop entry related operations, including authentication, device registration to the cloud, etc. After the loop entry operation is completed, the watch 103 and the phone form a near-field trust ring, or the watch 103 joins the trust ring.

[0050] It is understood that the MagicLink module in electronic devices such as watches or mobile phones is used to establish a trust loop with other electronic devices. This MagicLink module can have other names, such as the HnNearby module, a trust loop forming module, etc., and this application is not limited in this regard. Furthermore, the MagicLink module is typically a system-level application of the electronic device.

[0051] In scenarios where a trust loop is not established between the phone 101 and the watch 103, the phone 101 can establish a Bluetooth connection with the watch 103 via a fitness app, and the two can communicate via the Bluetooth channel. This solution is called the outgoing end solution. In scenarios where a trust loop is established between the phone 101 and the watch 103, data communication between them is achieved through the MagicLink module. This solution is also called the outgoing end solution.

[0052] The following combination Figure 2This section provides a brief introduction to the outgoing and internal solutions.

[0053] The Health & Fitness app for the Smartphone 101 includes modules such as a Health & Fitness platform, a wearable device connection management middleware (MbbSDK), and a connection service (MbbLink). The Health & Fitness app establishes a Bluetooth connection with the Watch 103's Bluetooth communication module and performs data communication based on Bluetooth. The dependencies and call chain of the output solution are shown below:

[0054] Sports and Health Platform -> MbbSDK -> MbbLink -> Bluetooth communication module of mobile phone 101 -> Bluetooth communication -> Bluetooth communication module of watch 103.

[0055] After the trust loop is established between the phone 101 and the watch 103, the lifecycle of the Bluetooth connection and data path between the watch 103 and the fitness app should be bound to the MagicLink module. To this end, the MagicLink module is also configured with a connection service (MbbLink) to maintain the correct online / offline status and lifecycle of the trust loop devices. Furthermore, the fitness app on the phone 103 and the MagicLink module communicate across processes through a newly constructed module—a proxy service, including the fitness app's proxy service client (MbbClient) and the MagicLink module's proxy service server (MbbServer). The fitness app calls the MagicLink module's connection service through the proxy service and establishes a Bluetooth connection with the watch 103. Thus, the connection between the fitness app and the watch 103 is established with the establishment of the MagicLink module and terminates with the termination of the MagicLink module, satisfying the requirements of the trust loop.

[0056] The dependencies and call chain of the in-client solution are shown below:

[0057] Sports and Health Platform -> MbbSDK -> Proxy Service - Client -> Proxy Service - Server -> MbbLink -> Bluetooth Communication Module of Mobile Phone 101 -> Bluetooth Communication -> Bluetooth Communication Module of Watch 103 -> MagicLink Module of Watch 103.

[0058] Understandable: The MagicLink module in Watch 103 and the MagicLink module in Phone 101 have basically the same architecture and functions. For the sake of simplicity in drawing, Figure 2 The architecture of the MagicLink module in Watch 103 was not shown.

[0059] As can be seen from the above, both the Health app and the MagicLink module include connectivity services, and these two services are essentially identical. Therefore, if a connection service malfunctions due to system vulnerabilities or other reasons, the problem will simultaneously manifest in both the Health app's connectivity service and the MagicLink module's connectivity service; that is, both services will experience the same issue. Naturally, the fix for this problem should be synchronous and universally applicable. For example, both the Health app and the MagicLink module rely on the same functional module (core module) within the connectivity service (MbbLink) and utilize the capabilities provided by the core module. Therefore, problems occurring on the core module are common, and the fix should be synchronous and universally applicable. The core module is typically used for Bluetooth pairing, connection, and data transmission.

[0060] To fix the connectivity service issue, the connectivity service (or the same functional module within the connectivity service, such as the core module) in both the Health & Fitness app and the MagicLink module needs to be updated simultaneously to ensure that the fix covers both in-app and outgoing scenarios. However, different independent applications often have different release schedules, making it difficult to synchronize the fixes.

[0061] For example, such as Figure 3 As shown, time points A, B, C, and D represent different moments on the timeline.

[0062] At point A, the Health & Fitness app had an issue, which was introduced by the connectivity service. Therefore, both the Health & Fitness app version 1.0 and the MagicLink module had this problem, and the connectivity service in both the Health & Fitness app and the MagicLink module needed to be fixed and updated.

[0063] At point B, the Sports & Health APP's version update was slightly faster than the MagicLink module's. Version V2.0 updated the connection service and fixed the issue in the outgoing scenario, but the MagicLink module was not updated at this time and remained at version V1.0, so the issue still existed in the in-app scenario.

[0064] At point C, the phone underwent an upgrade, updating the MagicLink module to V2.0. However, the connection service issue was not fixed, so the connection service in the V2.0 version of the MagicLink module still had problems. Therefore, even though the MagicLink module was updated, there were still issues in the in-app scenarios.

[0065] At point D, the phone 101 underwent another upgrade, updating the MagicLink module to V3.0, which finally resolved the connection service issue.

[0066] To address the aforementioned issues, this application provides an application update method that enables synchronized updates of the same functional modules across multiple different applications. This avoids situations where, for example, the update schedules of a fitness and health app and the MagicLink module are inconsistent, preventing synchronized updates of the same functional module.

[0067] In some embodiments, "multiple different applications" can refer to multiple applications, including system-level applications and non-system-level applications, or multiple non-system-level applications. The above description is for ease of understanding, using the example of a sports and health app as the first application, the MagicLink module as the second application, and a connection service included in both applications, or a core module within the connection service being a first functional module included in both the first and second applications. However, this does not constitute a limitation on the technical solution of this application.

[0068] In the technical solution provided in this application embodiment, the first functional module that needs to be updated, especially the first functional module that is frequently updated, is independently decoupled, so that its update package (which can be understood as the updated functional module itself) can be transferred between applications as an independent file. When an application performs a version update, the update package is transferred to another application as an independent file through a proxy service via cross-process file transfer to update the first functional module of that application.

[0069] For example, the core module in the connection service is independently decoupled. When the Health app is updated, the core module in the connection service of the Health app is updated synchronously. Through a proxy service, the updated core module is transferred as a separate file to the connection service of the MagicLink module via cross-process file transfer, thus updating and replacing the core module in that connection service. Afterwards, the connection service loads the new core module dynamically. Therefore, even if the MagicLink module is not updated or a new version is released, the problematic module in the MagicLink module can still be updated and replaced, thereby resolving the issue.

[0070] In summary, the technical solution provided in this application involves four stages, as follows:

[0071] 1) Modules are independently decoupled;

[0072] 2) Plugin compilation and packaging;

[0073] 3) Plugin transfer;

[0074] 4) Dynamic loading of plugins.

[0075] The following sections describe each of the four stages separately through different embodiments. To facilitate the introduction of the technical solutions provided in the embodiments of this application, the following descriptions all use updating the core module in the connection service as an example, but this does not constitute a limitation on the application scenarios of the technical solutions of this application.

[0076] Example 1: Module Independent Decoupling Process

[0077] Understandable: Module independence and decoupling are intended to make a functional module an independent whole, without external dependencies. After the functional module is transferred between applications, other applications can directly load and use the functional module.

[0078] Module decoupling offers the following main advantages:

[0079] 1. The higher the degree of module decoupling, the lower the difficulty of module porting and reuse. If the module is completely independent and decoupled, it is equivalent to being ready to use immediately without the need to introduce other dependencies.

[0080] 2. The higher the degree of module decoupling, the smaller the packaged plugin file will be, which is more conducive to transmission.

[0081] In some embodiments, a functional module that can be independently decoupled should be a functional module that is frequently called by the operating system and has small file resources. Frequent calling can be understood as the frequency with which the functional module is called by the operating system when the electronic device runs the application to which the functional module belongs, exceeding a threshold value, which can be a set value.

[0082] In some cases, during the operation of a functional module, it needs to utilize the capabilities of other functional modules, i.e., the results of those other functional modules. To distinguish between these functional modules, the running functional module will be referred to as the first type of functional module, and the other functional modules whose capabilities are used by it will be referred to as the second type of functional module. However, this does not constitute a restriction on the functional modules. The first type of functional module using the capabilities of the second type of functional module can also be understood as the first type of functional module depending on the second type of functional module.

[0083] In some scenarios, the first and second functional modules do not belong to the same application. The second functional module can be considered unique to the first functional module. To ensure that the first functional module can operate independently, the first and second functional modules need to be coupled to form a single module. Thus, when the first functional module is running, the second functional module can also be invoked to provide capabilities to the first functional module. In this scenario, the second functional module may be called infrequently by the first functional module, or the second functional module may be a large static resource (meaning it consumes a lot of resources), but in either case, the second functional module needs to form a single module with the first functional module.

[0084] In other scenarios, the first and second functional modules belong to the same application, or even the same module within the same application. Furthermore, the second functional module is a common module shared by multiple applications. During application runtime, both the first and second functional modules can be invoked and executed, and the results of the second functional module can be provided to the first functional module. In this scenario, the first and second functional modules are typically not coupled into a single module.

[0085] In other scenarios, the first and second functional modules belong to the same application, or even the same module within the same application. However, the second functional module is not a common module shared by multiple applications; that is, some applications include this module, while others do not. During application runtime, both the first and second functional modules can be invoked and executed, and the results of the second functional module can be provided to the first functional module. In this scenario, whether the first and second functional modules are coupled into a single module can be determined using the following criteria:

[0086] 1. Is the second functional module frequently called by the first functional module? 2. Is the second functional module a large static resource?

[0087] The second type of functional module is frequently called by the first type of functional module, and the second type of functional module is a small resource. The second type of functional module can be coupled with the first type of functional module to form a module. The second type of functional module is a large static resource. Usually, the second type of functional module is not coupled with the first type of functional module to ensure the lightweight requirement of the first type of functional module. In this case, the update of the second type of functional module depends on the update of the application.

[0088] The second type of functional module is not frequently called by the first type of functional module, i.e., it is called infrequently. The second type of functional module is also a large static resource. The second type of functional module is not coupled with the first type of functional module to ensure the lightweight requirement of the first type of functional module. If the second type of functional module is called infrequently and is a small resource, it can be either not coupled with the first type of functional module or coupled with the first type of functional module to form a single module.

[0089] By using the above criteria to determine whether the second functional module is coupled with the first functional module to form a single module, the lightweight and small size of the first functional module can be guaranteed.

[0090] It should be noted that the first and second functional modules are not coupled, and the second functional module is not a common module. Therefore, when an application that does not include the second functional module is running, the first functional module of that application needs to call the running result of the second functional module in the application that includes the second functional module through cross-process calls. This cross-process call method can be found in the following text, and will not be explained in detail here.

[0091] For example, the first type of functional module is the core module, which relies on the capabilities of the log printing module at runtime. Therefore, the log printing module is a second type of functional module, and it is included in both the health application (APP) and the MagicLink module, making it a common module. Thus, the log module can form a single module with the core module, or it can be decoupled from the core module. Typically, the log printing module is not coupled to the core module to ensure its lightweight and small size.

[0092] For another example, the first type of functional module is the core module, which requires the device model to run. Therefore, the core module depends on the device's configuration file, which is the second type of functional module. Furthermore, the device's configuration file is not a common module of the health app and the MagicLink module. However, the device's configuration file is called infrequently by the core module; therefore, it does not need to be coupled with the core module to ensure the core module's lightweight and small size.

[0093] It should be noted that the device's configuration file typically belongs only to the Health app and is not included in the MagicLink module. Therefore, the core module within the MagicLink module needs to use a cross-process call to access the device's configuration file in the Health app. This cross-process call method is explained below.

[0094] For another example, the first type of functional module is the core module. During the process of Bluetooth pairing, connection, and data transmission, the core module relies on encryption and decryption algorithms provided by an encryption / decryption algorithm library. This library is not a public module of the health and fitness app. Therefore, as... Figure 4 As shown, the encryption and decryption algorithm library is located in the core module, and is coupled with the core module to form the same module.

[0095] Combination Figure 4 After the core module in the sports and health app is updated, the proxy service - client MbbClient reads the updated core module and communicates with the proxy service - server MbbServer across processes to transmit the updated core module to the proxy service - server MbbServer, which then updates the core module in the MagicLink module. The core module in the MagicLink module can also use the encryption and decryption algorithms provided by the encryption and decryption algorithm library when it runs.

[0096] It should be noted that the design of independently decoupled modules presents an issue where system applications cannot dynamically load .so files. However, if the independently decoupled functional modules are transferred between multiple non-system-level applications, this issue can be disregarded. Similarly, if the independently decoupled functional modules do not involve .so files, this issue can also be disregarded. In other words, in scenarios involving the transfer of independently decoupled functional modules between multiple non-system-level applications, or in scenarios where the independently decoupled functional modules do not involve .so files, the application update scheme may not include... Figure 4 The presented solution.

[0097] Due to operating system security restrictions, system applications located in the phone's system partition cannot directly load .so files from non-system partitions. Furthermore, the system partition is read-only, disallowing modification and writing. This means that, since the MagicLink module is a system application, plugin files synced from the Health app to the MagicLink module cannot be stored in the system partition but must be stored in the data partition. Consequently, system applications cannot load and use the .so files within the plugin files. Plugin files can be understood as compiled versions of updated functional modules.

[0098] In related technologies, within a sports and health app, the core module and the authentication module are coupled, forming a single functional module. The authentication module can call the .so file at runtime, and it is a common module of the sports and health app, not unique to the core module. The .so file can be understood as a functional module. The fact that the authentication module can call the .so file at runtime means that the authentication module needs to utilize the capabilities of the .so file. Therefore, the authentication module belongs to the first type of functional module mentioned above, while the .so file belongs to the second type of functional module mentioned above. The authentication module can be independently decoupled, and the .so file can be coupled to or not coupled with the authentication module.

[0099] Given that the MagicLink module is a system application located in the phone's system partition, updating the core module separately to the MagicLink module will prevent the MagicLink module from dynamically loading the .so file within that plugin file when dynamically loading the corresponding plugin file of the core module. This will affect the operation of the authentication module.

[0100] Therefore, the core module needs to be decoupled from the authentication module; that is, the core module does not include the authentication module. The core module is an independently decoupled functional module, such as... Figure 4 As shown, the Health & Fitness app includes an authentication service—the server-side AuthServer—which is not located in the core module. The MagicLink module also includes an authentication service—the client-side AuthClient—which is also not located in the core module. Furthermore, the MagicLink module cannot dynamically load the .so files within plugin files, but the Health & Fitness app, located in the phone's data partition, can dynamically load .so files. Therefore, the loading of .so files needs to be moved from the MagicLink module to the Health & Fitness app, and the capabilities within the .so files need to be exposed as interfaces for the MagicLink module to call. In other words, the MagicLink module can use cross-process calls to access the .so files in the Health & Fitness app.

[0101] like Figure 4As shown, the .so file is stored in the authentication service - the server-side AuthServer, and is mainly used during the device authentication process. When the MagicLink module needs to use the device authentication capabilities, it calls the authentication interface AuthApi provided by HostManager. The implementation of this interface, AuthImpl B, is injected by AuthClient during process initialization. The interface implementation of AuthImpl B is a cross-process call to the AuthServer interface. Therefore, when the .so file is needed during the device authentication process, it can be called through the above cross-process call chain to access the .so file in the Health & Fitness app.

[0102] By shifting the task of dynamically loading .so files from system applications to non-system applications, and providing the capabilities of .so files to system applications in the form of interface calls, a non-intrusive programming approach is adopted to solve the problem of system applications being unable to dynamically load .so files. This not only normalizes function calls, but also maintains the original security mechanisms of the operating system and increases flexibility.

[0103] In other words, the .so file is not a common module of the health application APP and the MagicLink module, and the .so file is not coupled with the core module. Thus, the MagicLink module can dynamically load the .so file for the system application based on dependency injection and cross-process calls.

[0104] It should also be noted that in the design of independent and decoupled modules, in addition to considering the loading of .so files, the performance of cross-process calls also needs to be considered. For example, Figure 4 The demonstrated cross-process calls to the AuthServer interface will impact performance. Furthermore, the .so file cannot be dynamically loaded by the system application, therefore only supporting [specific methods]. Figure 4 This approach uses dependency injection and cross-process calls to enable dynamic loading of .so files by system applications.

[0105] For the second type of functional module that is not a .so file, namely the second type of functional module that can be dynamically loaded by system applications and non-system applications, the second type of functional module is decoupled from the first type of functional module. It achieves dynamic loading of multiple applications through dependency injection and cross-process calls. In addition to ensuring the lightweight and small size of the first type of functional module, it can also ensure the normalization of function calls and avoid the waste of memory space caused by repeatedly storing the same resource file. However, there will be a problem of reduced running performance caused by cross-process calls.

[0106] The second type of functional module is coupled with the first type of functional module and is dynamically loaded independently by each application in multiple applications. Although this results in a larger size for the first type of functional module, it avoids the performance degradation caused by cross-process calls.

[0107] Therefore, based on the above, in the module independent decoupling process, for non-common modules:

[0108] 1) High frequency, small resources: Plugin file synchronization (i.e., coupling of the first type of functional module and the second type of functional module);

[0109] 2) Low frequency: Dependency injection (i.e., the first functional module and the second functional module are not coupled).

[0110] For frequently called functional modules, especially small resource files, when modules are decoupled independently, functional modules with dependencies should be coupled into a single functional module as much as possible, i.e., placed in the same plugin file. After the plugin file is synchronized, the operating system no longer needs to make any cross-process calls, thus reducing the frequency of cross-process calls.

[0111] For low-frequency function modules, when the modules are independently decoupled, function modules with dependencies are not coupled. Dependency injection and cross-process calls can be used to maintain the normalization of function calls and shield the differences that may be caused by different calling environments.

[0112] For large resource files, when modules are decoupled independently, functional modules with dependencies can also be coupled to form a single functional module, avoiding cross-process transmission and storage by the operating system, thereby improving running performance and storage efficiency.

[0113] Example 2: Plugin compilation and packaging process

[0114] Plugin compilation and packaging can be understood as follows: an application, such as a sports and health app, obtains the update package of a functional module, compiles and packages the update package to obtain a plugin file that the application can recognize and use.

[0115] An update package for a functional module of an application can also be understood as the updated functional module itself. Its bytecode file is a class file. The bytecode file of an AAR file is usually a class file. However, the operating system can only dynamically load dex files. The bytecode file of an APK file is usually a dex file. Therefore, the operating system cannot dynamically load AAR files.

[0116] The following combination Figure 5 Taking the core module in the sports and health app as an example, this article introduces how the sports and health app compiles and packages the updated core module.

[0117] The core module is an AAR file; the sports and health app needs to first compile the AAR file into an APK file. In some embodiments, such as... Figure 5 As shown, the plugin module in MbbLink integrates the core module in AAR format, and then the plugin module is compiled into an APK file, namely plugin.apk. The contents of the APK file are the bytecode of the core module, and the file format is dex file.

[0118] It should be noted that if the application can recognize and use the functional modules of the AAR file, then editing the AAR file into an APK file does not necessarily require execution.

[0119] In some embodiments, to ensure data security of the compiled APK file during cross-process communication, the sports and health app can also encrypt the compiled APK file to obtain an encrypted APK file. In some embodiments, the sports and health app can use methods such as AES-CBC encryption to encrypt the compiled APK file to obtain an encrypted APK file. Both the compiled APK file and the encrypted APK file can be understood as plugin files corresponding to the core module.

[0120] In some embodiments, the MbbLink of the sports and health app is configured with a HostManager, which is used to implement plugin synchronization and dynamic loading. Of course, HostManager is just one example, and the sports and health app can also be configured with other modules that can implement plugin synchronization and dynamic loading; this application does not limit this.

[0121] The health and fitness app receives an encrypted APK file, which can be saved in the HostManager's Assets directory. The HostManager then compiles the APK file to obtain an AAR file, Host.aar. Finally, the HostManager provides Host.aar to the health and fitness app for integration, enabling it to access all the capabilities of the core module.

[0122] In some embodiments, after the Sports & Health App integrates the Host.aar file, the Sports & Health App can compile itself, which includes the Host.aar file, into an APK file for updating the Sports & Health App.

[0123] The reason for storing plugin files in HostManager is that by storing the plugin files in HostManager and then providing HostManager to applications (such as the fitness app) for integration, the main purpose is to encapsulate plugin synchronization and dynamic loading logic within HostManager. If the plugin module is directly provided to the application for integration, the application would need to implement plugin synchronization and dynamic loading operations itself, requiring application modifications. By configuring HostManager in the fitness app, plugin synchronization and dynamic loading operations are handled by HostManager. The fitness app can simply call the easy-to-use interface of HostManager without modification, achieving unified plugin synchronization and dynamic loading operations and shielding the differences between different applications.

[0124] The reason for storing plugin files in the HostManager's Assets directory is that the Assets directory is used to store static files. Files in this directory will not be compiled by the compiler, thus avoiding problems caused by recompiling already compiled plugin files. Furthermore, the application can flexibly access files in this directory during runtime.

[0125] The reason why HostManager compiles the APK file to obtain the AAR file is that the files integrated into the sports and health app need to be AAR files. In other words, the sports and health app can only depend on AAR files, so the APK file needs to be compiled to obtain the AAR file.

[0126] After the Health & Fitness app completes the compilation and packaging of the updated core module, it transfers the compiled and packaged plugin files to the MagicLink module. The following section combines... Figure 7 The plugin transmission process will be described.

[0127] Furthermore, after the Health & Fitness app is updated, in some scenarios, the app needs to control the core module to use its capabilities. For example, the Health & Fitness app may use an outgoing solution to communicate with other devices via Bluetooth. Based on this, the Health & Fitness app can dynamically load the compiled plugin files (…). Figure 5 The core module (either an encrypted APK file or an unencrypted plugin.apk) is used to control the core module's operation and provide its capabilities to the operating system. This process is the same as the plugin dynamic loading process mentioned below, except that this process involves the Health & Fitness app dynamically loading plugin files, while the plugin dynamic loading process mentioned below involves the MagicLink module dynamically loading plugin files.

[0128] The following combination Figure 6This paper introduces the process of dynamically recording plugin files in sports and health apps.

[0129] like Figure 6 As shown, the methods for dynamically loading plugin files include:

[0130] S601, MbbClient sets plugin information for HostManager.

[0131] MbbSDK reads plugin files from the Assets directory of MbbLink's HostManager via an InputStream, and then transmits the plugin files to MbbClient. The plugin file includes a plugin header, which contains plugin information such as version number and path information.

[0132] After obtaining the plugin file, MbbClient can retrieve the plugin information from the plugin file and set the plugin information to HostManager.

[0133] In some embodiments, the plugin file is an encrypted file, such as... Figure 5 In the content, the APK file is encrypted to obtain an encrypted APK file. In this case, the plugin file is also an encrypted file. After MbbClient obtains the plugin file, it can first decrypt the plugin file and then obtain the plugin information in the plugin file. The decryption method should correspond to the encryption method.

[0134] S602, HostManager retrieves path information from plugin information.

[0135] After receiving the plugin information, HostManager can read the path information in the plugin information, such as the path of the plugin's dex file.

[0136] S603, HostManager sets path information for DexLoader.

[0137] HostManager synchronizes the path of the dex file to the dex file parser, DexLoader. DexLoader can then load the dex file from the plugin files based on the path of the dex file.

[0138] S604, the Sports and Health APP notifies MbbClient of its primary ability to call functional modules.

[0139] For example, the functional module in step S604 is the core module, and the first capability can refer to the capabilities provided by the core module, such as Bluetooth pairing capability, Bluetooth connection establishment capability, and data transmission capability based on the Bluetooth channel. During the operation of the sports and health app, there are scenarios where it needs to call the core module to use its provided capabilities, such as the sports and health app calling the core module's Bluetooth pairing capability. In this scenario, the sports and health app notifies MbbClient that it is calling the core module's Bluetooth pairing capability.

[0140] S605, MbbClient is the first ability of the HostManager to notify the Sports and Health App to call the functional modules.

[0141] In the example above, after receiving a notification from the Health app, MbbClient can notify the HostManager that the Health app can use the Bluetooth pairing capability of the core module.

[0142] S606, HostManager obtains an instance of the corresponding class for the first capability from DexLoader.

[0143] After receiving the notification from MbbClient, HostManager can identify the capability of the functional module called by the health application APP as the primary capability, and therefore can obtain an instance of the corresponding class of the primary capability from DexLoader.

[0144] In the example above, HostManager obtains an instance of the class corresponding to the Bluetooth pairing capability of the core module from DexLoader.

[0145] S607, DexLoader loads instances of the corresponding classes of the first capability from the plugin file.

[0146] As can be seen from the aforementioned step S603, DexLoader can load the dex file in the plugin file based on the path of the dex file. Then, DexLoader can convert the dex file into the corresponding class instance, and further obtain the instance of the corresponding class of the first capability.

[0147] In the example above, DexLoader obtains an instance of the class corresponding to the Bluetooth pairing capability from the class instance after the dex file is converted.

[0148] S608, DexLoader returns an instance of the corresponding class of the first capability to the HostManager.

[0149] In the example above, DexLoader returns an instance of the class corresponding to the Bluetooth pairing capability of the core module to the HostManager.

[0150] S609, HostManager uses reflection to dynamically call the methods of the corresponding class instance of the first capability in order to run the class instance corresponding to the first capability.

[0151] Each capability provided by the functional module corresponds to a method of the class instance, which is used to run the class instance corresponding to that capability. Because the Sports & Health App calls the first capability of the functional module, the HostManager dynamically calls the method of the class instance corresponding to the first capability through reflection.

[0152] In the example above, HostManager uses reflection to dynamically call the methods of the corresponding class instance of the Bluetooth pairing capability of the core module. This can be understood as: when a method of a class instance is called by HostManager, it runs the class instance and produces a result, also known as the result of the method call.

[0153] From the above Figure 5 As the content indicates, the plugin file is an APK file. Therefore, HostManager needs to use reflection to call the method of the corresponding class instance of the first capability of the functional module. In some embodiments, the plugin file is in other formats, such as AAR files. In these cases, HostManager can use other methods or directly call the method of the corresponding class instance of the first capability of the functional module.

[0154] S610, HostManager returns the call result to MbbClient.

[0155] S611, MbbClient returns the call result to the sports and health APP.

[0156] HostManager can return the method call result of the class instance corresponding to the first capability to the Sports and Health APP through MbbClient, so that the Sports and Health APP can know the execution result of the first capability.

[0157] In the example above, HostManager returns the result of the Bluetooth pairing capability of the core module to the Sports & Health APP through MbbClient, i.e., whether the pairing was successful or unsuccessful.

[0158] Example 3: Plug-in transmission stage

[0159] This embodiment also uses the example of a sports and health app transferring the plugin file corresponding to the core module to the MagicLink module, but this does not constitute a limitation on the application scenarios of the plugin file transfer method. The plugin file can refer to... Figure 5 The encrypted APK file or the unencrypted plugin.apk file.

[0160] The plugin file is transferred from the Health & Fitness app to the MagicLink module. The plugin transfer process is as follows: Figure 7 As shown, it includes:

[0161] S701 and MbbSDK obtain plugin files from MbbLink.

[0162] In some embodiments, MbbSDK reads plugin files from the Assets directory of MbbLink's HostManager via an InputStream.

[0163] S702, MbbLink returns plugin files to MbbSDK.

[0164] After MbbSDK reads the plugin file, it can read the plugin information from the plugin header of the plugin file. The plugin information includes the version number, path information, etc.

[0165] In some embodiments, the plugin file is an encrypted file, such as... Figure 5 In the content, the APK file is encrypted to obtain an encrypted APK file. In this case, the plugin file is also an encrypted file. After MbbSDK obtains the plugin file, it can decrypt the plugin file and then obtain the plugin information in the plugin file. The decryption method should correspond to the encryption method.

[0166] S703 and MbbSDK bind the proxy service MbbServer through MbbClient.

[0167] MbbSDK sends a message to MbbClient, which instructs MbbClient to bind to MbbServer in the MagicLink module. Based on this message, MbbClient sends a binding request to MbbServer.

[0168] S704, MbbServer returns the binding result to MbbSDK through MbbClient.

[0169] When MbbServer receives a binding request, it accepts the request and obtains the binding result. It then returns the binding result to MbbSDK via MbbClient. This result can indicate whether the binding was successful or unsuccessful.

[0170] In some embodiments, the binding relationship between MbbClient and MbbServer can be broken when the fitness app or MagicLink module is exited.

[0171] S705 and MbbSDK send plugin information, including the version number V1.0, to MbbServer via MbbClient.

[0172] Based on the successful binding result, MbbSDK can send plugin information to MbbServer through MbbClient. This plugin information includes at least the version number V1.0. Of course, version number V1.0 is just an example and does not constitute a limitation on the value of the version number.

[0173] S706, MbbServer queries MbbLink for the version number of the plugin file.

[0174] After receiving version number V1.0, MbbServer can query MbbLink for the version number of the plugin file stored locally. Since the core module resides in MbbLink, MbbServer queries MbbLink for the plugin file's version number.

[0175] If the plugin file to be queried is a plugin file corresponding to other functional modules, MbbServer will query the version number of the plugin file from other functional modules. This step does not constitute a limitation on this case.

[0176] S707, MbbLink returns the plugin file version number V2.0 to MbbServer.

[0177] For example, the plugin file stored locally by the MagicLink module has a version number of V2.0. Of course, version number V2.0 is just an example and does not constitute a limitation on the value of the version number.

[0178] S708 and MbbServer compare version numbers V1.0 and V2.0.

[0179] MbbServer compares version numbers V1.0 and V2.0 to obtain a comparison result. This comparison result is used to indicate whether the plugin files stored in the Sports & Health APP are newer versions compared to the plugin files stored locally by the MagicLink module.

[0180] S709, MbbServer returns the comparison results to MbbSDK through MbbClient.

[0181] When MbbSDK receives the comparison result indicating that V1.0 > V2.0 (meaning the plugin version number on the Health & Fitness app side is higher than that of the MagicLink module), it initiates plugin transfer.

[0182] S710, MbbSDK creates file transfer streams.

[0183] When starting the MbbSDK plugin for file transfer, a file transfer stream is created first.

[0184] S711 and MbbSDK transmit plugin files to MbbClient based on file transfer streams.

[0185] In some embodiments, the plugin file is an encrypted file.

[0186] S712, MbbClient dynamically saves plugin files.

[0187] Through steps S710 and S712, MbbSDK transmits the plugin file to MbbClient and stores it there. In some embodiments, this storage can be understood as temporary storage.

[0188] S713, MbbClient creates file descriptors.

[0189] S714 and MbbClient transfer plugin files to MbbServer based on file descriptors.

[0190] A file descriptor (ParcelFileDescriptor) is a tool for cross-process file transfer. After receiving the plugin file, MbbClient can create this tool and use it to transfer the plugin file to MbbServer, thus synchronizing the plugin file from Fitness and Health to the MagicLink module. Using file descriptors for cross-process plugin file transfer also saves resources and reduces overhead.

[0191] After the aforementioned steps S703 and S704, a cross-process communication link is established between the sports and health APP and the MagicLink module. The messages that can be transmitted by this cross-process communication link are limited, and it usually supports the transmission of small data. File descriptors, on the other hand, can realize the transmission of large data across processes.

[0192] In some embodiments, when the amount of data in the plugin file is small, MbbClient and MbbServer can also transmit the plugin file based on the cross-process communication link without creating a file descriptor.

[0193] S715, MbbServer decryption plugin file.

[0194] In some embodiments, the plugin file is an encrypted file. After receiving the encrypted plugin file, MbbServer can decrypt it and then save the decrypted plugin file through the following step S716.

[0195] S716, MbbServer stores plugin files.

[0196] S717, MbbServer replaces the plugin files stored locally by MbbLink.

[0197] MbbServer replaces the locally stored plugin files with the received plugin files, enabling plugin file updates. In the example, the plugin file is the updated plugin file corresponding to the core module. Replacing the locally stored plugin files with the received plugin files achieves the update of the MagicLink module's core module, ensuring that the same functional modules in multiple applications can be updated synchronously even when the version rhythms of multiple applications are inconsistent.

[0198] Example 4: Dynamic Plugin Loading Process

[0199] After the plugin files corresponding to the core module stored in the MagicLink module are replaced, the MagicLink module can dynamically load the compiled plugin files to control the core module's operation and provide its own capabilities to the operating system. For example, the MagicLink module can establish a trust loop with other devices through an in-device solution and conduct data communication based on the trust loop.

[0200] The following combination Figure 8 This section introduces the process of dynamically recording plugin files in the MagicLink module.

[0201] like Figure 8 As shown, the methods for dynamically loading plugin files include:

[0202] S801 and MbbServer set plugin information for HostManager.

[0203] As mentioned above Figure 2 The content, MbbServer, is a functional module of the MagicLink module. After a plugin file stored locally by MbbLink is replaced, MbbServer can also obtain the replaced plugin file. The plugin file includes a plugin header, which contains plugin information such as version number and path information.

[0204] After obtaining the plugin file, MbbServer can retrieve the plugin information from the plugin file and set the plugin information to HostManager. HostManager can be understood as a functional module in the MagicLink module.

[0205] S802, HostManager retrieves path information from plugin information.

[0206] After receiving the plugin information, HostManager can read the path information in the plugin information, such as the path of the plugin's dex file.

[0207] S803, HostManager sets path information for DexLoader.

[0208] HostManager synchronizes the path of the dex file to the dex file parser, DexLoader. DexLoader can load the dex file from the plugin files based on the path of the dex file.

[0209] The S804 and MagicLink modules notify MbbServer of their primary ability to call functional modules.

[0210] For example, the functional module in step S804 is the core module, and the first capability can refer to the capabilities provided by the core module, such as Bluetooth pairing capability, Bluetooth connection establishment capability, and data transmission capability based on the Bluetooth channel. During the operation of the MagicLink module, there are scenarios where it needs to call the core module to use its provided capabilities, such as the MagicLink module calling the core module's Bluetooth pairing capability. In this scenario, the MagicLink module notifies the MbbServer that it is calling the core module's Bluetooth pairing capability.

[0211] S805, MbbServer, is the first ability of the HostManagerMagicLink module to call functional modules.

[0212] In the example above, after receiving the notification from the MagicLink module, MbbServer can notify the HostManager that the MagicLink module can invoke the Bluetooth pairing capability of the core module.

[0213] S808, HostManager obtains an instance of the corresponding class for the first capability from DexLoader.

[0214] After receiving the notification from MbbServer, HostManager can identify the capability of the functional module called by the health application APP as the primary capability, and therefore can obtain an instance of the corresponding class of the primary capability from DexLoader.

[0215] In the example above, HostManager obtains an instance of the class corresponding to the Bluetooth pairing capability of the core module from DexLoader.

[0216] S807, DexLoader loads instances of the corresponding classes of the first capability from the plugin file.

[0217] As can be seen from the aforementioned step S803, DexLoader can load the dex file in the plugin file based on the path of the dex file. Then, DexLoader can convert the dex file into the corresponding class instance, and further obtain the instance of the corresponding class of the first capability.

[0218] In the example above, DexLoader obtains an instance of the class corresponding to the Bluetooth pairing capability from the class instance after the dex file is converted.

[0219] S808, DexLoader returns an instance of the corresponding class of the first capability to HostManager.

[0220] In the example above, DexLoader returns an instance of the class corresponding to the Bluetooth pairing capability of the core module to the HostManager.

[0221] S809 and HostManager use reflection to dynamically call the methods of the corresponding class instance of the first capability in order to run the class instance corresponding to the first capability.

[0222] Each capability provided by the functional module corresponds to a method of the class instance, which is used to run the class instance corresponding to that capability. Because the MagicLink module calls the first capability of the functional module, the HostManager dynamically calls the method of the class instance corresponding to the first capability through reflection.

[0223] In the example above, HostManager uses reflection to dynamically call the methods of the corresponding class instance of the Bluetooth pairing capability of the core module. This can be understood as: when a method of a class instance is called by HostManager, it runs the class instance and produces a result, also known as the result of the method call.

[0224] S810, HostManager returns the call result to MbbServer.

[0225] S811, MbbServer returns the call result to the MagicLink module.

[0226] HostManager can return the method call results of the class instance corresponding to the first capability to the MagicLink module through MbbServer, so that the MagicLink module can know the execution result of the first capability.

[0227] In the example above, HostManager returns the result of the Bluetooth pairing capability of the core module to the MagicLink module through MbbServer, i.e., whether the pairing was successful or unsuccessful.

[0228] It should also be noted that, Figure 8 The demonstrated example uses the MagicLink module to dynamically load the plugin file corresponding to the core module, and does not involve the system application being unable to load the .so file in the plugin file.

[0229] The authentication module in the sports and health app is decoupled independently. Even if the .so file and the authentication module are coupled, the aforementioned correspondence can be used to achieve this. Figure 5 and Figure 7 In the updated authentication module's corresponding plugin file, when transferred to the MagicLink module, the MagicLink module is unable to load the .so file within the plugin file. When the MagicLink module executes step S804 to call the authentication module's capability (referred to as the second capability), it needs to use... Figure 4 The method of presentation involves dynamically loading the .so file in the authentication service - AuthServer - through dependency injection and cross-process calls, and obtaining an instance of the class corresponding to the second capability from the .so file.

[0230] Another embodiment of this application also provides an electronic device that can execute the application update method provided in the foregoing embodiments. Taking a mobile phone as an example, Figure 9 An example of the composition of an electronic device provided in this application embodiment.

[0231] like Figure 9 As shown, the electronic device may include a processor 910, an internal memory 920, and a display screen 930, etc.

[0232] It is understood that the structures illustrated in this embodiment do not constitute a specific limitation on the electronic device. The electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of both.

[0233] Processor 910 may include one or more processing units; for example, processor 110 may include an application processor (AP). Processor 110 may also include memory for storing instructions and data.

[0234] Internal memory 120 can be used to store computer executable program code, which includes instructions.

[0235] In some embodiments, internal memory 120 stores instructions for updating methods of the application. Processor 110 can execute the instructions stored in internal memory 120 to perform... Figures 4 to 8 The technical solutions on display.

[0236] Electronic devices Figure 9 The hardware components on display also run an operating system. For example... operating system, operating system, Operating system, etc. Applications such as fitness tracking and MagicLink modules can be installed and run on the operating system.

[0237] Another embodiment of this application provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform one or more steps of any of the above methods.

[0238] Computer-readable storage media can be non-transitory computer-readable storage media, such as read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage devices.

[0239] Another embodiment of this application provides a computer program product containing instructions. When the computer program product is run on a computer or processor, it causes the computer or processor to perform one or more steps of any of the methods described above.

Claims

1. An update method of an application, characterized by, The invention pertains to an electronic device, which includes a first application and a second application. Both the first and second applications include a first functional module. The plugin file corresponding to the first functional module is decoupled from the installation package file corresponding to the first application and from the installation package file corresponding to the second application. The plugin file corresponding to the first functional module is used to update the first functional module. The installation package file corresponding to the first application is used to update the first application. The installation package file corresponding to the second application is used to update the second application. The application update method includes: When the first functional module of the first application is updated, the electronic device obtains the plugin file corresponding to the first functional module of the first application, and transmits the plugin file corresponding to the first functional module of the first application to the second application based on the cross-process file transfer method, and replaces the plugin file corresponding to the first functional module stored in the second application. When the electronic device runs the first functional module of the second application to use the second capability of the first functional module of the second application, the electronic device calls the second interface through the first interface in the manner of cross-process calling interface, and obtains an instance of the corresponding class of the second capability from the plug-in file corresponding to the first functional module of the first application through the second interface. The first interface is an interface provided by the first functional module of the second application, and the second interface is an interface provided by the first functional module of the first application. The electronic device uses reflection to call methods of instances of the corresponding class of the second capability to run instances of the second capability.

2. The method of claim 1, wherein, The electronic device updates the first functional module of the first application in the following ways: The electronic device acquires the updated first functional module of the first application; The electronic device compiles the updated first functional module of the first application to obtain a plugin file corresponding to the first functional module of the first application, and obtains an installation package file corresponding to the first application based on the plugin file corresponding to the first functional module of the first application. The electronic device updates the first application based on the installation package file corresponding to the first application.

3. The method of claim 2, wherein, The plugin file corresponding to the first functional module of the first application compiled by the electronic device is stored in a preset directory, and the files stored in the preset directory are not recompiled by the electronic device. The process of the electronic device acquiring the plugin file corresponding to the first functional module of the first application includes: the electronic device acquiring the plugin file corresponding to the first functional module of the first application in the preset directory.

4. The method according to claim 2, characterized in that, The electronic device compiles the updated first functional module of the first application to obtain a plugin file corresponding to the first functional module of the first application, including: The electronic device compiles the updated first functional module of the first application to obtain a plugin file corresponding to the first functional module of the first application whose bytecode is of the first type. The bytecode of the updated first functional module of the first application is of the second type. The operating system of the electronic device supports recognizing the first type of file but does not support recognizing the second type of file.

5. The method according to claim 2, characterized in that, After updating the first application based on the installation package file corresponding to the first application, the electronic device further includes: When the electronic device runs the first functional module of the first application to use the first capability of the first functional module, the electronic device obtains an instance of the corresponding class of the first capability, and, based on reflection, calls the method of the instance of the corresponding class of the first capability to run the instance of the corresponding class of the first capability, wherein the instance of the corresponding class of the first capability is loaded from the plugin file corresponding to the first functional module of the first application.

6. The method according to claim 1, characterized in that, The electronic device transmits the plugin file corresponding to the first functional module of the first application to the second application based on a cross-process file transfer method, including: The electronic device transmits the plugin file corresponding to the first functional module of the first application to the second application using a file descriptor based on cross-process file transfer.

7. The method according to any one of claims 1 to 6, characterized in that, The first functional module refers to the module that is called by the electronic device more frequently than a threshold when the first or second application is running.

8. The method according to claim 7, characterized in that, The first functional module includes a second functional module, which is dependent on the first functional module. When the first functional module is running, the second functional module is called more frequently than a threshold.

9. An electronic device, characterized in that, include: One or more processors, memory, and a display screen; The memory and the display screen are coupled to the one or more processors, the memory being used to store computer program code including computer instructions, wherein when the one or more processors execute the computer instructions, the electronic device performs the application update method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, Used to store computer programs, which, when executed, are specifically used to implement the update method of the application as described in any one of claims 1 to 8.

11. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the application update method as described in any one of claims 1 to 8.

Images