Plug-in running system, plug-in running method, and electronic device

Abstract

The application discloses a plug-in running method and a plug-in running system. The method comprises the following steps: a user creates an application plug-in on a first operating system, wherein the application plug-in needs to call a first SDK under a second operating system. A first electronic device packs and installs a configuration file of the application plug-in, and starts the application plug-in on the first operating system. Then, a class loader module loads classes of the second SDK, wherein the second SDK is adapted to the first operating system. The first electronic device runs the application on the first operating system, and a business logic module finds the classes of the first SDK according to a mapping relationship. If the finding is successful, the first electronic device can use the first SDK of the second operating system. In this way, a developer can develop an application required by a user by using a plurality of SDKs under the second operating system, and does not need to write program codes one by one to realize the function logic of the application on the first operating system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronics, and in particular to a plug-in running system, a plug-in running method and an electronic device. BACKGROUND

[0002] At present, various electronic devices (for example, mobile phones, tablets, computers, car machines, smart watches and the like) can install application programs (application, APP). In order to improve the reusability of application programs, shorten the development period of application programs, save development costs, and bring flexibility to application developers, a plug-in, for example, a software development kit (software development kit, SDK), can be set for an application program. Generally speaking, for the same SDK, an application developer needs to write a set of program codes for different operating systems, and the code written by the application developer for an operating system electronic device cannot be directly reused in another electronic device of a different operating system. For example, the application developer needs to write a set of program codes for a mobile phone of an Android system, a mobile phone of an IOS system, a computer of a windows system, and the like, and the program codes of different systems cannot be reused. In this way, the application developer cannot conveniently develop an application program in another operating system by using an existing SDK of an operating system, and it takes a lot of time to develop an application program.

[0003] Therefore, how to promote the reuse of SDKs in different operating systems and accelerate the software development efficiency is a problem to be solved. SUMMARY

[0004] The purpose of the present application is to provide a plug-in running method, which can configure an SDK through an API mapping relationship, so that a first operating system can use an existing SDK of a second operating system. The method can promote the reuse of SDKs in different operating systems, accelerate the efficiency of software development, and further promote the ecological expansion of the first operating system.

[0005] The objects and other objects will be achieved by the features in the independent claims. Further implementation ways are embodied in the dependent claims, the description and the drawings.

[0006] In a first aspect, the present application provides a plug-in running method, which is applied to an electronic device. The method comprises: receiving, by the electronic device, a software development kit (SDK) calling request input by a user in a first operating system, wherein the SDK calling request carries an SDK identifier; determining a first SDK according to the SDK identifier, wherein the first SDK is a set of application software development tools established under a second operating system; obtaining the first SDK from the second operating system; and configuring the first SDK into a second SDK available for the first operating system.

[0007] In this way, the user can use the first SDK in the second operating system, and does not need to write a set of SDK for the first operating system, thereby saving the time for software research and development.

[0008] With reference to the first aspect, in some embodiments, the electronic device receives the SDK calling request input by the user in the first operating system, including: accepting the SDK calling request sent by the user to the first operating system by clicking the user interface; or accepting the SDK calling request input by the user through a shell command.

[0009] That is, the user can send the SDK calling request to the electronic device by directly clicking a specific button on the user interface, or can send the SDK calling request to the user by inputting a shell command.

[0010] With reference to the first aspect, in some embodiments, the application programming interface (API) of the second SDK in the first operating system is different from the API definition and declaration structure of the second operating system, and the first SDK cannot be directly used in the first operating system.

[0011] For example, when the first operating system is a Hongmeng system and the second operating system is an Android system, because the APIs of the Hongmeng system and the Android system are different, the application developer of the Hongmeng system cannot directly use the SDK adapted to the Android operating system.

[0012] With reference to the first aspect, in some embodiments, before determining the first SDK according to the SDK identifier, the method further includes: one-to-one mapping the API of the first SDK and the API of the second SDK, and then registering the mapping relationship.

[0013] The mapping relationship records the correspondence between the API of the first SDK and the API of the second SDK, and the mapping relationship can be recorded in a first file independent of the SDK, or can be recorded in a second file integrated in the SDK.

[0014] That is, the API mapping relationship of the first SDK and the second SDK can be integrated in the SDK by the SDK developer, and the API mapping relationship is loaded into the electronic device together when the second operating system loads the SDK. In other embodiments, the API mapping relationship can also be provided separately by the developer, and the API mapping relationship is not integrated in the SDK and is loaded together when the application is installed.

[0015] With reference to the first aspect, in some embodiments, after the first SDK is configured as the second SDK available to the first operating system, the method further includes: finding the API of the first SDK corresponding to the API of the second SDK according to the mapping relationship, and calling the API of the first SDK according to the API of the second SDK in the second operating system.

[0016] That is to say, when the user needs to call the second SDK, the electronic device only needs to find the corresponding first SDK according to the API mapping relationship, and then the function in the first SDK can be used.

[0017] In this way, the user can directly use the function of the first SDK without developing an SDK for the first operating system again and rewriting a set of codes again.

[0018] In a second aspect, the present application provides an electronic device, comprising a receiving module, a determining module, an obtaining module and a configuring module, wherein the receiving module is configured to receive a software development kit (SDK) calling request input by a user in a first operating system, wherein the SDK calling request carries an SDK identifier; the determining module is configured to determine a first SDK according to the SDK identifier, the first SDK being a set of application software development tools established under a second operating system; the obtaining module is configured to obtain the first SDK from the second operating system; and the configuring module is configured to configure the first SDK into a second SDK available for the first operating system.

[0019] In some possible designs, the receiving module is configured to receive the SDK calling request input by the user in the first operating system, which can be configured to accept the SDK calling request sent by the user to the first operating system by clicking a user interface, or can be configured to accept the SDK calling request input by the user through a shell command.

[0020] In some possible designs, the application programming interface (API) of the second SDK in the first operating system is different from the API of the first SDK in the second operating system, and the first SDK cannot be directly used in the first operating system.

[0021] In some possible designs, the electronic device further comprises a registering module configured to map the API of the first SDK and the API of the second SDK one by one and register the mapping relationship, wherein the mapping relationship records the correspondence between the API of the first SDK and the API of the second SDK; the mapping relationship is recorded in a first file independent of the SDK, or the mapping relationship is recorded in a second file integrated in the SDK.

[0022] In some possible designs, the electronic module further comprises a finding module and a calling module, wherein the finding module is configured to find the API of the first SDK corresponding to the API of the second SDK according to the mapping relationship; and the calling module is configured to call the API of the first SDK by the API of the second SDK in the second operating system.

[0023] In a third aspect, the present application provides a plug-in running system, characterized by comprising an electronic device, and the electronic device performs any possible implementation manner in the first aspect.

[0024] In a fourth aspect, the present application provides a computer readable storage medium, having stored therein instructions which, when executed on a computer, cause the computer to perform any possible implementation of the first aspect.

[0025] In a fifth aspect, the present application provides a computer program product comprising instructions which, when executed on a computer, cause the computer to perform any possible implementation of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0026] The drawings used by the embodiments of the present application are described below.

[0027] Figure 1 is a schematic diagram of a plug-in running system structure provided by the embodiments of the present application;

[0028] Figure 2 is a schematic diagram of a hardware structure of an electronic device provided by the embodiments of the present application;

[0029] Figure 3 is a schematic diagram of a layered structure of an operating system of an electronic device provided by the embodiments of the present application;

[0030] Figure 4 is a schematic diagram of an SDK structure provided by the embodiments of the present application;

[0031] Figure 5 is a schematic diagram of a module of a plug-in running system provided by the embodiments of the present application;

[0032] Figures 6A-6D is a schematic diagram of a user interface of an application program provided by the embodiments of the present application;

[0033] Figures 7A-7B is a schematic diagram of a user interface of an application program created by code provided by the embodiments of the present application;

[0034] Figure 8 is a schematic diagram of a flow of a plug-in running method provided by the embodiments of the present application;

[0035] Figure 9 is a schematic diagram of a relationship of application program files provided by the embodiments of the present application;

[0036] Figure 10 is a schematic diagram of a class loader work flow provided by the embodiments of the present application;

[0037] Figure 11 is a schematic diagram of data interaction of a plug-in running method provided by the embodiments of the present application;

[0038] Figure 12is an ecological schematic diagram of a plug-in running method provided by an embodiment of the present application.

[0039] Figure 13 is a three-party interaction flow schematic diagram provided by an embodiment of the present application.

[0040] Figure 14 is a schematic block diagram of an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0041] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; the "and / or" in the text only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which means that there are three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0042] Hereinafter, the terms "first" and "second" are used only for descriptive purposes and should not be construed as implying or suggesting relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more features. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" is two or more than two. In addition, the terms "include" and "have" and any variations thereof mentioned in the description of the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can optionally include other steps or units not listed, or can optionally include other steps or units inherent to the process, method, product or device. It should be noted that in the embodiments of the present application, the words "exemplarily" or "for example" are used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words "exemplarily" or "for example" are intended to present the relevant concept in a specific manner.

[0043] First, some concepts (such as software development kit SDK, plug-in Plug-in, and application programming interface API) related to the embodiments of the present application are introduced.

[0044] (1) Software development kit (software development kit, SDK)

[0045] SDK is a collection of development tools for a particular software package, software framework, hardware platform, operating system, etc. It is a toolkit provided by a third party service provider to implement a certain function of a software product.

[0046] It can provide some files of application programming interface API for a certain programming language, or it can include complex hardware that can communicate with a certain embedded system. Generally, a software development kit includes utility tools for debugging and other purposes. A software development kit also often includes sample code, supporting technical notes, or other supporting documents that clarify doubts for basic reference materials.

[0047] (2) Plug-in

[0048] Plug-in, also known as addin, add-in, addon or add-on, is a program written according to a certain specification of application programming interface (API). In some cases, plug-ins may need to call the function library or data provided by the original system, so they can only run on the system platform specified by the program and cannot run independently of the designated platform.

[0049] Application software provides services that enable plug-ins to be applied, including providing loading methods so that plug-ins can be loaded into application programs and network transmission protocols to interact with plug-ins. Plug-ins must rely on application programs to function, and plug-ins alone cannot function properly. Conversely, application programs can run without relying on plug-ins, so plug-ins can be loaded onto application programs and dynamically updated without any changes to the application program.

[0050] (3) Application Programming Interface (API)

[0051] Application Programming Interface (API) is a calling interface left by the operating system for application programs. Application programs can call the operating system's API to make the operating system execute the application's commands. API is a collection of definitions, programs and protocols that enable communication between computer software. One of the main functions of API is to provide a set of common functions.

[0052] API is also a kind of middleware, which provides data sharing for various different platforms. In the practice of programming design, the design of programming interface should first make the responsibilities of software system be reasonably divided. Good interface design can reduce the mutual dependence of each part of the system, improve the cohesion of the composed unit, reduce the coupling degree between the composed units, and thus improve the maintainability and scalability of the system.

[0053] (4) Activity Management Service (AMS)

[0054] AMS (ActivityManager Service) is the most core service in the operating system, which is mainly responsible for the startup, switching, scheduling of the four components in the system, and the management and scheduling of application processes.

[0055] Among them, the operating system is a free and open source system based on Linux kernel. It is mainly used in mobile devices such as smart phones, tablet computers, smart watches and other terminal devices. Application developers can have full access to the application programming interface (API) framework used by the core application. The architecture design of the application simplifies the reuse of components; any application can publish its function block and any other application can use the function block it publishes. Similarly, the application reuse mechanism also makes it easy for users to replace program components.

[0056] The four components of the above operating system are: Activity: used to represent functions. In the first operating system, Activity can also be called ability. Service: background service running, not providing interface presentation. Broadcast receiver: used to receive broadcasts. Content provider: supports storing and reading data in multiple applications, equivalent to a database.

[0057] (5) Document Type

[0058] The document types involved in the present application include operating system archive files, Java archive files, shared library files, application program packages, dex files and data compression files.

[0059] The operating system archive file (Android Archive, AAR) is a binary archive file of an Android library project, which contains class and res resource files. Therefore, after the aar file is decompressed and opened, it can be seen that the contents of each aar after decompression may not be exactly the same, but will all contain AndroidManifest.xml, classes.jar, res, R.txt.

[0060] Java Archive (JAR) is a software package file format, usually used to aggregate a large number of Java class files, related metadata and resource files into a file, so as to develop Java platform application software or library. JAR file can not only be used for compression and release, but also be used for deployment and packaging of library, component and plug-in program, and can be directly used by tools such as compiler and JVM.

[0061] Shared Object (SO) is an executable shared object file under Linux. The SO file format is ELF file format, and the shared library file and the target file have a unified format.

[0062] Android application package (APK) is an application package file format used by the operating system to distribute and install mobile applications and middleware. The code of the application must be compiled first and then packaged into an APK file that can be recognized by the Android system before it can run on an Android device. An APK file contains compiled code files (.dex files), file resources (resources), native resource files (assets), certificates (certificates), and manifest files (manifest files).

[0063] Dex file is an executable file of the operating system, which contains all the operation instructions and runtime data of the application. Each Apk installation package contains dex files, which contain all the source code of the app. The corresponding java source code can be obtained through the decompilation tool.

[0064] Zip file is a data compression and document storage file format. Zip file is a relatively simple archive format that compresses each file separately. Among them, compressing each file separately allows independent files to be retrieved without reading additional data.

[0065] (6) Class loader (classloader)

[0066] Class loader is used to load Java classes into Java virtual machine, and is a part of Java Runtime Environment (JRE). Java classes are usually loaded on demand, that is, the first time the class is used. Thanks to the class loader, the Java runtime system does not need to know the file and the file system.

[0067] In the Android system, there are two categories of class loaders: one is a Path Class Loader, which is used to load the application package already installed in the system; and the other is a Dex Class Loader, which is used to load the jar package or APK that has not been installed, including dex, jar, apk, zip files in any directory. If it is necessary to dynamically load the jar package on the operating system, only the Dex Class Loader can be used.

[0068] To solve the problem of SDK reuse, the application provides a plug-in running system 10. As shown in the figure, the plug-in running system 10 involves a first electronic device 100 and a second electronic device 200. The first electronic device 100 is equipped with a first operating system 110. The second electronic device 200 is equipped with a second operating system 210. The plug-in running system 10 is used to convert the first SDK of the second operating system 210 application into the second SDK available for the first operating system 110. In this way, the developer can use the existing multiple SDKs under the second operating system architecture to develop the application required by the user, without the need to write program codes one by one to realize the function logic of the application on the first operating system 110. Figure 1

[0069] In the embodiment of the application, the developer can also be referred to as a user, who can develop an application in the first electronic device 100 provided in the application.

[0070] The following describes an exemplary first electronic device 100 provided in the embodiments of the application.

[0071] Figure 2 The structure of the first electronic device 100 is shown. It should be understood that the first electronic device 100 can have more or fewer components than those shown in FIG. 1, can combine two or more components, or can have a different component configuration. Figure 2 The various components shown in FIG. 1 can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits. Figure 2 The various components shown in FIG. 1 can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0072] The first electronic device 100 can include a processor 101, a memory 102, a transceiver 103, a display screen 104, a sensor 105, etc., wherein:

[0073] The processor 101 can be used to obtain the data entity type supported by the connection point of the component, and determine whether the data entity types supported by the connection points of the two components match, and is also used to find the component matching the data entity type supported by the output connection point of the component according to the user operation.

[0074] ​In some embodiments, the processor 101 can include one or more processing units. For example, the processor 101 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video code, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices or integrated in one or more processors.

[0075] The controller can be the nerve center and command center of the first electronic device 100. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.

[0076] The processor 101 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 101 is a cache memory. The memory can save instructions or data that have just been used or are used repeatedly by the processor 101. If the processor 101 needs to use the instructions or data again, it can directly call them from the memory. This avoids repeated access and reduces the waiting time of the processor 101, thus improving the efficiency of the system.

[0077] In some embodiments, the processor 101 can include one or more interfaces. The interfaces can include 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, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0078] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 101 can contain multiple sets of I2C bus. The processor 101 can be coupled with touch sensor, charger, flash, camera, etc. through different I2C bus interfaces respectively. For example, the processor 101 can be coupled with the touch sensor through the I2C interface, so that the processor 101 and the touch sensor communicate through the I2C bus interface, and the touch function of the first electronic device 100 is realized.

[0079] The I2S interface can be used for audio communication. In some embodiments, the processor 101 can contain multiple sets of I2S bus. The processor 101 can be coupled with the audio device through the I2S bus, and communication between the processor 101 and the audio device is realized. In some embodiments, the audio device can deliver audio signals to the wireless communication module through the I2S interface, and the function of answering the phone through the Bluetooth earphone is realized.

[0080] The PCM interface can also be used for audio communication, which samples, quantizes and encodes analog signals. In some embodiments, the audio device and the wireless communication module can be coupled through the PCM bus interface. In some embodiments, the audio device can also deliver audio signals to the wireless communication module through the PCM interface, and the function of answering the phone through the Bluetooth earphone is realized. Both the I2S interface and the PCM interface can be used for audio communication.

[0081] The UART interface is a universal serial data bus, which is used for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is usually used to connect the processor 101 and the wireless communication module. For example, the processor 101 communicates with the Bluetooth module in the wireless communication module through the UART interface, and the Bluetooth function is realized. In some embodiments, the audio device can deliver audio signals to the wireless communication module through the UART interface, and the function of playing music through the Bluetooth earphone is realized.

[0082] The MIPI interface can be used to connect the processor 101 and peripheral devices such as display screen 104. The MIPI interface includes camera serial interface (CSI), display serial interface (DSI), etc. In some embodiments, the processor 101 and the display screen 104 communicate through the DSI interface, and the display function of the first electronic device 100 is realized.

[0083] The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 101 to the display screen 104, a wireless communication module, a sensor 105, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, an MIPI interface, etc.

[0084] The USB interface 430 is an interface that conforms to the USB standard specification, and can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 430 can be used to connect a charger to charge the first electronic device 100, or to transmit data between the first electronic device 100 and a peripheral device. It can also be used to connect a headset to play audio through the headset. The interface can also be used to connect other electronic devices, such as an AR device, etc.

[0085] It can be understood that the interface connection relationship between the modules shown in the embodiments of the present application is only illustrative and does not constitute a structural limitation of the first electronic device 100. In other embodiments of the present application, the first electronic device 100 can also use different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0086] The memory 102 can be used to store computer executable program code, which includes instructions. The processor 101 executes various functional applications and data processing of the first electronic device 100 by running the instructions stored in the memory 102. The memory 102 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), etc. The data storage area can store data created during use of the first electronic device 100 (such as audio data, a phonebook, etc.), etc. In addition, the memory 102 can include a high-speed random access memory and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), etc.

[0087] The transceiver 103 can be used to communicate with network devices and other electronic devices. The first electronic device 100 can upload or download components through the transceiver 103. In some embodiments, the transceiver 103 can include a mobile communication module (not shown in Figure 2 ) and a wireless communication module (not shown in Figure 2 ), wherein:

[0088] The mobile communication module can provide a solution for wireless communication including 2G / 3G / 4G / 5G, etc. applied on the first electronic device 100. The mobile communication module can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module can receive electromagnetic waves by the antenna 1, and perform filtering, amplification, etc. on the received electromagnetic waves, and transfer the processed signals to the modem processor for demodulation. The mobile communication module can also amplify the signals modulated by the modem processor, and radiate the signals as electromagnetic waves through the antenna 1. In some embodiments, at least part of the functional modules of the mobile communication module can be disposed in the processor 101. In some embodiments, at least part of the functional modules of the mobile communication module can be disposed in the same device as at least part of the modules of the processor 101.

[0089] The modem processor can include a modulator and a demodulator. The modulator is configured to modulate a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is configured to demodulate a received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. The low-frequency baseband signal processed by the baseband processor is transmitted to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker, a receiver, etc.), or displays an image or a video through the display screen 104. In some embodiments, the modem processor can be a separate device. In other embodiments, the modem processor can be independent of the processor 101, and disposed in the same device as the mobile communication module or other functional modules.

[0090] The wireless communication module can provide a solution for wireless communication including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc. applied on the first electronic device 100. The wireless communication module can be one or more devices integrated with at least one communication processing module. The wireless communication module receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signals, and transmits the processed signals to the processor 101. The wireless communication module can also receive signals to be transmitted from the processor 101, perform frequency modulation and amplification on the signals, and radiate the signals as electromagnetic waves through the antenna 2.

[0091] The first electronic device 100 implements a display function through a GPU, a display screen 104, and an application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 104 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 101 can include one or more GPUs that execute program instructions to generate or change display information.

[0092] The display screen 104 can be used to display controls for creating a configuration file, an input box of the configuration file, a prompt box after completing the configuration of the SDK, etc. The display screen 104 includes a display panel. The display panel can adopt a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled, a MicroLed, a Micro-oLed, a quantum dot light emitting diodes (QLED), etc. In some embodiments, the first electronic device 100 can include 1 or N display screens 104, and N is a positive integer greater than 1.

[0093] The sensor 105 can be used to detect user operations, such as user dragging a prompt box, user clicking an input box, etc. The sensor 105 can include a pressure sensor and a touch sensor, wherein:

[0094] A pressure sensor is used to sense pressure signals and converts them into electrical signals. In some embodiments, the pressure sensor may be located on the display screen 104. There are many types of pressure sensors, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to the pressure sensor, the capacitance between the electrodes changes. The first electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to the display screen 104, the first electronic device 100 detects the intensity of the touch operation based on the pressure sensor. The first electronic device 100 may also calculate the touch position based on the detection signal from the pressure sensor. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities may correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS message is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS message is executed.

[0095] A touch sensor, also known as a "touch panel," can be located on the display screen 104. The touch sensor and display screen 104 together form a touchscreen, also known as a "touch screen." The touch sensor detects touch operations applied to or near it. The touch sensor transmits the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 104. In other embodiments, the touch sensor may also be located on the surface of the first electronic device 100, in a different position than the display screen 104.

[0096] The second electronic device 200 has similar structural features to the first electronic device 100. It should be understood that the second electronic device 200 may have more or fewer components than the first electronic device 100, may combine two or more components, or may have different component configurations.

[0097] The operating system of the exemplary electronic device provided in the following embodiments of this application is described below.

[0098] The following explanation uses the layered architecture of the Android system as an example to illustrate the operating system. Figure 3 As shown, the layered architecture divides the system into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android Runtime and system libraries, and the kernel layer.

[0099] The application layer can include a series of application packages. The application packages can include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc.

[0100] The application framework layer provides an application programming interface (API) and a programming framework for the applications of the application layer. The application framework layer includes some pre-defined functions.

[0101] The Android runtime includes a core library and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0102] The core library contains two parts: one part is the function function that the java language needs to call, and the other part is the core library of the operating system. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the java file of the application layer and the application framework layer into a binary file. The virtual machine is used to perform the management of object life cycle, stack management, thread management, security and exception management, and garbage collection.

[0103] The system library can include a plurality of function modules. For example: surface manager, media library, three-dimensional graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL) and the like.

[0104] The kernel layer is the layer between hardware and software. The kernel layer at least contains display driver, camera driver, audio driver, sensor driver.

[0105] In the embodiments provided in the present application, the first operating system 110 can be a Hongmeng system, and the second operating system 210 can be an Android system. The Hongmeng system and the Android system have similar architectures, but the Hongmeng system is a distributed system for the whole scene, and a general-purpose system that can connect a plurality of devices together, such as a mobile phone, a smart screen, a tablet computer, a vehicle-mounted computer and the like. Data management and capability scheduling are all distributed.

[0106] Due to the difference in architecture between the first operating system 110 and the second operating system 210, and the difference in API definition and declaration structure between the first operating system 110 and the second operating system 210, the first operating system 110 cannot directly use the first SDK on the second operating system 210, and the plug-in running system 10 needs to provide the function of cross-platform use of the SDK for the first operating system 110. Among them, the first SDK is a collection of development tools for application software created on the second operating system. Next, combined withFigure 4 A first SDK structure diagram provided by an embodiment of the present application is introduced.

[0107] Exemplarily, the first SDK can include program codes for implementing specific functions, wherein the program codes are converted into byte codes (.class) after being compiled by a compiler. Meanwhile, the first SDK also includes some example codes, supporting technical notes or other supporting documents for clarifying doubts of basic reference materials, such as API documents and class.map.config documents. The API documents are used for a user to view and configure the API of the SDK, and the class.map.config documents are used for the user to view and configure the API mapping relationship between the second SDK of the first operating system 110 and the first SDK of the second operating system 210.

[0108] The second SDK is similar to the first SDK in structure, and the second SDK can not have the class.map.config documents. In addition, it should be understood that the second electronic device 200 can have more or less contents than those shown in the first electronic device 100, can combine two or more contents, or can have different content configurations.

[0109] As shown in FIG. 5, Figure 5 A structure diagram of a plug-in running system 10 provided by an embodiment of the present application is shown. The plug-in running system 10 includes a business logic module 11, a class loader module 12 and a function interface module 13.

[0110] The business logic module 11 is used to obtain a configuration file of an application program, select a target SDK from a plurality of SDKs according to the configuration file, and store the first SDK under an installation path of the application program. The functions of the SDKs can include initialization, login, payment, binding, push, subscription, data reporting, display of a floating window, hiding of the floating window, exit and the like. An application program often includes a plurality of SDKs, each of which has different function implementations. When the application program is converted from an SDK requiring A function to an SDK requiring B function, the business logic module 11 can realize switching of different SDKs.

[0111] Exemplarily, the business logic module 11 configures the application program by using configuration information provided by a user. The configuration information can include the following program codes:

[0112]

[0113]

[0114] The above code is a template except for the content in the "". The business logic module 101 can replace the content of the above code in < > according to the plug-in actually generated. For example, <plugin>The "plugin" in the <path in asset> can be replaced with the name of the specific second SDK (such as "push"). The "path in asset" in the <path in asset> can be replaced with the actual storage path of the generated second SDK (such as "D:\test\project\libs"). <pluginclass>The "Pluginclass" in the above can be replaced with the class name of the second SDK actually generated (e.g., "PushPlugin"). <pluginagent>The "plugin Agent" in the above can be replaced by the actual generated second SDK's agent class name (such as "PushAgent"). <pluginability>"pluginAbility" in the above description can be replaced by the application component name of the second SDK actually generated (e.g., "PushAbility").

[0115] The class loader module 12 is configured to load the classes of the first SDK into the memory space of the operating system. Specifically, the underlying functions of the SDK all use encapsulation, i.e., the underlying functions of the SDK hide the attributes and implementation details of the objects, and only expose the interface API to the outside to achieve the access level of controlling the reading and modification of the attributes in the program.

[0116] The function interface module 13 is configured to provide the developer with the API of the first SDK and the API mapping table of the first SDK and the second SDK. The API mapping table indicates the corresponding relationship between the API of the second SDK of the first operating system 110 and the API of the first SDK of the second operating system 210. The function interface module 13 provides the API mapping table to the developer, and the developer can configure according to the API mapping table to call the API of the first SDK of the second operating system 210 on the first operating system 110. It can be understood that the API mapping table can be provided by the first SDK or the first operating system 110. The developer can call the API to make the operating system of the first electronic device 100 execute the command of the application. The function interface module 13 holds the API of different SDKs, and different SDKs can be called by calling the API. For example, the API mapping table can include the content as shown in Table 1.

[0117] Table 1

[0118] API Function Second Operating System 210 API First Operating System API Subscribe push com.firstOS.push.turnOnPush com.secondOS.push.subscribe Unsubscribe push com.firstOS.push.turnOffPush com.secondOS.push.unsubscribe …… …… ……

[0119] In some other embodiments, the API mapping table can also be integrated into the first SDK by the developer of the first SDK, and the developer only needs to directly call the API through the function interface module.

[0120] It can be understood that the plug-in running system 10 in the present application can be used as a tool for running a plug-in alone, or can be a module in the first operating system 110. Herein, no limitation is made.

[0121] Based on the plug-in running system 10, the application provides a plug-in running method. The method comprises: the first electronic device 100 detects that a user creates an application plug-in on the first operating system 110, wherein the application plug-in needs to call the first SDK under the second operating system 210; in response to the operation, the first electronic device 100 packs and installs a configuration file of the application plug-in, and starts the application on the first operating system 110; the class loader module 12 of the plug-in running system 10 loads the class of the SDK required by the application; if the loading is successful, the first electronic device 100 runs the application on the first operating system 110; the business logic module 11 of the plug-in running system 10 finds the class of the first SDK according to the API mapping relationship table provided by the first SDK; if the finding is successful, the first electronic device 100 can use the first SDK of the second operating system 210.

[0122] The following describes the implementation process of loading and running the plug-in by the plug-in running system 10 provided by the application with reference to the accompanying drawings.

[0123] Figures 6A-6D An application plug-in is exemplarily shown to be developed, and the application needs to call the push service SDK (push). The first electronic device 100 is taken as an example to be a computer in the application embodiment.

[0124] Figure 6A User interface 30A is shown. User interface 30A is used by users to create applications, which in turn invoke the plugin "push". User interface 30A may include input boxes 301, 302, 304, 305, and 306, as well as controls 303, 307, 308, 309, and 310. Input box 301 is used to input the name of the application plugin created by the user, such as "push". Input box 302 is used by the user to select or input the storage location of the created application plugin. The user can directly input the storage location of the created application plugin in the input box, such as "D:\test\project\libs". The user can also select the storage location of the created application plugin through control 303 in the input box. Input box 304 can be used by the user to input the class name of the created application plugin, such as "PushPlugin". Input box 305 can be used by the user to input the agent class name, such as "PushAgent". Input box 306 can be used by the user to input the name of the capability component of the created application plugin, such as "PushAbility". Control 307 guides the user on how to operate within the user interface. Control 308 cancels a user-created item. Control 309 returns to the previous operation. Control 310 saves the user-created application and refreshes the user interface. After the user has filled in the content in input boxes 301, 302, 304, 305, and 306, they click control 310.

[0125] For example, in response to a user clicking control 310, the first electronic device 100 displays as shown Figure 6B The user interface 30B is shown. User interface 30B displays a prompt box 311 and controls 312 and 313. Prompt box 311 prompts the user "Application created successfully, do you want to start the application?". Control 312 is used by the user to start the application and refresh the interface. Control 313 is used by the user to refuse application startup and close the current interface.

[0126] For example, in response to a user clicking control 312, the first electronic device 100 displays as shown Figure 6C The user interface 30C is shown. A prompt box 314 indicates to the user that the plugin runtime system 10 is calling the SDK based on the configuration information provided by the user and completing cross-system configuration.

[0127] After the plugin runs on system 10 and completes cross-system configuration, it will display as follows: Figure 6D The user interface 30D is shown. User interface 30D displays a prompt box 315. Prompt box 315 is used to inform the user that the SDK cross-system configuration is complete and the application has been started.

[0128] In other embodiments, after completing the application configuration, the user can also input the request to call the SDK through a shell command. The shell command can interactively interpret and execute the user-inputted command or automatically interpret and execute a series of pre-set commands.

[0129] In other embodiments, the first electronic device 100 configures the application based on Java language input by the user. Figure 7A User interface 40A is shown, which is used by users to create applications through code. User interface 40A may include an input box 401, and controls 402, 404, 405, 406, 407, 408, 409, and a display box 403. Input box 401 is used by the user to input configuration information for creating the application. Control 402 is used to show and close display box 403, which can display controls 404, 405, and 406. Control 404 is used by the user to create a new configuration file. Control 405 is used by the user to save the contents of input box 401. Control 406 is used by the user to open a configuration file previously saved via control 405, or to open a configuration file obtained from other means. Control 407 guides the user on how to operate within the user interface. Control 408 returns to the previous operation. Control 409 saves and runs the user-created project and refreshes the user interface; running the user-created project includes converting the user's input into a configuration file. After the user fills in the content of input box 401, click control 409.

[0130] For example, when a user clicks control 409, the following is displayed: Figure 7B The user interface 40B is shown. Interface 40B, except for... Figure 7A In addition to the included controls, input boxes, and display boxes, the system also includes a display box 410, which displays the input box 412 and the control 413. The input box 412 is used by the user to directly enter the storage location of the created application plugin, such as "D:\test\project\libs". The user can also select the storage location of the created application plugin using the control 413 in the input box. After entering the storage location in the input box 412 or selecting the storage location using 413, the user clicks the control 410.

[0131] In response to the user's click on control 410, the first electronic device 100 will display an interface. Details can be found above. Figure 6B and Figure 6C The description is omitted here.

[0132] The following is combined with Figure 8 This section describes the loading process when an application uses a third-party SDK.

[0133] S101, the first electronic device 100 responds to the user's operation of creating a first application plug-in.

[0134] Specifically, the first electronic device 100 can detect the user's operation of creating a first application. Wherein, the first application needs to use the method provided by the first SDK. The user's operation of creating a first application plug-in can be in many ways. For example, the user opens the user interface provided in the first electronic device 100 to create a plug-in, and then inputs the configuration information of the application plug-in to be created in the user interface. Here, the user interface for creating an application plug-in can refer to the user interface shown in Figure 6A or Figure 7A . Here, no longer described.

[0135] S102, the first electronic device 100 parses and installs the configuration file of the application plug-in.

[0136] Specifically, after the first electronic device 100 detects the user's operation of creating a first application plug-in, it parses the configuration file, which includes the configuration information created by the user, and the configuration file is packaged in the application installation package. Wherein, packaging means that the first electronic device 100 compresses one or more files with compression software in the operating system to compress the file package. Wherein, the compressed file package includes: unpacked file, content file. The dependency relationship of the packaged file is as shown in Figure 9 , wherein the first SDK in the second operating system 210 called by the application plug-in is stored in the first SDK APK under the Har document; class.map.config is an API mapping relationship table file, the configuration file includes the configuration information set by the user, and class.map.config and the configuration file are packaged into APK. The APK package is used as an adaptation layer in the second operating system 210, and the APK package can be stored in the resources / rawfile / directory under the Har file in the first operating system 110 as a resource file loaded into the application of the first operating system 110. The Har file will finally be packaged into the Hap file. The above Har file and Hap file are archive files of the first operating system 110.

[0137] After the first electronic device 100 completes the file packaging of the application, it will install the application. In some other embodiments, the application will be installed by the user using the installation program. Wherein, the installation program is a kind of software in the first electronic device 100, which is used to assist the user to install other software or driver. Generally, the installation program will also provide a removal program (or called uninstaller) to assist the user to delete other software from the computer.

[0138] S103, the first electronic device 100 starts the application program.

[0139] Specifically, the first electronic device 100 starts the application program after completing the installation of the application program. In some embodiments, the application program can also be started by the user. The user interface for starting the application program by the user can refer to the user interface shown in Figures 6B-6D . Details are not described herein.

[0140] S104, the first electronic device 100 starts the class loader to load the second SDK.

[0141] Specifically, the first electronic device 100 starts the class loader of the plug-in running system 10 to load the classes of the second SDK in the application program into the operating system memory space.

[0142] The process of loading the class by the class loader is shown in Figure 10 .

[0143] S1041, the class loader loads the class.

[0144] Specifically, the first electronic device 100 uses the Class Loader to load the application package of the SDK, where the Class Loader can be the java virtual machine Class Loader. The first electronic device 100 can use the Class Loader to load the application package already installed in the system. In some embodiments, the first electronic device 100 can also use the Class Loader to load the uninstalled jar package or APK, including the dex, jar, apk, zip files in any directory.

[0145] S1042, the plug-in running system 10 registers the plug-in.

[0146] Specifically, the first electronic device 100 registers the second SDK in the plug-in running system 10, which is specifically manifested as that the second SDK is loaded into the memory of the first electronic device 100.

[0147] S1043, Find Class finds the class name.

[0148] Find Class is to find the class through the complete class name, which is to ensure that the loaded class conforms to the parent delegation model. When the first electronic device 100 executes Find Class, it will first traverse all the dex files, and find the class corresponding to the class name from each file.

[0149] S105, the first electronic device 100 runs the application program.

[0150] Specifically, the first electronic device 100 controls to move to an entry point of the program to start executing the program. Wherein, the running application program can be foreground running or background running.

[0151] S106, the first electronic device 100 finds the class mapped to the second SDK.

[0152] Specifically, the first electronic device 100 finds the class in the first SDK corresponding to the second SDK used by the application program in the second operating system 210 through the API mapping relationship table. Wherein, the API mapping relationship table is provided by the mapping file. The above mapping file can be integrated in the first SDK APK package.

[0153] S107, the first electronic device 100 uses the class in the first SDK.

[0154] Specifically, after the first electronic device 100 finds the class mapped to the second SDK, the first electronic device 100 can use the class in the first SDK of the second operating system 210 on the first operating system 110, and the application program can run normally.

[0155] The following will be described in detail in combination with Figure 11 The data interaction process between the first operating system 110 and the second operating system 210 in the plug-in running method provided by the embodiment of the application is introduced.

[0156] 1. Load the class of the second SDK under the har document.

[0157] Specifically, after the first operating system 110 completes the application installation and startup, the har archive file in the first operating system 110 of the first electronic device 100 loads the method class method of the second SDK in the application program. Wherein, the method class method can also be a class class, a filed class, etc., which will be described below. Then, the classloader of the plug-in running system 10 loads the second SDK APK package of the first operating system 110.

[0158] 2. Hap calls the method class.

[0159] Specifically, when the application program runs, the Hap needs to call the method class method in the second SDK. Wherein, the method class method is a collection of code blocks with independent functions, which is a collection with special functions, mainly used to dynamically obtain method information in the running state of the program.

[0160] 3. Find the corresponding class.

[0161] Specifically, when the Hap needs to call the method class in the second SDK, the plug-in running system 10 will obtain the class.map.config file, and find the corresponding class class in the first SDK through the API mapping table provided by the class.map.config file. The class.map.config is the mapping configuration file name.

[0162] 4. The first SDK calls the plug-in running system 10.

[0163] Specifically, taking the push service as an example, after the first electronic device 100 receives the message pushed by the server, the first electronic device 100 will obtain the processing result of the user for the information and send the processing result to the server, at this time, the plug-in needs to call the plug-in running system 10 first to send the result callback notification.

[0164] 5. The plug-in running system 10 calls the first operating system 110 application

[0165] Specifically, after the plug-in running system 10 receives the result callback notification sent by the plug-in, the plug-in running system 10 sends the notification to the first electronic device 100 through the callback function, and the first electronic device 100 receives the notification and sends it to the server through its own communication module.

[0166] In the embodiment of the application, the plug-in and the APP developed by the developer according to the method provided in the embodiment of the application can form a plug-in development ecosystem. Figure 12 An embodiment of the application shows a plug-in development ecosystem provided by the embodiment of the application.

[0167] The plug-in running method provided by the embodiment of the application is based on Figure 12 The ecosystem shown in the figure, the system includes a plug-in running system 10, an application program, and an SDK which are separately arranged. The plug-in running system 10 is provided by the first operating system 110; the configuration file of the application program and the API call are completed by the application developer; and the SDK jar package and the API mapping relationship of the push service are provided by the third-party SDK developer.

[0168] Specifically, the plug-in running system 10 is configured to receive a plug-in registration request sent by an application and invoke an SDK interface (API) according to the plug-in registration request. The plug-in registration request can be a static registration request or a dynamic registration request. The first SDK is invoked according to an API mapping relationship table provided by a first SDK developer to implement the function of using the first SDK of the second operating system 210 on the first operating system 110. The third-party service can access a cloud service, and the cloud service is a collection of cloud-side service capabilities and can include services such as an account, payment, Push, and map. The plug-in registration request details can be found in the description of the business logic module above, and the API mapping relationship table details can be found in the description of the function interface module above. Details are not repeated here.

[0169] Figure 13 The interaction process of the plug-in running system 10, the application program, and the second SDK provided by the embodiments of the present application is introduced. The following takes an example of the application program invoking the push SDK, i.e., the second SDK, as the push SDK to illustrate in detail.

[0170] 1. The plug-in running system 10 loads the configuration file of the application program through the class loader after the application program is started.

[0171] 2. The PushAbility configured by the application program derives the PluginAbility in the plug-in running system 10. The PluginAbility is a subclass of the PushAbility, and the PushAbility is a parent class of the PluginAbility.

[0172] 3. The application program registers the plug-in proxy class PushAgent corresponding to the push SDK.

[0173] 4. The PushManager in the configuration file of the application program associates the PushAgent corresponding to the plug-in in the startup process. The PushManager is the manager of the API mapping relationship in the plug-in running system 10.

[0174] 5. The cloud service provided by the first operating system 110 binds the core service of the second operating system 210. The core service of the second operating system 210 is mainly responsible for the startup, switching, scheduling management, and other work of the four components of the second operating system 210.

[0175] 6. After the first operating system 110 binds the core service of the second operating system 210, the startService is hooked. After the first operating system 110 binds the core service of the second operating system 210, the startService automatically started by the first operating system 110 needs to be intercepted first, and then the service of the second operating system 210 is invoked.

[0176] 7. The PushAbility in the plugin running system 10 binds the PushService component in the pushSDK. The PushService component belongs to the SDK cloud service platform.

[0177] 8. The PushService component in the SDK cloud service platform calls the PushPlugin plugin. The PushService component can also use a callback function to call the PushPlugin plugin. The callback function refers to the address of a function of the PushService component itself as a parameter passed to the API function of the PushPlugin plugin when the PushService component calls the API function of the PushPlugin plugin. The function of the PushService component itself is the callback function.

[0178] 9. The PushPlugin plugin calls Iplugin. Iplugin is the plugin abstraction type of the pushSDK, which is a collection of abstract methods. The PushPlugin plugin can also call back Iplugin.

[0179] 10. PushHost calls Iplugin. PushHost is the host of the pushSDK in the plugin running system 10. PushHost can also call back Iplugin.

[0180] 11. PluginHost calls PluginAgent. PluginHost can also call back PluginAgent. After PluginHost calls PluginAgent, the application can run normally.

[0181] Figure 14 A schematic block diagram of an electronic device is provided for the embodiments of the present application. As shown in the figure, the electronic device can include a receiving module, a registration module, a determination module, an acquisition module, a configuration module, a search module, and a calling module. Among them, Figure 14

[0182] The receiving module is configured to receive a software development kit (SDK) calling request input by a user in a first operating system 110, wherein the SDK calling request carries an SDK identifier. Specifically, the receiving module can be configured to accept an SDK calling request sent by the user to the first operating system 110 by clicking a user interface; or the receiving module can also be configured to accept an SDK calling request input by the user through a shell command.

[0183] ​The registration module is configured to one-to-one map the API of the first SDK and the API of the second SDK and register the mapping relationship; wherein the mapping relationship records the corresponding relationship between the API of the first SDK and the API of the second SDK, and the mapping relationship is recorded in a first file independent of the SDK, or the mapping relationship is recorded in a second file integrated in the SDK.

[0184] The determination module is configured to determine the first SDK according to the SDK identifier, the first SDK being a set of application software development tools established under the second operating system 210.

[0185] The acquisition module is configured to acquire the first SDK from the second operating system 210.

[0186] The configuration module is configured to configure the first SDK into the second SDK available to the first operating system 110.

[0187] The finding module is configured to find the API of the first SDK corresponding to the API of the second SDK according to the mapping relationship.

[0188] The calling module is configured to call the API of the first SDK by the API of the second SDK of the second operating system 210.

[0189] The detailed working process of each module in the electronic device can be referred to Figure 9 The loading process of the application program using the third-party SDK is described. Herein, no further description is made.

[0190] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, and no further description is made herein.

[0191] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented by other ways. For example, the device embodiments described above are merely schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0192] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0193] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0194] If the functions are realized in the form of software functional units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or the part of the present application which essentially contributes to the prior art or the part of the technical solutions can be embodied in the form of software products. The computer software product is stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk and various program code storage media.

[0195] The above embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.< / pluginability> < / pluginagent> < / pluginclass> < / plugin>

Claims

1. A plug-in execution method, characterized by, The method is applied to an electronic device, and the method comprises the following steps: The electronic device receives a software development kit (SDK) calling request input by a user in a first operating system of the electronic device, wherein the SDK calling request carries an SDK identifier; A first SDK is determined according to the SDK identifier, wherein the first SDK is a set of application software development tools established under a second operating system; The first SDK is obtained from the second operating system; The obtained first SDK is configured as a second SDK available for the first operating system; An application programming interface (API) of the second SDK is found according to a mapping relationship, and the API of the first SDK corresponding to the API of the second SDK is found; The API of the first SDK in the second operating system is called according to the API of the second SDK in the first operating system.

2. The method of claim 1, wherein, The electronic device receives a SDK calling request input by a user in a first operating system, comprising: The SDK calling request sent by the user to the first operating system by clicking a user interface is accepted; or The SDK calling request input by the user through a shell command is accepted.

3. The method of claim 1, wherein, The definition and declaration structure of an application programming interface (API) of a second SDK in the first operating system are different from the API of the second operating system, and the first SDK cannot be directly used in the first operating system.

4. The method of claim 1, wherein, Before the first SDK is determined according to the SDK identifier, the method further comprises the following steps: The API of the first SDK is one-to-one mapped with the API of the second SDK; The mapping relationship is registered, wherein the mapping relationship records the corresponding relationship between the API of the first SDK and the API of the second SDK; the mapping relationship is recorded in a first file independent of the SDK, or the mapping relationship is recorded in a second file integrated in the SDK.

5. An electronic device, comprising: The electronic device comprises a receiving module, a determining module, an obtaining module, a configuring module, a finding module and a calling module: The receiving module is used for receiving a software development kit (SDK) calling request input by a user in a first operating system of the electronic device, wherein the SDK calling request carries an SDK identifier; The determining module is used for determining a first SDK according to the SDK identifier, wherein the first SDK is a set of application software development tools established under a second operating system; The obtaining module is used for obtaining the first SDK from the second operating system; The configuring module is used for configuring the obtained first SDK as a second SDK available for the first operating system; The finding module is used for finding an application programming interface (API) of the first SDK according to a mapping relationship, and the API of the first SDK corresponding to the API of the second SDK is found; The calling module is used for calling the API of the first SDK in the second operating system according to the API of the second SDK in the first operating system.

6. The electronic device of claim 5, wherein, The receiving module is used for receiving a SDK calling request input by a user in a first operating system, and specifically comprising: The receiving module is used for accepting the SDK calling request sent by the user to the first operating system by clicking a user interface; or The receiving module is used for accepting the SDK calling request input by the user through a shell command. The receiving module is configured to accept an SDK calling request input by the user through a shell command.

7. The electronic device of claim 5, wherein, An application programming interface (API) of the second SDK in the first operating system is different from an API of the first SDK in the second operating system, and the first SDK cannot be directly used in the first operating system.

8. The electronic device of claim 5, wherein, The electronic device further includes a registration module. The registration module is configured to one-to-one map the API of the first SDK and the API of the second SDK and register a mapping relationship, wherein the mapping relationship records a correspondence between the API of the first SDK and the API of the second SDK; the mapping relationship is recorded in a first file independent of the SDK, or the mapping relationship is recorded in a second file integrated in the SDK.

9. A plug-in execution system, characterized by comprising: An electronic device is provided, which performs the method according to any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, which, when executed on a computer, cause the computer to perform the method according to any one of claims 1-4.

11. A computer program product comprising instructions, characterized in that, The computer readable storage medium stores instructions, which, when executed on a computer, cause the computer to perform the method according to any one of claims 1-4.

Images