Static linking method and related apparatus

Abstract

Provided in the present application are a static linking method and a related apparatus. In the scenario where full-static linking is performed on a third-party component and an operating system on an MCU device, the static linking method provided in the present application isolates the dependency of the third-party component on an actual storage address of a system function in the operating system and the dependency of a system application on an actual storage address of the third-party component by means of a binary difference isolation layer, thus realizing the decoupling between the third-party component and the operating system. The third-party component and the operating system can both be independently updated without affecting each other. Therefore, the updating costs of the third-party component and the operating system can be reduced.

Description

Static linking method and related device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on July 6, 2023, with application number 202310829978.8, and priority to the Chinese patent application entitled “Static Linking Method and Related Devices”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminal technology, and in particular to a static linking method and related devices. Background Art

[0003] The source files of the application need to be compiled and linked to generate executable files for the electronic device to run the application. When using a static library for static linking, the compiler and linker will relocate the symbols in the source file and convert the reference relationship of the symbols into absolute addresses. Therefore, in the final executable file, all symbols such as code and data are mapped and stored to a unique fixed physical address in the memory. There is a strong coupling relationship between the application and the static library (or operating system). When the static library (or operating system) is updated, the function that the application needs to reference in the static library changes, and the source file of the application needs to be recompiled and linked. This results in a high update cost for the static library or operating system.

[0004] Summary of the Invention

[0005] This application provides a static linking method and related apparatus. By introducing a binary difference isolation layer, the dependencies of third-party components on the actual storage addresses of system functions in the operating system, as well as the dependencies of system applications on the actual storage addresses of third-party components, are isolated, thereby decoupling the third-party components from the operating system. Both the third-party components and the operating system can be updated independently without affecting each other. This reduces the update costs of both third-party components and the operating system.

[0006] In a first aspect, the present application provides a static linking method. The method is applied to an electronic device, the electronic device includes a first operating system, and a first storage area corresponding to a first address in the electronic device stores a first call instruction, and the first call instruction is used to call a first system function provided by the first operating system. The electronic device updates the first operating system, and the first operating system is updated by static linking; the electronic device updates the first call instruction in the first storage area to a second call instruction, and the second call instruction is used to call the first system function provided by the updated first operating system; the electronic device runs a first component on the updated first operating system, obtains a second call instruction from the first storage area according to the first address, and executes the second call instruction for the first component to call the first system function.

[0007] The first address may be a fixed address agreed upon in advance by the component provider and the integrator, and is used to store a binary difference isolation layer (or system isolation layer) that encapsulates the first system function. The first call instruction and the second call instruction may both be binary instructions generated by the system isolation layer that encapsulates the first system function after static compilation and linking.

[0008] Before the first operating system is updated, the system isolation layer is compiled and linked together with the first operating system before the update. The system isolation layer can obtain the actual storage address of the first system function in the electronic device that is loaded with the first operating system before the update, and the system isolation layer can be compiled and linked as a first call instruction. After the first operating system is updated, the system isolation layer can be compiled and linked together with the updated first operating system. The system isolation layer can obtain the actual storage address of the first system function in the electronic device that is loaded with the first operating system after the update, and the system isolation layer can be compiled and linked as a second call instruction. Since the actual storage address of the first system function may change before and after the first operating system is updated, the first call instruction and the second call instruction are different.

[0009] The source program of the first component can be statically linked into an executable file according to the first address. The executable file of the first component can include the first address.

[0010] The first component mentioned above may be a third-party component, or may be a system application.

[0011] In some embodiments, the electronic device may store the first operating system in ROM and store the executable file of the above-mentioned first component in Flash. After the electronic device is turned on, the executable file of the first component may be read from Flash to RAM. Therefore, when the electronic device updates the first operating system in ROM, it may not affect the executable file of the first component in Flash and RAM. This can ensure that the first operating system and the first component can be updated independently. In other embodiments, the electronic device may store both the first operating system and the executable file of the first component in ROM. Among them, the storage area can be divided on the ROM. The executable files of the first operating system and the first component can be stored in two independent storage areas in the ROM respectively. When the electronic device re-burns the ROM to update data, it can update all the data on an independent storage area while keeping the data on the other independent storage area unchanged. This can also ensure that the first operating system and the first component can be updated independently.

[0012] It can be seen that regardless of whether the first operating system is updated, the first component can find the system isolation layer that encapsulates the first system function according to a fixed address (such as the first address), thereby using the system isolation layer to call the first system function. When the first operating system is updated, the system isolation layer can perceive the changes in the first operating system on behalf of the component, and encapsulate the updated system functions of the first operating system according to its changes. In this way, the first component may not perceive the changes in the first operating system. When the first operating system is updated, the component may not need to be recompiled and linked. In this way, the first operating system can be updated independently of the component, reducing the update cost of the system.

[0013] In combination with the first aspect, in some embodiments, when the electronic device runs the first component on the first operating system before the update, it obtains the first calling instruction from the first storage area according to the first address, and executes the first calling instruction for the first component to call the first system function.

[0014] It can be seen that before and after the operating system is updated, the storage address of the system isolation layer used to encapsulate the first system function (such as the first call instruction and the second call instruction after the system isolation layer is compiled and linked) remains unchanged. The first component can always find the system isolation layer that encapsulates the first system function according to the fixed address (such as the first address), thereby using the system isolation layer to call the first system function. Therefore, even if the first operating system is updated, the first component does not need to be updated. This can reduce the update cost of the system.

[0015] In conjunction with the first aspect, in some embodiments, the first call instruction includes a storage address of the first system function in the electronic device before the first operating system is updated, and the second call instruction includes a storage address of the first system function in the electronic device after the first operating system is updated. The storage address of the first system function in the electronic device may be located in the ROM of the electronic device.

[0016] In conjunction with the first aspect, in some embodiments, the first component stored in the electronic device remains unchanged before and after the first operating system is updated. Specifically, the first component remaining unchanged may mean that the executable file of the first component stored in the electronic device remains unchanged.

[0017] In combination with the first aspect, in some embodiments, the electronic device updates the first component, and the updated first component still needs to call the first system function, and the first component is updated through static linking; the electronic device runs the updated first component on the first operating system before the update, obtains the first calling instruction from the first storage area according to the first address, and executes the first calling instruction for the updated first component to call the first system function.

[0018] When the first component is updated, the updated first component can be published to the electronic device after compilation and linking. The electronic device can also update the executable file of the first component stored in the memory.

[0019] It can be seen that when the first component is updated, the source program of the updated first component can still be statically linked into an executable file based on the fixed address (such as the first address) used to encapsulate the first system function. Therefore, the updated first component can still find the system isolation layer that encapsulates the first system function based on the fixed address (such as the first address), and thus use the system isolation layer to call the first system function. During the update process, the first component does not need to consider whether the first operating system has been updated.

[0020] In conjunction with the first aspect, in some embodiments, a second storage area corresponding to a second address in the electronic device stores a third call instruction, where the third call instruction indicates a second system function provided by the first operating system before the update, and the updated first component also needs to call the second system function. The electronic device runs the updated first component in the first operating system before the update, obtains the third call instruction from the second storage area based on the second address, and executes the first call instruction for the updated first component to call the second system function.

[0021] The third calling instruction may include a storage address of the first system function in the electronic device before the first operating system is updated.

[0022] When the first operating system is updated, the system isolation layer for encapsulating the second system function can be compiled and linked with the updated first operating system, and the system isolation layer can obtain the actual storage address of the second system function in the electronic device loaded with the updated first operating system. The call instruction generated by the system isolation layer for encapsulating the second system function after recompilation and linking can include the storage address of the first system function in the electronic device after the first operating system is updated, and the call instruction can still be stored in the second storage area corresponding to the above-mentioned second address.

[0023] It can be seen that the first component may need to call multiple system functions, and the calls to these system functions can be implemented through the system isolation layer that encapsulates these system functions.

[0024] In conjunction with the first aspect, in some embodiments, the electronic device further includes a second component and a third component, the second component being a third-party component and the third component being a system application, the third component needing to call the second component, and a third storage area corresponding to a third address in the electronic device storing a fourth call instruction, the fourth call instruction being used to call the second component. The electronic device updates the second component, the second component being updated via a static link; the electronic device updates the fourth call instruction in the third storage area to a fifth call instruction, the fifth call instruction being used to call the updated second component; the electronic device runs the third component after updating the second component, obtains the fifth call instruction from the third storage area according to the third address, and executes the fifth call instruction for the third component to call the second component.

[0025] The third address may be a fixed address agreed upon in advance by the component provider and the integrator, and is used to store the binary difference isolation layer (or component isolation layer) that encapsulates the second component. The fourth and fifth call instructions may be binary instructions generated by the component isolation layer that encapsulates the second component after static compilation and linking.

[0026] Before the second component is updated, the component isolation layer is compiled and linked together with the second component before the update. The component isolation layer can obtain the actual storage address of the second component before the update in the electronic device, and the component isolation layer can be compiled and linked into a fourth call instruction. After the second component is updated, the component isolation layer is compiled and linked together with the updated second component. The component isolation layer can obtain the actual storage address of the updated second component in the electronic device, and the component isolation layer can be compiled and linked into a fifth call instruction. Since the actual storage address of the second component in the electronic device may change before and after the second component is updated, the fourth call instruction and the fifth call instruction are different.

[0027] The source program of the third component can be statically linked into an executable file according to the third address. The executable file of the third component can include the third address.

[0028] As can be seen, when third-party components are updated, system applications and the operating system do not need to be updated. To allow system applications to call updated third-party components without being updated, electronic devices can update the component isolation layer at the fixed address used to encapsulate third-party components. System applications can find the updated component isolation layer based on the fixed address and use it to call the updated third-party components. The above method can effectively reduce the cost of updating third-party components and improve the efficiency of third-party component updates in electronic devices.

[0029] In combination with the first aspect, in some embodiments, the electronic device runs a third component before the second component, obtains a fourth call instruction from a third storage area according to a third address, and executes the fourth call instruction for the third component to call the second component.

[0030] In combination with the first aspect, in some embodiments, the fourth calling instruction includes the storage address of the second component in the electronic device before the update, and the fifth calling instruction includes the storage address of the second component in the electronic device after the update.

[0031] Wherein, when the second electronic device is stored in the ROM of the electronic device, the storage address of the second component contained in the fourth call instruction and the fifth call instruction may be an address in the ROM. When the second component is stored in the Flash of the electronic device, since the executable file of the second component will be read into the RAM, the storage address of the second component contained in the fourth call instruction and the fifth call instruction may be an address in the RAM.

[0032] In conjunction with the first aspect, in some embodiments, before and after the second component is updated, the third component and the first operating system stored in the electronic device remain unchanged. Specifically, the third component and the first operating system remaining unchanged may mean that the executable file of the first component stored in the electronic device remains unchanged, and the executable file of the first operating system remains unchanged.

[0033] In combination with the first aspect, in some embodiments, the update content of the first operating system includes one or more of the following: a change in the storage address of the first system function, a change in the content of the first system function.

[0034] In conjunction with the first aspect, in some embodiments, the first storage area is a storage area on a ROM in an electronic device. The second storage area and the third storage area can also be storage areas on a ROM in an electronic device.

[0035] In a second aspect, the present application provides an electronic device. The electronic device includes a memory and a processor, wherein the memory can be used to store a computer program. The processor can be used to call the computer program so that the electronic device executes any possible implementation method as described in the first aspect.

[0036] In a third aspect, the present application further provides an electronic device, which may be a first electronic device. The first electronic device includes a component providing module and a calling interface providing module, wherein the component providing module is used to provide a first component, the first component needs to call a first system function provided by a first operating system, and the first component is published to a second electronic device including the first operating system after static linking; the calling interface providing module is used to provide a first interface, the first interface is used to encapsulate the first system function in a first storage area corresponding to a first address in the second electronic device, and the first interface is published to the second electronic device after static linking; the program for implementing the first component includes the first address.

[0037] The first electronic device may represent a device used by a component provider to develop and release components and binary difference isolation layers. The second electronic device may be a device product provided by an integrator. The second electronic device may include the first operating system, system applications, and third-party components.

[0038] The first electronic device can provide the first component to the integrator (integrator server) through the component providing module, and provide the first interface to the integrator through the calling interface providing module. The first interface can also be called a system isolation layer. The first interface can be statically linked with the first operating system, and the first interface obtains the actual storage address of the first system function in the second electronic device loaded with the first operating system, and the system isolation layer can be compiled and linked as a first call instruction. When the first operating system is updated, the first interface can be compiled and linked with the updated first operating system, and the first interface can obtain the actual storage address of the first system function in the electronic device loaded with the updated first operating system, and the first interface can be compiled and linked as a second call instruction. Since the actual storage address of the first system function may change before and after the first operating system is updated, the first call instruction and the second call instruction are different. Among them, the first call instruction and the second call instruction can both be stored in the storage area corresponding to the fixed address in the second electronic device.

[0039] It can be seen that the first electronic device can provide a first component and a first interface for encapsulating the first system function. After the first component is released to the second electronic device, there is no need to perceive whether the first operating system in the second electronic device has changed. The first component can always find the first interface according to the fixed storage address of the first interface in the second electronic device, thereby calling the first system function using the first interface. Even if the first operating system in the second electronic device is updated, the first electronic device does not need to update the first component and the first interface. The first component also does not need to be recompiled and linked before being released to the second electronic device.

[0040] In combination with the third aspect, in some embodiments, the first interface obtains the storage address of the first system function in the second electronic device during the static linking stage, and generates a calling instruction for calling the first system function after the static linking.

[0041] In combination with the third aspect, in some embodiments, the component providing module is also used to provide a second component, the second component is called by a third component in the second electronic device, and the second component is published to the second electronic device after static linking; the calling interface providing module is also used to provide a second interface, the second interface is used to encapsulate the second component in a third storage area corresponding to a third address in the second electronic device, and the second interface is published to the second electronic device after static linking.

[0042] The second component may be a third-party component, and the third component may be a system application. The third component may be developed by the manufacturer of the second electronic device. The first electronic device may provide the second component to the integrator (integrator server) through the component providing module, and provide the second interface to the integrator by calling the interface providing module. The second interface may also be referred to as a component isolation layer. The second interface is statically linked with the second component, and the second interface obtains the actual storage address of the second component in the second electronic device. The second interface can be compiled and linked as a fourth call instruction.

[0043] In conjunction with the third aspect, in some embodiments, the component providing module is further used to provide an updated second component, and the updated second component is published to the second electronic device after static linking; wherein the second interface obtains the storage address of the updated second component in the second electronic device during the static linking stage, and generates a call instruction for calling the updated second component after static linking. The call instruction generated after the second interface is statically linked to the updated second component can be a fifth call instruction. Because the actual storage address of the second component in the electronic device may change before and after the second component is updated, the fourth call instruction and the fifth call instruction are different.

[0044] As can be seen, when third-party components are updated, system applications and the operating system do not need to be updated. To allow system applications to call updated third-party components without being updated, electronic devices can update the component isolation layer at the fixed address used to encapsulate third-party components. System applications can find the updated component isolation layer based on the fixed address and use it to call the updated third-party components. The above method can effectively reduce the cost of updating third-party components and improve the efficiency of third-party component updates in electronic devices.

[0045] In a fourth aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on an electronic device, enables the electronic device to execute any possible implementation method as in the first aspect.

[0046] In a fifth aspect, the present application provides a computer program product, which may include computer instructions. When the computer instructions are run on an electronic device, the electronic device executes any possible implementation method as in the first aspect.

[0047] In a sixth aspect, the present application provides a chip, which is applied to an electronic device. The chip includes one or more processors, and the processor is used to call computer instructions to enable the electronic device to execute any possible implementation method as in the first aspect.

[0048] It is understandable that the electronic device provided in the second aspect, the electronic device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, the computer program product provided in the fifth aspect, and the chip provided in the sixth aspect are all used to execute the methods provided in the embodiments of the present application. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] FIG1A is a schematic diagram of generating an executable file provided in an embodiment of the present application;

[0050] FIG1B is a schematic diagram of a static link provided in an embodiment of the present application;

[0051] FIG1C is a schematic diagram of an executable file and a static library stored in a ROM according to an embodiment of the present application;

[0052] FIG2 is a schematic diagram of a component provided by an embodiment of the present application for compiling and linking in different compilation environments;

[0053] FIG3 is a schematic diagram of compiling and linking components based on a binary difference isolation layer according to an embodiment of the present application;

[0054] FIG4A is a schematic diagram of the hardware structure of an electronic device 100 provided in an embodiment of the present application;

[0055] FIG4B is a software structure block diagram of an electronic device 100 provided in an embodiment of the present application;

[0056] FIG5A is a schematic diagram of publishing a component and an operating system provided in an embodiment of the present application;

[0057] FIG5B is a schematic diagram of a storage location of a third-party component, a binary difference isolation layer, a system application, and an operating system in an electronic device 100 according to an embodiment of the present application;

[0058] FIG5C is a schematic diagram of another storage location of a third-party component, a binary difference isolation layer, a system application, and an operating system in the electronic device 100 according to an embodiment of the present application;

[0059] FIG6A is a schematic diagram of a component update provided by an embodiment of the present application;

[0060] FIG6B is a schematic diagram of a storage location of a third-party component, a binary difference isolation layer, a system application, and an operating system in an electronic device 100 according to an embodiment of the present application;

[0061] FIG7A is a schematic diagram of an operating system update provided by an embodiment of the present application;

[0062] FIG7B is a schematic diagram of a storage location of a third-party component, a binary difference isolation layer, a system application, and an operating system in an electronic device 100 according to an embodiment of the present application;

[0063] FIG8 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] The technical solutions in the embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of 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 used as limitations on the present application. As used in the specification and claims of the present application, the singular expressions "a", "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 following embodiments of the present application, "at least one", "one or more" refer to one or more (including two). The term "and / or" is used to describe the association relationship of associated objects, indicating that three relationships can 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 associated objects before and after are in an "or" relationship.

[0065] References to "one embodiment" or "some embodiments" etc. described in this specification mean that the specific features, structures or characteristics described in conjunction with the embodiment are included in one or more embodiments of the present application. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in another way. The term "connected" includes direct and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0066] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0067] To facilitate understanding, the components involved in this application are first conceptually introduced here.

[0068] A component may refer to a computer program that provides one or more functions. Components in an electronic device may include third-party components and system components. A third-party component may be provided or developed by a company other than the manufacturer of the electronic device. A system component may be provided or developed by the manufacturer of the electronic device.

[0069] The types of third-party components may include: applications (APP), services, functional functions, and so on. In some embodiments, services may be a smaller granularity division of applications based on the functions provided. An application may contain one or more services. For example, a shopping application may include a product browsing service (providing the function of browsing products), a shopping cart service (providing the function of adding products to a shopping cart), a payment service (providing the function of payment), and so on. The above services may also be referred to as atomic services and other names. In third-party components, applications (or services) provided by manufacturers of non-electronic devices may also be referred to as third-party applications (or third-party services) and other names, and functional functions provided by manufacturers of non-electronic devices may also be referred to as third-party functions and other names. Third-party functions can be called by system components.

[0070] The types of system components may include: APP, service. System components may also be referred to as system applications, etc. In the subsequent embodiments of this application, the name "system application" is used to introduce the static linking method provided by this application.

[0071] In some embodiments, components of the APP or service type may be displayed on the interface as visual interface elements such as APP icons, cards, shortcut function methods, widgets, etc., so that users can use the functions provided by the components.

[0072] The electronic devices to which the static linking method provided in this application is applied may include: devices with a microcontroller unit (MCU) as the computing core, and having business requirements such as small size, low cost and low power consumption. In other words, the electronic devices of this application can be distinguished from smart devices such as mobile phones and personal computers that have powerful processing and storage capabilities. For example, the electronic devices of this application may be wearable devices such as smart watches, smart bracelets, and smart glasses, or may be IoT devices such as smart speakers, smart air conditioners, smart refrigerators, smart TVs, smart door locks, smart gateways, Internet of Vehicles roadside devices, IoT sensors, and smart medical devices. The embodiments of this application do not limit the types of electronic devices.

[0073] Optionally, the electronic device of the present application may also include a device in which a main core processor and an MCU processor coexist. Among them, the MCU processor may be integrated with a central processing unit (CPU) and a memory. The memory may include a read-only memory (ROM) and a random access memory (RAM). Electronic devices have a demand to use as little RAM as possible on the MCU processor. The MCU processor can reduce the burden on the main core processor and reduce the power consumption of the device. The above-mentioned main core processor may include one or more processors such as an application processor, a graphics processor, an image signal processor, and a neural network processor. For example, when the main core processor is in a dormant state, the MCU processor can continue to work in a low-power state and listen for events that need to wake up the main core processor. The above-mentioned events that wake up the main core processor may include voice wake-up instructions, etc. The MCU processor can wake up the main core processor after listening to the event that wakes up the main core processor. In this way, the main core processor does not need to be in a working state in real time, which is conducive to saving power consumption of the device.

[0074] Understandably, wearable devices, IoT devices, and other electronic devices utilize MCUs to meet business requirements for small size, low cost, and low power consumption. MCUs play a crucial role in improving device battery life, reducing the burden on the core processor, and achieving low power consumption. MCUs typically consist of only a CPU, ROM, RAM, and basic peripherals (serial interfaces, timers, etc.). These limited hardware resources can be integrated on a single chip.

[0075] Due to resource and performance limitations, the system image in electronic devices using MCUs can be statically compiled and stored in ROM, and components (such as third-party components and system applications) can also be statically compiled into executable files and stored in ROM. The system image can refer to the computer program corresponding to the operating system. In this way, electronic devices using MCUs (which can be called MCU devices) can directly fetch instructions on-chip and execute corresponding instructions. The above-mentioned on-chip instruction fetch can mean that the CPU on the MCU reads the binary instructions required for the operation of the component from ROM. The CPU can then execute the above-mentioned binary instructions to implement the corresponding functions provided by the running component. The above-mentioned static compilation can reduce the RAM occupied by the application during operation and reduce the demand for RAM resources. The limited RAM in electronic devices using MCUs can be used to store stacks and variables.

[0076] However, during the static compilation process, fully statically linked functions generate actual addresses during the linking phase. After statically linking third-party components and system applications, they must call system functions based on their actual addresses. After statically linking system applications, they must call third-party functions based on their actual addresses.

[0077] In some embodiments, a third-party component may need to call a system function provided by the operating system during operation. After the third-party component is statically compiled and linked, the actual storage address of the system function that the third-party component needs to call may be recorded in the executable file of the third-party component. When running the third-party component, the electronic device may read and execute the executable file of the third-party component and call the corresponding system function based on the actual storage address of the system function in the executable file of the third-party component.

[0078] Therefore, when an operating system update causes the actual storage address of a system function that a third-party component needs to call to change, the electronic device must also update the third-party component. Otherwise, the third-party component will not be able to correctly call the required system function based on the original actual storage address of the system function. This results in a high cost for operating system updates.

[0079] In some embodiments, in addition to relying on the operating system during operation, the system application may also need to call one or more third-party functions (i.e., third-party components of the type of functional functions). Among them, the system application depends on the operating system, and the process of calling the system function can refer to the process of the third-party component calling the system function. After the system application is statically compiled and linked, the actual storage address of the third-party function that the system application needs to call may be recorded in the executable file of the system application. When running the system application, the electronic device can read and execute the executable file of the system application, and call the corresponding third-party function according to the actual storage address of the third-party function in the executable file of the system application.

[0080] Therefore, when a third-party function is updated and its actual storage address changes, the electronic device needs to update its operating system accordingly. Otherwise, the system application will not be able to correctly call the required third-party function based on the original actual storage address of the third-party function. This results in a high cost for updating third-party functions.

[0081] It can be seen that after the components and operating system are statically compiled, the addresses of the components and the operating system are coupled, and the system applications and third-party functions are also coupled. Any modification can only be done by re-linking the entire system, and it is impossible to modify the components or the system individually.

[0082] In some embodiments, electronic devices can use dynamic loading technology to dynamically link functions and other resources required by applications during operation, thereby resolving issues caused by component-system coupling. Devices such as personal computers (PCs) and mobile phones have dynamic loading capabilities. The system first reads the library file into memory and maps its address to the application's memory address space. It then associates the function addresses in the symbol table with the function calls in the program, ultimately accessing the interface functions within the library file. This symbol table can contain the relative positions (i.e., offset addresses) of the interface functions within the library file, which can be used to determine the actual memory addresses of each interface function within the library file based on the library file's initial memory address. However, this solution first requires sufficient RAM (RAM) space to store the loaded library files, but MCU RAM space is scarce and insufficient to support the loading of large numbers of library files into RAM for operation. Furthermore, the address mapping function requires a memory management unit (MMU), but most MCU processors lack an MMU, making this physical limitation unavailable. Therefore, traditional dynamic loading technology cannot be directly applied to wearable devices and IoT devices.

[0083] In other embodiments, the compiler can generate an interface function address table during the compilation phase of the system. The interface function address table may include the actual address of the interface function. The system can load the interface function address table into the memory (RAM) of the device and pass the interface function address table to the application. During operation, the application can determine the address of the interface function it needs to call based on the interface function address table, thereby accessing the corresponding interface function. Exemplarily, a global offset table (GOT) is generated during the compilation phase. The GOT table may include an address mapping table of global symbols in the executable file. The application can obtain the address of the symbol by searching the GOT table, thereby accessing the corresponding interface function. Alternatively, an executable file is divided into independent functional modules, each module maintains its own interface function address list, and other modules can find the address of the interface function through the interface function address list.

[0084] However, the interface function address table (such as the GOT) described above relies on compiler generation, which is dependent on the compiler's capabilities. Generating indexes for all functions can actually lead to binary bloat. These methods all require software to implement a function similar to MMU address mapping, recalculating function addresses by initializing address segment information and the offset address found. This calculation process is relatively complex. The loaded component files require an equal amount of memory (RAM) for caching, placing a high demand on RAM resources, making them difficult to apply to devices that require minimal RAM.

[0085] The present application provides a static linking method that can isolate the mutual dependency between third-party components and the operating system, so that both the third-party components and the operating system can be updated independently. Among them, the operating system's dependence on third-party components can be reflected in the need for system applications to call third-party components (such as third-party functions). When either the third-party component or the operating system in an electronic device is updated, the other party does not need to be updated accordingly. This can save the update time of the third-party component and the update time of the operating system. Especially when the third-party component is updated, since there is no need to update the operating system, the time it takes for the electronic device to update the third-party component can be greatly reduced.

[0086] The following describes the component compilation and linking process.

[0087] During component development, developers write the component's source files using high-level language code to implement the component's corresponding functions. Component source files can be, for example, files with suffixes such as .c or .cpp. Source files can also be referred to as source code. Converting component source files into executable files that can be recognized and executed by electronic devices requires the precompilation, compilation, assembly, and linking processes shown in Figure 1A. Executable files can be binary files containing binary instructions. Electronic devices can execute the binary instructions in the executable file to implement the component's corresponding functions.

[0088] As shown in Figure 1A, source file 1 can be converted into a file with a suffix of .i (i.e., .i file) after pre-compilation. In the pre-compilation stage, the compiler can process the various pre-processing commands in the source file, load header files, macro replacement, conditional compilation, de-annotation, etc. The .i file can be converted into a file with a suffix of .s (i.e., .s file) after compilation. In the compilation stage, the compiler can perform syntax analysis, semantic analysis, and symbol aggregation on the .i file to generate assembly code. The .s file can be converted into a file with a suffix of .o (i.e., .o file, which can also be called target file or target code, etc.) after assembly. In the assembly stage, the compiler can convert the assembly code into machine code. The linker can link the target file and the required related resources to generate executable file 1. For example, the above-mentioned related resources for linking can include system functions in the operating system.

[0089] The above-mentioned pre-compilation, compilation and assembly performed by the compiler can be collectively referred to as compilation. That is, after compilation and linking, the source file 1 can be converted into an executable file 1. Among them, the compiler is a computer program that can be used to translate the source file written in the high-level programming language into an equivalent target program in the machine language format so that the computer can recognize and run it. The linker is a computer program that can be used to link one or more target files generated by the compiler with the target files in the library file into an executable file. During the development stage of the component, the developer can use the compiler to compile the source file of the component into the above-mentioned target file, and use the linker to link the target file of the component into an executable file.

[0090] FIG1B exemplarily shows a schematic diagram of a static link.

[0091] As shown in Figure 1B, a plurality of target files can be included in the static library, for example, target file 1, target file 2, etc. The static library can facilitate the reuse of computer programs. A target file in the static library can include one or more functional functions for realizing specific functions (for example, read-write function, arithmetic operation function, etc.). These one or more functional functions can be system functions provided by the operating system. The component can realize the calling of system functions therein by quoting the target file in the static library. In certain embodiments, the static library can be stored in the ROM of an electronic device after static compilation together with the operating system.

[0092] During the static linking process, the linker retrieves resources required by source file 1, such as target file 1, from the static library and links the target file generated by compiling source file 1 with target file 1 to generate executable file 1. Executable file 1 may contain symbols such as code and data from the target file generated by compiling source file 1, as well as code that indicates the storage location of target file 1 and references target file 1. Executable file 1 may also be stored in the ROM of an electronic device. In this way, the electronic device can directly fetch instructions from the ROM and execute the instructions in executable file 1.

[0093] In some embodiments, a static library may be part of an operating system. Functions contained in an object file in a static library may be referred to as system functions. Calling a function in a static library by a component at runtime based on statically linked resources in an executable file may be referred to as a system call.

[0094] In some embodiments, in addition to the system functions in the static library described above, the electronic device also includes third-party functions. During compilation and linking, the system application can statically link the third-party functions to be called into the executable file of the system application. In this way, the system application can call the third-party functions at runtime based on the statically linked resources in the executable file.

[0095] FIG1C exemplarily shows a schematic diagram of executable files and static libraries stored in ROM.

[0096] As shown in Figure 1C, the storage area at address a1 in the ROM can store executable file 1, the storage area at address ak can store target file 1, and the storage area at address ak+1 can store target file 2. When executable file 1 needs to be executed, the electronic device can obtain executable file 1 from the storage area at address a1 in the ROM and execute the instructions therein. When the instruction related to target file 1 in executable file 1 is executed, the electronic device can index target file 1 in the ROM according to the instruction. The storage address of target file 1 in ROM (i.e., ak) can be recorded in executable file 1. In this way, the electronic device can index target file 1 in the storage area at address ak in the ROM, thereby executing the instructions in target file 1.

[0097] In some embodiments, the system application can be coupled with the operating system. The executable file of the system application can be stored in the ROM on the MCU chip of the electronic device together with the operating system. The executable file of the third-party component can also be stored in the ROM on the MCU chip.

[0098] In other embodiments, the executable file of the third-party component can also be stored in the flash memory on the MCU chip. Flash memory can be referred to as Flash. Flash is a non-volatile memory device. Different from the above-mentioned ROM, ROM can support random access by the CPU on the MCU chip, but Flash does not support random access. Among them, in the case where the executable file of the third-party component is stored in Flash, the electronic device can read the executable file of the third-party component from Flash to RAM, and then the electronic device can obtain the executable file of the third-party component from the on-chip instruction in RAM, thereby running the third-party component. That is to say, if the above-mentioned component 1 is a third-party component, then the executable file 1 of component 1 can be stored in Flash.

[0099] It should be noted that the location where the third-party component is read from Flash and stored in RAM may be determined by the third-party component during the compilation and linking phase. That is, there is a preset location in RAM for storing the executable file of the third-party component read from Flash. The location in RAM for storing the executable file of the third-party component may also be referred to as the execution location or execution address of the third-party component.

[0100] The storage locations of the executable files and static libraries shown in FIG1C are merely exemplary illustrations of the present application and should not constitute a limitation on the present application.

[0101] FIG2 exemplarily shows a schematic diagram of compiling and linking components in different compilation environments.

[0102] As shown in Figure 2, area 210 may include components and systems compiled and linked in compilation environment A: executable file f1 of third-party component 1, executable file f3 of third-party component 2, executable file f5 of system application 1, and operating system 1. Area 220 may include components and systems compiled and linked in compilation environment B: executable file f2 of third-party component 1, executable file f4 of third-party component 2, executable file f5 of system application 1, and operating system 2. Compilation environment A and compilation environment B are different.

[0103] In some embodiments, the above-mentioned compilation environment A and compilation environment B can be environments located in different servers respectively. Both compilation environment A and compilation environment B may include a compiler and a linker. The compiler can be used to compile the source program into a target file. The linker can be used to statically link the target file into an executable file. The components (such as third-party component 1, third-party component 2, system application 1, etc.) and the operating system that have been compiled and linked in area 210 can be stored in the memory of the electronic device (for example, stored in ROM). Similarly, the components and the operating system that have been compiled and linked in area 220 can all be stored in the memory of the electronic device. The storage location of the above-mentioned components and the operating system in the electronic device can be determined in the compilation and linking stage.

[0104] Both operating system 1 and operating system 2 may include system function 1. For example, the specific content of system function 1 may be located in target file 1 of the static library shown in FIG1B . That is, target file 1 may be the target file corresponding to system function 1 and may be used to implement the functionality of system function 1.

[0105] In some embodiments, operating system 1 and operating system 2 may be different operating systems. The different operating systems mentioned above may refer to different source programs of the operating systems. The location of system function 1 in operating system 1 and operating system 2 may be different. Therefore, after compilation and linking, the storage address of system function 1 in the electronic device loaded with operating system 1 is different from the storage address in the electronic device loaded with operating system 2.

[0106] In other embodiments, operating system 1 and operating system 2 may also be the same operating system. The above-mentioned same operating system may refer to the same source program of the operating system. In the scenario where the same operating system is compiled and linked in different compilation environments, due to the different compilation environments, the order of compiling and / or linking the source program of the operating system may be different. Therefore, after the same operating system is compiled and linked in different compilation environments, the actual storage address of the same system function may be different. Although the source programs of operating system 1 and operating system 2 are the same, after being compiled and linked in different compilation environments (such as compilation environment A and compilation environment B), the storage address of system function 1 in the electronic device loaded with operating system 1 is different from the storage address in the electronic device loaded with operating system 2.

[0107] It can be seen from the above embodiments that in the scenario of an operating system update, the source program changes before and after the operating system is updated. Then, compared to the operating system before the update, the storage address of the static library in the updated operating system may change. For example, the number of bytes occupied by a system function in the updated operating system increases, so the storage space used by this system function increases, and the addresses of the storage spaces used by other system functions may need to be shifted backward in sequence. In this way, after the operating system is updated, the storage address of one or more system functions in the static library changes. In addition, when the same operating system is compiled and linked in different compilation environments, affected by the compilation environment, the storage address of the static library in the operating systems compiled and linked in different compilation environments may be different.

[0108] During operation, third-party component 1 needs to call the aforementioned system function 1. During the static linking process for third-party component 1, the linker may write the storage address of system function 1 into the executable file of third-party component 1. This allows the electronic device to index system function 1 based on the storage address of system function 1 and thus call system function 1. Because system function 1 is located differently in operating system 1 and operating system 2, the executable files of third-party component 1 generated in compilation environment A and compilation environment B are also different. To distinguish them, executable file f1 of third-party component 1 refers to the executable file generated by third-party component 1 in compilation environment A, and executable file f2 of third-party component 1 refers to the executable file generated by third-party component 1 in compilation environment B. Executable file f1 of third-party component 1 may record the storage address of system function 1 in the electronic device loaded with operating system 1. Executable file f2 of third-party component 1 may record the storage address of system function 1 in the electronic device loaded with operating system 2. Executable file f1 of third-party component 1 is applicable only to operating system 1. The executable file f2 of the third-party component 1 is only applicable to the operating system 2.

[0109] Similarly, in order to distinguish the executable files generated by the third-party component 2 in different compilation environments, the executable file f3 of the third-party component 2 is used here to represent the executable file generated by the third-party component 2 in compilation environment A, and the executable file f4 of the third-party component 2 is used to represent the executable file generated by the third-party component 2 in compilation environment B. The third-party component 2 is a third-party component different from the third-party component 1. Among them, if the third-party component 2 needs to call a system function during operation, and the location of the system function in the operating system 1 and the operating system 2 is different, then the contents of the executable file f3 of the third-party component 2 and the executable file f4 of the third-party component 2 are different. If the third-party component 2 is a third-party function and does not need to call a system function during operation, then the contents of the executable file f3 of the third-party component 2 and the executable file f4 of the third-party component 2 may be the same.

[0110] Among them, since the order of compiling and / or linking the source program may be different in different compilation environments, the storage address of the executable file f3 of the third-party component 2 in the electronic device loaded with the operating system 1 may be different from the storage address of the executable file f4 of the third-party component 2 in the electronic device loaded with the operating system 2.

[0111] Here, an example is taken where a system application 1 needs to call a third-party component 2 during operation.

[0112] During the static linking process for system application 1, the linker can write the storage address of third-party component 2 into the executable file of system application 1. Thus, when executing the executable file of system application 1, the electronic device can index third-party component 2 based on its storage address, thereby invoking third-party component 2. Because the storage address of the executable file of third-party component 2 in the electronic device loaded with operating system 1 is different from the storage address in the electronic device loaded with operating system 2, the executable files of system application 1 generated in compilation environment A and compilation environment B are also different.

[0113] To distinguish them, the executable file f5 of system application 1 can represent the executable file generated by system application 1 in compilation environment A. The executable file f6 of system application 1 can represent the executable file generated by system application 1 in compilation environment B. The executable file f5 of system application 1 can record the storage address of the executable file f3 of third-party component 2 in the electronic device that loads operating system 1. The executable file f6 of system application 1 can record the storage address of the executable file f4 of third-party component 2 in the electronic device that loads operating system 2. Among them, the executable file f5 of system application 1 is only applicable to operating system 1. The executable file f6 of system application 1 is only applicable to operating system 2.

[0114] As shown in Figure 2, the executable files of the same component (such as third-party component 1, system application 1, etc.) cannot be reused in different operating systems. These different operating systems can include operating systems with different source programs, or operating systems with the same source program but different versions after compilation and linking in different compilation environments.

[0115] As can be seen from Figures 1A, 1B, and 2, due to the use of static linking in the MCU device, the components in the MCU device are strongly coupled to the static library. That is, once the static library changes (for example, the storage address of the static library in the ROM changes), the components in the MCU device need to be recompiled, linked, and then written into the MCU device. Otherwise, when the MCU device executes the executable file of the component, it will not be able to find the required resources based on the address of the static library that was once linked. In other words, developers cannot modify the static library or operating system in the MCU device independently. The cost of system updates is high.

[0116] In addition, some system applications also need to call third-party components (such as third-party functions) during operation. After the system application is statically linked, the actual storage addresses between the system application and the third-party component are coupled. That is, once the third-party component changes (for example, the storage address of the third-party component in the electronic device changes), the system application in the MCU device needs to be recompiled, linked, and then written into the MCU device. When the system application is coupled with the operating system and stored together in an area of ​​the MCU device, the need for the system application to be recompiled and linked means that the entire operating system needs to be recompiled and linked. Therefore, developers cannot modify the third-party components in the MCU device individually. The cost of updating third-party components is also high.

[0117] This application provides a static linking method that enables independent updates of components and the operating system by introducing a binary difference isolation layer. The independent updates of components and the operating system can include: independent updates of third-party components without requiring updates to system applications and the operating system; independent updates of the operating system without requiring updates to third-party components; and independent updates of the operating system without requiring updates to system applications.

[0118] The binary difference isolation layer can be an interface for components to call functional functions (such as system functions and third-party functions). The binary difference isolation layer can be used to encapsulate functional functions, decoupling components from the actual storage addresses of functional functions. After compilation and linking, the binary difference isolation layer can be stored at a preset fixed address. Components can call the binary difference isolation layer from the fixed address to call the functional functions encapsulated by the binary difference isolation layer. This way, components do not need to be aware of changes in the actual storage addresses of functional functions.

[0119] The binary difference isolation layer may include a system isolation layer and a component isolation layer.

[0120] The system isolation layer can be used to encapsulate system functions and decouple third-party components from the actual storage addresses of system functions. In some embodiments, the system isolation layer can also decouple system applications from the actual storage addresses of system functions. The system isolation layer can be statically linked with the operating system and written to the electronic device. During the static linking process between the system isolation layer and the operating system, the system isolation layer can obtain the actual storage address of the system function in the operating system. The electronic device can store the statically linked system isolation layer at a preset fixed address.

[0121] The executable file of a third-party component can contain the fixed address of the system isolation layer that encapsulates the system function that the third-party component needs to call. This way, the third-party component can always call the system isolation layer based on the fixed address, thereby finding the system function at its actual storage address and calling it.

[0122] The component isolation layer can be used to encapsulate third-party functions and realize the decoupling of system applications and the actual storage addresses of third-party functions. The component isolation layer can be statically linked with the third-party function and written into the electronic device. In the process of static linking of the component isolation layer and the third-party function, the component isolation layer can obtain the actual storage address of the third-party function. The third-party function can be stored in ROM or Flash. When the third-party function is stored in ROM, the actual storage address of the third-party function can represent the storage address of the third-party function on ROM. When the third-party function is stored in Flash, the actual storage address of the third-party function can represent the storage address of the third-party function in RAM when it is read from Flash (that is, the execution address of the third-party function). The electronic device can store the statically linked component isolation layer in a preset fixed address.

[0123] The executable file of a system app can contain the fixed address of the component isolation layer that encapsulates the third-party functions that the system app needs to call. This way, the system app can always call the component isolation layer based on the fixed address, thereby finding the third-party functions at their actual storage addresses and calling them.

[0124] In some embodiments, the system isolation layer and the component isolation layer can be stored in different areas of the ROM of the MCU processor. The two areas storing the system isolation layer and the component isolation layer in the ROM can be re-burned separately without affecting each other. Among them, when the operating system is updated, the system isolation layer can be statically re-linked together with the operating system and then written to the electronic device. After re-static linking, the system isolation layer can obtain the actual storage address of the system function after the operating system is updated. The electronic device can re-burn the area storing the system isolation layer in the ROM, and burn the re-statically linked system isolation layer into the area. When a third-party function is updated, the component isolation layer can be statically re-linked together with the third-party function and then written to the electronic device. After re-static linking, the component isolation layer can obtain the actual storage address of the third-party function after the third-party function is updated. The electronic device can re-burn the area storing the component isolation layer in the ROM, and burn the re-statically linked component isolation layer into the area.

[0125] The fixed addresses for storing the binary difference isolation layer may be preset. For example, these fixed addresses may be determined in advance by the component provider and the device manufacturer.

[0126] FIG3 exemplarily shows a schematic diagram of compiling and linking components based on a binary difference isolation layer.

[0127] As shown in Figure 3, area 310 may include components and systems compiled and linked in compilation environment A: executable file f7 of third-party component 1, executable file f8 of third-party component 2, executable file f9 of system application 1, system isolation layer 311, component isolation layer 312, and operating system 1. Area 320 may include components and systems compiled and linked in compilation environment B: executable file f7 of third-party component 1, executable file f8 of third-party component 2, executable file f9 of system application 1, system isolation layer 321, component isolation layer 322, and operating system 2.

[0128] Compilation environment A, compilation environment B, operating system 1, and operating system 2 can all refer to the above description of FIG2 , and will not be repeated here.

[0129] 1. Compile and link components based on the system isolation layer.

[0130] It can be seen from the embodiment of Figure 2 above that the actual storage address of the system function 1 in the electronic device loaded with the operating system 1 is different from the actual storage address in the electronic device loaded with the operating system 2. During the process of compiling and linking the system isolation layer 311 in the compilation environment A, the actual storage address of the system function 1 in the electronic device loaded with the operating system 1 can be passed to the system isolation layer 311. The system isolation layer 311 can be stored in a fixed address in the electronic device. The linker in the compilation environment A can statically link the third-party component 1 according to the fixed address where the system isolation layer 311 is located. Similarly, during the process of compiling and linking the system isolation layer 321 in the compilation environment B, the actual storage address of the system function 1 in the electronic device loaded with the operating system 2 can be passed to the system isolation layer 321. The system isolation layer 321 can be stored in a fixed address in the electronic device. The linker in the compilation environment B can statically link the third-party component 1 according to the fixed address where the system isolation layer 321 is located.

[0131] The fixed address used to store the system isolation layer 311 and the fixed address used to store the system isolation layer 321 can be the same. For example, the electronic device loaded with the operating system 1 and the electronic device loaded with the operating system 2 can be devices of the same device manufacturer. The fixed address of the system isolation layer for storing the encapsulated system function 1 agreed by the device manufacturer can be the same in different devices. Then, the executable files generated by the third-party component 1 after static linking in the compilation environment A and the compilation environment B are the same, for example, both are executable files f7. The fixed address of the system isolation layer 311 (that is, the fixed address of the system isolation layer 321) can be recorded in the executable file f7.

[0132] It can be seen that although the locations of system function 1 in operating system 1 and operating system 2 are different, the address used to encapsulate system function 1 can be the same. In other words, in different compilation environments, the same third-party component can be statically linked based on the fixed address of the system isolation layer used to encapsulate the system function to be called to generate the same executable file. Then, even in different operating systems, the executable file of the same third-party component can be reused. The above method can isolate the third-party component's dependence on the operating system and realize the decoupling of the third-party component from the actual storage address of the system function. When the operating system is updated, the third-party component does not need to be updated accordingly.

[0133] Similarly, system applications can call system functions through the aforementioned system isolation layer. For details, see the section "Third-Party Applications Calling System Functions Through the System Isolation Layer." This method isolates system applications from their dependence on the operating system, decoupling them from the actual storage addresses of system functions. This eliminates the need for system applications to be updated when the operating system is updated.

[0134] 2. Compile and link system applications based on the component isolation layer.

[0135] From the above-mentioned embodiment of compiling and linking components based on the system isolation layer, it can be seen that the contents of the executable files generated by the same third-party component after being compiled and linked in different compilation environments can be the same. Therefore, the contents of the executable files generated by the third-party component 2 after being compiled and linked in compilation environment A and compilation environment B can be the same, for example, both are executable files f8. However, because the order of compiling and / or linking programs in different compilation environments may be different, the actual storage address of the executable file f8 of the third-party component 2 in the electronic device loaded with operating system 1 may be different from the actual storage address in the electronic device loaded with operating system 2.

[0136] During the process of compiling and linking the component isolation layer 312 in the compilation environment A, the actual storage address of the executable file f8 of the third-party component 2 in the electronic device loaded with the operating system 1 can be passed to the component isolation layer 312. The component isolation layer 312 can be stored at a fixed address in the electronic device. The linker in the compilation environment A can statically link the system application 1 according to the fixed address where the component isolation layer 312 is located. Similarly, during the process of compiling and linking the component isolation layer 322 in the compilation environment B, the actual storage address of the executable file f8 of the third-party component 2 in the electronic device loaded with the operating system 2 can be passed to the component isolation layer 322. The component isolation layer 322 can be stored at a fixed address in the electronic device. The linker in the compilation environment B can statically link the system application 1 according to the fixed address where the component isolation layer 322 is located.

[0137] The fixed address used to store component isolation layer 312 and the fixed address used to store component isolation layer 322 can be the same. Therefore, the executable files generated by statically linking system application 1 in compilation environment A and compilation environment B are identical, for example, both are executable files f9. Executable file f9 can record the fixed address of component isolation layer 312 (i.e., the fixed address of component isolation layer 322).

[0138] It can be seen that although the third-party component 2 is stored in different locations in the electronic device after being compiled and linked in different compilation environments, the address used to encapsulate the third-party component 2 can be the same. In other words, in different compilation environments, the same system application can be statically linked based on the fixed address of the component isolation layer used to encapsulate and call third-party components (such as third-party functions) to generate the same executable file. Then, even if the third-party component changes, the executable file of the same system application can still be reused. The above method can isolate the operating system (specifically, it can be a system application coupled to the operating system) from its dependence on the third-party component, and realize the decoupling of the system application and the actual storage address of the third-party component. When the third-party component is updated, the system application and the operating system do not need to be updated accordingly.

[0139] As can be seen from the above method, upper-layer components are not required to be aware of changes in the actual storage address of the system function to be called. The above system isolation layer can isolate the component's dependency on the actual storage address of the system function. If an operating system update causes the actual storage address of the system function to change, the component does not need to be recompiled and linked, as the fixed address of the system isolation layer used to encapsulate the system function remains unchanged. The component's executable file can continue to run on the updated operating system. Furthermore, system applications are not required to be aware of changes in the actual storage address of the third-party function to be called. The above component isolation layer can isolate the system application's dependency on the actual storage address of the third-party function. If an update of the third-party function causes the actual storage address of the third-party function to change, the fixed address of the component isolation layer used to encapsulate the third-party function remains unchanged, eliminating the need for recompilation and linking of the system application and the operating system. The system application and the operating system can still correctly find and call the third-party function even if the third-party function is not updated. The above method of introducing a binary difference isolation layer can decouple the component from the operating system. Both the component and the operating system can be updated independently.

[0140] The structure of the electronic device 100 involved in this application is introduced below.

[0141] FIG. 4A exemplarily shows a schematic diagram of the hardware structure of the electronic device 100 .

[0142] As shown in FIG4A , the electronic device 100 may include an MCU, an antenna, a wireless communication module, a speaker, a microphone, a display, buttons, a motor, a sensor module, a power management module, a battery, and the like.

[0143] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0144] An MCU can integrate a central processing unit (CPU), peripheral units, and basic functional units. Peripheral units can include memory (such as ROM, RAM, Flash, etc.), input / output interfaces, and registers. Basic functional units can include timers / counters, interrupt systems, and serial interfaces. The MCU can be used to implement functions such as timing, connecting to external channels as an input / output interface, implementing external interrupt control, and providing a communication interface. The CPU, the various components in the peripheral units, and the various components in the basic functional units can be coupled via a bus.

[0145] Among them, the memory can be used to store computer programs and data. For example, the memory can store a binary difference isolation layer and executable files of programs and components corresponding to the operating system. The memory can include ROM, RAM, and Flash. Both ROM and RAM can support on-chip instruction fetch. The CPU can randomly access the contents of ROM and RAM. In some embodiments, the storage area on the ROM can be divided into regions. Different storage areas on the ROM can be updated independently. For example, the storage areas on the ROM may include storage area 1 and storage area 2. Storage area 1 and storage area 2 occupy different storage addresses. Storage area 1 and storage area 2 can be used to store different contents. When the content in storage area 1 needs to be updated, the electronic device 100 can re-burn the entire storage area 1 and store the updated content in storage area 1. In this case, the electronic device 100 can keep the content of storage area 2 unchanged, that is, not burn storage area 2. Flash does not support random access by the CPU. Flash power failure will not lose data. The electronic device 100 can read the content stored in Flash into RAM. The CPU can then access the relevant content from RAM. Among them, the content stored in Flash is read into RAM, and the storage location in RAM can be predetermined by the content during the compilation and linking stage. RAM will lose data in the event of power failure. Therefore, when RAM loses power (such as when the electronic device 100 is turned off or the power of the electronic device 100 is exhausted) and then powered on (such as when the electronic device 100 is turned on), the data previously stored in RAM that was read from Flash is lost. The electronic device 100 can read the data in Flash into RAM again after the RAM is powered on.

[0146] In some embodiments, the electronic device 100 may store system applications together with the operating system in ROM. The system applications may be coupled with the operating system and stored together in a storage area in the ROM. That is, the system applications and the operating system are always updated together. Alternatively, the system applications and the operating system may be stored in different storage areas in the ROM. The system applications and the operating system may be updated independently. The electronic device 100 may store third-party components in Flash. The electronic device 100 may read the executable files of the third-party components from Flash into RAM and then execute them.

[0147] In other embodiments, the electronic device 100 may also store third-party components in ROM. The storage area of ​​the third-party components in ROM is different from the storage area of ​​the system applications and the operating system in ROM. In this way, the third-party components can be updated independently of the system applications and the operating system.

[0148] In some other embodiments, the electronic device 100 may also store the system application in Flash and read the executable file of the system application from Flash into RAM for execution.

[0149] The embodiment of the present application does not limit the type of memory. For example, in addition to ROM, RAM, and Flash, the MCU may also be integrated with pseudo static random access memory (PSRAM) and the like.

[0150] The CPU can include components such as a controller and an arithmetic unit. The CPU can read and execute binary instructions from ROM or RAM. In other words, the MCU can perform on-chip instruction fetching and execution. For example, the CPU can read a component's executable file from ROM or RAM and execute the binary instructions contained therein to implement the component's corresponding function.

[0151] The input / output interface may include a USB interface. In addition to being limited to a USB interface, the input / output interface integrated on the MCU may also include one or more of the following: an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, and the like.

[0152] Registers can be used to temporarily store data and operation structures involved in calculations.

[0153] Timers / counters can be used to measure the time it takes for an event to occur or to measure the time difference between two events.

[0154] The interrupt system can be used to achieve real-time control, automatic fault handling, and data transmission between the CPU and peripheral devices.

[0155] The serial interface may be an expansion interface using a serial communication method, and may be used to implement sequential transmission of data bit by bit.

[0156] A loudspeaker, also known as a "horn", is used to convert audio electrical signals into sound signals.

[0157] A microphone, also known as a "microphone" or "microphone", is used to convert sound signals into electrical signals.

[0158] The display screen is used to display images, videos, etc. In some embodiments, the electronic device 100 may include 1 or N display screens, where N is a positive integer greater than 1.

[0159] Buttons include power button, volume button, etc.

[0160] The motor can generate vibration prompts.

[0161] The sensor module may include one or more of the following sensors: pressure sensor, gyroscope sensor, air pressure sensor, magnetic sensor, acceleration sensor, gravity sensor, distance sensor, proximity light sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor, bone conduction sensor, etc.

[0162] The power management module connects the battery to the MCU. It receives charging input from the charger to charge the battery and power the MCU, speakers, microphones, display, sensor modules, wireless communication modules, and more. It also receives input from the battery to power the MCU, speakers, microphones, display, sensor modules, wireless communication modules, and more.

[0163] The wireless communication function of the electronic device 100 can be implemented through an antenna, a wireless communication module, etc.

[0164] Antennas are used to transmit and receive electromagnetic wave signals. Each antenna in an electronic device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, antennas can be used in conjunction with a tuning switch.

[0165] The wireless communication module can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc. applied to the electronic device 100. The wireless communication module can be one or more devices that integrate at least one communication processing module. The wireless communication module receives electromagnetic waves via an antenna, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the MCU. The wireless communication module can also receive signals to be sent from the MCU, frequency modulate them, amplify them, and convert them into electromagnetic waves for radiation through the antenna. In some embodiments, the wireless communication module can also provide solutions for wireless communications such as 2G / 3G / 4G / 5G.

[0166] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present application, the layered architecture is used as an example to illustrate the software structure of the electronic device 100.

[0167] FIG4B is a block diagram of the software structure of the electronic device 100 according to an embodiment of the present application.

[0168] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other via software interfaces. In some embodiments, the software system of electronic device 100 can be divided into three layers: the application layer, the application framework and system services layer, and the kernel layer.

[0169] The application layer can include a series of application packages. Application packages can also be called component packages.

[0170] As shown in FIG4B , the application package may include third-party components and system applications, such as compass, weather, WLAN, Bluetooth, time, camera, short message, and other components.

[0171] The application framework and system service layer provide API and programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0172] As shown in FIG4B , the application framework and system service layer may include a log management module, a communication management module, a view system, a memory management module, and the like.

[0173] The log management module can be used to provide log recording and log maintenance.

[0174] The communication management module can be used for unified management of semaphores and message handles.

[0175] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0176] The memory management module can be used to implement memory management. For example, the electronic device 100 can manage different storage areas in the ROM through the memory management module.

[0177] In some embodiments, the application framework and system service layer may further include a binary difference isolation layer. The binary difference isolation layer may include a component isolation layer and a system isolation layer. The component isolation layer may be an interface for calling third-party functions. The system isolation layer may be an interface for calling system functions. In other words, both the component isolation layer and the system isolation layer are interface functions. For details about the binary difference isolation layer, please refer to the description of the aforementioned embodiment.

[0178] The kernel layer is the layer between hardware and software. The kernel layer includes at least the file system, hardware drivers, and bus drivers.

[0179] The file system can be used to manage files and data stored in the electronic device 100 and can be equivalent to a file explorer. A file system can be a method for organizing files in an electronic device. The file system can adopt a hierarchical structure, starting from a root directory and divided into multiple subdirectories. The file system can be responsible for functions such as creating files, storing, reading, modifying, and transferring files. For example, the file system can store files in a storage location corresponding to a file path. In this way, users can find the corresponding files by file path.

[0180] Hardware drivers can be used by software in the electronic device 100 (such as the content of the application layer, the application framework layer, and the system service layer) to drive the hardware in the electronic device 100. For example, the hardware in the electronic device 100 may include one or more of the following: a display screen, a camera, a speaker, a microphone, a sensor, etc. Therefore, the hardware driver may include one or more of the following: a display driver, a camera driver, an audio driver, a sensor driver, etc.

[0181] The bus driver can be used to control bus components to implement corresponding functions. It is the controller, adapter and bridge of the bus.

[0182] In some embodiments, the software system of the electronic device 100 may further include a static library so that components implemented based on static linking in the electronic device 100 can call required system functions during operation. The embodiments of the present application do not limit the location of the static library in the software system. For example, the static library may be located in the application framework and system service layer, or in other layers between the application framework and system service layer and the kernel layer.

[0183] In some embodiments, after the software system of the electronic device 100 is built, it can be packaged from top to bottom into a system image. This system image can be a binary file. The content in the system image can be divided according to preset rules. For example, the part of the system image that is allowed to be loaded later (such as the file system, third-party components) and the part that is not allowed to be loaded later (such as the operating system) can be separated. Among them, the above-mentioned part that is allowed to be loaded later can be placed in the Flash of the electronic device 100. The above-mentioned part that is not allowed to be loaded later can be burned into the ROM of the electronic device 100. Therefore, the electronic device 100 can burn the operating system in the ROM and store the file system and third-party components in the Flash. The file system can manage the storage location of the third-party components in the Flash. The executable files of the third-party components in the Flash can be stored and indexed according to the file path. After the electronic device 100 is turned on, the instructions in the ROM can be executed first, and then the contents in the Flash (such as the executable files of the third-party components) can be read into the preset storage area in the RAM.

[0184] The embodiment of the present application does not limit the type of operating system of the electronic device 100. For example, the operating system may be: OS, etc.

[0185] The following describes the static linking method provided by this application in conjunction with some release updates of components and operating systems.

[0186] Case 1 (FIGS. 5A to 5C): The component provider provides third-party components before the electronic device 100 leaves the factory.

[0187] In some embodiments, a component provider may develop components and a binary difference isolation layer. A component provider may include devices such as PCs and servers used to develop the components and binary difference isolation layer. An integrator may develop an operating system and load the operating system into the electronic device 100 produced by the integrator. An integrator may also be referred to as a device manufacturer, etc. An integrator may include devices such as PCs and servers used to develop the operating system and load the operating system into the electronic device 100.

[0188] Among them, the component provider and the integrator may be different. That is, the component provider may be a manufacturer other than the electronic device 100, and there is a need to publish the components it develops in the electronic device 100. When the component provider and the integrator are different, the components provided by the component provider may be third-party components. The integrator can integrate third-party components provided by multiple component providers on the operating system and publish them on the electronic device 100. Alternatively, the component provider and the integrator may be the same party. That is, the component provider may be the manufacturer of the electronic device 100. For example, in addition to developing the operating system, the integrator may also develop one or more components to publish in the electronic device 100. When the component provider and the integrator are the same party, the components provided by the component provider may be system components (i.e., system applications).

[0189] Here we take the example where the component provider is different from the integrator and the component provider provides third-party components.

[0190] In some embodiments, the component provider and the integrator can communicate in advance to determine the fixed address in the memory of the electronic device 100 for encapsulating functional functions (including system functions and third-party functions). That is, a portion of the memory of the electronic device 100 can be preset with a storage area for storing the component isolation layer and the system isolation layer to achieve address solidification of the interface function. The above-mentioned interface functions are the system isolation layer and the component isolation layer, which can be used to call system functions and third-party functions. The preset storage area corresponding to the above-mentioned fixed address can be unaffected by changes in the content stored in other storage areas in the electronic device 100 and is an independent storage area. Among them, the preset storage area corresponding to the above-mentioned fixed address can include two independent storage areas, one for storing the system isolation layer and the component isolation layer respectively. Therefore, the system isolation layer and the component isolation layer can be updated independently without interfering with each other. The preset storage area corresponding to the above-mentioned fixed address can be a storage area on the ROM of the electronic device 100. An independent storage area on the ROM can be a section with continuous storage addresses on the ROM. When the content of an independent storage area on the ROM is updated, this independent storage area can be re-burned as a whole and the updated content can be written.

[0191] Here we take the following scenario as an example: the component provider develops third-party component 1 and third-party component 2, the integrator provides system application 1, third-party component 1 needs to call system function 1 provided by the operating system, and the system application needs to call third-party component 2, where the third-party component can be a third-party function.

[0192] It is understandable that a third-party component can call one or more system functions. A system application can also call one or more third-party components. In addition to system function 1, third-party component 1 can also call more system functions. For the method for third-party component 1 to call other system functions, please refer to the description of the method for third-party component 1 to call system function 1. In addition to third-party component 2, system application 1 can also call more third-party components. For the method for system application 1 to call other third-party components, please refer to the description of the method for system application 1 to call third-party component 2.

[0193] As shown in Figure 5A, the component provider can develop third-party components 1 and 2, and develop binary difference isolation layers based on the fixed addresses agreed upon with the integrator. The binary difference isolation layers can include system isolation layer 1 and component isolation layer 1. System isolation layer 1 can be used to encapsulate system function 1, allowing components such as third-party component 1 to call system function 1. Component isolation layer 1 can be used to encapsulate third-party component 2, allowing components such as system application 1 to call third-party component 2.

[0194] The fixed address mentioned above may include the fixed address used to encapsulate system function 1 (i.e., the fixed address used to store system isolation layer 1), and the fixed address used to encapsulate third-party component 2 (i.e., the fixed address used to store component isolation layer 1). In this way, during the static linking process of third-party component 1, the linker can use the fixed address used to store system isolation layer 1 to statically link component 1, isolating the third-party component 1 from its dependency on the actual storage address of system function 1.

[0195] Not limited to the above-mentioned fixed addresses for encapsulating system functions 1 and the fixed addresses for encapsulating third-party components 2, the binary difference isolation layer can also be used to encapsulate other functional functions (such as system functions, third-party functions, etc.) so that the components can complete static links based on the fixed addresses used to encapsulate the functional functions they need. In other words, not limited to the above-mentioned system isolation layer 1 and component isolation layer 1, the binary difference isolation layer can also include more system isolation layers for encapsulating other system functions, and component isolation layers for encapsulating other third-party components. The binary difference isolation layer can isolate the dependency of one or more components on the actual storage addresses of the functional functions they need.

[0196] It is understandable that different component providers can communicate with the integrator in advance to determine the fixed addresses in the memory of the electronic device 100 for encapsulating system functions and the fixed addresses for encapsulating third-party components. In other words, different component providers can provide corresponding system isolation layers for their respective developed third-party components, and provide component isolation layers for encapsulating their developed third-party components.

[0197] Optionally, the binary difference isolation layer may also be provided by the integrator, which is not limited in this embodiment of the present application.

[0198] Before the electronic device 100 leaves the factory (that is, during the development process of the electronic device 100), the component provider may provide the integrator with the third-party component 1, the third-party component 2, the system isolation layer 1, and the component isolation layer 1. Upon receiving the above content provided by the component provider, the integrator may statically link the third-party component (including the third-party component 1 and the third-party component 2), the binary difference isolation layer (including the system isolation layer 1 and the component isolation layer 1), the system application (such as the system application 1), and the operating system and publish them to the electronic device 100. That is, when leaving the factory, the electronic device 100 may include the operating system, the instructions 511 of the system isolation layer 1, the instructions 512 of the component isolation layer 1, the executable file F1 of the third-party component 1, the executable file F2 of the third-party component 2, and the executable file F3 of the system application.

[0199] The instruction 511 of the system isolation layer 1 may be a binary instruction obtained after the source program of the system isolation layer 1 is compiled and linked.

[0200] The instruction 512 of the component isolation layer 1 may be a binary instruction obtained after the source program of the component isolation layer 1 is compiled and linked.

[0201] The above-mentioned static linking of the third-party component 1 may include: statically linking the target file of the third-party component 1 and the system function 1 into an executable file F1 according to the fixed address used to encapsulate the system function 1. The executable file F1 may contain a fixed address for encapsulating the system function 1. The instructions 511 of the system isolation layer 1 may be stored in the storage area corresponding to the fixed address for encapsulating the system function 1. In this way, when the electronic device 100 executes the executable file F1, the electronic device 100 can call the system isolation layer 1 according to the fixed address used to encapsulate the system function 1, thereby using the system isolation layer 1 to call the system function 1.

[0202] The above-mentioned static linking of the system isolation layer 1 and the operating system may include: providing the actual storage address of the system function 1 to the system isolation layer 1. When the system isolation layer 1 is statically linked and published to the electronic device 100, the electronic device 100 may store the instructions 511 of the system isolation layer 1 in the storage area corresponding to the fixed address in the memory according to the fixed address used to encapsulate the system function 1. When the operating system is statically linked and published to the electronic device 100, the electronic device 100 may store the operating system in the memory. Among them, the electronic device 100 may store the instructions corresponding to the system functions in the corresponding storage area according to the actual storage address of each system function. For example, the electronic device 100 may store the instructions of the system function 1 in the storage area corresponding to the actual storage address of the system function 1.

[0203] The system application 1 can be compiled and linked together with the operating system. Static linking of the system application 1 may include: statically linking the target file of the system application 1 and the third-party component 2 into an executable file F3 according to the fixed address used to encapsulate the third-party component 2. The executable file F3 may contain a fixed address for encapsulating the third-party component 2. The instructions 512 of the component isolation layer 1 may be stored in the storage area corresponding to the fixed address for encapsulating the third-party component 2. In this way, when the electronic device 100 executes the executable file F3, the electronic device 100 can call the component isolation layer 1 according to the fixed address for encapsulating the third-party component 2, thereby using the component isolation layer 1 to call the third-party component 2.

[0204] The above-mentioned static linking of the third-party component 2 and the component isolation layer 1 may include: statically linking the target file of the third-party component 2 into the executable file F2, determining the actual storage address of the executable file F2, and providing the actual storage address of the executable file F2 to the component isolation layer 1. When the component isolation layer 1 is statically linked and published to the electronic device 100, the electronic device 100 may store the instructions 512 of the component isolation layer 1 in the storage area corresponding to the fixed address in the memory based on the fixed address used to encapsulate the third-party component 2. When the third-party component 2 is statically linked and published to the electronic device 100, the electronic device 100 may store the executable file F2 in the storage area corresponding to the actual storage address of the executable file F2.

[0205] In one possible implementation, the third-party component 1 provided by the component provider to the integrator can be the target file obtained by compiling the source file of the third-party component 1. The third-party component 2 provided by the component provider to the integrator can be the target file obtained by compiling the source file of the third-party component 2. The binary difference isolation layer provided by the component provider to the integrator can also be the target file obtained by compiling the binary difference isolation layer. In other words, the component provider can compile the third-party component 1, the third-party component 2, and the binary difference isolation layer before providing them to the integrator.

[0206] Among them, the integrator can compile system applications such as system application 1 and operating system, and statically link the compiled system applications such as system application 1 and operating system with the target files of third-party components from the component provider and the target files of the binary difference isolation layer.

[0207] FIG5B exemplarily shows a schematic diagram of a storage location of third-party components, a binary difference isolation layer, system applications, and an operating system in the electronic device 100 .

[0208] As shown in FIG5B , the memory of electronic device 100 may include ROM, RAM, and Flash. The executable file F1 of third-party component 1 and the executable file F2 of third-party component 2 may be stored in Flash. The executable file F3 of the system application, the operating system, instructions 511 of system isolation layer 1, and instructions 512 of component isolation layer 1 may be stored in ROM.

[0209] After the RAM is powered on (such as after the electronic device 100 is turned on), the electronic device 100 can read the executable file F1 and the executable file F2 from the Flash into the RAM. Among them, the electronic device 100 can store the executable file F1 in the storage area corresponding to the address H1 in the RAM, and store the executable file F2 in the storage area corresponding to the address H2 in the RAM. The above-mentioned address H1 and address H2 can be determined by the third-party component 1 and the third-party component 2 during the compilation and linking stage. When it is necessary to run the third-party component 1, the electronic device 100 can obtain the executable file F1 from the storage area corresponding to the address H1 in the RAM and execute it. Address H1 can be called the execution address of the third-party component 1. Similarly, when it is necessary to run the third-party component 2, the electronic device 100 can obtain the executable file F2 from the storage area corresponding to the address H2 in the RAM and execute it. Address H2 can be called the execution address of the third-party component 2. Address H1 and address H2 are only exemplary descriptions of the present application and should not constitute a limitation to the present application.

[0210] The storage area with address L1 in the ROM can store the executable file F3 of the system application 1, the storage area with address Ln can store the instruction 511 of the system isolation layer 1, the storage area with address Lk can store the system function 1, the storage area with address Lk+1 can store the system function 2, and the storage area with address Lq can store the instruction 512 of the component isolation layer 1.

[0211] The address Ln in the ROM can be a fixed address used to encapsulate the system function 1. The third-party component 1 can be statically linked according to the address Ln. Therefore, the executable file F1 of the third-party component 1 can contain the address Ln. When running the third-party component 1, the electronic device 100 can fetch instructions from the RAM on chip to obtain the executable file F1. The electronic device 100 executes the executable file F1 and can read the instruction 511 of the system isolation layer 1 in the ROM according to the address Ln in the executable file F1 to call the system isolation layer 1. Since the system isolation layer 1 can obtain the actual storage address of the system function 1 (i.e., the address Lk) when statically linked, the electronic device 100 can execute the instruction 511 of the system isolation layer 1 to call the system function 1. In this way, the third-party component 1 can use the system isolation layer 1 to call the system function 1 according to the fixed address used to encapsulate the system function 1 during operation.

[0212] The address Lq in the ROM can be a fixed address used to encapsulate the third-party component 2. The system application 1 can be statically linked according to the address Lq, so the executable file F3 of the system application 1 can contain the address Lq. When running the system application 1, the electronic device 100 can fetch instructions from the ROM on-chip to obtain the executable file F3. When the electronic device 100 executes the executable file F3, it can read the instruction 512 of the component isolation layer 1 in the ROM according to the address Lq in the executable file F3 and call the component isolation layer 1. Since the component isolation layer 1 can obtain the actual storage address (i.e., address H2) of the third-party component 2 when statically linked, the electronic device 100 can execute the instruction 512 of the component isolation layer 1 to call the third-party component 2. In this way, the system application 1 can call the third-party component 2 using the component isolation layer 1 according to the fixed address used to encapsulate the third-party component 2 during operation.

[0213] In some embodiments, the storage area where address Lk and address Lk+1 are located can be the area in the ROM where the operating system is stored. The operating system, system applications, and system isolation layer can be stored together in an independent area in the ROM, such as storage area A1. That is, the operating system, system applications, and system isolation layer are always updated together. If any one or more of the contents of the operating system, system applications, and system isolation layer need to be updated, the electronic device 100 can re-burn the storage area A1 as a whole and write the updated operating system, system applications, and system isolation layer in the storage area A1. Among them, the system isolation layer is stored in the storage area corresponding to the fixed address in the storage area A1. The address L1, address Ln, address Lk, and address Lk+1 shown in Figure 5B can all be addresses in the storage area A1. In other embodiments, the operating system and system applications can be stored in different independent areas in the ROM respectively. For example, the operating system can be stored in the storage area A2 in the ROM. The system application can be stored in the storage area A3 in the ROM. When the operating system in the storage area A2 is updated, the storage area A3 can remain unchanged (that is, the system application does not need to be updated). When the system application in storage area A3 is updated, storage area A2 may remain unchanged (ie, the operating system may not need to be updated). In other embodiments, the system isolation layer and the operating system may also be stored in different independent areas in the ROM.

[0214] The storage area of ​​the component isolation layer (such as component isolation layer 1) in ROM can be an independent area distinct from the operating system, system applications, and system isolation layer. In other words, when one or more of the operating system, system applications, and system isolation layer are updated, the component isolation layer stored in ROM can remain unchanged without the need for re-burning.

[0215] The above-mentioned address Ln and address Lq are preset fixed addresses. Addresses L1, Ln, Lk and Lq are all physical addresses in the ROM. The storage address division and storage content in the ROM shown in Figure 5B are only exemplary descriptions of this application and should not constitute a limitation on this application.

[0216] It is understandable that the contents are not limited to being stored in ROM, and the system applications 1 and other system applications, binary difference isolation layer, operating system and the like may also be stored in other memories that support on-chip instruction fetching.

[0217] In some embodiments, one or more components pre-installed on the electronic device 100 before shipment may be removed.

[0218] FIG5C exemplarily shows another schematic diagram of storage locations of third-party components, binary difference isolation layer, system applications, and operating system in electronic device 100 .

[0219] As shown in Figure 5C, third-party components, binary difference isolation layer, system applications and operating system can all be stored in the ROM of electronic device 100. The storage locations of executable file F3 of system application 1, instruction 511 of system isolation layer 1, system function 1 and system function 2 in ROM can be referred to the description of Figure 5B.

[0220] The storage area at address Lp in the ROM may store the executable file F1 of the third-party component 1 , and the storage area at address Ls may store the executable file F2 of the third-party component 2 .

[0221] When running third-party component 1, electronic device 100 can fetch instructions from the ROM on-chip to obtain executable file F1. As can be seen from the previous embodiment, executable file F1 can contain a fixed address Ln used to encapsulate system function 1. When electronic device 100 executes executable file F1, it can use system isolation layer 1 to call system function 1 based on address Ln in executable file F1.

[0222] When running system application 1, electronic device 100 can fetch instructions from the ROM on-chip, obtain and execute executable file F3. As can be seen from the above embodiment, executable file F3 may contain a fixed address Lq for encapsulating third-party component 2. Address Lq may store instructions 512 of component isolation layer 1. Since component isolation layer 1 can obtain the actual storage address (i.e., address Ls) of third-party component 2 during static linking, electronic device 100 can use component isolation layer 1 to call third-party component 2 according to address Lq in executable file F3.

[0223] It should be noted that the storage area for third-party components in ROM can be an independent area distinct from the operating system, system applications, and binary difference isolation layer. In other words, when one or more of the operating system, system applications, and binary difference isolation layer are updated, the third-party components stored in ROM can remain unchanged without the need for re-burning. Optionally, the third-party components and the component isolation layer can be stored together in a separate area in ROM. In other words, the third-party components and the component isolation layer are always updated together.

[0224] The embodiment of the present application does not limit the partitioning of the storage area in the ROM.

[0225] In some embodiments, the component provider may also provide a new third-party component to the integrator after the electronic device 100 leaves the factory. The binary difference isolation layer that the component provider has provided to the integrator includes a system isolation layer for encapsulating the system functions required by the new third-party component. Upon receiving the new third-party component provided by the component provider, the integrator may link the new third-party component and publish it to the electronic device 100 based on the fixed address used to encapsulate the system function. The electronic device 100 may install the new third-party component, store the executable file of the new third-party component in Flash, and read it from Flash into RAM. Alternatively, the electronic device 100 may directly store the executable file of the new third-party component in a memory that supports on-chip instruction fetch (such as ROM). Optionally, the electronic device 100 may include an application market or other application for installing components or apps. The user may search for the new third-party component in the application market in the electronic device 100. In response to the user operation of installing the new third-party component, the electronic device 100 may obtain the executable file of the new third-party component and store the executable file of the new third-party component.

[0226] In some embodiments, system applications (such as system application 1, etc.) can also call system functions through the system isolation layer (such as system isolation layer 1) during runtime. For details, please refer to the method for third-party component 1 to call system functions through system isolation layer 1. In other words, system applications can also be decoupled from the operating system and updated independently without affecting each other.

[0227] That is to say, the third-party components installed by the electronic device 100 before leaving the factory and the third-party components triggered to be installed by the user after leaving the factory can all be components released through static linking based on the fixed address used to encapsulate the system functions required by the third-party components. The system isolation layer encapsulates the system functions required by the third-party components, and can isolate the dependency of the above-mentioned third-party components on the actual storage address of the system functions. The component isolation layer encapsulates the third-party components required by the system applications, and can isolate the dependency of the system applications on the actual storage address of the third-party components. In this way, the components and the operating system can be updated independently without affecting each other.

[0228] Case 2 ( FIG. 6A and FIG. 6B ): The third-party component is updated after the electronic device 100 leaves the factory.

[0229] Component providers and integrators can refer to the description in Scenario 1 above. It should be noted that since the component provider already provides binary difference isolation layers (such as system isolation layer 1 and component isolation layer 1), the integrator can also own the binary difference isolation layers. When updating a component, the component provider only needs to provide the updated third-party component.

[0230] Here, the update of third-party component 1 and third-party component 2 by the component provider is taken as an example for explanation.

[0231] As shown in Figure 6A, the component provider can update third-party component 1 and third-party component 2. The updated component of third-party component 1 can be third-party component 1′. The updated component of third-party component 2 can be third-party component 2′. The component provider can request the integrator to update the third-party components (including third-party component 1 and third-party component 2) and provide third-party component 1′ and third-party component 2′ to the integrator. For example, the component provider can provide the integrator with the target files compiled from the source files of third-party component 1′ and third-party component 2′. Upon receiving the target files of third-party component 1′ and third-party component 2′, the integrator can statically link third-party component 1′, third-party component 2′, and component isolation layer 1 into executable files and publish them to electronic device 100. Electronic device 100 can update third-party component 1, third-party component 2, and component isolation layer 1, and store the executable file F4 of third-party component 1′, the executable file F5 of third-party component 2′, and the instructions 611 of component isolation layer 1. In the scenario where third-party component 1 and third-party component 2 are updated, system applications such as system application 1, system isolation layer 1, and the operating system can remain unchanged. The electronic device 100 may still store the instructions of the system isolation layer 1 , the operating system, and the executable file F3 of the system application 1 .

[0232] Comparing Figures 5A and 6A , it can be seen that when third-party component 2 is updated, the statically linked instructions of component isolation layer 1, which encapsulates third-party component 2, are also updated. That is, instruction 512 shown in Figure 5A is updated to instruction 611 shown in Figure 6A . Instruction 512 and instruction 611 may be different.

[0233] Here, the reason why the instructions of the component isolation layer 1 after static linking are updated as the third-party component 2 is updated is explained.

[0234] When the third-party component 2 is updated to the third-party component 2′, statically linking the third-party component 2′ and the component isolation layer 1 may include: statically linking the target file of the third-party component 2′ to the executable file F5, determining the actual storage address of the executable file F5, and providing the actual storage address of the executable file F5 to the component isolation layer 1. Since the actual storage address of the executable file F5 may be different from the actual storage address of the executable file F2 of the third-party component 2 before the update, and the component isolation layer 1 needs to obtain the actual storage address of the third-party component 2 (or the third-party component 2′) to implement indexing and calling the third-party component 2 (or the third-party component 2′), the instructions after the static linking of the component isolation layer 1 need to be updated as the third-party component 2 is updated.

[0235] Before the third-party component 2 is updated, the instruction 512 of the component isolation layer 1 shown in FIG5A can be used to find and call the third-party component 2 according to the actual storage address of the third-party component 2. After the third-party component 2 is updated, the instruction 611 of the component isolation layer 1 shown in FIG6A can be used to find and call the third-party component 2′ according to the actual storage address of the third-party component 2′.

[0236] When component isolation layer 1 is statically linked and released to electronic device 100, electronic device 100 can store component isolation layer 1 instructions 611 in a storage area corresponding to the fixed address used to encapsulate third-party component 2 in memory. When third-party component 2′ is statically linked and released to electronic device 100, electronic device 100 can store executable file F5 in a storage area corresponding to the actual storage address of executable file F5.

[0237] It is understood that when the component isolation layer 1 is statically linked with the third-party component 2′, the source code of the component isolation layer 1 can remain unchanged, but the instructions of the component isolation layer 1 after static linking can be changed. In other words, when the third-party component is updated, the component provider does not need to provide the binary difference isolation layer again.

[0238] In addition, although the instructions of the component isolation layer 1 after static linking are updated as the third-party component 2 is updated, the address where the instructions of the component isolation layer 1 are stored does not change. In other words, the fixed address used to encapsulate the third-party component 2 will not change as the third-party component 2 is updated. Therefore, the system application 1 can still find the instruction 611 of the component isolation layer 1 based on the fixed address used to encapsulate the third-party component 2, and use the component isolation layer 1 to call the third-party component 2'. The system application 1 can be recompiled and linked. Since the operating system has not been updated, the operating system also does not need to be recompiled and linked. The actual storage address of the system function in the operating system has not changed, so the system isolation layer 1 does not need to be recompiled and linked.

[0239] In some embodiments, the third-party component 1′ still needs to call the system function 1. When the integrator uses the target file of the third-party component 1′ for static linking, the target file of the third-party component 1′ can be statically linked to the executable file F4 according to the fixed address used to encapsulate the system function 1. The executable file F4 may contain a fixed address for encapsulating the system function 1. The instructions 511 of the system isolation layer 1 may be stored in the storage area corresponding to the fixed address for encapsulating the system function 1. In this way, when the electronic device 100 executes the executable file F4, the electronic device 100 can call the system isolation layer 1 according to the fixed address used to encapsulate the system function 1, thereby using the system isolation layer 1 to call the system function 1.

[0240] Optionally, after the third-party component 1 is updated, the third-party component 1′ also needs to call the system function 2. The component provider shown in Figure 5A above has provided a system isolation layer for encapsulating the system function 2. For example, the ROM of the electronic device 100 contains a fixed address for encapsulating the system function 2, and the fixed address may store the instructions for the system isolation layer for encapsulating the system function 2 after compilation and linking. When the integrator uses the target file of the third-party component 1′ for static linking, the target file of the third-party component 1′ may be statically linked to an executable file based on the fixed address for encapsulating the system function 2. The executable file of the third-party component 1′ may contain a fixed address for encapsulating the system function 2. In this way, when the electronic device 100 executes the executable file of the third-party component 1′, it can call the system isolation layer based on the fixed address for encapsulating the system function 2, thereby using the system isolation layer to call the system function 2.

[0241] The embodiment of the present application does not limit the above-mentioned method of updating the third-party component 1 and the third-party component 2 in the electronic device 100. In one possible implementation, after the third-party component 1 is updated, the executable file F4 of the third-party component 1′ can overwrite the executable file F1 of the third-party component 1 shown in Figure 5A and be stored in the memory of the electronic device 100. In another possible implementation, the content that changes after the third-party component 1 is updated can be stored in the memory of the electronic device 100, and the content that does not change after the third-party component 1 is updated can remain unchanged in the memory and continue to be stored. The method for updating the third-party component 2 can refer to the above-mentioned method for updating the third-party component 1.

[0242] FIG6B exemplarily shows a schematic diagram of a storage location of third-party components, a binary difference isolation layer, system applications, and an operating system in the electronic device 100 .

[0243] As shown in Figure 6B, the memory of the electronic device 100 may include ROM, RAM, and Flash. The electronic device 100 may update the third-party component 1 and the third-party component 2 in Flash, and store the executable file F4 of the third-party component 1' and the executable file F5 of the third-party component 2' in Flash.

[0244] After the RAM is powered on, the electronic device 100 can read the executable file F4 and the executable file F5 from the Flash into the RAM. Among them, the electronic device 100 can store the executable file F4 in the storage area corresponding to the address H3 in the RAM, and store the executable file F5 in the storage area corresponding to the address H4 in the RAM. The above-mentioned address H3 and address H4 can be determined by the third-party component 1′ and the third-party component 2′ during the compilation and linking stage. When it is necessary to run the third-party component 1′, the electronic device 100 can obtain the executable file F4 from the storage area corresponding to the address H3 in the RAM and execute it. Address H3 can be called the execution address of the third-party component 1′. Similarly, when it is necessary to run the third-party component 2′, the electronic device 100 can obtain the executable file F5 from the storage area corresponding to the address H4 in the RAM and execute it. Address H4 can be called the execution address of the third-party component 2′. Address H3 and address H4 are only exemplary descriptions of the present application and should not constitute a limitation to the present application.

[0245] The address Lq in the ROM may be a fixed address used to encapsulate the third-party component 2. When the third-party component 2 is updated to the third-party component 2′, the electronic device 100 may update the component isolation layer 1 in the storage area corresponding to the address Lq. The electronic device 100 may update the content stored in the storage area corresponding to the address Lq in the ROM from the instruction 512 of the component isolation layer 1 shown in FIG. 5B to the instruction 611 of the component isolation layer 1 shown in FIG. 6B . For the storage content of other areas in the ROM, please refer to the description of FIG. 5B .

[0246] When the system application 1 is running, it can call the component isolation layer 1 through the instruction 611 of the component isolation layer 1 in the address Lq, and then use the component isolation layer 1 to call the third-party component 2'. It can be seen from the above embodiment that the executable file F3 of the system application 1 can contain the address Lq. When running the system application 1, the electronic device 100 can execute the executable file F3, read the instruction 611 of the component isolation layer 1 according to the address Lq in the executable file F3, and call the component isolation layer 1. Since the component isolation layer 1 can obtain the actual storage address (i.e., address H4) of the third-party component 2' during static linking, the electronic device 100 executes the instruction 611 of the component isolation layer 1 to call the third-party component 2'.

[0247] When running, the third-party component 1′ can call the system isolation layer 1 through the instruction 511 of the system isolation layer 1 at the address Ln, and then use the system isolation layer 1 to call the system function 1. As can be seen from the above embodiment, the executable file F4 of the third-party component 1′ can contain the address Ln. When running the third-party component 1′, the electronic device 100 can execute the executable file F4, read the instruction 511 of the system isolation layer 1 according to the address Ln in the executable file F4, and call the system isolation layer 1. The electronic device 100 executes the instruction 511 of the system isolation layer 1 to call the system function 1.

[0248] In some embodiments, the updated third-party component 1' and the third-party component 2' may also be stored in the ROM. For details, please refer to the introduction of FIG. 5C above. No further details will be given here.

[0249] It can be seen that when third-party components are updated, system applications and the operating system do not need to be updated accordingly. To allow system applications to call updated third-party components without being updated, the electronic device 100 can update the component isolation layer at the fixed address used to encapsulate the third-party components. The system application can find the updated component isolation layer based on the fixed address and use the component isolation layer to call the updated third-party components. The above method can effectively reduce the update cost of third-party components and improve the efficiency of third-party component updates in the electronic device 100.

[0250] Case 3 ( FIG. 7A and FIG. 7B ): The operating system of the electronic device 100 is updated after leaving the factory.

[0251] The integrator can refer to the above introduction in Case 1 and Case 2. It should be noted that the binary difference isolation layer (including system isolation layer 1 and component isolation layer 1) owned by the integrator can be the binary difference isolation layer provided by the component provider before the electronic device 100 leaves the factory as shown in Figure 5A above. Alternatively, the binary difference isolation layer owned by the integrator can also be a binary difference isolation layer updated by the component provider after the electronic device 100 leaves the factory. Among them, after the binary difference isolation layer is updated, it can include more system isolation layers that encapsulate different system functions, and more component isolation layers that encapsulate different third-party components. In this way, more third-party components can use the system isolation layer to call the system functions they need, and more system applications can use the component isolation layer to call the third-party components they need.

[0252] As shown in FIG7A , the integrator can update the operating system and statically link the system isolation layer 1, system application 1, and other system applications with the updated operating system and then publish them to the electronic device 100. The electronic device 100 can update the storage area of ​​the system isolation layer 1, system application 1, and operating system to store the executable file F6 of the system application 1, the instructions 711 of the system isolation layer 1, and the updated operating system.

[0253] The source program of system application 1 may remain unchanged. Since the order of compiling and / or linking the source program of system application 1 may change after the operating system update compared to the compilation and linking process before the operating system update, the content of the executable file generated by statically linking system application 1 with the updated operating system may change, and the storage location of the executable file may also change. To distinguish them, executable file F6 is used here to represent the executable file generated by statically linking system application 1 with the updated operating system.

[0254] After the operating system is updated, the storage address of the system function in the electronic device 100 may change. The system isolation layer indexes and calls the system function by obtaining the actual storage address of the system function during static linking. Therefore, the instructions of the system isolation layer 1 after static linking must be updated as the operating system is updated. Among them, the above-mentioned system isolation layer 1 is statically linked with the updated operating system, and the actual storage address of the system function 1 in the electronic device 100 after the operating system is updated can be obtained. To distinguish, instruction 711 is used here to represent the instruction generated after the system isolation layer 1 is statically linked with the updated operating system. Instruction 711 of the system isolation layer 1 can be used to find and call the system function 1 according to the actual storage address of the system function 1 after the operating system is updated. The instruction 511 of the system isolation layer 1 shown in Figure 5A above can be used to find and call the system function 1 according to the actual storage address of the system function 1 before the operating system is updated.

[0255] It is understandable that when the system isolation layer 1 is statically linked with the updated operating system, the source program of the system isolation layer 1 can remain unchanged, but the instructions of the system isolation layer 1 after static linking can be changed. In other words, when the operating system is updated, the component provider does not need to provide the binary difference isolation layer again.

[0256] In addition, although the instructions of the system isolation layer 1 after static linking are updated as the operating system is updated, the address where the instructions of the system isolation layer 1 are stored does not change. In other words, the fixed address used to encapsulate the system function 1 will not change with the system update. Therefore, the third-party component 1 can still find the instruction 711 of the system isolation layer 1 based on the fixed address used to encapsulate the system function 1, and use the system isolation layer 1 to call the system function 1 after the operating system is updated. The third-party component 1 can be linked without recompilation. The third-party component 2 also does not need to be recompiled. The component isolation layer 1 is used to encapsulate the third-party component 2. Since the third-party component 2 has not been updated, the component isolation layer 1 does not need to be recompiled and linked.

[0257] It can be seen that the instructions of the system isolation layer 1 may change before and after the above-mentioned operating system is updated. For example, the instruction 511 shown in Figure 5A changes to the instruction 711 shown in Figure 7A. However, the instructions of the system isolation layer 1 are always stored in the same storage area before and after the operating system is updated. The above-mentioned storage in the same storage area can mean storage in the storage area corresponding to the same address (i.e., the fixed address used to encapsulate system function 1). In the present application, the unchanged storage area of ​​information can mean that the storage address of the information on the memory (such as ROM, RAM, etc.) remains unchanged.

[0258] FIG7B exemplarily shows a schematic diagram of a storage location of third-party components, a binary difference isolation layer, system applications, and an operating system in the electronic device 100 .

[0259] As shown in FIG7B , the memory of the electronic device 100 may include ROM, RAM, and Flash. The electronic device 100 may update the system application 1, the system isolation layer 1, and the operating system in the ROM. For example, the electronic device 100 may store the executable file F6 of the system application 1 in the storage area at address Lm in the ROM, store the system function 1 in the storage area at address Lr in the ROM, store the system function 2 in the storage area at address Lr+1 in the ROM, and still store the instruction 711 of the system isolation layer 1 in the storage area at address Ln in the ROM.

[0260] By comparing the aforementioned Figures 5B and 7B, it can be seen that after the operating system of the electronic device 100 is updated, the executable file of the system application 1 can be changed from executable file F3 to executable file F6, and the storage address can be changed from address L1 to Lm. After the operating system is updated, the storage address of the system function 1 can be changed from address Lk to Lr. The fixed address used to encapsulate the system function 1 before and after the operating system is updated can remain unchanged (for example, still address Ln), and the fixed address used to encapsulate the third-party component 2 can also remain unchanged (for example, still Lq). Since the instructions of the system isolation layer 1 are changed after the operating system is updated, the electronic device 100 can update the content in the storage area corresponding to the address Ln, and update the instruction 511 of the system isolation layer 1 shown in Figure 5B to the instruction 711 of the system isolation layer 1. Since the instructions of the component isolation layer 1 remain unchanged after the operating system is updated, the electronic device 100 can keep the content in the storage area corresponding to the address Lq unchanged, that is, it is still the instruction 512 of the component isolation layer 1.

[0261] The storage contents in the Flash and RAM can refer to the introduction of FIG. 5B .

[0262] When the system application 1 is running, it can call the component isolation layer 1 through the instruction 711 of the component isolation layer 1 in the address Lq, and then use the component isolation layer 1 to call the third-party component 2. It can be seen from the above embodiment that when the integrator statically links the system application 1, it can statically link the target file of the system application 1 into the executable file F6 according to the fixed address (i.e., address Lq) used to encapsulate the third-party component 2. That is, the executable file F6 contains the address Lq. When running the system application 1, the electronic device 100 can fetch instructions from the ROM on-chip, obtain and execute the executable file F6. The electronic device 100 can read the instruction 512 of the component isolation layer 1 according to the address Lq in the executable file F6 and call the component isolation layer 1. Since the component isolation layer 1 can obtain the actual storage address (i.e., address H2) of the third-party component 2 when statically linked, the electronic device 100 executes the instruction 512 of the component isolation layer 1 to call the third-party component 2.

[0263] When running, the third-party component 1 can call the system isolation layer 1 through the instruction 711 of the system isolation layer 1 in the address Ln, and then use the system isolation layer 1 to call the system function 1. It can be seen from the above embodiment that the executable file F1 of the third-party component 1 can contain the address Ln. When running the third-party component 1, the electronic device 100 can execute the executable file F1, read the instruction 711 of the system isolation layer 1 according to the address Ln in the executable file F1, and call the system isolation layer. Since the system isolation layer 1 can obtain the actual storage address of the system function 1 (i.e., the address Lr) during static linking, the electronic device 100 executes the instruction 711 of the system isolation layer 1 to call the system function 1.

[0264] It can be understood that the storage address division and storage content in the ROM shown in Figure 7B are only exemplary descriptions of the present application and should not constitute a limitation to the present application.

[0265] In some embodiments, when system applications such as system application 1 and the operating system are stored in two independent storage areas in ROM, when the operating system is updated, the system applications do not need to be recompiled and linked. That is, the electronic device 100 does not need to re-burn the storage area where system applications such as system application 1 are located. Among them, if the system application needs to call the system function after the operating system is updated, the system application can use the system isolation layer to call the system function. For details, please refer to the method of third-party component 1 using system isolation layer 1 to call system function 1.

[0266] It can be seen that when the operating system is updated, the updated operating system can be statically linked with the system isolation layer and then released to the electronic device 100. The system isolation layer can sense the changes in the operating system and encapsulate the updated system functions of the operating system according to the changes. In this way, third-party components and / or system applications can still find the system isolation layer according to the fixed address, thereby calling the updated system functions of the operating system. Among them, the upper-layer components may not perceive the changes in the above-mentioned operating system. When the operating system is updated, the components do not need to be recompiled and linked. In this way, the operating system can be updated independently of the components, reducing the update cost of the system.

[0267] The following describes a method for implementing a binary difference isolation layer provided in an embodiment of the present application.

[0268] In one possible implementation, the binary difference isolation layer can encapsulate the function using the "__attribute__" function in the C language. The "__attribute__" function can solidify the interface address used to call the encapsulated function. Regardless of whether the storage address of the encapsulated function changes, the binary difference isolation layer can be stored at a fixed address.

[0269] Here, the system function (read function) for reading data is taken as an example to illustrate how to implement the system isolation layer.

[0270] The read function can include: int read(int fd, char* buf, size_t len). At runtime, the component can call the read function to read the specified data by passing the corresponding parameters to the read function. For example, the parameter passed to the read function can include the storage address of the data to be read. In this way, the component can call the read function to read the data at the storage address.

[0271] The content of the system isolation layer used to encapsulate the read function may include: int__attribute__((section(".adaptor"),address(0x10000)))adaptor_read(int fd,char*buf,size_t len).

[0272] Among them, "0x10000" may be a fixed address used to encapsulate the read function. That is, after the system isolation layer is statically linked, the electronic device 100 can store the system isolation layer instructions in the storage area corresponding to the fixed address. In some embodiments, the above-mentioned fixed address may be located in the ROM of the electronic device 100. This fixed address is only an exemplary description of this application and should not constitute a limitation of this application.

[0273] During the process of statically linking the system isolation layer with the operating system, the system isolation layer can obtain the actual storage address of the read function in the electronic device 100 .

[0274] Based on the fixed address used to encapsulate the read function, the way the component calls the read function may include: int(0x10000)(int fd,char*buf,size_t len). In other words, when developing the component, the component developer can write the above-mentioned fixed address in the source program of the component, and use the fixed address to indicate that the component needs to apply the system function encapsulated by the fixed address. Among them, since the above-mentioned fixed address is written in the source program of the component, after compilation and linking, the executable file of the component can include the above-mentioned fixed address used to encapsulate the read function, so that the component can index to the system isolation layer based on the fixed address, and use the system isolation layer to call the read function.

[0275] As can be seen, the system isolation layer is a computer program that encapsulates system functions at a specified fixed address. After compilation and linking, the system isolation layer can be stored in the electronic device 100 and called by components at runtime based on the fixed address. Components can call the target system function by calling the system isolation layer.

[0276] The "__attribute__" function in the C language is only one implementation method for encapsulating system functions and should not be construed as limiting this application. The binary difference isolation layer can also be implemented by other methods of encapsulating functional functions.

[0277] The implementation of the component isolation layer can refer to the implementation of the system isolation layer described above. No further details will be given here. The component isolation layer can be compiled and linked together with the third-party components it encapsulates to obtain the actual storage address of the third-party components it encapsulates in the electronic device 100.

[0278] Among them, since the actual storage address of the functional function encapsulated by the binary difference isolation layer may be located in ROM or RAM, the actual storage address of the functional function obtained by the binary difference isolation layer during the static linking process may include: the address in ROM and the address in RAM.

[0279] The embodiments of this application do not limit the name of the binary difference isolation layer. For example, the binary difference isolation layer may also be called an isolation module, an isolation function, an isolation interface, and so on. Other programs that can encapsulate the actual storage address of the target system function within a specified fixed address are also within the scope of protection of this solution.

[0280] FIG8 exemplarily shows a schematic diagram of the architecture of a communication system 80 provided in this application.

[0281] As shown in FIG8 , the communication system 80 may include the electronic device 100 , a component and binary difference isolation layer publishing server 810 , a component and binary difference isolation layer development environment 820 , an integrator server 830 , and an integrator development environment 840 .

[0282] The electronic device 100 may be an electronic device with an MCU as a computing core. The structure of the electronic device 100 may refer to the description of the above embodiments.

[0283] The component and binary difference isolation layer publishing server 810 and the component and binary difference isolation layer development environment 820 may be devices of the aforementioned component provider. The component and binary difference isolation layer development environment 820 may include one or more devices used by developers of the component provider to develop third-party components and binary difference isolation layers. In some embodiments, the component and binary difference isolation layer development environment 820 or the component and binary difference isolation layer publishing server 810 may compile the source files and binary difference isolation layer of the third-party component to obtain the target files of the third-party component and the target files of the binary difference isolation layer.

[0284] The component and binary difference isolation layer development environment 820 can upload the developed third-party component and binary difference isolation layer to the component and binary difference isolation layer publishing server 810. For example, the component and binary difference isolation layer development environment 820 can upload the source file and / or target file of the third-party component to the component and binary difference isolation layer publishing server 810, and upload the source file of the binary difference isolation layer to the component and binary difference isolation layer publishing server 810.

[0285] The component and binary difference isolation layer publishing server 810 may send the target file of the third-party component and the target file of the binary difference isolation layer to the integrator server 830 .

[0286] The integrator server 830 and the integrator development environment 840 may be the aforementioned integrator's devices. The integrator may also be referred to as a device provider, etc. The integrator development environment 840 may include one or more devices used by the integrator's developers to develop an operating system and implement the design of the electronic device 100. The integrator development environment 840 may upload the developed operating system to the integrator server 830. In some embodiments, the integrator's developers may also develop system applications. The integrator development environment 840 may upload the developed system applications to the integrator server 830.

[0287] Upon receiving the operating system, the integrator server 830 may compile the operating system. Alternatively, the integrator development environment 840 may compile the operating system and upload the compiled operating system to the integrator server 830.

[0288] The integrator server 830 can statically link the compiled operating system, compiled components (such as third-party components, system applications, etc.) and the binary difference isolation layer, and publish them to the electronic device 100. The specific process can refer to the description of the above embodiment.

[0289] In some embodiments, the component and binary difference isolation layer development environment 820 can upload the updated third-party component to the component and binary difference isolation layer publishing server 810. The component and binary difference isolation layer publishing server 810 can send the target file of the updated third-party component to the integrator server 830. The integrator server 830 can then statically link the updated third-party component and publish it to the electronic device 100. In some embodiments, the integrator server 830 can statically link the updated third-party component and the component isolation layer used to encapsulate the updated third-party component and then publish it to the electronic device 100.

[0290] In some embodiments, the integrator development environment 840 may upload the updated operating system to the integrator server 830. The integrator server 830 may statically link the system isolation layer and the updated operating system together and publish the static link to the electronic device 100.

[0291] As can be seen from the above-mentioned communication system 80, in the scenario where components and operating systems are fully statically linked on an MCU device, the static linking method provided in this application can isolate the component's dependency on the actual storage address of system functions through the system isolation layer, and the component isolation layer can isolate the system application's dependency on the actual storage address of third-party components. The above-mentioned method can achieve decoupling of components from the operating system. Both components and the operating system can be updated independently. This can effectively reduce the update costs of components and the operating system.

[0292] It is understood that the various user interfaces described in the embodiments of this application are merely exemplary interfaces and do not limit the scope of this application. In other embodiments, the user interface may adopt a different interface layout, include more or fewer controls, and add or remove other functional options. As long as they are based on the same inventive concept provided by this application, they are all within the scope of protection of this application.

[0293] It should be noted that, without causing any contradiction or conflict, any feature in any embodiment of the present application, or any part of any feature, can be combined, and the combined technical solution is also within the scope of the embodiments of the present application.

[0294] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A static linking method, characterized in that: The method is applied to an electronic device, the electronic device includes a first operating system, a first storage area corresponding to a first address in the electronic device stores a first calling instruction, the first calling instruction is used to call a first system function provided by the first operating system, and the method includes: The electronic device updates the first operating system, and the first operating system is updated in a static link manner; The electronic device updates the first calling instruction in the first storage area to a second calling instruction, where the second calling instruction is used to call the first system function provided by the updated first operating system; The electronic device runs a first component on the updated first operating system, obtains the second calling instruction from the first storage area according to the first address, and executes the second calling instruction for the first component to call the first system function.

2. The method according to claim 1, characterized in that The method further comprises: When the electronic device runs the first component on the first operating system before updating, it obtains the first calling instruction from the first storage area according to the first address, and executes the first calling instruction for the first component to call the first system function.

3. The method according to claim 1 or 2, characterized in that: The first calling instruction includes a storage address of the first system function in the electronic device before the first operating system is updated, and the second calling instruction includes a storage address of the first system function in the electronic device after the first operating system is updated.

4. The method according to any one of claims 1 to 3, characterized in that Before and after the first operating system is updated, the first component stored in the electronic device remains unchanged.

5. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The electronic device updates the first component, the updated first component still needs to call the first system function, and the first component is updated in a static link manner; The electronic device runs the updated first component on the first operating system before updating, obtains the first calling instruction from the first storage area according to the first address, and executes the first calling instruction for the updated first component to call the first system function.

6. The method according to claim 5, characterized in that A second storage area corresponding to a second address in the electronic device stores a third calling instruction, a second system function provided by the first operating system before the third calling instruction is updated, and the first component after the update also needs to call the second system function, and the method further includes: The electronic device runs the updated first component in the first operating system before updating, obtains the third calling instruction from the second storage area according to the second address, and executes the first calling instruction for the updated first component to call the second system function.

7. The method according to any one of claims 1 to 6, characterized in that The electronic device further includes a second component and a third component, the second component is a third-party component, the third component is a system application, the third component needs to call the second component, a third storage area corresponding to a third address in the electronic device stores a fourth calling instruction, and the fourth calling instruction is used to call the second component, and the method further includes: The electronic device updates the second component, and the second component is updated in a static link manner; The electronic device updates the fourth calling instruction in the third storage area to a fifth calling instruction, where the fifth calling instruction is used to call the updated second component; The electronic device runs the third component after updating the second component, obtains the fifth calling instruction from the third storage area according to the third address, and executes the fifth calling instruction for the third component to call the second component.

8. The method according to claim 7, characterized in that The method further comprises: The electronic device runs the third component before the second component, obtains the fourth calling instruction from the third storage area according to the third address, and executes the fourth calling instruction for the third component to call the second component.

9. The method according to claim 7 or 8, characterized in that: The fourth calling instruction includes a storage address of the second component in the electronic device before updating, and the fifth calling instruction includes a storage address of the second component in the electronic device after updating.

10. The method according to any one of claims 7 to 9, characterized in that: Before and after the second component is updated, the third component and the first operating system stored in the electronic device remain unchanged.

11. The method according to any one of claims 1 to 10, characterized in that The update content of the first operating system includes one or more of the following: a change in the storage address of the first system function, a change in the content of the first system function.

12. The method according to any one of claims 1 to 11, characterized in that The first storage area is a storage area on a ROM in the electronic device.

13. The method according to claims 1-12, characterized in that The first component is a third-party component.

14. An electronic device, characterized in that: The electronic device comprises a memory and a processor, wherein the memory is used to store a computer program; and the processor is used to call the computer program so that the electronic device executes the method according to any one of claims 1 to 13.

15. An electronic device, the electronic device being a first electronic device, characterized in that: The first electronic device includes a component providing module and a calling interface providing module, wherein: The component providing module is used to provide a first component, the first component needs to call a first system function provided by a first operating system, and the first component is published to a second electronic device including the first operating system after being statically linked; The calling interface providing module is used to provide a first interface, and the first interface is used to encapsulate the first system function in a first storage area corresponding to a first address in the second electronic device, and the first interface is published to the second electronic device after static linking; the first address is included in the program used to implement the first component.

16. The electronic device according to claim 15, characterized in that: The first interface obtains the storage address of the first system function in the second electronic device during the static linking stage, and generates a calling instruction for calling the first system function after the static linking.

17. The electronic device according to claim 15 or 16, characterized in that: The component providing module is further used to provide a second component, the second component is called by a third component in the second electronic device, and the second component is published to the second electronic device after being statically linked; The calling interface providing module is further used to provide a second interface, where the second interface is used to encapsulate the second component in a third storage area corresponding to a third address in the second electronic device, and the second interface is published to the second electronic device after static linking.

18. The electronic device according to claim 17, characterized in that: The second interface obtains the storage address of the second component in the second electronic device during the static linking stage, and generates a calling instruction for calling the second component after the static linking.

19. The electronic device according to claim 17 or 18, characterized in that: The component providing module is also used to provide the updated second component, and the updated second component is published to the second electronic device after static linking; wherein, the second interface obtains the storage address of the updated second component in the second electronic device during the static linking stage, and generates a calling instruction for calling the updated second component after static linking.

20. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on an electronic device, the electronic device executes the method according to any one of claims 1 to 13.

21. A computer program product, characterized in that The computer program product comprises computer instructions, and when the computer instructions are run on an electronic device, the electronic device executes the method according to any one of claims 1 to 13.

Images