Simulator data injection method, simulator system and electronic device

Abstract

The application discloses a simulator data injection method, which comprises the following steps: receiving a user's starting operation on at least two simulators, i.e., a first simulator and a second simulator, starting the first simulator and the second simulator, and generating a simulator registration list; receiving a user's data adding operation, determining first data added by the user for injection into the first simulator and second data for injection into the second simulator; receiving a user's data injection operation, injecting corresponding data into the first simulator and the second simulator according to the simulator registration list, the first data and the second data, so that the first simulator and the second simulator perform corresponding processing according to the corresponding data. That is, the data injection of two or more simulators can be realized through one data injection operation of the user, the data injection operation is simplified, the data injection is more convenient, and the development and debugging experience of the user is improved. The application further discloses a simulator system and an electronic device.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a simulator data injection method, simulator system, and electronic device. Background Technology

[0002] An emulator is software that simulates the actions of a real chip, providing an environment for the design and debugging of software applications (APPs). For example, application developers (or manufacturers) often use emulators to debug their applications during the development phase. Data injection is a common function used by emulators during application debugging. This involves application developers injecting data (also called simulated data) into the emulator, modifying some values ​​to simulate specific scenarios. For example, developers can inject battery level data to simulate a low-battery device, or GPS data to simulate the device's location.

[0003] If different emulators, designed for different environments such as personal computers (PCs), mobile phones, or wearable devices, operate independently, application developers can only operate one emulator at a time when injecting data into it. If data needs to be injected into multiple emulators, the application developer must operate each emulator separately, resulting in inconvenience and negatively impacting the development and debugging experience. Furthermore, the independence of different emulators cannot meet the needs for cross-emulator application debugging, limiting debugging scenarios and further affecting the development and debugging experience. Summary of the Invention

[0004] This application provides a simulator data injection method, simulator system, and electronic device, which can solve the problems of inconvenient data injection operation and limited application debugging scenarios in the prior art, which affect the development and debugging experience of application developers and other users. It can realize more convenient simulator data injection and meet the needs of more application debugging scenarios, thereby improving the development and debugging experience of application developers and other users.

[0005] To address the aforementioned technical problems, in a first aspect, embodiments of this application provide a simulator data injection method for an electronic device. The method includes: receiving a user's startup operation on at least two simulators, a first simulator and a second simulator; starting the first simulator and the second simulator; and generating simulator registration lists based on first registration information of the first simulator and second registration information of the second simulator, respectively. The simulator registration lists include the first registration information and the second registration information. The method also includes receiving a user's data addition operation, determining first data added by the user for injection into the first simulator, and second data added for injection into the second simulator. Finally, the method includes receiving a user's data injection operation, and injecting the first data into the first simulator and the second data into the second simulator based on the simulator registration list, the first data, and the second data, respectively, so that the first simulator performs corresponding processing based on the first data, and the second simulator performs corresponding processing based on the second data.

[0006] The simulator data injection method provided in this embodiment can be applied to simulator systems running in electronic devices. Specifically, the simulator system can receive simultaneous startup operations from users on two or more simulators, launch the corresponding simulators, and generate a simulator registration list. Then, the simulator system receives user data addition operations and a single data injection operation from the user, and can inject the user-added data into the corresponding simulators. This allows for convenient data injection into two or more simulators with a single user data injection operation, simplifying the data injection process, making data injection more convenient, and improving the user's development and debugging experience.

[0007] In this embodiment, the simulator system can specifically run and execute the simulator data injection method provided in this embodiment in an electronic device, so it can also be considered that the electronic device executes the simulator data injection method.

[0008] In one possible implementation of the first aspect described above, the first registration information includes the identification information and control port information of the first simulator, and the second registration information includes the identification information and control port information of the second simulator; the first data includes several first sub-data items, and the second data includes several second sub-data items; according to the simulator registration list, the first data, and the second data, the first data is injected into the first simulator, and the second data is injected into the second simulator, respectively, including: determining the data injection task queue corresponding to the sub-data based on the association between the first data and the second data; determining the first data injection port of the first simulator based on the first registration information, and determining the second data injection port of the second simulator based on the second registration information; performing task scheduling to execute the data injection task queue, and sequentially injecting the first sub-data into the first simulator through the first data injection port, and sequentially injecting the second sub-data into the second simulator through the second data injection port.

[0009] Data added by users to different simulators can be correlated. The simulator system can then inject the user-added data into the corresponding simulator based on these correlations. This allows users to perform a single data injection operation in a distributed environment, injecting related data into multiple simulators. This enables cross-simulation debugging of applications across different simulators, improving the user's development and debugging experience.

[0010] In one possible implementation of the first aspect mentioned above, the association relationship includes the injection sequence relationship between the first and second sub-data during the data injection process. That is, different sub-data can be injected according to the injection sequence relationship to perform application linkage debugging between different simulators.

[0011] In one possible implementation of the first aspect described above, the first data further includes first injection time information of the first sub-data, and the second data further includes second injection time information of the second sub-data, wherein the injection timing relationship is determined based on the first injection time information and the second injection time information. The injection timing information can be used to conveniently determine the injection timing of each sub-data.

[0012] In one possible implementation of the first aspect described above, if there is no correlation between the first data and the second data, the first data added by the user can be directly injected into the first simulator, and the second data added by the user can be injected into the second simulator. That is, if there is no correlation between the data corresponding to each simulator, the data added by the user can be directly injected into the corresponding simulator, which can conveniently realize the simultaneous injection of different data into different simulators.

[0013] In one possible implementation of the first aspect described above, the first data and the second data can be the same or different. That is, the data corresponding to each simulator can be different or the same, to meet the needs of different application debugging scenarios.

[0014] In one possible implementation of the first aspect described above, the first data further includes first verification information, and the second data further includes second verification information. Before injecting the first data into the first simulator and the second data into the second simulator, the method further includes: verifying the first data based on the first verification information and / or the simulator list; if the verification is successful, injecting the first data into the first simulator; if the verification fails, stopping the injection of the first data; and verifying the second data based on the second verification information and / or the simulator list; if the verification is successful, injecting the second data into the second simulator; if the verification fails, stopping the injection of the second data. Verifying the data using verification information can effectively ensure the legality of the data and improve the data injection success rate.

[0015] In one possible implementation of the first aspect described above, the first verification information includes at least one of the following: identification information and type information of the first simulator, and type information of the first data; and the second verification information includes at least one of the following: identification information and type information of the second simulator, and type information of the second data. The simulator identification information may be, for example, the name of the simulator; the simulator type information may be, for example, information such as mobile phone or watch; and the data type information may be, for example, GPS.

[0016] In one possible implementation of the first aspect described above, before injecting the first data into the first simulator and the second data into the second simulator, the method further includes: installing a first application to be debugged in the first simulator and installing a second application to be debugged in the second simulator. This is so that each simulator can run the corresponding application according to the corresponding data and perform application debugging and other processing.

[0017] In one possible implementation of the first aspect above, the first simulator performs corresponding processing based on the first data, and the second simulator performs corresponding processing based on the second data, including: the first simulator runs a corresponding first application based on the first data, and displays a first simulation interface corresponding to the first application based on the first data; and the second simulator runs a corresponding second application based on the second data, and displays a second simulation interface corresponding to the second application based on the second data.

[0018] This allows for the simultaneous launch of at least two emulators, as well as the simultaneous running and debugging of corresponding applications on at least two emulators, enabling linked debugging of applications and improving the user's development and debugging experience.

[0019] In one possible implementation of the first aspect above, the method further includes: the first simulator sending associated data to the second simulator so that the second simulator performs a corresponding operation based on the associated data, wherein the associated data is first data or processing data obtained based on the first data.

[0020] By transmitting related data between different simulators, it is easy to achieve application linkage debugging between different simulators, which improves the user's development and debugging experience.

[0021] In one possible implementation of the first aspect above, the second simulator performs corresponding operations based on the associated data, including: the second simulator runs the corresponding second application based on the associated data, and displays the third simulation interface corresponding to the second application based on the associated data.

[0022] In one possible implementation of the first aspect described above, the method further includes: displaying a data input interface, the data input interface including identification information of a first simulator, a first data addition control corresponding to the identification information of the first simulator, identification information of a second simulator, a second data addition control corresponding to the identification information of the second simulator, and a data injection control; receiving a user's trigger operation on the first data addition control, and receiving first data added by the user through the first data addition control; receiving a user's trigger operation on the second data addition control, and receiving second data added by the user through the second data addition control; and receiving a user's trigger operation on the data injection control as a user's data injection operation.

[0023] The data input interface allows users to easily add data to at least two simulators, and a single data injection operation can easily inject data into two or more simulators, simplifying the data injection process and improving the user's development and debugging experience.

[0024] In one possible implementation of the first aspect described above, the method further includes: displaying a simulator selection interface, the simulator selection interface including a simulator selection control, receiving user trigger operations on the simulator selection control, receiving simulators added by the user through the simulator selection control, and adding and displaying the user-added simulators as simulators to be injected with data. The simulator selection interface facilitates the user's selection and addition of simulators.

[0025] In one possible implementation of the first aspect described above, the method further includes: displaying an emulator startup interface, the emulator startup interface including a list of first and second emulators added by the user, and startup controls corresponding to the first and second emulators respectively; receiving user trigger operations on the startup controls; and starting the corresponding emulator. The emulator startup interface provides a convenient way to start the emulator.

[0026] In one possible implementation of the first aspect above, the method further includes: displaying the startup interfaces of the first simulator and the second simulator after startup, respectively, as corresponding simulation interfaces.

[0027] In one possible implementation of the first aspect described above, the method further includes: displaying an application debugging interface, the application debugging interface including identification information of several applications, identification information of the emulator corresponding to each application, and application debugging controls; receiving user selection operations for applications and corresponding emulators, and receiving user trigger operations for the application debugging controls; installing the user-selected application to the corresponding emulator and running the application in the emulator; and displaying the application running interface corresponding to the application as a simulation interface. The application debugging interface makes it convenient to identify the application to be run and debugged, as well as the corresponding emulator.

[0028] Secondly, embodiments of this application provide a simulator system, comprising: a simulator server, and at least two simulators, a first simulator and a second simulator. The simulator server is configured to receive user startup operations on at least the first and second simulators, start the first and second simulators, and generate simulator registration lists based on first registration information of the first simulator and second registration information of the second simulator, respectively. The simulator registration lists include the first and second registration information. The simulator server is configured to receive user data addition operations, determine first data to be injected into the first simulator and second data to be injected into the second simulator. The simulator server is configured to receive user data injection operations, and inject the first data into the first simulator and the second data into the second simulator based on the simulator registration list, the first data, and the second data, respectively. The first simulator is configured to receive the first data injected from the simulator server and perform corresponding processing based on the first data. The second simulator is configured to receive the second data injected from the simulator server and perform corresponding processing based on the second data.

[0029] In one possible implementation of the second aspect above, the first registration information includes the identification information and control port information of the first simulator, and the second registration information includes the identification information and control port information of the second simulator; the first data includes several first sub-data items, and the second data includes several second sub-data items; the simulator server is further configured to: determine the data injection task queue corresponding to each sub-data item based on the association between the first data and the second data; determine the first data injection port of the first simulator based on the first registration information, and determine the second data injection port of the second simulator based on the second registration information; perform task scheduling to execute the data injection task queue, and sequentially inject the first sub-data into the first simulator through the first data injection port, and sequentially inject the second sub-data into the second simulator through the second data injection port.

[0030] The simulator system provided in this application is used to execute the simulator data injection method provided by the first aspect and / or any possible implementation of the first aspect, and thus can also achieve the beneficial effects (or advantages) of the simulator data injection method provided by the first aspect.

[0031] Thirdly, embodiments of this application provide an electronic device, including: a memory for storing a computer program, the computer program including program instructions; and a controller for executing the program instructions to cause the electronic device to perform the simulator data injection method provided by the first aspect and / or any possible implementation of the first aspect.

[0032] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which are executed by a computer to cause an electronic device to perform the simulator data injection method provided by the first aspect and / or any possible implementation of the first aspect.

[0033] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0034] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0035] Figure 1 This diagram illustrates a display interface for the simulator data injection process.

[0036] Figure 2 Based on some implementation methods of this application, a schematic diagram of the framework structure of a simulator system provided by this application is shown;

[0037] Figure 3 A schematic diagram of the framework structure of multiple independent simulators is shown;

[0038] Figure 4A-4O Based on some implementations of this application, the diagram shows some display interfaces during the process of injecting GPS data and heart rate data in some implementations of the simulator data injection method provided in this application;

[0039] Figure 5 Based on some implementation methods of this application, a schematic diagram of the startup process of simulator 1 and simulator 2 in the simulator data injection method provided in this application is shown;

[0040] Figure 6Based on some implementation methods of this application, a schematic diagram is shown of the process of injecting data into simulator 1 and simulator 2 in the simulator data injection method provided in this application;

[0041] Figure 7 Based on some implementations of this application, a schematic diagram of the structure of an electronic device is shown;

[0042] Figure 8 Based on some implementations of this application, a schematic diagram of a System-on-a-Chip (SoC) structure is shown. Detailed Implementation

[0043] The technical solution of this application will be described in further detail below with reference to the accompanying drawings.

[0044] During the application development phase, application developers often use emulators that run on electronic devices such as computers to debug their applications. For example, Android application developers use Google's Android emulator, and iOS application developers use Apple's iPhone emulator. Taking the debugging of a map application as an example, during the debugging process, the application developer can inject (or write, input, import, etc.) GPS data into the emulator to simulate the location and other scenarios of the map application. Emulators can be, for example, mobile phone emulators, watch emulators, TV emulators, etc., corresponding to different electronic devices (emulators can also be called simulated devices or simulated terminals, etc.).

[0045] Please see Figure 1 , Figure 1 This illustrates a display interface during the emulator data injection process. Taking an application developer debugging a map application for a mobile phone as an example, the debugging process typically involves the application developer launching a mobile emulator running on their computer (as an example, an Android emulator). After receiving the application developer's launch command, the mobile emulator opens and displays an interface such as... Figure 1The right side shows the operation interface of the mobile emulator, which includes an extended function interface 10. Then, if the mobile emulator receives an operation from the application developer clicking the "location" control 11 on the extended function interface 10, the mobile emulator enters the "location" function and displays the map interface 12. Next, if the mobile emulator receives an operation from the application developer selecting GPS coordinates on the map interface 12, such as clicking to select point M on the map interface 12, and clicking the "setlocation" control 13, the mobile emulator can use the coordinate data corresponding to point M as the data to be injected into the mobile emulator. Then, if the mobile emulator determines that the map application to be debugged is already installed in the mobile emulator, the mobile emulator opens a simulated new map application window, displaying... Figure 1 The left side shows a simulated interface 20 of a map application in a mobile emulator. And as... Figure 1 As shown, the current location M' in the simulation interface 20 of the map application in the mobile phone emulator has switched to the location corresponding to the location selected by the application developer through the map interface 12, that is, it has switched to the location corresponding to the coordinates of point M.

[0046] It should be noted that, Figure 1 The mobile phone simulator interface shown also includes other information, which will not be described in detail in this application.

[0047] Currently, because different emulators such as mobile phone emulators, watch emulators, and TV emulators operate independently, application developers can only operate one emulator at a time and inject data into that emulator. For example, Figure 1 As shown, application developers can inject GPS data into mobile phone emulators to debug map applications for mobile phones, or inject heart rate data into watch emulators to debug health monitoring applications for watches. If data needs to be injected into multiple emulators, application developers need to perform the data injection operation on each emulator individually, which is inconvenient and negatively impacts the development and debugging experience.

[0048] Furthermore, with the development of electronic devices and applications, there are scenarios requiring application-linked debugging across different simulators, such as the simulation of distributed scenarios (also known as distributed multi-device scenarios or distributed multi-terminal scenarios). Taking the scenario of running outdoors with a mobile phone and a watch as an example, a simulator system is needed to support debugging sports applications with GPS positioning and heart rate monitoring. This means the simulator system needs to support simultaneously simulating both mobile phones and watches, and can simultaneously inject different data into each simulator—for example, injecting GPS data into the mobile phone simulator and heart rate data into the watch simulator. There needs to be a correlation between the GPS data and the heart rate data; for example, when the GPS data reaches a certain location, the heart rate data reaches a certain heart rate value. This allows sports application developers to debug their applications using GPS and heart rate data. However, current technology allows different simulators to operate independently, failing to meet the need for application-linked debugging between different simulators. This limits the application debugging scenarios and negatively impacts the development and debugging experience for application developers.

[0049] Therefore, this application proposes a simulator system and a simulator data injection method applied to the simulator system. The simulator system supports two or more simulators at the same time. The simulator system and simulator data injection method can be applied to the above-mentioned distributed scenarios and other scenarios that require application linkage debugging of different simulators.

[0050] The simulator data injection method provided in this application includes the simulator system receiving a startup operation from an application developer (as an example of a user of the simulator system) for at least two simulators, a first simulator and a second simulator. The system starts the first and second simulators and generates simulator registration lists based on first registration information of the first simulator and second registration information of the second simulator, respectively. The simulator registration lists include the first and second registration information. The first registration information includes identification information (e.g., name) and control port information of the first simulator, and the second registration information includes identification information (e.g., name) and control port information of the second simulator. Then, the simulator system receives a data addition operation from the application developer, determining the first data added by the application developer for injection into the first simulator and the second data added for injection into the second simulator. Next, the simulator system receives a data injection operation from the user, and injects the first data into the first simulator and the second data into the second simulator based on the simulator registration list, the first data, and the second data, respectively, so that the first simulator performs corresponding processing based on the first data, and the second simulator performs corresponding processing based on the second data.

[0051] In the simulator data injection method provided in this application, the simulator system can receive data addition operations from application developers simultaneously on two or more simulators, determine the corresponding data for each simulator, and then receive a single data injection operation from the application developer. This allows the data added (or imported, etc.) by the application developer to be injected into the corresponding simulators. In other words, data injection into two or more simulators can be conveniently achieved with a single data injection operation, simplifying the data injection process, making it more convenient, and improving the development and debugging experience for application developers.

[0052] Furthermore, the data added by application developers to different simulators can have relationships. The simulator system can inject the data added by the application developer into the corresponding simulator according to the relationship, for example, injecting the first data into the first simulator and the second data into the second simulator. The relationship can include the injection sequence of data during the data injection process. This allows application developers to inject related data into multiple simulators with only one data injection operation in a distributed scenario, enabling application-wide debugging across different simulators and improving the development and debugging experience for application developers.

[0053] The simulator system provided in this application can run on electronic devices such as computers to meet the needs of application developers or related users for running, debugging, and designing applications.

[0054] Please see Figure 2 , Figure 2 The diagram shown illustrates the framework of a simulator system according to one implementation of this application. The simulator system includes a simulator server and a simulator client. The simulator server includes a data injection graphical user interface (GUI) module and a device manager module.

[0055] The data injection graphical user interface module provides an input interface for the simulator system's data and sends the received data added by application developers to the device management module. This data can include, for example, GPS data, camera data, and sensor data. Additionally, the data injection graphical user interface module also provides the simulator system with a simulation interface during the data injection process, as well as other related display interfaces.

[0056] The device management module includes a simulator management (also known as device management, Device Server) unit and a server-side data injection management (Data Server) unit. The simulator management unit provides registration and management services for simulators within the simulator system, as shown by the dotted line with arrows in the diagram. Each simulator (e.g., Figure 2 The simulators 1, 2, and 3 shown (simulators can also be called emulators) send their respective registration information to the simulator management unit after startup. This registration information includes the simulator's name (as an example of simulator identification information), control port information, and version information. The simulator management unit then registers the simulators based on this registration information, generating and storing a simulator registration list (or terminal list).

[0057] The server-side data injection management unit receives data from the data injection graphical user interface module and provides services such as data verification, data injection task orchestration, and task scheduling management. It also pushes (or distributes) data to each simulator to inject it into the corresponding simulator. Furthermore, the server-side data injection management unit receives various data injection response information sent by the simulators.

[0058] The simulator client includes multiple simulators, which can be considered as distributed simulators corresponding to a distributed system in a distributed scenario. Additionally, the simulator client includes a virtual device operating system (Virturl Device OS) corresponding to each simulator to support the operation of different simulators. For example, ... Figure 2 The simulator client shown includes simulator 1 and simulator operating system 1 for mobile phones, simulator 2 and simulator operating system 2 for watches, simulator 3 and simulator operating system 3 for TVs, etc.

[0059] The emulator client can simulate various types of electronic devices, such as devices based on the distributed HarmonyOS system. In this case, the emulator client can run and debug distributed HarmonyOS applications.

[0060] Each simulator includes a client data injection management module. The client data management module acts as the data injection module for the simulator client, providing services such as data reception, forwarding, and result response. For example, it is used to receive data pushed by the aforementioned server-side data injection management unit, and to provide services such as further data push or forwarding to the corresponding simulator operating system.

[0061] Each emulator operating system comprises a Pipe, a Hardware Abstraction Layer (HAL), and an Application (APP) layer. The HAL layer includes devices such as GPS, cameras, and sensors, serving as a crucial bridge connecting devices like the Android Framework and Linux kernel device drivers. The application layer includes modules such as Feature Ability (FA) and Atomic Ability (AA). The client data management module pushes data to the emulator operating system; for example, it might push data sequentially along the pipe, HAL layer, and APP layer to the running emulator operating system via a pipe.

[0062] The simulator system provided by this implementation includes multiple simulators and a simulator server that can manage multiple simulators and enable interaction between them. In particular, through the settings of the simulator management unit, the server-side data injection management unit, and the client-side data injection management module, it is possible to conveniently and quickly inject corresponding data into different simulators based on a single data injection operation by the application developer.

[0063] Specifically, during the data injection process, such as Figure 2 As shown by the solid line with arrows, after receiving data added by the application developer, the data injection graphical user interface module sends the data to the server-side data injection management unit in the device management module. The server-side data injection management unit receives the data, retrieves the emulator registration list corresponding to the started emulators from the emulator management unit, verifies the data, and then injects the data into the corresponding emulator according to the emulator registration list and the data itself. Furthermore, there are dynamic linkages between the data corresponding to different emulators, meaning the server-side data injection management unit can dynamically and linkedly inject data into the corresponding emulators according to the emulator registration list based on the linkages between the data corresponding to different emulators. Then, the emulator injects the data into the emulator operating system sequentially through pipes, the HAL layer, and the APP layer, enabling the emulator operating system to perform data injection and application debugging operations based on the data. The emulator system provided by this application simplifies the user's data injection operation, making data injection more convenient and facilitating application linkage debugging in distributed scenarios.

[0064] Please see Figure 3 , Figure 3The schematic diagram of the framework structure showing multiple independent simulators is presented. Different simulators respectively correspond to simulator operating systems. Therefore, during the process of simulator data injection, each simulator only supports application developers to inject different data into different simulators separately one by one, and there is no linkage during the data injection process between different simulators.

[0065] The specific implementation manner provided by this application Figure 2 The shown simulator system, compared with Figure 3 The shown multiple independent simulators, can enable application developers to only perform one data injection operation in a distributed scenario to dynamically inject mutually associated data corresponding to different simulators into multiple simulators, enhancing the development and debugging experience of application developers. And linkage injection during the data injection process can be achieved between different simulators, which can be applied to distributed scenarios to meet requirements such as application linkage debugging in distributed scenarios, thus enhancing the development and debugging experience of application developers.

[0066] The simulator system provided by the implementation manner of this application can be a simulator tool provided for HarmonyOS application developers and can be used in the HarmonyOS system that is a distributed operating system to implement data injection for distributed simulators for running and debugging applications corresponding to distributed systems.

[0067] Please refer to Figure 4A , in an implementation manner of this application, the process of data injection through the simulator data injection method provided by the implementation manner of this application includes that the computer displays the operation interface 100 (which can also be called the function interface) of the simulator system running on it. The operation interface 100 includes a function list 101 of the functions supported by the simulator system. For example, the functions supported by the simulator system include functions such as Device selection, App debugging, Inject date, etc. In addition, the operation interface 100 also includes other information 102, and the other information 102 can be information such as some running programs of the simulator system, which can be set as needed, and this implementation manner does not elaborate on this part in detail.

[0068] As Figure 4A shown, if the simulator system receives a click operation from an application developer on the "Device selection" control in the function list 101, the simulator system will display a simulator selection interface. The application developer can select and add simulators through the simulator selection interface, and the simulator system displays the simulator startup interface after the application developer selects and adds simulators.

[0069] For example, the simulator system displays as Figure 4BThe image shows the emulator launch interface 200 after the application developer selects to add an emulator. The emulator launch interface 200 includes emulator type information 201, such as the emulator system supporting phone emulators, TV emulators, tablet emulators, wearable device emulators (e.g., watch emulators), and car emulators. Additionally, the emulator launch interface 200 includes an emulator search box 202 and an emulator addition control 203 (each serving as an example of an emulator selection control). Application developers can search for and add emulators by entering the emulator name in the emulator search box 202 (not shown in the image), or they can select an emulator from the list displayed after clicking the emulator addition control 203 (not shown in the image). The specific search and selection methods can be the same as, similar to, or different from commonly used search and selection methods; they can be selected and set as needed, and this implementation does not provide a detailed explanation.

[0070] After receiving an application developer's request to add an emulator, the emulator system displays a list of the emulators selected by the application developer. For example... Figure 4B As shown, the emulator startup interface 200 also includes a list 204 of emulators selected and added by the application developer. List 204 includes basic information about the emulators selected by the application developer, such as emulator type, name, screen density, application programming interface (API), central processing unit (CPU) / application binary interface (ABI), disk space, status, and startup actions. Of course, the basic information can also include the emulator's operating system version, screen resolution, and source. Furthermore, list 204 can display more or less basic information, or display other information, which can be selected and set as needed. In addition, the emulator startup interface 200 also includes other information such as "Help" and "Refresh," which will not be described in detail in this implementation.

[0071] Taking the aforementioned scenario of running outdoors with a mobile phone and a watch as an example, when the application developer selects a mobile phone simulator named "mate40" (hereinafter referred to as simulator "mate40"), the simulator "mate40" is used as the first simulator example. When the application developer selects a watch simulator named "watchGT" (hereinafter referred to as simulator "watchGT"), simulator "watchGT" is used as the second simulator example. After the simulator system receives the application developer's selection to add a simulator, as follows... Figure 4B As shown, if the emulator system receives a click operation from the application developer on the "ALL" control, the emulator system will display as follows. Figure 4B The list 204 shown shows all the emulators that the application developer selected to add, including the names of the emulators "mate40" and "watchGT", as well as some other basic information about each emulator.

[0072] Then, as Figure 4B As shown, if the emulator system receives a click operation from the application developer on the launch controls 2041 corresponding to the emulator "mate40" and the emulator "watchGT" respectively (as an example of a launch operation), the emulator system launches the emulator "mate40" and the emulator "watchGT", displaying as shown. Figure 4C The displayed interface shows that the simulators "mate40" and "watchGT" have been launched.

[0073] Additionally, after launching the "mate40" and "watchGT" emulators, the emulator system also displays the following: Figure 4D The displayed interface shown is an example of the simulation interface 300 of the simulator "mate40" and the startup interface of the simulator "watchGT" as simulation interface 400.

[0074] In this implementation, after the emulator "mate40" and the emulator "watchGT" are started, the emulator system also needs to register information based on the emulator "mate40" name, control port information, version information and other registration information (as an example of the first registration information), and register information based on the emulator "watchGT" name, control port information, version information and other registration information (as an example of the second registration information), to generate an emulator registration list. The emulator registration list includes the emulator "mate40" name, control port information, version information and other registration information, as well as the emulator "watchGT" name, control port information, version information and other registration information.

[0075] Please see Figure 4E After launching the "mate40" and "watchGT" emulators, if the emulator system receives a click operation from the application developer on the "App debugging" control, the emulator system will display as follows: Figure 4F The application debugging interface 500 shown includes a list 501 of the names of several applications supported by the emulator system (as an example of application identification information). For example, applications supported by the emulator system include sports apps, social apps, and games. If the emulator system receives a click operation from an application developer on the "Sports app" control (as an example of an application selection operation), the emulator system displays information 502 about the aforementioned launched emulators, such as displaying the names of the aforementioned emulators "mate40" and "watchGT" (as an example of emulator identification information).

[0076] Please see Figure 4G If the emulator system receives a click operation from the application developer on the name of the emulator "mate40" (as an example of selecting the emulator), and / or receives a click operation from the application developer on the application debugging control 503 corresponding to the emulator "mate40" (as another example of a user selecting the emulator), the emulator system will install a sports application (as an example of a first application) on the emulator "mate40" and open the sports application, then begin waiting for debugging of the sports application; or open a sports application already installed on the emulator "mate40" and begin waiting for debugging of the sports application. If the emulator receives a click operation from the application developer on the name of the emulator "watchGT", and / or receives a click operation from the application developer on the application debugging control 503 corresponding to the emulator "watchGT", the emulator system will install a sports application (as an example of a second application, the second application being the same as the first application) on the emulator "watchGT" and open the sports application, then begin waiting for debugging of the sports application; or open a sports application already installed on the emulator "watchGT" and begin waiting for debugging of the sports application.

[0077] Please see Figure 4H If the simulator system receives a click operation on the "Inject date" control from the application developer while waiting for the debugging of a motion-based application, the simulator system will display the following: Figure 4IThe data input interface 600 is shown. The data input interface 600 includes the name of the simulator "mate40" (as an example of the simulator's identification information), a data addition control 601 corresponding to the name of the simulator "mate40" (as an example of a first data addition control), and a first data information display box 602. It also includes the name of the simulator "watchGT" (as an example of the simulator's identification information), a data addition control 603 corresponding to the name of the simulator "watchGT" (as an example of a second data addition control), and a second data information display box 604. If the simulator system receives a click operation from the application developer on the data addition control 601, the simulator system displays the file path so that the application developer can select to add the corresponding GPS data file. The addition method is the same as the current normal file addition method, and will not be described further here. Additionally, if the simulator system receives a click operation from the application developer on the data addition control 603, the simulator system displays the file path so that the application developer can select to add the corresponding heart rate data file. The addition method is the same as the current normal file addition method, and will not be described further here.

[0078] like Figure 4I As shown, the simulator system receives the data addition operation from the application developer, adding data corresponding to the simulators "mate40" and "watchGT" respectively, and displays it. Figure 4I The interface shown is as follows. The GPS data that the application developer needs to inject into the simulator "mate40" is "choose date file" (as an example of the first data) displayed in the data information display box 602 corresponding to the simulator "mate40", and the heart rate data that needs to be injected into the simulator "watchGT" is " / date / health.date" (as an example of the second data) displayed in the data information display box 604 corresponding to the simulator "watchGT".

[0079] In addition, the data input interface 600 also includes an "Apply" (i.e., injection) control 605 (as an example of a data injection control). If the simulator system receives a click operation from the application developer on the "Apply" control 605, the simulator determines that it has received the application developer's data injection operation. Based on the correlation between GPS data and heart rate data, the simulator system injects GPS data and heart rate data into the simulator "mate40" and the simulator "watchGT" respectively.

[0080] After receiving GPS data, the emulator "mate40" runs the corresponding sports application based on the GPS data and displays it on the simulation interface 300 according to the GPS data. Figure 4J The route shown corresponds to this GPS data (as an example of the first simulated interface corresponding to the running process of a sports application in the "mate40" mobile phone emulator), that is, the "mate40" emulator debugs the sports application based on GPS data. After receiving heart rate data, the "watchGT" emulator runs the corresponding sports application according to the heart rate data, and displays the heart rate data on the simulated interface 400 as shown below. Figure 4J The heart rate value shown, such as "heart rate 88 / minute" (as an example of the second simulation interface corresponding to the running process of a sports app in the watch simulator "watchGT"), means that the simulator "watchGT" debugs the sports app based on the heart rate data.

[0081] In another implementation of this application, after the simulator "mate40" receives GPS data, it can also determine the association data between the simulator "mate40" and the simulator "watchGT" based on the GPS data and heart rate data, and send the association data to the simulator "watchGT". The association data may be, for example, several GPS data points from the GPS data, or it may be navigation information obtained based on the GPS data (navigation information is an example of data processing, for example, it may be...). Figure 4K The distance shown is "268 meters along Shangdi West Road". This means the simulator "mate40" can send navigation information obtained from GPS data to the simulator "watchGT" or send GPS data directly. After receiving the navigation information or GPS data, the simulator "watchGT" can also run corresponding sports applications based on the navigation information or GPS data and display them on the simulation interface 400. Figure 4K The navigation information shown is another example of the simulation interface corresponding to the running process of sports applications in the watch simulator "watchGT", that is, as an example of a third simulation interface. That is, the simulation interface 400 of the simulator "watchGT" can alternately display heart rate values ​​and navigation information to simulate the sports applications that need to be debugged by the simulators "mate40" and "watchGT" in a distributed scenario.

[0082] In another implementation of this application, the simulator data injection method can be applied to distributed systems such as HarmonyOS. For example... Figure 4L As shown, after receiving GPS data, the simulator "mate40" runs the corresponding sports application based on the GPS data, and can also display the GPS data on the simulation interface 300. Figure 4LThe route shown corresponds to this GPS data; that is, the GPS data injected by the mobile emulator "mate40" is displayed as a preset running route. Then, the emulator "mate40" obtains navigation information based on the GPS data (for example, it could be...). Figure 4L The navigation information (e.g., "Turn left 500 meters ahead") is sent as associated data to the simulator "watchGT". In this implementation, the distributed capabilities of the HarmonyOS system manifest as the mobile simulator "mate40" sending data to the watch simulator "watchGT". After receiving the navigation information, the "watchGT" simulator runs the corresponding sports application and displays navigation information such as "Turn left 500 meters ahead" on the simulation interface 400. Additionally, after receiving the injected heart rate data, the "watchGT" simulator runs the corresponding sports application based on the heart rate data and displays the heart rate value on the simulation interface 400, such as "Heart rate 88 / minute". This means the heart rate data injected by the watch simulator "watchGT" represents the heart rate changes during running. In short, the simulation interface 400 of the "watchGT" simulator alternately displays heart rate values ​​and navigation information to simulate the sports applications that the simulators "mate40" and "watchGT" need to debug in a distributed scenario.

[0083] In this implementation, application developers can choose the simulators "mate40" and "watchGT" as the simulators in the simulator system to inject data, such as... Figure 4I As shown, the simulator system can receive data to be injected by application developers into the simulators "mate40" and "watchGT" respectively. Then, upon receiving such data... Figure 4I The diagram illustrates how a single data injection operation by an application developer (i.e., receiving a click on the "Apply" control 603) can simultaneously inject different data into the "mate40" and "watchGT" simulators. Specifically, GPS data is injected into the "mate40" simulator, and heart rate data into the "watchGT" simulator. Furthermore, a correlation exists between the injected GPS and heart rate data, allowing the simulator system to dynamically inject the data added by the application developer into the corresponding simulators based on this correlation. This enables application developers in distributed multi-device scenarios to dynamically inject interrelated data from different simulators into multiple simulators with a single data injection operation. This simplifies the data injection process for users, enhances the development and debugging experience for application developers, and makes data injection more convenient.

[0084] In addition, the emulator "mate40" can send GPS data or navigation information obtained from GPS data to the emulator "watchGT" as the data linking the two, which can facilitate application linkage debugging between different emulators and improve the user's development and debugging experience.

[0085] In some other implementations of this application, the simulator system can also display, after startup, as shown below. Figure 4M As shown in the operation interface 100, if the emulator system receives a click operation from the application developer on the "Device selection" control, the emulator system will display as follows: Figure 4N The display interface 700 shown includes information 701 on the types of emulators supported by the emulator system. Additionally, the display interface 700 includes an Add Device control 702, an Appdebugging control 703, and an Inject Data control 704. If the emulator receives a click operation from the application developer on the Add Device control 702, the emulator system displays a list of emulators supported by the emulator system for the application developer to select the corresponding emulator (not shown in the figure). Then, as... Figure 4O As shown, the emulator system displays a list 705 of emulators selected by the application developer. For example, the emulators selected by the application developer include "Huawei Watch", "Huawei Mate 20", and "Huawei P40". Basic information about each emulator is as follows: Figure 4O As shown, it will not be elaborated further here.

[0086] If the emulator system receives a click from the application developer on the application debugging control 703, the emulator system can display [the corresponding text]. Figure 4F The same or different application debugging interfaces can be used to allow the emulator system to install and open the application to be debugged according to the application developer's operation, or the emulator system can only install the application to be debugged according to the application developer's operation, and then open the application to be debugged when performing data injection.

[0087] If the emulator system receives a click operation from the application developer on the injected data control 704, the emulator system displays the same information as the control. Figure 4I The same or different data injection interfaces are available for application developers to add the data that needs to be injected.

[0088] In other implementations of this application, after launching the registered emulator, the application developer can also first use the aforementioned... Figure 4I Perform data addition and injection operations, and then proceed as described above. Figure 4FThis allows the emulator system to install and open the application to be debugged, or to open an already installed application to be debugged and begin debugging. Once debugging is complete, the emulator system can then display the application. Figure 4J A schematic diagram of the simulated interface.

[0089] In other implementations of this application, the display interfaces corresponding to the simulator system can also be of other types or layouts. These can be configured as needed, as long as they allow application developers to select multiple simulators, add data to different simulators, and inject multiple data streams at once through a single data injection operation using a control similar to the aforementioned "Apply" control 605. In other words, application developers can conveniently inject multiple data streams into multiple simulators with a single data injection operation, improving their development and debugging experience.

[0090] In some other implementations of this application, the aforementioned application identification information may also be information such as an application icon other than the application name used to identify different applications, and the aforementioned emulator identification information may also be information such as an emulator icon other than the emulator name used to identify different emulators, etc., all of which can be selected and set as needed.

[0091] In some implementations of this application, the application developer's triggering operation on each display interface and / or control can be the aforementioned click operation, such as a single click or double click of the mouse. Of course, it can also be a user's touch operation, such as a click or swipe, which can be set and selected as needed.

[0092] The following will combine Figure 2 The simulator system shown in this application provides a detailed explanation of the simulator data injection process using the simulator data injection method provided in this implementation.

[0093] Please see Figure 5 The simulator system provided in this application, during the simulator data injection process, includes the following steps: starting simulator 1 (e.g., the aforementioned mobile phone simulator "mate40") and simulator 2 (e.g., the aforementioned watch simulator "watchGT"), and simulator 1 and simulator 2 registering information.

[0094] S101, the data injection graphical user interface module in the simulator system receives the data as described above. Figure 4B The application developer's operation shown is to start emulator 1 by sending an emulator start notification message to emulator 1.

[0095] S102, after receiving the simulator startup notification information, simulator 1 starts and checks whether the simulator management unit is started. If it is not started, execute S103; if it is started, execute S106.

[0096] Emulator 1 can check if the emulator management unit is running by checking if it receives a startup notification from the emulator management unit. If it does, the emulator management unit is considered running; otherwise, it is considered not running. Alternatively, emulator 1 can send a startup confirmation message to the emulator management unit to confirm its startup status. This can be selected and configured as needed.

[0097] S103, Simulator 1 sends a Simulator Management Unit startup notification message to the Simulator Management Unit to notify the Simulator Management Unit to start.

[0098] S104, the simulator management unit starts after receiving the simulator management unit startup notification information, and listens to the relevant interfaces of the simulator management unit to receive registration information sent by simulator 1 and other simulators.

[0099] S105, the simulator management unit sends a startup result message to simulator 1 to notify simulator 1 that the simulator management unit has started.

[0100] S106, after receiving the startup result information, simulator 1 sends registration information to the simulator management unit to register the startup information. The registration information includes the name and control port of simulator 1, so that the server-side data injection management unit can inject data based on the name and control port of simulator 1 during data injection. Additionally, the registration information may also include simulator 1's version information for use in version checks and updates within the simulated scenario. Of course, the registration information can also include other information, which can be selected and set as needed.

[0101] S107, after receiving the registration information, the simulator management unit registers the device and generates a simulator registration list. The simulator registration list includes information such as the name, control port, and version information of simulator 1. The simulator management unit then sends the registration result information to simulator 1. The name of simulator 1 serves as an example of the first identification information of simulator 1; this first identification information can also be other information identifying simulator 1.

[0102] S108, after receiving the registration result information, simulator 1 sends the startup result information of simulator 1 to the data injection graphical user interface module, so that the data injection graphical user interface module displays the aforementioned information based on the startup result information of simulator 1. Figure 4D The image shows the simulation interface after emulator 1 (i.e., mobile phone emulator) is started.

[0103] S109, the data injection graphical user interface module in the simulator system receives the data as described above. Figure 4B The application developer's operation shown is to start emulator 2 by sending an emulator start notification message to emulator 2.

[0104] S110, after receiving the simulator startup notification information, simulator 2 starts and checks whether the simulator management unit is started. If it is started, execute S111; if it is not started, execute steps similar to those in S103 to S105 above to start the simulator management unit. These steps will not be repeated here.

[0105] S111, Simulator 2 sends registration information to the simulator management unit to initiate information registration. The registration information includes the name and control port of simulator 2, so that the server-side data injection management unit can inject data based on the name and control port of simulator 2 during data injection. Additionally, the registration information may also include simulator 2 version information for use in version checks and updates within the simulated scenario.

[0106] S112, after receiving the registration information, the simulator management unit registers the device and updates the simulator registration list, adding information such as the name, control port, and version information of simulator 2 to the simulator registration list. That is, the simulator registration list also includes information such as the name, control port, and version information of simulator 2. The simulator management unit then sends the registration result information to simulator 2.

[0107] S113, after receiving the registration result information, simulator 2 sends the startup result information of simulator 2 to the data injection graphical user interface module, so that the data injection graphical user interface module displays the aforementioned information based on the startup result information of simulator 2. Figure 4D The simulated interface after simulator 2 is started is shown.

[0108] Please see Figure 6 After the simulator system starts simulator 1 and simulator 2, the process of injecting data into simulator 1 and simulator 2 includes the following steps:

[0109] S201, the data injection graphical user interface module in the simulator system receives, for example, the aforementioned... Figure 4I The data injection operation shown is where the application developer injects data into the simulator system. This involves receiving the application developer's data file import operation, determining the data to be injected, which includes the aforementioned GPS data and heart rate data.

[0110] S202, the data injection graphical user interface module sends data to the server-side data injection management unit. This data includes GPS data and heart rate data.

[0111] Examples of GPS data and heart rate data in some implementations of this application are shown below:

[0112] GPS data example:

[0113]

[0114]

[0115] As can be seen, the GPS data includes the name "mate40" corresponding to simulator 1 (as an example of the identifier information of simulator 1) and the type "phone" (as an example of the type information of simulator 1), as well as multiple sub-data items (as an example of the first sub-data item). Each sub-data item includes its ID, such as id:1, id:2, etc., and also includes the data type "gps" (as an example of the type information of the first data item), the data injection time information "timeOffset" (as an example of the first injection time information), and data details (such as longitude, latitude, altitude, and other coordinate information). In this implementation, the name "mate40", type "phone", and data type "gps" of simulator 1 serve as an example of the first verification information of simulator 1.

[0116] Heart rate data example:

[0117]

[0118]

[0119] As can be seen, the heart rate data includes the name "watchGT" (as an example of the identifier information of simulator 2) and the type "watch" (as an example of the type information of simulator 2), as well as multiple sub-data items (as an example of the second sub-data items). Each sub-data item includes its ID, such as id:1, id:2, etc., and also includes the data type "heartRate", the injection time information "timeOffset" (as an example of the second injection time information), and data details (e.g., value:"80"). In this implementation, the name "watchGT", type "watch", and data type "heartRate" of simulator 2 serve as an example of the second verification information of simulator 2.

[0120] S203, after receiving the data, the server-side data injection management unit obtains the aforementioned simulator registration list from the simulator management unit. The simulator registration list includes information such as the names, control ports, and version information of simulators 1 and 2.

[0121] S204, the server-side data injection management unit verifies the injected data and orchestrates data injection tasks.

[0122] The server-side data injection management unit validates the data, including checking the validity of the data types. For example, it verifies the names of simulator 1 and simulator 2 in the simulator registration list, the name and type of simulator 1 in GPS data, and the data type of GPS data; it also verifies the name and type of simulator 2 in heart rate data, and the data type of heart rate data. This ensures that the injected data type must be a valid type such as gps or heartRate. Alternatively, the server-side data injection management unit verifies whether the simulator type matches the data. For example, if the simulator type is "phone," its corresponding data type is "gps," meaning heart rate data cannot be injected into a mobile phone simulator. It also verifies the validity of the data range, such as the longitude range of GPS data being [-180, 180].

[0123] In addition, the server-side data injection management unit can also verify whether there is a deadlock problem in the interdependence of data based on information such as the simulator registration list, GPS data, and heart rate data, or perform other verifications, which can be selected as needed.

[0124] The server-side data injection management unit orchestrates data injection tasks by creating a data injection task queue based on the data file. This allows the server-side data injection management unit to send data injection instructions to each simulator sequentially based on the data injection task queue after the injection task begins.

[0125] Taking the GPS data and heart rate data example files above as an example, during the data injection task arrangement process, the server-side data injection management unit can know from the "timeOffset:0" information in the first data of GPS data and the "timeOffset:0" information in the first data of heart rate data that after simulator 1 and simulator 2 are started, the first GPS data is injected into simulator 1 and the first heart rate data is injected into simulator 2 respectively. Then, based on the "timeOffset:2000" information in the second GPS data (i.e., the time interval since the previous data injection) and the "timeOffset:2000" and "inject data again after the second data injection of Mate 40, and after an interval of at least 2 seconds from the previous data" information in the heart rate data, the second GPS data is injected into simulator 1 2 seconds after the first GPS data is injected. Then, after the second GPS data is successfully injected into simulator 2, the second heart rate data is injected into simulator 2. Then, based on the "timeOffset" information in the third and fourth data points of the GPS and heart rate data, data is injected into simulator 1 and simulator 2 respectively, or GPS data and heart rate data can be injected into simulator 1 and simulator 2 periodically according to the aforementioned interval (i.e., 2 seconds). The data injection task queues for GPS data and heart rate data can then be determined as follows:

[0126] ①0 seconds after startup: mate40-id1, watchGT-id1

[0127] ② 2 seconds after startup: mate40-id2

[0128] ③ Two seconds after startup, and after successful injection of mate40-id2: watchGT-id2.

[0129] Next, the subsequent data injection tasks are executed in sequence.

[0130] The "timeOffset" information in the GPS and heart rate data serves as an example of information used to determine the correlation between the GPS and heart rate data, specifically the injection timing relationship during the data injection process. That is, based on GPS and heart rate data in different data file formats, the injection timing relationship (or the correlation before and after data injection) can be set separately for each data set.

[0131] S205, after the server-side data injection management unit has arranged the data injection task, it sends the data import result information to the data injection graphical user interface module.

[0132] S206. After receiving the data import result information, the data injection graphical user interface module displays a corresponding notification interface to show the application developer the data import result. For example, it can display information such as "Data import successful" or "Data import failed".

[0133] Next, the server-side data injection management unit performs task scheduling, that is, executes the pre-arranged data injection task queue, and injects each piece of data into simulator 1 and simulator 2 respectively, so that simulator 1 and simulator 2 perform the corresponding processing and display the simulation interface. Specifically, this includes the following steps:

[0134] S207, the server-side data injection management unit performs task scheduling and executes the aforementioned data injection task queue to inject the first GPS data into simulator 1 through the data injection port of simulator 1 (as an example of the first data injection port), which is the first time data is injected into simulator 1.

[0135] S208, after receiving the first GPS data, simulator 1 sequentially performs data injection and application debugging operations based on the data through the pipes, HAL layer, and application layer in the simulator operating system corresponding to simulator 1. This process can be the same as or similar to the current data injection and application debugging process, and will not be elaborated here. Simulator 1 then sends data injection result information to the server-side data injection management unit to inform the unit whether the first GPS data injection was successful.

[0136] After receiving the data injection result message, the server-side data injection management unit will execute S209 if the data injection is successful; otherwise, it will execute the operation of injecting the next GPS data or the next heart rate data, or it may pause the data injection.

[0137] S209, the server-side data injection management unit performs task scheduling. While injecting the first GPS data into simulator 1, it injects the first heart rate data into simulator 2 through the data injection port of simulator 2 (as an example of the second data injection port), which is the first time data is injected into simulator 1.

[0138] S210, after receiving the first heart rate data, simulator 2 sequentially performs data injection and application debugging operations based on the data through the pipes, HAL layer, and application layer in the simulator's corresponding operating system. This process can be the same as or similar to the current data injection and application debugging process, and will not be elaborated here. Simulator 2 then sends data injection result information to the server-side data injection management unit to inform it of whether the first heart rate data injection was successful.

[0139] After receiving the data injection result information, if the server-side data injection management unit determines that the data injection was successful, it executes S211, that is, continues to perform further task scheduling and injects the next piece of data into simulator 1 and simulator 2 respectively; if the injection is unsuccessful, it executes the operation of injecting the next piece of data or it can pause the data injection.

[0140] S211, the server-side data injection management unit performs task scheduling, and injects data into simulator 1 and simulator 2 in sequence, such as the process shown in S207 to S210 above, for the second, third and so on.

[0141] During the data injection process, the server-side data injection management unit determines the injection time relationship of each data point based on the injection time information of GPS data and heart rate data. This relationship serves as the association between the GPS data and heart rate data. Then, based on the injection time relationship, a data injection task queue is determined and executed to inject each data point. The process for determining the GPS and heart rate data injection tasks is as follows: First, the first GPS data point is injected into simulator 1, and the first heart rate data point is injected into simulator 2. Then, after 2 seconds, the second GPS data point is injected into simulator 1. After the second GPS data point is successfully injected, the second heart rate data point is injected into simulator 2. Then, other GPS and heart rate data are injected into simulator 1 and simulator 2 sequentially.

[0142] Of course, in some other embodiments of this application, simulator 1 may also send GPS data to simulator 2, so that simulator 2 can obtain navigation information based on the GPS data and display the navigation information, in order to simulate the debugging of a motion application linked between simulator 2 and simulator 1. Alternatively, simulator 1 may also send navigation information obtained based on GPS data to simulator 2, so that simulator 2 can display the navigation information, in order to simulate the debugging of a motion application linked between simulator 2 and simulator 1.

[0143] In this implementation, before executing the aforementioned step S201 or before executing the aforementioned step S207, it is also necessary to install and open the motion application to be debugged in simulator 1 and simulator 2 respectively.

[0144] In this implementation, during the data injection process, the server-side data injection management unit can determine the data injection port based on the port information of each simulator in the aforementioned simulator registration list and send the corresponding data to the corresponding simulator.

[0145] The simulator data injection method provided in this implementation supports two or more simulators simultaneously. This method involves the simulator system receiving data added by the application developer to two or more simulators simultaneously, and then receiving a single data injection operation from the application developer. This allows the system to inject the data added by the application developer into the corresponding simulators, simplifying the user's data injection process and making it more convenient. It facilitates data injection into two or more simulators, improving the development and debugging experience for application developers. Furthermore, the data added by the application developer to different simulators can have relationships. The simulator system can inject the data added by the application developer into the corresponding simulators based on these relationships. In distributed scenarios, application developers only need to perform a single data injection operation to dynamically inject related data into multiple simulators, enabling distributed simulator data injection. This simulates distributed, multi-device data injection linkage application scenarios, further enhancing the development and debugging experience for application developers.

[0146] In some implementations of this application, as mentioned above, the simulator system can inject different data into different simulators, and there can be correlation information between the different data. In other implementations of this application, the simulator system can inject different data into different simulators, and there is no correlation information between the different data. If the injected data has no correlation, the simulator system can directly inject data into different simulators respectively.

[0147] In other implementations of this application, the simulator system can also inject the same data into different simulators, so that the different simulators can simulate and debug the same application based on the data. Injecting the same data into different simulators can be as described above. Figure 4I As shown, it can receive data addition operations from application developers for data corresponding to different emulators to determine the data added by the application developers. Alternatively, it can receive only one data addition operation from the application developers for data corresponding to each emulator to determine the data added by the application developers. It can be selected and set as needed.

[0148] In other implementations of this application, the simulator data injection method provided in this application can also inject data into the simulator to enable the simulation of other applications such as social applications and games in mobile phones and watches on electronic devices such as computers.

[0149] In other implementations of this application, the applications that need to be debugged in different emulators can be the same applications as described above, so as to achieve coordinated debugging of applications. Of course, the applications that need to be debugged in different emulators can also be different applications, to meet the needs of other application debugging scenarios.

[0150] In some other implementations of this application, the aforementioned association may also refer to information such as identical data or injection conditions between at least two types of data, or it may be other information that identifies the association between the data, which can be selected and set as needed.

[0151] The simulator data injection method provided in this implementation can be applied to application simulation scenarios, and therefore can also be called an application simulation method; or it can be applied to application debugging scenarios, and therefore can also be called an application debugging method. Correspondingly, the simulator system provided in this implementation can also be called an application simulation system or an application debugging system, etc. Of course, the simulator data injection method provided in this application can also be applied to other scenarios, which can be selected as needed.

[0152] Please see Figure 7 , Figure 7 The diagram illustrates the structure of an electronic device 900 according to one embodiment of this application. The electronic device 900 may include one or more processors 901 coupled to a controller hub 904. In at least one embodiment, the controller hub 904 communicates with the processor 901 via a multi-branch bus such as a Front Side Bus (FSB), a point-to-point interface such as a QuickPath Interconnect (QPI), or a similar connection. The processor 901 executes instructions controlling general types of data processing operations. In one embodiment, the controller hub 904 includes, but is not limited to, a Graphics Memory controller hub (GMCH) (not shown) and an Input / Output Hub (IOH) (which may be on a separate chip) (not shown), wherein the GMCH includes memory and a graphics controller and is coupled to the IOH.

[0153] Electronic device 900 may also include a coprocessor 906 and a memory 902 coupled to a controller hub 904. Alternatively, one or both of the memory 902 and the GMCH may be integrated within the processor 901 (as described in this application), with the memory 902 and the coprocessor 906 directly coupled to the processor 901 and the controller hub 904, which is located on a single chip with the IOH.

[0154] The memory 902 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two.

[0155] In one embodiment, the coprocessor 906 is a dedicated processor, such as, for example, a high-throughput many-integrated-core (MIC) processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), or an embedded processor, etc. Optional properties of the coprocessor 906 are indicated by dashed lines. Figure 7 middle.

[0156] In one embodiment, the electronic device 900 may further include a Network Interface Card (NIC) 903. The network interface 903 may include a transceiver for providing a radio interface for the electronic device 900 to communicate with any other suitable device (such as a front-end module, antenna, etc.). In various embodiments, the network interface 903 may be integrated with other components of the electronic device 900. The network interface 903 can implement the functions of the communication unit in the above embodiments.

[0157] Electronic device 900 may further include input / output (I / O) device 905. Input / output (I / O) device 905 may include: a user interface designed to enable a user to interact with electronic device 900; a peripheral component interface designed to enable peripheral components to also interact with electronic device 900; and / or sensors designed to determine environmental conditions and / or location information related to electronic device 900.

[0158] It is worth noting that, Figure 7 This is merely an example. That is, although... Figure 7 The electronic device 900 shown includes multiple devices such as a processor 901, a controller hub 904, and a memory 902. However, in practical applications, devices using the methods of this application may include only a portion of the devices in the electronic device 900. For example, it may include only the processor 901 and the NIC 903. Figure 7 The properties of the optional devices are shown by dashed lines.

[0159] The memory of the electronic device 900 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. The computer-readable storage medium stores instructions, specifically, temporary and permanent copies of those instructions.

[0160] In this application, the electronic device 900 may specifically be a terminal device such as a mobile phone, tablet computer, personal digital assistant (PDA), or desktop computer. The instructions stored in the memory of the electronic device may include instructions that, when executed by at least one unit in the processor, cause the electronic device to implement the simulator data injection method as mentioned above.

[0161] Please see Figure 8 , Figure 8 The diagram shown is a schematic representation of the structure of a SoC (System on Chip) 1000 according to an embodiment of this application. Figure 8 In the figures, similar components have the same reference numerals. Additionally, the dashed box is an optional feature of the more advanced SoC 1000. This SoC 1000 can be used in any electronic device according to this application, and can implement corresponding functions depending on the device it is in and the instructions stored within it.

[0162] exist Figure 8 In this SoC 1000, the following are included: an interconnect unit 1002 coupled to a processor 1001; a system proxy unit 1006; a bus controller unit 1005; an integrated memory controller unit 1003; a group or one or more coprocessors 1007, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random-access memory (SRAM) unit 1008; and a direct memory access (DMA) unit 1004. In one embodiment, the coprocessor 1007 includes a dedicated processor, such as, for example, a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, or an embedded processor, etc.

[0163] SRAM cell 1008 may include one or more computer-readable media for storing data and / or instructions. The computer-readable storage medium may store instructions, specifically, temporary and permanent copies of those instructions. These instructions may include instructions that, when executed by at least one unit of processor 1001, cause the electronic device to implement the simulator data injection method as described above.

[0164] It should be noted that the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0165] It should be noted that some structural or methodological features may be shown in the accompanying drawings in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, including structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0166] Although this application has been illustrated and described with reference to certain preferred embodiments, those skilled in the art should understand that the above description is a further detailed explanation of the application in conjunction with specific embodiments, and should not be construed as limiting the specific implementation of the application to these descriptions. Those skilled in the art can make various changes in form and detail, including some simple deductions or substitutions, without departing from the spirit and scope of this application.

Claims

1. A simulator data injection method for electronic devices, characterized in that, The method includes: The system receives at least two startup operations from the user, namely the first simulator and the second simulator, starts the first simulator and the second simulator, and generates simulator registration lists based on the first registration information of the first simulator and the second registration information of the second simulator, respectively. The simulator registration lists include the first registration information and the second registration information. Receive user data addition operation, determine the first data added by the user for injection into the first simulator, and the second data added for injection into the second simulator; The system receives a user's data injection operation and, based on the simulator registration list, the first data, and the second data, injects the first data into the first simulator and injects the second data into the second simulator, so that the first simulator performs corresponding processing based on the first data and the second simulator performs corresponding processing based on the second data. The first registration information includes the identification information and control port information of the first emulator, and the second registration information includes the identification information and control port information of the second emulator; the first data includes several first sub-data items, and the second data includes several second sub-data items; according to the emulator registration list, the first data, and the second data, the first data is injected into the first emulator, and the second data is injected into the second emulator, including: Based on the correlation between the first data and the second data, determine the data injection task queue corresponding to the sub-data; and The first data injection port of the first simulator is determined based on the first registration information, and the second data injection port of the second simulator is determined based on the second registration information. Task scheduling is performed to execute the data injection task queue, and the first sub-data is injected into the first simulator sequentially through the first data injection port, and the second sub-data is injected into the second simulator sequentially through the second data injection port.

2. The simulator data injection method according to claim 1, characterized in that, The relationship includes the injection sequence relationship between the first sub-data and the second sub-data during the data injection process.

3. The simulator data injection method according to claim 2, characterized in that, The first data further includes first injection time information of the first sub-data, and the second data further includes second injection time information of the second sub-data, wherein the injection timing relationship is determined based on the first injection time information and the second injection time information.

4. The simulator data injection method according to claim 2, characterized in that, The first data further includes first verification information, and the second data further includes second verification information. The first data is injected into the first simulator, and before injecting the second data into the second simulator, the process further includes: The first data is verified based on the first verification information and / or the simulator registration list. If the verification is successful, the first data is injected into the first simulator; if the verification fails, the injection of the first data is stopped. The second data is verified based on the second verification information and / or the simulator registration list. If the verification is successful, the second data is injected into the second simulator. If the verification fails, the injection of the second data is stopped.

5. The simulator data injection method according to claim 4, characterized in that, The first verification information includes at least one of the following: the identification information and type information of the first simulator, and the type information of the first data; and The second verification information includes at least one of the following: the identification information and type information of the second simulator, and the type information of the second data.

6. The simulator data injection method according to claim 1, characterized in that, Before injecting the first data into the first simulator and the second data into the second simulator, the process further includes: The first application to be debugged is installed in the first emulator, and A second application, to be debugged, is installed in the second simulator.

7. The simulator data injection method according to claim 1, characterized in that, The first simulator performs corresponding processing based on the first data, and the second simulator performs corresponding processing based on the second data, including: The first emulator runs the corresponding first application based on the first data, and displays the first simulation interface corresponding to the first application based on the first data; and The second simulator runs the corresponding second application based on the second data, and displays the second simulation interface corresponding to the second application based on the second data.

8. The simulator data injection method according to claim 1, characterized in that, The method further includes: The first simulator sends associated data to the second simulator so that the second simulator can perform corresponding operations based on the associated data. The associated data is either the first data or processing data obtained based on the first data.

9. The simulator data injection method according to claim 8, characterized in that, The second simulator performs corresponding operations based on the associated data, including: The second simulator runs the corresponding second application based on the associated data, and displays the third simulation interface corresponding to the second application based on the associated data.

10. The simulator data injection method according to any one of claims 1-9, characterized in that, The method further includes: The data input interface includes the identification information of the first simulator, a first data addition control corresponding to the identification information of the first simulator, the identification information of the second simulator, a second data addition control corresponding to the identification information of the second simulator, and a data injection control. Receives a user's trigger operation on adding a control to the first data, and receives the first data added by the user through the first data adding control; and Receives user-triggered operation on the second data adding control, and receives the second data added by the user through the second data adding control; The system receives a user's trigger operation on the data injection control, which is then used as the user's data injection operation.

11. A simulator system, characterized in that, include: An emulator server, and at least two emulators: a first emulator and a second emulator. The simulator server is configured to receive user startup operations for at least the first simulator and the second simulator, start the first simulator and the second simulator, and generate simulator registration lists based on the first registration information of the first simulator and the second registration information of the second simulator, respectively. The simulator registration lists include the first registration information and the second registration information. Used to receive user data addition operations, determine the first data added by the user for injection into the first simulator, and the second data for injection into the second simulator; Used to receive user data injection operations, injecting the first data into the first simulator and the second data into the second simulator according to the simulator registration list, the first data and the second data respectively; The first simulator is used to receive the first data injected by the simulator server and perform corresponding processing based on the first data; The second simulator is used to receive the second data injected from the simulator server and perform corresponding processing based on the second data; The first registration information includes the identification information and control port information of the first emulator, and the second registration information includes the identification information and control port information of the second emulator; the first data includes several first sub-data items, and the second data includes several second sub-data items; the emulator server is further configured to: Based on the relationship between the first data and the second data, determine the data injection task queue corresponding to each sub-data; as well as The first data injection port of the first simulator is determined based on the first registration information, and the second data injection port of the second simulator is determined based on the second registration information. Task scheduling is performed to execute the data injection task queue, and the first sub-data is injected into the first simulator sequentially through the first data injection port, and the second sub-data is injected into the second simulator sequentially through the second data injection port.

12. An electronic device, characterized in that, include: A memory for storing computer programs, the computer programs including program instructions; A processor for executing the program instructions to perform the simulator data injection method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which are executed by an electronic device to cause the electronic device to perform the simulator data injection method as described in any one of claims 1-10.

Images