Application updating method, electronic equipment, readable medium and program product

Abstract

The invention provides an application updating method, an electronic device comprises a first application and a second application, the first application and the second application each comprise a first function module, and 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. The method comprises the steps that when a first function module of a first application is updated, the electronic equipment obtains a plug-in file corresponding to the first function module of the first application, and based on the plug-in file corresponding to the first function module of the first application, a first function module of a second application is updated, in this way, synchronous updating of the first function modules of the first application and the second application is achieved, and the first function modules in the two applications can be synchronously modified.

Description

Technical Field

[0001] The present application relates to the field of software update technology, and in particular to an application update method, electronic device, computer program product, and computer-readable storage medium. Background Art

[0002] Multiple applications on an electronic device may include functional modules with the same functionality. However, due to inconsistent version update schedules across different applications, these functional modules cannot be updated synchronously. In particular, if a problem with a functional module occurs, the inconsistent version schedules across multiple applications mean that the problem cannot be fixed simultaneously.

[0003] For example, an electronic device includes a first application and a second application, both of which include a first functional module. A problem with the first functional module causes both the first and second applications to malfunction during operation. The first application is updated, but the second application is not. The problem with the first functional module of the first application is fixed, allowing the first application to operate normally. However, the problem with the first functional module of the second application remains unfixed, preventing the second application from operating normally. Summary of the Invention

[0004] The present application provides an application update method, electronic device, computer program product, and computer-readable storage medium, which can realize the synchronous update of functional modules shared by multiple applications.

[0005] In order to achieve the above objectives, this application provides the following technical solutions:

[0006] In the first aspect, the present application provides an update method for an application applied to an electronic device, the electronic device including a first application and a second application, the first application and the second application both including 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 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 application update method including: 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] It can be seen from the above content that: when the first functional module of the first application is updated, that is, 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 plug-in file corresponding to the first functional module of the first application, and based on the plug-in file, update the first functional module of the second application. In this way, the synchronous update of the first functional modules of the first application and the second application is achieved, and the problems of the first functional modules in the two applications can be modified synchronously.

[0008] In some embodiments, the first application is typically a non-system-level application, and the second application is typically a system-level application. 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 not coupled with the installation package file corresponding to the second application, indicating that the first functional module is an independent and decoupled functional module.

[0009] Based on the first aspect, in one possible implementation, the way in which an electronic device updates a first functional module of a first application includes: the electronic device obtains 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 plug-in file corresponding to the first functional module of the first application, and based on the plug-in file corresponding to the first functional module of the first application, obtains an installation package file corresponding to the first application; the electronic device updates the first application based on the installation package file corresponding to the first application, so as to update the first application through the installation package file corresponding to the first application and thereby update the first functional module of 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 obtains the plug-in file corresponding to the first functional module of the first application, including: the electronic device obtains the plug-in file corresponding to the first functional module of the first application in the preset directory.

[0011] In some embodiments, the preset directory is the Assets directory of the HostManager. Files in this directory will not be compiled by the compiler, so as to avoid problems caused by recompiling already compiled plug-in 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 plug-in 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 plug-in file corresponding to the first functional module of the first application whose bytecode is a first-category file, the bytecode of the updated first functional module of the first application is a second-category file, and the operating system of the electronic device supports recognition of the first-category file but does not support recognition of the second-category file. In some embodiments, the first-category file is a dex file, and the second-category 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 plug-in file corresponding to the first application and the installation package file corresponding to the first application, it also 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 the reflection mechanism, calls the method of the capability 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 plug-in 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 based on a cross-process file transfer method, 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 a 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 a cross-process file transfer method, which can save resources and reduce overhead.

[0016] Based on the first aspect, in a possible implementation, it also 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 calls the method of the capability of the corresponding class of the second capability based on the reflection mechanism to run the instance of the corresponding class of the second capability.

[0017] Based on the first aspect, in one possible implementation, the electronic device obtains an instance of a corresponding class of the second capability from a plug-in file corresponding to a first functional module of the first application, including: the electronic device calls a second interface through a first interface in a cross-process calling interface manner, and obtains an instance of a corresponding class of the second capability from a plug-in file corresponding to the first functional module of the first application through the second interface, the first interface being an interface provided by the first functional module of the second application, and the second interface being 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 at a frequency greater than a threshold when the first application or the second application is running. The frequently called first functional module is independently decoupled, ensuring that the first functional module is ready for immediate use 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 runs, the frequency of calling the second functional module is greater than a threshold.

[0020] In some embodiments, the second functional module does not belong to the common module of multiple applications, that is, the first application includes the second functional module, but the second application does not include the second functional module. In addition, the second functional module is called frequently, which means that the second functional module belongs to high-frequency calls. In the scenario where the second functional module does not belong to the common module, the first functional module includes the second functional module, that is, the first functional module and the second functional module are coupled. In this way, after the electronic device updates the first functional module of the second application based on the plug-in file corresponding to the first functional module, the second application also includes and updates the second functional module, which can ensure that the second functional module provides dependency to the first functional module. In the second aspect, the present application provides an electronic device, including: one or more processors, a memory and a display screen; the memory and the display screen are coupled to one or more processors, the memory is used to store computer program code, the computer program code includes 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] In a third aspect, the present application provides a computer-readable storage medium for storing a computer program, which, when executed, is specifically used to implement the application update method as described in any one of the first aspects.

[0022] In a fourth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the application update method as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A schematic diagram of establishing a trust ring for multiple electronic devices according to an embodiment of the present application;

[0024] Figure 2 A schematic diagram of modules involved in outbound and inbound scenarios provided in an embodiment of the present application;

[0025] Figure 3 This is a diagram showing that the inconsistent update rhythms of the Sports Health App and MagicLink module caused functional module issues to not be fixed synchronously;

[0026] Figure 4 A diagram showing the calling of the functional modules provided in the embodiment of the present application;

[0027] Figure 5 A diagram showing the compilation and packaging of the plug-in provided in the embodiment of the present application;

[0028] Figure 6 A flowchart of loading a plug-in file for the sports health APP provided in an embodiment of the present application;

[0029] Figure 7 A flowchart of transferring plug-in files between applications provided in an embodiment of the present application;

[0030] Figure 8 A flowchart of the MagicLink module loading a plug-in file provided in an embodiment of the present application;

[0031] Figure 9 This is a hardware structure diagram of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. The terms used in the following embodiments are only for the purpose of describing specific embodiments and are not intended to be limiting of the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include expressions such as "one or more", unless there is a clear contrary indication in the context. It should also be understood that in the embodiments of the present application, "one or more" refers to one, two or more; "and / or" describes the association relationship of associated objects, indicating that three relationships may exist; for example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship.

[0033] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in 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 "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0034] The "multiple" involved in the embodiments of the present application means greater than or equal to two. It should be noted that in the description of the embodiments of the present application, the words "first" and "second" are only used for the purpose of distinguishing the description and cannot be understood as indicating or implying relative importance or order.

[0035] Two or more electronic devices establish a trust relationship through trusted authentication, forming a trust loop.

[0036] Taking watches as an example, watches and other electronic devices typically establish a trust relationship using far-field communication (e.g., mobile networks), forming a trust loop. This trust loop is called a far-field trust loop, which requires the watch to support the activation of an eSim card. To enable watches and other electronic devices without eSim cards to form a trust loop, a near-field trust loop solution is proposed, as follows:

[0037] For example, a mobile phone equipped with a sports health app can establish a Bluetooth connection with the watch through the app. Once the Bluetooth connection is established, the watch can automatically or manually log in to the user's account. By logging into the same account on both the watch and phone, the two form a trust loop known as a near-field trust loop. This means that electronic devices using the same account trust each other.

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

[0039] Taking mobile phone 103 and mobile phone 101 as an example, the process of forming a near-field trust loop between a watch and other electronic devices can be as follows:

[0040] 1) Discovering devices

[0041] The mobile phone 101 starts the sports health APP, clicks Add Device on the device page of the APP, and discovers nearby Bluetooth devices through Bluetooth scanning, such as the watch 103.

[0042] 2) Pairing and connection

[0043] After the mobile phone 101 discovers the watch 103, under the user's operation, the mobile phone 101 and the watch 103 are paired and connected via Bluetooth.

[0044] 3) Device authentication

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

[0046] 4) Account login

[0047] After the legitimacy authentication is successful, the mobile phone 101 synchronizes the account of the mobile phone 101 to the watch 103 based on the sports health APP, and the watch 103 logs in the account.

[0048] 5) Join the trust circle

[0049] After completing the first four steps, the Sports Health APP notifies the MagicLink module of the mobile phone 101 of the device information of the watch 103 (such as device model, SN, MAC address). The MagicLink module of the mobile phone 101 communicates with the MagicLink module of the watch 103 through the Bluetooth channel established by the Sports Health APP and the watch 103, and performs ring-entry related operations, including authentication, device registration on the cloud, etc. After the ring-entry operation is completed, the watch 103 and the mobile phone form a near-field trust ring, or it is called the watch 103 joining the trust ring.

[0050] It is understood that the MagicLink module of an electronic device such as a watch or mobile phone is used to complete the service of forming a trust ring with other electronic devices. The MagicLink module can be called by other names, such as HnNearby module, trust ring formation module, etc., and this application does not limit this. In addition, the MagicLink module is generally a system-level application of the electronic device.

[0051] In scenarios where the phone 101 and watch 103 do not form a trust loop, the phone 101 can establish a Bluetooth connection with the watch 103 using the Sports Health app. The phone 101 and watch 103 can then communicate data over the Bluetooth channel. This solution is called an outbound solution. In scenarios where the phone 101 and watch 103 form a trust loop, data communication between the phone 101 and watch 103 is accomplished via the MagicLink module. This solution is called an outbound solution.

[0052] The following combination Figure 2, briefly introduce the outbound solution and the inbound solution.

[0053] The sports health app on mobile phone 101 includes modules such as the sports health middleware, wearable device connection management middleware (MbbSDK), and connection service (MbbLink). The sports health app establishes a Bluetooth connection with the Bluetooth communication module of watch 103 and performs data communication based on Bluetooth communication. The dependency relationship and call chain of the output solution are as follows:

[0054] Sports and health middle platform -> MbbSDK -> MbbLink -> Bluetooth communication module of mobile phone 101 -> Bluetooth communication -> Bluetooth communication module of watch 103.

[0055] After the mobile phone 101 and the watch 103 form a trust loop, the life cycle of the Bluetooth connection and data path between the watch 103 and the sports health 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 and offline status and life cycle of the trust loop device. In addition, the sports health APP of the mobile phone 103 and the MagicLink module communicate across processes through a newly constructed module - that is, a proxy service, including the proxy service-client (MbbClient) of the sports health APP and the proxy service-server (MbbServer) of the MagicLink module. The sports health APP calls the connection service of the MagicLink module through the proxy service and establishes a Bluetooth connection with the watch 103. As a result, the connection between the sports health APP and the watch 103 is established with the establishment of the MagicLink module and disappears with the disappearance of the MagicLink module, meeting the requirements of the trust loop.

[0056] The dependencies and call chains of the on-device solution are as follows:

[0057] Sports and health middle 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] It can be understood that the architecture of the MagicLink module of the watch 103 and the MagicLink module of the mobile phone 101 are basically the same, and the functions are basically the same. For the sake of simplicity, Figure 2 The architecture of the MagicLink module of watch 103 is not shown.

[0059] It can be seen from the above content that both the Sports Health APP and the MagicLink module include connection services, and there is basically no difference between the two connection services. Therefore, if there is a problem with the connection service due to system vulnerabilities or other reasons, the problem will be simultaneously presented to the connection service of the Sports Health APP and the connection service of the MagicLink module, that is, the connection service of the Sports Health APP and the connection service of the MagicLink module will have the same problem simultaneously. Of course, the fix for this problem should be synchronous and universal. For example, both the Sports Health APP and the MagicLink module rely on the same functional module (core module) in the connection service (MbbLink), and both use the capabilities provided by the core module. Therefore, the problems that occur in the core module are common, and the fix for this problem should be synchronous and universal. The core module is usually used to implement Bluetooth pairing, connection, data transmission, etc.

[0060] To fix connection service issues, both the Health app and the MagicLink module's connection service (or the same functional module within the connection service, such as the core module) need to be updated simultaneously to ensure that the fix covers both on-device and off-device scenarios. However, the release cadence of different independent applications is often inconsistent, making it difficult to synchronize fixes.

[0061] For example, Figure 3 As shown, time point A, time point B, time point C and time point D are different moments on the time axis.

[0062] At time point A, there was a problem with the Sports Health App, and the problem was introduced by the connection service. Therefore, this problem existed in both the V1.0 version of the Sports Health App and the MagicLink module, so the connection services in both the Sports Health App and the MagicLink module needed to be repaired and updated.

[0063] At time point B, the version pace of the Sports Health App was slightly faster than that of the MagicLink module. The connection service was updated in version V2.0, and the problem in the outbound scenario was fixed. However, the MagicLink module was not updated at this time and the version was still V1.0. The problem still existed in the inbound scenario.

[0064] At time point C, mobile phone 101 was upgraded and updated to the MagicLink module V2.0, but the connection service problem was not fixed. Therefore, the connection service in the MagicLink module of version V2.0 still had problems. Therefore, even if the MagicLink module was updated, there were still problems with the end scene.

[0065] At time point D, mobile phone 101 was upgraded again, updating the MagicLink module V3.0, and the problem of connecting to the service was completely solved.

[0066] To address the above issues, an embodiment of the present application provides an application update method that can achieve synchronous updates of the same functional modules of multiple different applications, so as to avoid, for example, inconsistent version update rhythms of the sports health APP and the MagicLink module, and the inability to synchronize updates of the same functional module.

[0067] In some embodiments, multiple different applications may refer to: multiple applications including system-level applications and non-system-level applications, or multiple non-system-level applications. The above content is for the convenience of understanding, taking the Sports Health App as the first application, the MagicLink module as the second application, and the connection service included in both applications, or the core module in the connection service as the first functional module included in both the first application and the second application as an example for illustration, but this does not constitute a limitation on the technical solution of this application.

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

[0069] For example, the core module in the connection service is independently decoupled. When the Sports Health App is updated, the core module in the connection service in the Sports Health App will be updated synchronously. The updated core module is transferred to the connection service of the MagicLink module as an independent file through the proxy service through cross-process file transfer, and the core module in the connection service is updated and replaced. After that, the connection service loads the new core module through dynamic loading. Therefore, even if the MagicLink module is not updated and a new version is not released, the problem module in the MagicLink module can be updated and replaced, thereby solving the problem.

[0070] In summary, the technical solution provided in the embodiment of this application involves four aspects:

[0071] 1) Modules are independently decoupled;

[0072] 2) Plug-in compilation and packaging;

[0073] 3) Plug-in transmission;

[0074] 4) Dynamic loading of plug-ins.

[0075] The following describes the four steps separately through different embodiments. To facilitate the introduction of the technical solutions provided by the embodiments of this application, the following description uses the updating of 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 link

[0077] It can be understood that independent decoupling of modules is to make the 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] Independent module decoupling has the following main benefits:

[0079] 1. The higher the degree of module decoupling, the easier it is to transplant and reuse the modules. If the modules are completely independent and decoupled, they are ready to use without the need to introduce other dependencies.

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

[0081] In some embodiments, the functional modules that can be independently decoupled should be those that are frequently called by the operating system and do not consume large file resources. Frequent calls can be understood as when the electronic device runs the application to which the functional module belongs, and the frequency of the operating system calling the functional module exceeds a threshold, which can be a set value.

[0082] In some cases, during the operation of a functional module, it requires the capabilities of other functional modules, that is, the operating results of other functional modules. To distinguish functional modules, the operating functional module is referred to as the first functional module, and the other functional modules whose capabilities are used by the functional module are referred to as the second functional module. This does not constitute a restriction on the functional modules. When a first functional module uses the capabilities of a second functional module, it can also be understood that the first functional module depends on the second functional module.

[0083] In some scenarios, the first and second functional modules do not belong to the same application, and the second functional module can be considered unique to the first functional module. In order to ensure that the first functional module can run independently, the first and second functional modules need to be coupled to form a single module. In this way, when the first functional module is running, the second functional module can also be called to run 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 (which can be understood as the second functional module occupying more resources), but the second functional module must 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. The second functional module is a common module for multiple applications. When the application is running, both the first and second functional modules can be called and run, and the results of the second functional module's execution 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. This means that some applications include the module, but others do not. When the application is running, both the first and second functional modules can be called and run, and the results of the second functional module's execution can be provided to the first functional module. In this scenario, whether the first and second functional modules are coupled into one module can be determined using the following criteria:

[0086] 1. Whether the second functional module is frequently called by the first functional module; 2. Whether the second functional module is a large static resource.

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

[0088] The second functional module is not frequently called by the first functional module, that is, it is called infrequently. The second functional module is also a large static resource and is not coupled with the first functional module to ensure the first functional module's lightweight requirements. The second functional module is called infrequently and is a small resource. The second functional module can be uncoupled from the first functional module or coupled with the first functional module to form a single module.

[0089] By using the above standards to determine whether the second functional module is coupled with the first functional module to form a module, the first functional module can be ensured to be lightweight and small in size.

[0090] It should be noted that the first functional module and the second functional module 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 the application needs to call the running result of the second functional module in the application that includes the second functional module through a cross-process call. The cross-process call method can be found in the following content and will not be explained in detail here.

[0091] For example, the first functional module is the core module, which relies on the capabilities of the log printing module during operation. That is, the log printing module is the second functional module, and the log printing module is a module included in both the health application APP and the MagicLink module. That is, the log printing module is a common module. Therefore, the log module can form a module with the core module, or the log module is not coupled with the core module. Typically, the log printing module is not coupled with the core module to ensure the lightweight and small size of the core module.

[0092] For example, the first functional module is the core module. Its operation requires the device model. Therefore, the core module relies on the device configuration file, which is the second functional module. Furthermore, the device configuration file is not a common module between the health app and the MagicLink module. However, the device configuration file is called infrequently by the core module, so it does not need to be coupled with the core module, ensuring the core module's lightweight and compact size.

[0093] It should be noted that the device configuration file is usually only part of the Health app, and the MagicLink module does not include this functional module. Therefore, the core module in the MagicLink module needs to use a cross-process call method to call the device configuration file in the Health app. This cross-process call method is described below.

[0094] For example, the first functional module is the core module. During the operation of the core module to realize Bluetooth pairing, connection, and data transmission, it needs to rely on the encryption and decryption algorithm provided by the encryption and decryption algorithm library, and the encryption and decryption algorithm library does not belong to the public module of the sports health APP. Therefore, 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] Combine Figure 4 After the core module in the Sports Health app is updated, the proxy service client MbbClient reads the updated core module and communicates with the proxy service server MbbServer through cross-process communication to pass the updated core module to the proxy service server MbbServer, which then updates the core module in the MagicLink module. When the core module in the MagicLink module is running, it can also use the encryption and decryption algorithms provided by the encryption and decryption algorithm library.

[0096] It should be noted that in the design of independent decoupling of modules, there is a problem that system applications cannot dynamically load so files. Of course, if the independently decoupled functional modules are transmitted between multiple non-system-level applications, the problem that system applications cannot dynamically load so files can be ignored. If the independently decoupled functional modules do not involve so files, the problem that system applications cannot dynamically load so files can also be ignored. In other words: in scenarios where independently decoupled functional modules are transmitted between multiple non-system-level applications, and independently decoupled functional modules do not involve so files, the application update plan may not include Figure 4 The scheme presented.

[0097] Due to the operating system's security restrictions, system applications located in the system partition of the phone's memory cannot directly load so files located outside the system partition. Furthermore, the system partition is read-only, neither modification nor writing is allowed. This means that, because the MagicLink module is a system application, plug-in files synchronized from the Sports Health app to the MagicLink module cannot be saved in the system partition and can only be stored in the data partition of the memory. This prevents system applications from loading and using the so files in the plug-in files. Plugin files can be understood as the compiled files of updated functional modules.

[0098] In the related art, in the sports health APP, the core module and the authentication module have a coupling relationship, and the two are coupled to form a functional module. The authentication module can call the so file when it is running, and the authentication module belongs to the public module of the sports health APP and is not exclusive to the core module. Among them, the so file can be understood as a functional module. The so file can be called when the authentication module is running, which means that the authentication module needs to use the so file when it is running, that is, the authentication module belongs to the first functional module mentioned above, and the so file belongs to the second functional module mentioned above. The authentication module can be independently decoupled, and the so file can be coupled with the authentication module, or not.

[0099] Considering that the MagicLink module is a system application and is located in the system partition of the phone's memory, the core module is updated separately to the MagicLink module. When the MagicLink module dynamically loads the plug-in file corresponding to the core module, it cannot dynamically load the so file in the plug-in file, thus affecting the operation of the authentication module.

[0100] Based on this, the core module needs to be decoupled from the authentication module, that is, the core module does not include the authentication module, and the core module is an independent decoupled functional module, such as Figure 4 As shown, the Sports Health APP includes an authentication service - server AuthServer, which is not located in the core module, and the MagicLink module includes an authentication service - client AuthClient, which is also not located in the core module. In addition, when the MagicLink module dynamically loads the plug-in file, it cannot dynamically load the so file in it. However, the Sports Health APP is located in the data partition of the mobile phone's memory and can dynamically load so files. Therefore, the loading of the so file needs to be transferred from the MagicLink module to the Sports Health APP, and the capabilities in the so file are exposed to the outside in the form of an interface and provided to the MagicLink module for calling. In other words: the MagicLink module can use a cross-process call method to call the so file in the Sports Health APP.

[0101] like Figure 4As shown, the so file is stored in the authentication service (AuthServer) and is primarily used during device authentication. When the MagicLink module needs to use 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 calls the AuthServer interface across processes. Therefore, when the so file is needed during device authentication, it can be called through this cross-process call link to the so file in the Sports Health App.

[0102] By transferring the work of dynamically loading so files from system applications to non-system applications, and providing the capabilities in so files to system applications in the form of interface calls, a non-invasive programming method is used to solve the problem that system applications cannot dynamically load so files. This not only achieves the normalization of function calls, but also maintains the original security mechanism of the operating system and increases flexibility.

[0103] In other words, the so file does not belong to the common module of the health application APP and the MagicLink module, and the so file is not coupled with the core module. In this way, the MagicLink module can dynamically load the so file by the system application based on dependency injection and cross-process calling.

[0104] It should also be noted that in the design of independent decoupling of modules, in addition to considering the problem of so file loading, it is also necessary to consider the performance of cross-process calls. For example, Figure 4 The cross-process call to the AuthServer interface shown will affect performance. Of course, the so file cannot be dynamically loaded due to system application limitations, so only the use of Figure 4 The system application dynamically loads the so file by using dependency injection and cross-process calling.

[0105] For other second-type functional modules that are not so files, that is, second-type functional modules that can be dynamically loaded by system applications and non-system applications, the second-type functional modules are not coupled with the first-type functional modules, and dynamic loading of multiple applications is achieved through dependency injection and cross-process calls. In addition to ensuring the lightweight and small size of the first-type functional modules, it can also ensure the normalization of function calls and avoid the waste of memory space caused by repeated storage of the same resource file. However, there will be a problem of reduced operating performance caused by cross-process calls.

[0106] The second functional module is coupled with the first functional module and is dynamically loaded independently by each application in multiple applications. Although this results in a larger volume of the first functional module, it can avoid the problem of reduced operating performance caused by cross-process calls.

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

[0108] 1) High-frequency, small resources: plug-in file synchronization (i.e., coupling of the first functional module and the second 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 the modules are independently decoupled, functional modules with dependencies should be coupled as much as possible to form one functional module, that is, placed in the same plug-in file. After the plug-in file synchronization is completed, the operating system no longer needs to make any cross-process calls, reducing the frequency of cross-process calls.

[0111] For functional modules that are called infrequently, when the modules are independently decoupled, functional modules with dependencies are not coupled. Through dependency injection and cross-process calls, the normalization of function calls can be maintained to shield the differences that may be caused by different calling environments.

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

[0113] Example 2: Plugin compilation and packaging

[0114] Plug-in compilation and packaging can be understood as: after an application, such as sports and health, obtains an update package of a functional module, it compiles and packages the update package to obtain a plug-in file that the application can recognize and use.

[0115] The update package of 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 Health APP as an example, this article introduces how the Sports Health APP compiles and packages the updated core module.

[0117] The core module is an AAR file, and the sports health APP needs to compile the AAR file into an APK file first. In some embodiments, Figure 5 As shown in the figure, the plugin module in MbbLink integrates the core module in AAR format, and then compiles the plugin module into an APK file, plugin.apk. The content of the APK file is the bytecode of the core module, and the file format is a dex file.

[0118] It should be noted that when the application can recognize and use the functional modules of the AAR file, editing the AAR file into an APK file does not have to be performed.

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

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

[0121] The Sports Health app receives the encrypted APK file and saves it in the HostManager's Assets directory. The HostManager then compiles the APK file to generate an AAR file, Host.aar. The HostManager then integrates Host.aar with the Sports Health app, providing all the core module's capabilities to the app.

[0122] In some embodiments, after the sports health app integrates the Host.aar file, the sports health app may compile itself with the integrated Host.aar file into an APK file to facilitate updating the sports health app.

[0123] The reason for saving plug-in files in HostManager is that after the plug-in files are saved in HostManager, HostManager is provided to applications (such as sports health apps) for integration. This is mainly to encapsulate logic such as plug-in synchronization and dynamic loading in HostManager. If the plug-in module is directly provided to the application for integration, the application needs to implement plug-in synchronization, dynamic loading and other operations on its own, which requires the application to be modified. The sports health app configures HostManager, which implements plug-in synchronization, dynamic loading and other operations. The sports health app can only call the simple and easy-to-use interface of HostManager without making any modifications. It can also implement unified plug-in synchronization, dynamic loading and other operations, 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 are not compiled by the compiler, which prevents 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 health app need to be AAR files. It can also be understood that the sports health app can only rely on AAR files, so the APK file needs to be compiled again to obtain the AAR file.

[0126] After the Sports Health APP completes the compilation and packaging of the updated core module, the Sports Health APP transmits the compiled and packaged plug-in file to the MagicLink module. Figure 7 This section introduces the plug-in transmission process.

[0127] Moreover, after the Sports Health APP is updated, in some scenarios, when the Sports Health APP is running, it is necessary to control the operation of the core module to use the capabilities of the core module, such as the Sports Health APP to achieve Bluetooth communication with other devices through the output solution. Based on this, the Sports Health APP can dynamically load the compiled plug-in file ( Figure 5 The encrypted APK file or unencrypted plugin.apk file in the plugin.apk file is used to control the core module's operation and provide its own capabilities to the operating system. This process is the same as the dynamic plugin loading process described below. The difference is that this process dynamically loads the plugin file for the Sports Health app, while the dynamic plugin loading process described below is for the MagicLink module.

[0128] The following combination Figure 6, introduces the process of dynamic recording plug-in files of sports health APP.

[0129] like Figure 6 As shown, the method of dynamically loading a plug-in file includes:

[0130] S601. MbbClient sets plug-in information to HostManager.

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

[0132] After MbbClient obtains the plug-in file, it can obtain the plug-in information in the plug-in file and set the plug-in information to HostManager.

[0133] In some embodiments, the plug-in 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 plug-in file is the encrypted file. After MbbClient obtains the plug-in file, it can first decrypt the plug-in file and then obtain the plug-in information in the plug-in file. The decryption method should correspond to the encryption method.

[0134] S602. HostManager obtains path information from the plug-in information.

[0135] After receiving the plug-in information, HostManager can read the path information in the plug-in information, such as the path of the dex file of the plug-in file.

[0136] S603. HostManager sets path information to DexLoader.

[0137] HostManager synchronizes the path of the dex file to the dex file parser DexLoader. DexLoader can load the dex file in the plugin file based on the dex file path.

[0138] S604 : The sports health APP notifies the MbbClient of the first capability of calling the functional module.

[0139] For example, the functional module in step S604 is a core module, and the first capability may refer to the capabilities provided by the core module, such as Bluetooth pairing capability, Bluetooth connection establishment capability, and data transmission capability over a Bluetooth channel. During the operation of the Sports Health App, there may be a scenario where it needs to call the core module to use the capabilities it provides. For example, the Sports Health App calls the core module's Bluetooth pairing capability. In this scenario, the Sports Health App notifies the MbbClient that it has called the core module's Bluetooth pairing capability.

[0140] S605 , MbbClient notifies HostManager of the first capability of the sports health APP to call the functional module.

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

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

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

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

[0145] S607 . DexLoader loads an instance of a class corresponding to the first capability from the plug-in file.

[0146] From the aforementioned step S603 , it can be seen that DexLoader can load the dex file in the plug-in file based on the path of the dex file. Afterwards, DexLoader can convert the dex file into a corresponding class instance, and further obtain an instance of the corresponding class of the first capability.

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

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

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

[0150] S609 . HostManager dynamically calls a method of a class instance corresponding to the first capability based on a reflection mechanism to run the class instance corresponding to the first capability.

[0151] Each capability provided by a functional module corresponds to a class instance method, 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 above example, the HostManager uses reflection to dynamically call the method of the class instance corresponding to the Bluetooth pairing capability of the core module. It can be understood that when a class instance method is called by the HostManager, it runs the class instance, and the result of the execution is also called the result of the class instance method call.

[0153] By the aforementioned Figure 5 As can be seen from the content, the plugin file is an APK file, so the HostManager must use reflection to call the method of the class instance corresponding to the first capability of the functional module. In some embodiments, the plugin file is in other formats, such as AAR format. The HostManager can use other methods or directly call the method of the class instance corresponding to 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 health app.

[0156] HostManager may return the call result of the method of the class instance corresponding to the first capability to the sports health APP through MbbClient, so that the sports health APP can learn the execution result of the first capability.

[0157] In the above example, HostManager returns the execution result of the Bluetooth pairing capability of the core module to the sports health app through MbbClient, that is, successful pairing or unsuccessful pairing.

[0158] Example 3: Plug-in transmission

[0159] This embodiment also takes the example of the Sports Health APP transmitting the plug-in file corresponding to the core module to the MagicLink module, but this does not constitute a limitation on the application scenario of the plug-in file transmission method. Figure 5 The encrypted APK file or the unencrypted plugin.apk in .

[0160] Transfer the plug-in file from the Sports Health APP to the MagicLink module. The plug-in transfer process is as follows: Figure 7 As shown, including:

[0161] S701. MbbSDK obtains a plug-in file from MbbLink.

[0162] In some embodiments, MbbSDK reads the plug-in file from the Assets directory of the HostManager of MbbLink through the input stream InputStream.

[0163] S702. MbbLink returns the plug-in file to MbbSDK.

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

[0165] In some embodiments, the plug-in 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 plug-in file is the encrypted file. After MbbSDK obtains the plug-in file, it can decrypt the plug-in file and then obtain the plug-in information in the plug-in file. The decryption method should correspond to the encryption method.

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

[0167] MbbSDK sends a message to MbbClient, which is used to instruct 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] MbbServer receives the binding request, accepts the binding request, obtains the binding result, and returns the binding result to MbbSDK through MbbClient. The binding result can include binding success or binding failure.

[0170] In some embodiments, the binding relationship between MbbClient and MbbServer may be disconnected upon exiting the sports health app or the MagicLink module.

[0171] S705. MbbSDK sends plug-in information, including version number V1.0, to MbbServer through MbbClient.

[0172] Based on the successful binding result, MbbSDK can send plug-in information to MbbServer through MbbClient. The plug-in information includes at least version number V1.0. Of course, version number V1.0 is only 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 plug-in file.

[0174] After receiving version number V1.0, MbbServer can query MbbLink for the version number of the plug-in file stored locally. Of course, the core module is located in MbbLink, so MbbServer queries MbbLink for the version number of the plug-in file.

[0175] If the plug-in file to be queried is a plug-in file corresponding to other functional modules, MbbServer queries the version number of the plug-in file from the other functional modules. This step does not constitute a limitation to this case.

[0176] S707. MbbLink returns the version number V2.0 of the plug-in file to MbbServer.

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

[0178] S708. MbbServer compares version number V1.0 and version number V2.0.

[0179] MbbServer compares version number V1.0 and version number V2.0 to obtain a comparison result, which is used to indicate whether the plug-in file stored in the Sports Health APP is a newer version than the plug-in file stored locally in the MagicLink module.

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

[0181] MbbSDK receives the comparison result, which indicates V1.0>V2.0, that is, the plug-in version number on the sports health app side is higher than the MagicLink module, and then starts the plug-in transmission.

[0182] S710. MbbSDK creates a file transfer stream.

[0183] When MbbSDK starts plug-in transmission, it first creates a file transmission stream.

[0184] S711. MbbSDK transmits the plug-in file to MbbClient based on the file transfer stream.

[0185] In some embodiments, the plug-in file is an encrypted file.

[0186] S712. MbbClient dynamically saves plug-in files.

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

[0188] S713. MbbClient creates a file descriptor.

[0189] S714. MbbClient transmits the plug-in file to MbbServer based on the file descriptor.

[0190] A file descriptor (ParcelFileDescriptor) is a tool used to transfer files across processes. After receiving a plugin file, MbbClient creates this tool and uses it to transfer the plugin file to MbbServer, synchronizing the plugin file from Sports Health to the MagicLink module. Using file descriptors to transfer plugin files across processes also saves resources and reduces overhead.

[0191] After the aforementioned steps S703 and S704, a cross-process communication link is established between the sports health APP and the MagicLink module. The cross-process communication link has limitations on the messages supported for transmission and generally supports the transmission of small data. File descriptors can realize cross-process transmission of large data.

[0192] In some embodiments, in a scenario where the data volume of the plug-in file is not large, MbbClient and MbbServer may also transmit the plug-in file based on an inter-process communication link without creating a file descriptor.

[0193] S715. MbbServer decrypts the plug-in file.

[0194] In some embodiments, the plug-in file is an encrypted file. After receiving the encrypted plug-in file, the MbbServer may decrypt it and then save the decrypted plug-in file in step S716 described below.

[0195] S716. MbbServer saves the plug-in file.

[0196] S717. MbbServer replaces the plug-in files stored locally by MbbLink.

[0197] MbbServer replaces the locally stored plug-in file with the received plug-in file to update the plug-in file. In the example, the plug-in file is the plug-in file corresponding to the updated core module. Replacing the locally stored plug-in file with the received plug-in file implements the update of the core module of the MagicLink module, ensuring that the same functional modules of multiple applications can be updated synchronously even if the version rhythms of multiple applications are inconsistent.

[0198] Example 4: Dynamic loading of plug-ins

[0199] After the plug-in file corresponding to the core module stored in the MagicLink module is replaced, the MagicLink module can dynamically load the compiled plug-in file to control the operation of the core module and provide its own capabilities to the operating system. For example, the MagicLink module can form a trust ring with other devices through the end-to-end solution and conduct data communication based on this trust ring.

[0200] The following combination Figure 8 , introduces the process of dynamically recording plug-in files in the MagicLink module.

[0201] like Figure 8 As shown, the method of dynamically loading a plug-in file includes:

[0202] S801. MbbServer sets plug-in information to HostManager.

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

[0204] After MbbServer obtains the plug-in file, it can obtain the plug-in information in the plug-in file and set the plug-in information to HostManager. HostManager can be understood as a functional module in the MagicLink module.

[0205] S802. HostManager obtains path information from the plug-in information.

[0206] After receiving the plug-in information, HostManager can read the path information in the plug-in information, such as the path of the dex file of the plug-in file.

[0207] S803. HostManager sets path information to DexLoader.

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

[0209] S804. The MagicLink module notifies the MbbServer of its first capability of calling the functional module.

[0210] For example, the functional module in step S804 is the core module, and the first capability may refer to the capabilities provided by the core module, such as Bluetooth pairing capability, Bluetooth connection establishment capability, and data transmission capability over a Bluetooth channel. During the operation of the MagicLink module, there may be a scenario where it needs to call the core module to use the capabilities it provides. For example, the MagicLink module calls the core module's Bluetooth pairing capability. In this scenario, the MagicLink module notifies the MbbServer that it has called the core module's Bluetooth pairing capability.

[0211] S805. MbbServer notifies the HostManagerMagicLink module to call the first capability of the functional module.

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

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

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

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

[0216] S807 . DexLoader loads an instance of a class corresponding to the first capability from the plug-in file.

[0217] From the aforementioned step S803 , it can be seen that DexLoader can load the dex file in the plug-in file based on the path of the dex file. After that, DexLoader can convert the dex file into a corresponding class instance, and further obtain an instance of the corresponding class of the first capability.

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

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

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

[0221] S809. HostManager dynamically calls the method of the class instance corresponding to the first capability based on the reflection mechanism to run the class instance corresponding to the first capability.

[0222] Each capability provided by a functional module corresponds to a class instance method, 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 class instance method corresponding to the first capability through reflection.

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

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

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

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

[0227] In the above example, HostManager returns the execution result of the Bluetooth pairing capability of the core module to the MagicLink module through MbbServer, that is, successful pairing or unsuccessful pairing.

[0228] It should also be noted that Figure 8 The embodiment shown takes the MagicLink module dynamically loading the plug-in file corresponding to the core module as an example, and does not involve the system application being unable to load the so file in the plug-in file.

[0229] Independently decouple the authentication module in the sports health APP. Even if the so file is coupled with the authentication module, the above corresponding Figure 5 and Figure 7 The solution is to transfer the plug-in file corresponding to the updated authentication module to the MagicLink module. The MagicLink module cannot load the so file in the plug-in file. When the MagicLink module executes step S804 to call the capability of the authentication module (called the second capability), it needs to use Figure 4 The display method is to dynamically load the so file in the authentication service-server AuthServer through dependency injection and cross-process calling, and obtain the instance of the class corresponding to the second capability from the so file.

[0230] Another embodiment of the present application further provides an electronic device, which can execute the application update method provided in the above embodiment. Taking a mobile phone as an example, Figure 9 This is an example of the composition of an electronic device provided in an embodiment of the present application.

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

[0232] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device. The electronic device may include more or fewer components than illustrated, or may combine or separate certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0233] The processor 910 may include one or more processing units. For example, the processor 110 may include an application processor (AP), etc. The processor 110 may also be provided with a memory for storing instructions and data.

[0234] The internal memory 120 may be used to store computer executable program codes, where the executable program codes include instructions.

[0235] In some embodiments, the internal memory 120 stores instructions for the update method of the application. The processor 110 can execute the instructions stored in the internal memory 120 to perform Figures 4 to 8 Technical solutions on display.

[0236] Electronic equipment in Figure 9 The hardware components shown also run an operating system. operating system, operating system, Operating system, etc. Applications such as sports health and MagicLink module can be installed and run on the operating system.

[0237] Another embodiment of the present application further provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is executed on a computer or a processor, the computer or processor executes one or more steps in any of the above methods.

[0238] The computer-readable storage medium may be a non-temporary computer-readable storage medium, for example, a non-temporary computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0239] Another embodiment of the present application further provides a computer program product comprising instructions, which, when executed on a computer or processor, causes the computer or processor to execute one or more steps in any of the above methods.

Claims

1. A method for updating an application, characterized in that: Applied to an electronic device, the electronic device includes a first application and a second application, the first application and the second application both include a first functional module, a plug-in file corresponding to the first functional 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, 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 application update method comprising: When the first functional module of the first application is updated, the electronic device obtains a 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.

2. The method according to claim 1, characterized in that The electronic device updates the first functional module of the first application in a manner including: The electronic device obtains 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 plug-in 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 plug-in 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 according to claim 2, characterized in that 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; 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.

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 plug-in file corresponding to the first functional module of the first application, including: The electronic device compiles the first functional module of the updated first application to obtain a plug-in file corresponding to the first functional module of the first application whose bytecode is a first-type file. The bytecode of the first functional module of the updated first application is a second-type file. The operating system of the electronic device supports recognition of the first-type file but does not support recognition of the second-type file.

5. The method according to claim 2, characterized in that After the electronic device updates 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 the reflection mechanism, calls the method of the capability 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 plug-in file corresponding to the first functional module of the first application.

6. The method according to any one of claims 1 to 5, characterized in that The electronic device updating the first functional module of the second application based on the plug-in file corresponding to the first functional module of the first application includes: The electronic device transmits the plug-in file corresponding to the first functional module of the first application to the second application based on a cross-process file transmission method, and replaces the plug-in file corresponding to the first functional module stored in the second application.

7. The method according to claim 6, characterized in that The electronic device transmits the plug-in file corresponding to the first functional module of the first application to the second application based on a cross-process file transmission 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 a cross-process file transmission method.

8. The method according to claim 6, characterized in that Also 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 a class corresponding to the second capability from a plug-in file corresponding to the first functional module of the first application; The electronic device calls a method of the capability of the class corresponding to the second capability based on a reflection mechanism to run an instance of the class corresponding to the second capability.

9. The method according to claim 8, characterized in that The electronic device obtains an instance of a class corresponding to the second capability from a plug-in file corresponding to a first functional module of the first application, including: The electronic device calls the second interface through the first interface in a cross-process calling interface manner, 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.

10. The method according to any one of claims 1 to 9, characterized in that The first functional module refers to a module that is called by the electronic device at a frequency greater than a threshold when the first application or the second application is running.

11. The method according to claim 10, characterized in that 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 frequency of calling the second functional module is greater than a threshold.

12. An electronic device, characterized in that: include: one or more processors, memory, and display screens; The memory and the display screen are coupled to the one or more processors, the memory is used to store computer program code, and the computer program code includes computer instructions. When the one or more processors execute the computer instructions, the electronic device executes the application update method as described in any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that Used to store a computer program, which, when executed, is specifically used to implement the application update method according to any one of claims 1 to 11.

14. A computer program product, characterized in that When the computer program product is run on a computer, the computer is enabled to execute the application updating method according to any one of claims 1 to 11.

Images