A compatibility verification method, device and system for device virtualization services

Abstract

A compatibility verification method for device virtualization services, an electronic device, an Internet of Things device, and a system, relate to the field of terminal technology. The method includes: when an application accesses the device virtualization service provided by the DMSDP of an electronic device through a DVSDK, the DVSDK requests a first version number from the DMSDP of the electronic device; the first version number monotonically increases with the DMSDP version update, and when the DMSDP is updated, a newly added Android Interface Definition Language (AIDL) interface is added to the end of the AIDL interface file of the DMSDP; when it is determined, based on the DVSDK version number and the first version number, that the DVSDK version is lower than or equal to the DMSDP version of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification fails. Utilizing this method, compatibility issues when an application implements device virtualization services can be improved, thereby enhancing efficiency and user experience.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a compatibility verification method, device, and system for device virtualization services. Background Art

[0002] At present, by installing components such as the device virtualization software development kit (DVSDK) and the distributed mobile sensing development platform (DMSDP) on central-side devices such as mobile phones and tablets, and setting up corresponding DMSDP for adaptation on Internet of Things (IoT) devices that can use cameras, such as desk lamps, the central-side devices can be connected to IoT devices and the virtualized camera function of the IoT devices can be used on the central-side devices.

[0003] Third-party applications on central devices typically access DMSDP through the DVSDK to implement device virtualization service capabilities. Communication between the DVSDK and DMSDP processes occurs via the Android Interface Definition Language (AIDL). DMSDP leverages the virtualized camera capabilities of IoT devices, interacting with them through the DMSDP-created transmission channel to control their cameras for preview and photo capture.

[0004] However, DMSDP is generally a closed-source module, and its version upgrades are performed by the manufacturer of the central-side device; while DVSDK is an interface module that belongs to the same process as the application. The DVSDK version can be upgraded by third-party application manufacturers. Therefore, the DVSDK interface module version may not match the AIDL version in DMSDP, resulting in compatibility issues, which in turn may cause the central-side device to abnormally interrupt the control process of the IoT device, affecting the user experience. Summary of the Invention

[0005] In order to solve the above problems, the present application provides a compatibility verification method, device and system for device virtualization services, which can improve the compatibility issues when applications implement device virtualization services, thereby improving efficiency and user experience.

[0006] In a first aspect, the present application provides a device virtualization service compatibility verification method, which is applied to an electronic device, on which an application, a device virtualization software development kit (DVSDK), and a distributed mobile sensing development platform (DMSDP) are installed, and the electronic device is used to connect to an Internet of Things device. The method includes:

[0007] When the application accesses the device virtualization service of the DMSDP of the electronic device through the DVSDK, the DVSDK requests a first version number from the DMSDP of the electronic device; the first version number monotonically increases as the DMSDP version of the electronic device is updated, and when the DMSDP of the electronic device is updated, a new Android Interface Definition Language (AIDL) interface is added to the end of the AIDL interface file of the DMSDP of the electronic device;

[0008] When it is determined based on the version number of the DVSDK and the first version number that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification of the DMSDP of the electronic device fails.

[0009] The solution provided by the present application is that each time the DMSDP version of the electronic device is updated, the version number of the DMSDP increases monotonically. In order to enable the lower version of the DVSDK interface module to access the higher version of the DMSDP, it is necessary to avoid modifying the existing AIDL interface. If modification is really necessary, a new addition method is used instead. Whenever a new AIDL interface is added, ensure that the new AIDL interface is added at the end of the AIDL interface file so that the AIDL interface file that is not updated on the front end remains unchanged. Therefore, even if the DMSDP module is upgraded, applications that have integrated a lower version of the DVSDK can also use the capabilities of the DMSDP. The compatibility verification process for the DMSDP can be performed before the IoT device discovery phase, ensuring that users can accurately know whether the IoT control process can proceed normally and determine whether the DMSDP version needs to be upgraded earlier, thereby improving efficiency.

[0010] In a possible implementation, when it is determined, based on the version number of the DVSDK and the first version number, that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification of the DMSDP of the electronic device fails, specifically including:

[0011] When the version number of the DVSDK is lower than or equal to the first version number, it is determined that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, and the compatibility verification of the DMSDP of the electronic device is passed;

[0012] When the version number of the DVSDK is higher than the first version number, it is determined that the version of the DVSDK is higher than the version of the DMSDP of the electronic device, and the compatibility verification of the DMSDP of the electronic device fails.

[0013] In a possible implementation, when it is determined, based on the version number of the DVSDK and the first version number, that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification of the DMSDP of the electronic device fails, specifically including:

[0014] Determine the minimum version supported by the DVSDK according to the version number and mapping relationship of the DVSDK;

[0015] When the minimum version supported by the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device is passed;

[0016] When the minimum version supported by the DVSDK is higher than the version of the DMSDP of the electronic device, compatibility verification of the DMSDP of the electronic device fails.

[0017] In a possible implementation, the method further includes:

[0018] When the DMSDP of the electronic device is updated, each time a new AIDL interface is added, the first version number is incremented by 1. At the same time, the DVSDK provided to the application also has a version number that is strongly correlated with the version number in the DMSDP.

[0019] In a possible implementation, when the DMSDP compatibility verification of the electronic device fails, the method further includes:

[0020] An error code indicating that the compatibility verification of the DMSDP of the electronic device fails is returned to the application.

[0021] In a possible implementation, after the DMSDP compatibility verification of the electronic device passes, the method further includes:

[0022] authenticating the application;

[0023] After the authentication of the application is passed, the application is allowed to continue accessing the device virtualization service of the DMSDP of the electronic device.

[0024] In a possible implementation, authenticating the application specifically includes:

[0025] When the authentication identifier of the application is obtained and the authentication identifier is the specified authentication identifier, the authentication of the application passes; otherwise, it is determined whether the application has been registered for the cloud service. If it has been registered for the cloud service, the authentication of the application passes; if it has not been registered for the cloud service, the authentication of the application fails.

[0026] In a possible implementation, when the authentication of the application fails, the method further includes:

[0027] The DMSDP of the electronic device returns an authentication failure error code to the DVSDK and blocks the DVSDK from accessing the DMSDP of the electronic device, thereby eliminating attacks on central devices and even IoT devices by unsafe applications.

[0028] In a possible implementation, the method further includes:

[0029] After establishing a connection channel with the IoT device, the DMSDP of the electronic device receives version number information sent by the IoT device, where the version number information is used to indicate the DMSDP version number of the IoT device;

[0030] The DMSDP of the electronic device determines, based on the version number information, a lowest version number between the first version number and the version number of the DMSDP of the IoT device;

[0031] When it is determined, based on the version number of the DVSDK and the minimum version number, that the version of the DVSDK is lower than or equal to the version corresponding to the minimum version number, the compatibility verification of the DMSDP of the IoT device passes; otherwise, the compatibility verification of the DMSDP of the IoT device fails.

[0032] This solution can also verify the compatibility of DMSDP on the IoT side. This compatibility verification process occurs during the virtual camera service enablement phase, ensuring that users can accurately determine whether the IoT device control process can proceed normally at an earlier stage, thereby determining whether the DMSDP version on the IoT side needs to be upgraded, thereby improving efficiency.

[0033] In a possible implementation, when the DMSDP compatibility verification of the IoT device fails, the method further includes:

[0034] An error code indicating that the compatibility verification of the DMSDP of the IoT device fails is returned to the application.

[0035] In one possible implementation, the version number information is carried in the device capability information sent by the IoT device to the electronic device, and the device capability information is also used to indicate the device virtualization services supported by the IoT device, where the device virtualization services include at least one of a virtualized camera service and a virtualized microphone service.

[0036] In a possible implementation, when the DMSDP compatibility verification of the IoT device passes, the method further includes:

[0037] The DMSDP of the electronic device caches the device capability information in a cache object;

[0038] When the application enables the device virtualization service of the DMSDP of the electronic device, the DMSDP of the electronic device determines whether the IoT device supports the device virtualization service that needs to be enabled based on the device capability information cached by the cache object; if it does, the device virtualization service continues to be enabled; otherwise, the enabling fails.

[0039] In a possible implementation, the DMSDP of the electronic device caches the device capability information in a cache object, specifically including:

[0040] The DMSDP of the electronic device uses the service serial number and the device serial number in the device capability information as a key and stores the key in the cache object.

[0041] In a possible implementation, the DMSDP of the electronic device determines whether the IoT device supports the device virtualization service that needs to be enabled based on the device capability information cached by the cache object, specifically including:

[0042] When the DMSDP of the electronic device finds a key that matches the service serial number and device serial number corresponding to the device virtualization service that needs to be enabled in the key stored in the cache object, it determines that the Internet of Things device supports the device virtualization service that needs to be enabled; otherwise, it determines that the Internet of Things device does not support the device virtualization service that needs to be enabled.

[0043] In a possible implementation, after enabling the device virtualization service is completed, the method further includes:

[0044] The DMSDP of the electronic device uses the device virtualization service that is enabled to be terminated as a key and the capability of the device virtualization service that is enabled to be terminated as a value to form a key-value pair;

[0045] The DMSDP of the electronic device stores the key-value pair in a capability buffer.

[0046] In a possible implementation, the method further includes:

[0047] When the application accesses the target capability of the enabled device virtualization service, the DMSDP of the electronic device uses the enabled device virtualization service as the key. When the value corresponding to the target capability is obtained in the capability buffer, it is determined that the Internet of Things device supports the target capability; otherwise, it is determined that the Internet of Things device does not support the target capability.

[0048] The above implementation method can ensure that in the entire virtualization service application process, the virtualization services that can be provided by the IoT device side and the capabilities of the virtualization services can be verified in time before preparation work, avoiding crashes in the process and improving efficiency and user experience.

[0049] In a possible implementation, when the device virtualization service is a virtualized camera service, the capability of the virtualization service is previewing or taking a photo.

[0050] In a second aspect, the present application further provides a method for verifying the compatibility of a virtualized service, which is characterized in that the method is applied to an Internet of Things device, wherein a distributed mobile sensing development platform DMSDP is installed on the Internet of Things device, and the Internet of Things device is used to connect to the electronic device, and the method includes:

[0051] Establishing a transmission channel with electronic equipment;

[0052] Send version number information to the electronic device, where the version number information is used to indicate the version number of the DMSDP of the Internet of Things device.

[0053] This allows electronic devices to verify the compatibility of DMSDP on the IoT side based on the version number information. The compatibility verification process occurs before the virtual camera service is enabled, ensuring that users can accurately know earlier whether the desk lamp control process can proceed normally, and thus determine whether the DMSDP version on the IoT side needs to be upgraded, thereby improving efficiency.

[0054] In one possible implementation, the version number information is carried in the device capability information sent by the IoT device to the electronic device, and the device capability information is also used to indicate the device virtualization services supported by the IoT device, where the device virtualization services include at least one of a virtualized camera service and a virtualized microphone service.

[0055] In a third aspect, the present application further provides an electronic device comprising a memory and a processor, wherein the memory is coupled to the processor. The memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the compatibility verification method for the device virtualization service provided in the first aspect or in each implementation corresponding to the first aspect.

[0056] In a fourth aspect, the present application further provides an IoT device comprising a camera, a memory, and a processor. The memory is coupled to the processor, and the camera is coupled to the processor. The IoT device may include one or more cameras. The memory stores program instructions that, when executed by the processor, cause the IoT device to perform the compatibility verification method for the device virtualization service provided in the second aspect or any corresponding implementation of the second aspect.

[0057] In a fifth aspect, the present application also provides a collaborative work system, which includes one or more electronic devices provided in the third aspect and one or more Internet of Things devices provided in the fourth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 Indicate the scene Figure 1 ;

[0059] Figure 2a A schematic diagram of a center-side device provided in this application;

[0060] Figure 2b A schematic diagram of the software structure of the central-side device provided in this application;

[0061] Figure 3a A schematic diagram of an IoT device provided in this application;

[0062] Figure 3b A schematic diagram of the software structure of the IoT device provided in this application;

[0063] Figure 4 The process of the photographing method provided in the embodiment of the present application Figure 1 ;

[0064] Figure 5 A flowchart of a method for verifying compatibility of a device virtualization service provided in an embodiment of the present application;

[0065] Figure 6 An architectural diagram for processing the interaction and compatibility between multiple applications and device virtual services provided in an embodiment of the present application;

[0066] Figure 7 A flowchart of another method for verifying compatibility of a device virtualization service provided in an embodiment of the present application;

[0067] Figure 8 Another architectural diagram for processing the interaction compatibility between multiple applications and device virtual services provided in an embodiment of the present application;

[0068] Figure 9 A flowchart of another method for verifying compatibility of a device virtualization service provided in an embodiment of the present application;

[0069] Figure 10 Another architectural diagram for processing the interaction and compatibility between multiple applications and device virtual services provided in an embodiment of the present application;

[0070] Figure 11 A flowchart of another method for verifying compatibility of a device virtualization service provided in an embodiment of the present application;

[0071] Figure 12 An architectural diagram for processing the interaction and compatibility between multiple applications and device virtual services provided in an embodiment of the present application;

[0072] Figure 13 A schematic diagram of a collaborative working system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] The following will describe the technical solutions in the embodiments of this application in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0074] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0075] The terms "first" and "second" and the like in the description and claims of the embodiments of the present application are used to distinguish different objects rather than to describe a specific order of objects.

[0076] In order to enable people skilled in the art to more clearly understand the solution of the present application, the application scenario of the technical solution of the present application is first described below.

[0077] Online education is gaining popularity, and students' demand for it is also growing. In some scenarios, when encountering unfamiliar words, students can look up the relevant explanations online. In other scenarios, online reading of textbook content facilitates students' learning and pronunciation. In still other scenarios, students need to submit their homework online. Therefore, how to meet users' online education needs based on smart devices is a challenge that needs to be addressed.

[0078] See also Figure 1 , the picture shows the scene Figure 1 .

[0079] The central-side device 10 is installed with an educational application. IoT devices 20 such as desk lamps take photos using their cameras and transmit the photos back to the central-side device to implement functions such as answering questions and submitting homework. Alternatively, the central-side device 10 uses the camera on the IoT device 20 to preview the images and provide users with various online education functions based on the images collected by the IoT device 20, such as online word lookup and online reading.

[0080] The central side device 10 may be a mobile phone, a tablet computer, a laptop computer, or a desktop computer, etc., and is not specifically limited in the embodiment of the present application.

[0081] The central device 10 and the IoT device 20 can perform near-field communication and / or far-field communication. Near-field communication can be accomplished through devices such as routers to exchange information between devices, while far-field communication can be accomplished through cloud servers to exchange information between devices.

[0082] The hardware architecture of the center-side device 10 will be described first.

[0083] See also Figure 2a , this figure is a schematic diagram of a center-side device provided in this application.

[0084] Figure 2a The center-side device 10 shown is merely an example, and the center-side device 10 may have more or fewer components than shown, may combine two or more components, or may have a different configuration of components. Figure 2a The various components shown in the drawings may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0085] The central device 10 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identification module (SIM) card interface 195. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an acceleration sensor, a temperature sensor, a motion sensor, an air pressure sensor, a magnetic sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

[0086] The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc.

[0087] Among them, different processing units can be independent devices or integrated into one or more processors.

[0088] The controller can be the nerve center and command center of the central side device 10. The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0089] The processor 110 may further include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory.

[0090] The USB interface 130 is an interface that complies with USB standards and specifications, and may be a MiniUSB interface, a MicroUSB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to charge the central device 10, or to transfer data between the central device 10 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect other electronic devices, such as AR devices.

[0091] The charging management module 140 is configured to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from the wired charger via the USB interface 130.

[0092] In some wireless charging embodiments, the charging management module 140 may receive wireless charging input via a wireless charging coil of the central device 10. While charging the battery 142, the charging management module 140 may also power the electronic device via the power management module 141.

[0093] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to provide power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160.

[0094] The wireless communication function of the central side device 10 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0095] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the central device 10 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0096] For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antenna can be used in combination with a tuning switch.

[0097] The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G, etc. applied to the central side device 10. The mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc.

[0098] The wireless communication module 160 can provide wireless communication solutions applied to the central-side device 10, including wireless local area networks (WLAN) (such as Wi-Fi networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0099] In some embodiments, antenna 1 of the central device 10 is coupled to the mobile communication module 150, and antenna 2 is coupled to the wireless communication module 160, so that the central device 10 can communicate with the network and other devices through wireless communication technology.

[0100] The central device 10 implements display functions through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0101] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the central device 10 may include one or N display screens 194, where N is a positive integer greater than one.

[0102] In the embodiment of the present application, the display screen 194 can display a shooting preview interface and a photo image interface, etc. It should be noted that in the embodiment of the present application, the shooting preview interface refers to an interface in which a user can view images captured in real time by the camera of the IoT device through the display screen 194.

[0103] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the central device 10. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage.

[0104] The internal memory 121 can be used to store computer executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the central-side device 10 by running the instructions stored in the internal memory 121, for example, enabling the central-side device 10 to implement the collaborative working method in the embodiment of the present application. The internal memory 121 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.

[0105] The data storage area can store data created during the use of the central device 10 (such as audio data, phone book, etc.). In addition, the internal memory 121 may include a high-speed random access memory and a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0106] The central device 10 can implement audio functions such as music playback and recording through the audio module 170 , the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0107] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be provided in the processor 110, or some functional modules of the audio module 170 can be provided in the processor 110.

[0108] The speaker 170A, also called a "speaker," is used to convert audio electrical signals into sound signals. The central device 10 can listen to music or make hands-free calls through the speaker 170A. In some embodiments, the central device 10 can be equipped with multiple speakers 170A.

[0109] The receiver 170B, also called a "handset", is used to convert audio electrical signals into sound signals. When the central device 10 receives a call or voice message, the user can hear the voice by placing the receiver 170B close to the ear.

[0110] Microphone 170C, also known as "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to the microphone 170C to input the sound signal into the microphone 170C. The central-side device 10 can be provided with at least one microphone 170C. In other embodiments, the central-side device 10 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the central-side device 10 can also be provided with three, four or more microphones 170C to realize sound signal collection, noise reduction, and identification of sound sources, and realize directional recording function, etc.

[0111] The headphone jack 170D is used to connect a wired headphone and can be a USB interface 130 or a 3.5mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0112] Next, the software structure of the center-side device 10 will be described.

[0113] See also Figure 2b , this figure is a schematic diagram of the software structure of the central side device provided in this application.

[0114] The software system of the central side device 10 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present invention, the Android system with a layered architecture is used as an example to illustrate the software structure of the central side device 10.

[0115] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other via software interfaces. In some embodiments, these layers, from top to bottom, are the application layer, application framework layer, system library layer, extension layer, and kernel layer.

[0116] The application layer can include a series of application packages. For example, an application package can include applications such as gallery, map, Wi-Fi, Bluetooth, SMS, music, call, navigation, video, camera, device management application, and education application.

[0117] Among them, the device management application can sense, discover and register IoT devices in the area.

[0118] Educational applications can be developed by third-party manufacturers to provide users with online education functions, which may have but are not limited to viewing, broadcasting, annotation, query and other functions.

[0119] In some embodiments, a device management application can be bound to an IoT device such as a desk lamp; an educational application can also be bound to an IoT device such as a desk lamp.

[0120] The application framework layer provides an application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0121] like Figure 2b As shown, the application framework layer may include DVSDK, DMSDK, AUTH, intelligent interconnection services and interconnection services, etc.

[0122] Among them, identity verification (AUTH), also known as "authentication" and "authorization", refers to the use of certain means and interface calls for authentication to provide security permission management capabilities and complete the confirmation of user identity, that is, to provide authentication services.

[0123] DVSDK provides device virtualization services, providing an entry point for third-party applications to connect to these services and managing interface access security permissions. Specifically, it can be used to establish a logical channel between the central device and the IoT device, providing virtualized camera capabilities.

[0124] DMSDK is used to provide device management services, providing third-party manufacturers with far-field (i.e., cloud) IoT device information and near-field (i.e., nearby connectable IoT device information).

[0125] Smart interconnection services are used to provide physical transmission channels, data transmission capabilities, and manage the startup of interconnection services.

[0126] Interconnection services establish logical channels between central devices and IoT devices, providing virtualized camera capabilities. They are used to implement data processing, transmission channels, flow control, and capability collection.

[0127] In addition, it can also include window managers, content providers, view systems, phone managers, resource managers, notification managers, etc.

[0128] The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen, take screenshots, etc.

[0129] Content providers store and retrieve data and make it accessible to applications. This data can include video, images, audio, incoming and outgoing calls, browsing history and bookmarks, and phone books. The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views.

[0130] For example, the display interface including the SMS notification icon may include a view for displaying text and a view for displaying pictures. The phone manager is used to provide the communication function of the electronic device 100. For example, the management of call status (including answering, hanging up, etc.). The resource manager provides various resources for applications, such as localized strings, icons, pictures, layout files, video files, etc. The notification manager enables applications to display notification information in the status bar, which can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction.

[0131] The system layer includes system libraries and Android Runtime.

[0132] Android Runtime includes core libraries and a virtual machine. Android Runtime is responsible for scheduling and management of the Android system.

[0133] The core library consists of two parts: one containing the Java language's callable functions and the other the Android core library. The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0134] In the embodiment of the present application, Android Runtime also includes a virtual camera adaptation layer that provides the ability to register a virtual camera.

[0135] The system library can include multiple functional modules, such as multimedia platform, audio framework, graphics and image processing library, decoding module, and virtual camera adaptation layer.

[0136] The multimedia platform can be used for multimedia management, supporting playback and recording of a variety of common audio and video formats, as well as static image files. The multimedia platform can support a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0137] The graphics and image processing library can be used to implement graphics drawing, image rendering, compositing, and layer processing.

[0138] Codecs can be used to implement encoding and decoding operations on audio data and video data.

[0139] The extension layer includes the Hardware Abstraction Layer (HAL). HAL is a routine package of the software layer and an interface layer located between the operating system kernel and the hardware circuit. It is used to simulate the details of a specific system platform so that programs can directly access hardware resources.

[0140] The HAL layer includes but is not limited to: Audio HAL, Sensor HAL, Modem HAL, Camera HAL, and Virtual Camera HAL.

[0141] The audio HAL is used to process audio streams, for example, by performing noise reduction and directional enhancement. The camera HAL is used to process image streams corresponding to the camera on the electronic device side, and the virtual camera HAL is used to process image streams corresponding to the virtual camera registered on the electronic device side, that is, to process image streams captured by the camera on the IoT device side.

[0142] The kernel layer is the layer between hardware and software. The kernel layer may include display drivers, camera drivers, USB drivers, CPU drivers, audio drivers, network drivers (such as Wi-Fi drivers), storage drivers, and printer drivers.

[0143] Next, the hardware structure of the IoT device 20 will be described.

[0144] See also Figure 3a , which is a schematic diagram of an IoT device provided by this application.

[0145] In some embodiments, the IoT device is a desk lamp with a camera. Figure 3a The IoT device 20 shown is merely an example and may have more or fewer components than shown, may combine two or more components, or may have a different configuration of components. Figure 3a The various components shown in the drawings may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0146] The IoT device may include: a processor 210, a camera 201, a wireless communication module 202, a memory 203, an audio module 204, a USB interface 205, a charging management module 206, a power management module 207, a battery 208, a lighting device 209, a button 211, etc.

[0147] The processor 210 may include one or more processing units, for example, the processor 210 may include a GPU, an ISP, a controller, a memory, a video codec, etc. The different processing units may be independent devices or integrated into one or more processors.

[0148] The controller can be the nerve center and command center of the IoT device 20. The controller can generate operation control signals based on instruction opcodes and timing signals to complete the control of instruction fetching and execution.

[0149] Camera 201 is used to capture still images or videos. The object is projected through the lens into an optical image, which is then projected onto a photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor.

[0150] The photosensitive element converts the light signal into an electrical signal, which is then transmitted to the ISP for conversion into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. Taking a desk lamp as an example, the camera 201 can be set on the desk lamp stand to capture images downward.

[0151] The IoT device 20 can implement a shooting function through an ISP, a camera 201, a video codec, a GPU, and the like.

[0152] The ISP processes data fed back by camera 201. For example, when taking a photo, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, which is then passed to the ISP for processing and transformed into a visible image. The ISP can also perform algorithmic optimization on image noise, brightness, and skin tone. It can also optimize parameters such as exposure and color temperature of the captured scene. In some embodiments, the ISP can be located within camera 201.

[0153] The wireless communication module 202 can provide wireless communication solutions for IoT device 20, including WLAN (such as Wi-Fi network) and Bluetooth (BT). In some embodiments, the antenna of IoT device 20 is coupled to the wireless communication module 202, so that IoT device 20 can communicate with the network and other devices through wireless communication technology.

[0154] The memory 203 can be used to store computer-executable program code, which includes instructions. The processor 210 executes the instructions stored in the memory 203 to execute various functional applications and data processing of the IoT device 20, for example, enabling the IoT device 20 to implement the collaborative working method in the embodiment of the present application.

[0155] The IoT device 20 can implement audio functions, such as music playback, through the audio module 204, the speaker 212, etc.

[0156] The USB interface 205 is an interface that complies with USB standards, and may be a MiniUSB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 205 can be used to connect a charger to charge the IoT device 20, and can also be used to transmit data between the IoT device 20 and peripheral devices.

[0157] The charging management module 206 is configured to receive charging input from a charger. While charging the battery 208 , the charging management module 206 can also power the IoT device 20 through the power management module 207 .

[0158] The power management module 207 is used to connect the battery 208, the charging management module 206, and the processor 210. The power management module 207 receives input from the battery 208 and / or the charging management module 206 to provide power to the processor 210, the memory 203, the camera 201, the wireless communication module 202, and the lighting device 209.

[0159] The buttons 211 include a power button (or power button) and the like.

[0160] Next, the software structure of the IoT device 20 will be described.

[0161] See also Figure 3b , which is a schematic diagram of the software structure of the IoT device provided by this application.

[0162] The layers of an IoT device communicate with each other through software interfaces. In some embodiments, from top to bottom, they are the application layer, the application framework layer, the system library layer, and the kernel layer.

[0163] The application layer can include device application services. Device application services can be understood as system-level applications. Device application services are started after the IoT device system is started.

[0164] The application framework layer includes some predefined functions. Figure 3b As shown, the application framework layer may include intelligent interconnection services, resource managers and interconnection services, etc.

[0165] The resource manager is used to provide various resources, such as localized strings, icons, images, layout files, audio files, video files, etc.

[0166] Smart interconnection services provide physical transmission channels to provide data transmission capabilities and manage the activation of interconnection services.

[0167] Interconnection services: Establish a logical channel between central devices and IoT, provide virtualized camera capabilities, and provide open interfaces for device cameras. Specifically, these interfaces include data processing, capability acquisition, virtual audio modules, and virtual camera modules.

[0168] The system layer can include multiple functional modules, such as a multimedia platform, an audio framework, a graphics and image processing library, a decoding module, and an IoT vendor-adapted camera module.

[0169] The multimedia platform can be used for multimedia management, supporting playback and recording of a variety of common audio and video formats, as well as static image files. The multimedia platform can support a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0170] The graphics and image processing library can be used to implement graphics drawing, image rendering, compositing, and layer processing.

[0171] Codecs can be used to implement encoding and decoding operations on audio data and video data.

[0172] IoT manufacturers adapt camera modules to implement interfaces for interconnected modules, providing functions such as opening the camera, taking photos, and previewing.

[0173] The kernel layer is the layer between hardware and software. The kernel layer may include camera drivers, USB drivers, CPU drivers, audio drivers, network drivers, storage drivers, etc.

[0174] Currently, by installing components such as DVSDK and DMSDP on central-side devices such as mobile phones and tablets, and setting up corresponding DMSDP on IoT devices such as desk lamps for adaptation, central-side devices can be connected to IoT devices and the virtualized camera function of IoT devices can be used on central-side devices.

[0175] A typical application scenario for the above technology is education. A central device has a third-party educational application installed, and an IoT device, such as a desk lamp, includes a camera. Once the central device establishes a connection with the IoT device, the IoT device's virtualized camera function can be used on the central device. For example, the IoT device's camera can be used to capture text from a book on a desk. When a mobile phone is pointed at the text, the educational application on the central device automatically recognizes the text, displays annotations, and provides voice reading. The educational application can also initiate a photo request. The IoT device, such as the desk lamp, takes the photo using its camera and then transmits the photo back to the central device for functions such as answering questions and submitting assignments.

[0176] Third-party applications (APPs) on central devices typically access DMSDP through the DVSDK to implement device virtualization service capabilities. Communication between the DVSDK and DMSDP processes occurs via the Android Interface Definition Language (AIDL). DMSDP leverages the virtualized camera capabilities of IoT devices, interacting with them through the DMSDP-created transmission channel to control their cameras for preview and photo capture.

[0177] However, DMSDP is generally a closed-source module, and its version upgrade is performed by the manufacturer of the central-side equipment. The manufacturer of the central-side equipment opens DMSDP to multiple authorized third-party application manufacturers through DVSDK for use; DVSDK is an interface module that belongs to the same process as the application. The DVSDK version can be upgraded by the manufacturer of the central-side equipment and the third-party application manufacturers.

[0178] Because the manufacturer of the central device and the manufacturer of the third-party application may be independent of each other, in some cases, the DVSDK interface module version used by the third-party application manufacturer may not match the AIDL version in DMSDP, or there may even be a large version difference, which in turn leads to compatibility issues. This causes the central device to abnormally interrupt the control process of the IoT device, making it impossible to use the camera on the IoT device to preview and take pictures, affecting the user experience.

[0179] In order to solve the above technical problems, the present application provides a compatibility verification method, device and system for device virtualization services, which can improve the compatibility issues when applications implement device virtualization services and enhance the user experience.

[0180] The following describes the specific implementation method.

[0181] To help those skilled in the art better understand the technical solution of this application, the following first describes the process of establishing a connection between a central device and an IoT device and collaboratively taking photos in this application solution. The following description uses a tablet as the central device and a desk lamp as an example.

[0182] See also Figure 4 , which is a flow chart of the photographing method provided in the embodiment of the present application Figure 1 .

[0183] 0. The device service initialization phase includes the following steps:

[0184] S0.1: In response to the user operation, the device application service of the desk lamp is started and the interconnection service is loaded.

[0185] For example, the user operation can be turning on the power of a desk lamp. In response to the user operation, the desk lamp system starts, the device application service starts, and the interconnection service is loaded. The interconnection service can be used to establish a physical transmission channel between the tablet and the desk lamp to provide data transmission capabilities.

[0186] S0.2, the lamp's Internet service loads the hardware abstraction service.

[0187] The interconnection service can also control the startup of the hardware abstraction service. For example, after the interconnection service is started, the interconnection service can load the hardware abstraction service as a plug-in. The hardware abstraction service can be used to establish a logical channel between the tablet and the desk lamp, providing virtualized camera capabilities and an open interface for the desk lamp camera.

[0188] The hardware abstraction service may include at least a basic component and a camera component. In the device service initialization phase, the interconnected service first loads the basic component and initializes the basic component. After the basic component is initialized, information interaction can be performed with the device adaptation module of the desk lamp to obtain device information and virtualization capability information. Exemplarily, the device information includes but is not limited to the device name, device identification, device type, etc. Exemplarily, the virtualization capability information includes but is not limited to whether a virtualized camera is supported, whether a virtualized microphone is supported, etc., and may further include supported virtualized camera functions, such as only supporting video preview, only supporting photo taking, or supporting both photo taking and video preview.

[0189] Among them, the desk lamp has the ability to support virtualized cameras, which can be understood as the camera of the desk lamp allowing other electronic devices (such as tablets) to call it, that is, it can be understood as the camera of the desk lamp allowing it to be used as a virtual camera of other electronic devices.

[0190] After the basic component obtains the device information and capability information of the desk lamp, if the desk lamp has the ability to support virtualized cameras, the basic component loads the camera component to provide the capability of virtualized cameras. At this point, the basic component can prepare to establish a negotiation channel, waiting to establish a negotiation channel with the tablet to negotiate network connection related information (including but not limited to IP addresses and ports, etc.). Among them, when the basic component prepares to establish a negotiation channel, it creates a session service (SessionServer) and sends the session name (Session Name) of the session service to the interconnection service, waiting for the transmission management service on the tablet side to establish a negotiation channel with the interconnection service on the desk lamp side.

[0191] 1. The device discovery phase includes the following steps:

[0192] S1.1: In response to a user operation, the tablet's education app sends a device discovery instruction to the device management service.

[0193] The user operation may be an operation in which the user clicks on a function option in the education APP that requires calling a virtual camera. For example, the user operation may be an operation in which the user clicks on a reading function, a word lookup function, an assignment function, or a photo taking function in the education APP.

[0194] The tablet's education app receives a user action and, in response, sends a device discovery command to the tablet's device management service. This device discovery command instructs the tablet to search for IoT devices that can connect to the tablet. For example, the device discovery command may include, but is not limited to, the command type and the type of device to be discovered. In this embodiment, the device discovery command specifically searches for a desk lamp that can connect to the tablet.

[0195] S1.2: The device management service in the tablet calls the authentication service to authenticate the education app and obtains the authentication result of the education app.

[0196] After receiving the device discovery instruction, the device management service authenticates the education APP based on the name of the education APP.

[0197] The authentication service obtains the authentication result of the education APP (authentication success or authentication failure) and sends the authentication result to the device management service.

[0198] S1.3: When the education APP is successfully authenticated, the device management service in the tablet sends a device search instruction to the transmission management service.

[0199] The device search instruction may include, but is not limited to, the instruction type, the device type to be searched, and the search method. Exemplary search methods include, but are not limited to, near-field device scanning and obtaining device information from a cloud server. In this embodiment, the device type to be searched is a desk lamp.

[0200] S1.4: The transmission management service in the tablet obtains a list of near- and far-field devices according to the device search instruction, and sends the list of near- and far-field devices to the device management service.

[0201] The far-field and near-field device lists include both the far-field device list and the near-field device list. The far-field devices listed in the far-field device list are registered devices obtained from the cloud server, while the near-field devices listed in the near-field device list are devices scanned via near-field communication. Device information in both the far-field and near-field device lists includes, but is not limited to, the device name, device ID, and device type.

[0202] When the transmission management service receives a device search instruction, it performs relevant device search operations based on the device type to be searched and the search method carried in the device search instruction, such as performing a near-field device scanning operation and obtaining relevant device information in the cloud server, obtaining a far-field device list and a near-field device list, and sending the far-field device list and the near-field device list to the device management service.

[0203] S1.5: The device management service in the tablet filters devices based on the far-field and near-field device lists, and reports the filtered device information to the education app.

[0204] Filter devices, determine the desk lamp information that can be linked with the tablet, and send it to the education APP.

[0205] The device management service can perform an intersection operation on the far-field device list and the near-field device list, filtering out lamps that only exist in the far-field device list or only exist in the near-field device list. The lamps that exist in both the far-field device list and the near-field device list are treated as lamps that can interact with the tablet. In this way, the device management service can filter out lamps that are not registered with the cloud server and can also filter out lamps that cannot perform near-field communication with the tablet.

[0206] In another optional embodiment, regardless of whether the tablet and the desk lamp are in the same local area network, the tablet's transmission management service can obtain a communication device list and a registered device list based on a device search instruction. The devices included in the communication device list are devices scanned via near-field communication or far-field communication, and the devices included in the registered device list are registered devices obtained from the cloud server. The near-field devices included in the near-field device list are devices scanned via near-field communication. In the communication device list and the registered device list, device information includes, but is not limited to, device name, device ID, device type, etc.

[0207] The transmission management service in the tablet sends the communication device list and the registered device list to the device management service. The device management service filters the devices based on the communication device list and the registered device list, and reports the filtered device information to the education APP. Among them, the device management service can perform an intersection operation on the communication device list and the registered device list, filtering out desk lamps that only exist in the communication device list or only exist in the registered device list, and using desk lamps that exist in both the communication device list and the registered device list as desk lamp information that can be linked with the tablet. In this way, the device management service can filter out desk lamps that are not registered in the cloud server, and can also filter out desk lamps that cannot perform near-field communication with the tablet.

[0208] 2. The virtual camera enabling stage includes the following steps:

[0209] S2.1: The tablet's education APP determines the desk lamp to be linked.

[0210] S2.2: The tablet's educational app performs device verification and device connection on the desk lamp, and obtains the desk lamp's ability to support a virtualized camera.

[0211] S2.3: The tablet's education app sends a virtual camera enablement request to the hardware virtualization service.

[0212] The virtual camera enable request is used to instruct the virtual camera to be registered in the virtual camera HAL. The virtual camera enable request may include, but is not limited to, a request type, a device name, a device identifier, a device type, and an identifier of the virtual camera.

[0213] S2.4: The hardware virtualization service of the tablet registers the virtual camera with the virtual camera HAL.

[0214] After receiving the virtual camera enable request, the hardware virtualization service registers the corresponding virtual camera with the virtual camera HAL according to the virtual camera enable request.

[0215] S2.5: After the virtual camera registration is completed, the tablet's virtual camera HAL sends a virtual camera enabling success indication to the education app.

[0216] 3. Virtual camera preview access stage:

[0217] S3.1: The hardware virtualization API in the tablet sends a virtual camera access instruction to the camera service.

[0218] The virtual camera access instruction refers to an instruction for calling a virtual camera, wherein the virtual camera access instruction may include but is not limited to an instruction type, a virtual camera ID, and camera configuration parameters.

[0219] S3.2: The camera service in the tablet sends an image preview request to the virtual camera HAL according to the virtual camera access instruction.

[0220] After receiving the virtual camera access instruction, the camera service generates a corresponding image preview request based on the virtual camera ID and sends it to the virtual camera HAL.

[0221] The image preview request is used to request a preview of an image data stream. Exemplarily, the image preview request may include, but is not limited to, a request identifier, a virtual camera ID, and camera configuration parameters.

[0222] S3.3: The virtual camera HAL in the tablet sends an image preview request to the hardware virtualization service.

[0223] After receiving the image preview request, the virtual camera HAL determines the matching virtualized hardware identifier based on the virtual camera ID carried in the image request.

[0224] In this embodiment, the virtual camera HAL determines the linked desk lamp camera based on the virtual camera ID and the mapping relationship between the virtual camera ID and the desk lamp camera, and generates a corresponding image request based on the determined virtualization hardware identifier and sends it to the hardware virtualization service.

[0225] Exemplarily, the image preview request may include but is not limited to a request identifier, device information (ie, desk lamp information), a virtualized hardware identifier (ie, desk lamp camera identifier), and camera configuration parameters.

[0226] S3.4: The hardware virtualization service in the tablet sends an image preview request to the transmission management service.

[0227] The hardware virtualization service sends an image preview request to the transmission management service. The image preview request may include, but is not limited to, a request identifier, device information (i.e., desk lamp information), a virtualized hardware identifier (i.e., desk lamp camera identifier), and camera configuration parameters.

[0228] When the tablet's hardware virtualization service sends an image preview request to the transmission management service, if it finds that a data channel with the desk lamp is not established, it generates a data channel establishment request and sends it to the transmission management service. This data channel establishment request is used to instruct data transmission between the desk lamp and the tablet. The data channel establishment request may include, but is not limited to, a session identifier, connection information, and data encoding and decoding mode.

[0229] The tablet's transmission management service receives the data channel establishment request and, based on the information in the data channel establishment request, establishes a data channel connection with the lamp, effectively establishing a data channel between the tablet and the lamp. The tablet's transmission management service and the lamp's interconnection service can then use this data channel to transmit various data, including but not limited to image data.

[0230] After the data channel is successfully established, the tablet's transport management service sends a successful data channel connection indication to the tablet's hardware virtualization service, and the lamp's interconnection service sends a successful data channel connection indication to the camera component in the hardware abstraction service. The successful data channel connection indication may include, but is not limited to, a successful connection flag and data channel related information.

[0231] S3.5: The transfer management service in the tablet transmits an image preview request to the interconnection service in the desk lamp.

[0232] The transmission management service in the tablet determines the corresponding control channel based on the device information carried in the image preview request, and transmits the image preview request to the interconnection service of the desk lamp through the control channel.

[0233] S3.6: The interconnection service in the desk lamp sends an image preview request to the camera driver.

[0234] After receiving the image preview request, the interconnection service in the desk lamp determines the corresponding hardware driver (in this embodiment, the camera driver) according to the virtualized hardware identifier, and sends the corresponding image preview request to the camera driver.

[0235] S3.7: The camera driver in the desk lamp drives the camera to capture images and transmits the preview image data to the hardware virtualization service of the tablet through the data channel.

[0236] The camera driver turns on the camera and drives it to capture images using the camera configuration parameters carried in the image preview request. This generates a preview image data stream and sends it to the interconnection service via the hardware abstraction service. The interconnection service then continuously transmits the preview image data stream to the tablet's hardware virtualization service via the data channel. The details of the preview image data stream's packetization, assembly, and encoding / decoding are not detailed here.

[0237] S3.8: The hardware virtualization service in the tablet sends the preview image data to the virtual camera HAL.

[0238] The hardware virtualization service continuously receives the preview image data stream and sends the preview image data stream to the virtual camera HAL.

[0239] S3.9: The virtual camera HAL in the tablet sends the preview image data to the camera service.

[0240] At this time, the virtual camera HAL continues to obtain the preview image data collected by the desk lamp camera and continues to send the preview image data to the camera service.

[0241] S3.10: The camera service in the tablet sends the preview image data to the education app.

[0242] S3.11: The educational app on the tablet displays a preview image.

[0243] 4. Virtual camera photo taking stage

[0244] S4.1: In response to the received user operation, the education APP in the tablet sends a photo request to the hardware virtualization service.

[0245] The user operation may be, for example, clicking a photo option. In response to the received user operation, the education APP in the tablet sends a photo request to the hardware virtualization service.

[0246] The photo request may include but is not limited to the image sequence number, device information (i.e., desk lamp information), virtualized hardware identifier (i.e., desk lamp camera identifier), and camera configuration parameters, etc. The camera configuration parameters include but are not limited to image resolution.

[0247] The photo request may also carry a task identifier to ensure orderly management of multiple photo tasks.

[0248] S4.2: The hardware virtualization service in the tablet sends a photo-taking request to the transmission management service.

[0249] S4.3: The transfer management service in the tablet transmits a photo-taking request to the interconnection service of the desk lamp.

[0250] The transmission management service in the tablet determines the corresponding control channel based on the device information carried in the image preview request, and transmits the image preview request to the interconnection service of the desk lamp through the control channel.

[0251] S4.4: The Internet service in the desk lamp sends a photo request to the camera driver.

[0252] After receiving the image preview request, the interconnection service in the desk lamp determines the corresponding hardware driver (in this embodiment, the camera driver) according to the virtualized hardware identifier, and sends the corresponding photo request to the camera driver.

[0253] S4.5: The camera driver in the desk lamp drives the camera to capture images and transmits the captured image data to the hardware virtualization service of the tablet through the data channel.

[0254] The camera driver drives the camera to capture an image using the camera configuration parameters carried in the photo request, obtains the captured image data, and sends the captured image data to the interconnection service through the hardware abstraction service. The interconnection service then continuously transmits the captured image data to the tablet's hardware virtualization service through the data channel. The image data packetization, grouping, encoding, and decoding processes are not detailed here.

[0255] S4.6: The hardware virtualization service in the tablet sends the captured image data to the education app.

[0256] S4.7: The educational app on the tablet displays the captured image.

[0257] This technical solution allows central devices to be directly connected to electronic devices such as mobile phones and tablets. IoT devices can be installed separately from central devices, eliminating the need for a heavy base with a retractable camera. IoT devices, such as desk lamps, can be positioned freely, with screen angles adjusted as needed. Furthermore, educational applications installed on central devices offer high compatibility and scalability, making them easy to implement and promote, greatly facilitating education.

[0258] The above steps are used to establish a connection between the central device and the IoT device and collaborate to realize the process of taking pictures. However, when the educational APP pulls up the DMSDP service through the DVSDK interface module, that is, when the above hardware virtualization service is realized, the mismatch between the DVSDK version and the AIDL version in the DMSDP will cause compatibility issues, causing the above picture-taking process to be abnormally interrupted, greatly wasting the user's time and reducing efficiency. Therefore, the solution of this application designs a compatibility detection step before the IoT device is started, that is, before the above step S01, in order to detect compatibility problems as early as possible. It is understandable that the execution order of this method can also be set between S1.1, which can also achieve early detection of compatibility problems.

[0259] See also Figure 5 , which is a flowchart of the compatibility verification method for device virtualization services provided in an embodiment of the present application.

[0260] The compatibility verification method of the device virtualization service includes the following steps:

[0261] S51: The education app accesses the device virtualization service provided by DMSDP.

[0262] DMSDP is a capability platform that requires not only cross-process and application layer interaction via AIDL, but also cross-device interaction with IoT devices via transmission channels. Therefore, educational apps must first access the DV service capabilities provided by the DMSDP module through the DVSDK interface.

[0263] Specifically, the DMSDP and DVSDK processes communicate through the AIDL interface, which means that the DVSDK can access the DMSDP through the AIDL interface.

[0264] S52: The DVSDK requests the current DMSDP version number.

[0265] See also Figure 6 , this figure is an architectural diagram for processing the interactive compatibility between multiple applications and device virtual services provided by an embodiment of the present application.

[0266] Among them, multiple third-party APPs are installed on the central side device, and the versions of the DVSDK interface modules of the multiple third-party APPs can be the same or different, which is not specifically limited in the embodiment of this application.

[0267] The upgrade of DMSDP means that the DMSDP AIDL interface has been transformed. To ensure compatibility, that is, the lower version of the DVSDK interface module can access the higher version of the DMSDP module, the technical solution adopted in this application is:

[0268] First, avoid modifying existing AIDL interfaces. If modification is necessary, use a new interface instead. That is, if AIDL interface 1 is the current version's interface and the updated version is AIDL interface 2, AIDL interface 2 will not replace AIDL interface 1. Instead, AIDL interface 2 will be added while retaining AIDL interface 1. After this update, DVSDKs that previously connected to AIDL interface 1 and did not support connecting to AIDL interface 2 will still be able to communicate with DMSDP through AIDL interface 1 without being affected.

[0269] Secondly, whenever a new AIDL interface is added, ensure that it is added at the end of the AIDL interface file so that the AIDL interface files that are not updated by the front-end remain unchanged. This way, even if the DMSDP module is upgraded, applications that integrate an earlier version of the DVSDK can still use the DMSDP capabilities.

[0270] In addition, to ensure efficient interaction between DMSDP and DVSDK, a version management module has been added to DMSDP. The DMSDP version number increases with each version update.

[0271] In some embodiments, the DMSDP version number monotonically increases with each version update. For example, if the current DMSDP version is 1.0.0, after a version update, the version number in the version management module is incremented by one, and the DMSDP version becomes 1.0.1. The number of newly added AIDL interfaces in each version update can be one or more, and this is not specifically limited in this embodiment.

[0272] In other embodiments, taking the current DMSDP version as 1.0.0 as an example, during the version update process, each time an AIDL interface is added, the version number in the version management module is counted and increased by one, and the DMSDP version becomes 1.0.1.

[0273] At the same time, the DVSDK provided to the application also has a version number that is strongly correlated with the version number in the DMSDP.

[0274] In some embodiments, if the version number of the DVSDK provided to the application is the same as the version number of the DMSDP, it indicates that the DVSDK is upward compatible with the corresponding DMSDP version. For example, if the DVSDK version number is 1.0.0, it means that the DVSDK is compatible with DMSDP versions 1.0.0 and above (1.0.1, 1.0.2, etc.).

[0275] In other embodiments, a mapping relationship exists between the DVSDK version number provided to the application and the DMSDP version number. The DVSDK version number can be used to determine the minimum DMSDP version it supports. For example, if the DVSDK version number is 2.0.0, the mapping relationship determines that the minimum DMSDP version supported by the DVSDK is 1.0.0, indicating that the DVSDK is compatible with DMSDP versions 1.0.0 and above (1.0.1, 1.0.2, etc.).

[0276] DVSDK accesses the version management module through the AIDL interface to obtain the current DMSDP version.

[0277] S53: DMSDP returns the current DMSDP version number to DVSDK.

[0278] DMSDP returns its current version number to DVSDK through the AIDL interface.

[0279] S54: DVSDK compares the current DMSDP version number with its own version number to determine whether they are compatible.

[0280] DVSDK compares the current DMSDP version number with its own version number. If the DVSDK version number is lower than or equal to the DMSDP version number, the compatibility verification passes. If the DVSDK version number is higher than the DMSDP version number, the compatibility verification fails.

[0281] S55: Return the compatibility verification result.

[0282] When the compatibility verification passes, the APP of the center-side device can normally access the device virtualization service provided by DMSDP and can continue to execute S56; when the compatibility verification fails, an incompatible error code can be returned to the APP, and the user is prompted to upgrade the DMSDP version.

[0283] S56: Educational APP connects to DVSDK interface module.

[0284] S57: DVSDK connects to the device virtualization service provided by DMSDP.

[0285] In summary, the solution provided by the embodiment of the present application is that each time the DMSDP version of the electronic device is updated, the version number of the DMSDP increases monotonically. In order to enable the lower version of the DVSDK interface module to access the higher version of the DMSDP, it is avoided to modify the existing AIDL interface. If modification is really necessary, a new addition method is used instead. Whenever a new AIDL interface is added, ensure that the new AIDL interface is added at the end of the AIDL interface file so that the AIDL interface file that is not updated on the front end remains unchanged. Therefore, even if the DMSDP module is upgraded, applications that have integrated a lower version of the DVSDK can also use the capabilities of the DMSDP. The compatibility verification process for the DMSDP can be performed before the IoT device discovery phase, ensuring that users can accurately know whether the IoT control process can proceed normally and determine whether the DMSDP version needs to be upgraded earlier, thereby improving efficiency.

[0286] Because DVSDK is an open interface, while DMSDP is a closed-source module that provides cross-device capabilities, to accurately manage information security issues in cross-device scenarios, it is necessary to ensure that only third-party applications authorized by the central device manufacturer and the central device manufacturer's applications can access DMSDP services. Therefore, a mechanism must be designed to address the security issues of different applications accessing DMSDP services. The details are explained below.

[0287] In some embodiments, the APP authentication step can be performed every time the APP calls the interface in DMSDP through DVSDK, such as connection, enablement, preview, photo taking, etc. It is understandable that even if the third-party application is authorized by the device manufacturer on the central side, it may only be authorized to use some but not all of the DMSDP services. Therefore, in order to avoid excessive use of permissions by third-party applications, authentication can be performed multiple times. For example, after the third-party application passes the authentication of the preview process, it needs to be authenticated again when performing the photo taking process.

[0288] See also Figure 7 and Figure 8 .in, Figure 7 A flowchart of another method for verifying compatibility of a device virtualization service provided in an embodiment of the present application; Figure 8 Another architectural diagram for processing the interactive compatibility between multiple applications and device virtual services provided in an embodiment of the present application.

[0289] Continuing to use the educational app as an example, based on compatibility verification, the method also includes:

[0290] S58: Authenticate the education APP.

[0291] Whenever an application needs to call an interface in DMSDP through DVSDK, the APP must be authenticated.

[0292] The device management service provided by DMSDP integrates an authentication module. Based on the education app's package name and signature fingerprint, the authentication module can determine whether the application layer's education app is a third-party application or a self-developed application by the device manufacturer on the central side.

[0293] The signature fingerprint is a unique authentication mark of the central device manufacturer, which is used to directly identify the educational app itself and is unforgeable, equivalent to an anti-counterfeiting mark. The central device manufacturer will add this signature fingerprint to the app during the development process. The signature fingerprints of different apps developed by the central device manufacturer can be the same or different, and this embodiment of the application does not specifically limit this.

[0294] If it is a self-developed application from the central equipment manufacturer, it can pass the authentication directly.

[0295] If it comes from a third-party application, you can use cloud authentication to determine whether it can access DMSDP capabilities.

[0296] In some embodiments, third-party applications authorized by the central-side device manufacturer can register with the central-side device manufacturer's cloud service. By accessing the cloud service, it is determined whether the third-party application is a secure application registered with the cloud service. If it is a secure application, it passes authentication; if it is not a secure application, DMSDP directly returns an error code indicating authentication failure, blocking its ability to access DMSDP, thereby eliminating attacks on central-side devices and even IoT devices by unsafe applications.

[0297] S59: Return the authentication result.

[0298] If the authentication succeeds, the authentication result is passed; if the authentication fails, the authentication result is the error code of authentication failure.

[0299] Furthermore, the above description only uses the compatibility verification of DVSDK and DMSDP of the central-side device as an example. In actual applications, since the central-side device needs to establish a connection with the IoT device, and the IoT device also includes the corresponding DMSDP module, the compatibility with the IoT device also needs to be considered. The details are explained below.

[0300] See also Figure 9 and Figure 10 .in, Figure 9 A flowchart of another method for verifying compatibility of a device virtualization service provided in an embodiment of the present application; Figure 10An architectural diagram of another solution for handling the interactive compatibility between multiple applications and device virtual services provided in an embodiment of the present application.

[0301] Figure 9 The method shown in Figure 7 Based on this, the following steps are also included:

[0302] S60: Send a device discovery instruction.

[0303] In response to user operations, the tablet's education app sends a device discovery command to the DMSDP device management service through the DVSDK. The device discovery command is used to instruct the tablet to find an IoT device that can establish a connection with the tablet.

[0304] S61: Establish a transmission channel.

[0305] S62: Device discovery connection.

[0306] S63: The IoT device connects to the central device.

[0307] S64: The DVSDK of the IoT device obtains device capability information including the DMSDP version number on the IoT side.

[0308] S65: The DVSDK returns the device capability information to the network transmission module on the central device side through the network transmission module on the IoT device side.

[0309] S66: The network transmission module on the central device side returns the device capability information to the transmission channel.

[0310] S67: The transmission channel returns the device capability information to the device management service.

[0311] S68: Determine the minimum DMSDP version number.

[0312] In some embodiments, the version management module of the DMSDP on the central device side determines the minimum DMSDP version number.

[0313] The minimum DMSDP version number is the minimum value between the DMSDP version number on the IoT side and the DMSDP version number on the central device side.

[0314] For example, if the IoT-side DMSDP version is 1.0.2 and the central device-side DMSDP version is 1.1.1, the minimum version number is 1.0.2. This value means that since DVSDK is upwardly compatible with DMSDP versions, if DVSDK is compatible with the minimum DMSDP version, it can be compatible with both the IoT-side DMSDP and the central device-side DMSDP.

[0315] S69: DMSDP returns the minimum DMSDP version number to DVSDK.

[0316] S70: DVSDK compares the minimum DMSDP version number with its own version number to determine whether they are compatible.

[0317] DVSDK compares the obtained minimum DMSDP version number with its own version number. If the DVSDK version number is lower than or equal to the minimum DMSDP version number, the compatibility verification passes. If the DVSDK version number is higher than the minimum DMSDP version number, the compatibility verification fails.

[0318] S71: Return the final compatibility verification result.

[0319] If the compatibility verification passes, the central device's app can access the device virtualization service provided by DMSDP and proceed to the subsequent virtual camera service enablement phase. If the compatibility verification fails, the user needs to upgrade the DMSDP version of the IoT device.

[0320] It is understandable that the version number information of the IoT-side DMSDP in the above description is carried in the device capability information. In other embodiments, the version number of the IoT-side DMSDP may also be carried in other information, or sent by the IoT as independent version number information, for example, the IoT side directly sends version number information, which carries the version number of the IoT-side DMSDP.

[0321] In some embodiments, the updating method of the DMSDP on the IoT side is the same as the updating method of the DMSDP on the IoT device side, and will not be repeated again.

[0322] To sum up, using the solution provided by the embodiment of the present application, after establishing a connection channel with the IoT device, the DMSDP of the electronic device receives the version number information sent by the IoT device, and the version number information is used to indicate the version number of the DMSDP of the IoT device; the DMSDP of the electronic device determines the lowest version number between the first version number and the version number of the DMSDP of the IoT device based on the version number information; when it is determined that the version of the DVSDK is lower than or equal to the version corresponding to the lowest version number based on the version number of the DVSDK and the lowest version number, the compatibility verification of the DMSDP of the IoT device is passed; otherwise, the compatibility verification of the DMSDP of the IoT device fails.

[0323] Therefore, it is possible to verify the compatibility of DMSDP on the IoT side. This compatibility verification process occurs before the virtual camera service is enabled, ensuring that users can accurately determine whether the desk lamp control process can proceed normally at an earlier stage, and thus determine whether the DMSDP version on the IoT side needs to be upgraded, thereby improving efficiency.

[0324] In addition to verifying DMSDP version compatibility, IoT devices also need to verify device capability compatibility. It's possible that a central device, such as a mobile phone or tablet, may not have the capabilities required by the IoT device. For example, an app may need to control the IoT device's camera through the central device to take photos, but the IoT device's camera may not have the capability.

[0325] See also Figure 11 and Figure 12 .in, Figure 11 A flowchart of another method for verifying compatibility of a device virtualization service provided in an embodiment of the present application; Figure 12 Another architectural diagram for processing the interactive compatibility between multiple applications and device virtual services provided in an embodiment of the present application.

[0326] The following method uses an IoT device camera that supports preview but not photo capture as an example. The implementation principles for IoT devices with photo capture support are similar and are not detailed here.

[0327] The method provided in the embodiment of the present application can be Figure 9 Continue after S71 in.

[0328] S80: Cache the device capability information into a cache object.

[0329] The device capability information is the device capability information obtained in S67. The device capability information is used to indicate the device virtualization services supported by the IoT device, and the device virtualization services include but are not limited to at least one of a virtualized camera service and a virtualized microphone service.

[0330] DMSDP designs the device capability management module.

[0331] The device capability management module operates as follows: During the connection process between a central device and an IoT device, once the transmission channel is established, the IoT device sends its capability information to the central device via the transmission channel. After receiving the capability information, the central device caches it in a cache object called Profile Management. Profile Management stores all the IoT device's services and their capabilities, using the service ID and device ID as keys.

[0332] The device ID is used to identify individual cameras. An IoT device can include one or more cameras, each with a different device ID. For example, camera 1 has a device ID of 1, and camera 2 has a device ID of 2. Profile Management stores the services that each camera can provide. The services and capabilities provided by each camera can be the same or different, and this embodiment does not limit this.

[0333] S81: Call the DMSDP enable interface to register the virtual camera service.

[0334] If your app needs to access the virtual camera service on the IoT device through DMSDP for previewing or taking photos, you must first call the DMSDP enablement API to enable the virtual camera service, that is, register the virtual camera service.

[0335] S82: Determine whether the IoT device has the service that needs to be enabled based on the device capability information cached by the cache object.

[0336] In the virtual camera service enablement process, the service ID and device ID are used as keys in Profile Management to determine whether the peer IoT device has the required device virtualization service. If not, the virtualization service required by the application exceeds the service capabilities of the IoT device. Therefore, the enablement fails and the "unsupported capability" message is directly returned, enabling the IoT device service to be verified as soon as possible.

[0337] If Profile Management has device virtualization services that need to be enabled, the process continues.

[0338] S83: Enable the virtual camera service.

[0339] For the specific process of enabling the virtual camera service, please refer to the above Figure 4 The description in the embodiment of the present application will not be repeated here.

[0340] In this embodiment, the virtual camera service is used as an example. This means that the central device can use the IoT device's camera to preview or take photos, virtualizing the IoT device's camera as its own camera. The principle of the virtual microphone service is similar and will not be repeated here.

[0341] S84: Store the correspondence between the service sequence number and the camera capability in the camera capability buffer.

[0342] After the virtual camera service is successfully enabled, a key-value pair is created, using the service ID (i.e., the specific device virtualization service) of the enabled camera as the key and the device virtualization service's capabilities as the value. This pair is then cached in the camera capabilities buffer. In this embodiment, the device virtualization service's capabilities, i.e., the virtualized camera's capabilities, include one or more of the following: photo capture and preview.

[0343] When an app controls an IoT device through DMSDP to enable camera preview or photography, it retrieves a value from the camera capability buffer using the service ID as the key. If a value is retrieved and indicates that the corresponding preview or photography is supported, the process continues. If no value is retrieved, it means that the IoT device's camera does not support the selected capability.

[0344] For example, if service ID 1 represents the virtualized camera service and service ID 2 represents the virtualized microphone service, the camera of the IoT device only supports the preview capability but not the photo capability. Therefore, when you use 1 as the key to retrieve a value from the camera capability buffer, you can retrieve the value corresponding to the preview capability but not the value corresponding to the photo capability.

[0345] S85: Send a virtual camera preview access instruction.

[0346] The education app sends a virtual camera preview access instruction to the DMSDP through the DVSDK interface.

[0347] S86: Query the camera capability buffer based on the service sequence number to see whether the camera supports preview.

[0348] The DMSDP capability management module retrieves a value from the camera capability buffer based on the service ID corresponding to the virtual camera service. If a value is retrieved and indicates that preview is supported, the process continues. If no value is retrieved, it means that the IoT device's camera does not support preview.

[0349] S87: Continue the virtual camera preview access process.

[0350] For the specific process of virtual camera preview access process, please refer to the above Figure 4 The description in the embodiment of the present application will not be repeated here.

[0351] S88: Send a photo taking request.

[0352] The education app sends a photo request to the DMSDP through the DVSDK interface.

[0353] S89: Query the camera capability buffer according to the service sequence number to see whether the camera supports taking photos.

[0354] The DMSDP capability management module retrieves a value from the camera capability buffer based on the service ID corresponding to the virtual camera service. If a value is retrieved and indicates that photo taking is supported, the process continues. If no value is retrieved, it means that the IoT device's camera does not support photo taking.

[0355] S90: Returns the error code that photography is not supported.

[0356] When the camera does not support taking photos, an error code indicating that the camera does not support taking photos is returned.

[0357] When the camera supports taking photos, continue with the virtual camera photo taking process, see Figure 4 The relevant descriptions in the embodiments of the present application will not be repeated here.

[0358] In summary, the solution provided by the embodiment of the present application is that the DMSDP of the electronic device uses the service serial number and device serial number in the device capability information as keys and stores the keys in the cache object. When the application enables the device virtualization service of the DMSDP of the electronic device, when the DMSDP of the electronic device finds a key that matches the service serial number and device serial number corresponding to the device virtualization service that needs to be enabled in the keys stored in the cache object, it determines that the Internet of Things device supports the device virtualization service that needs to be enabled; otherwise, it determines that the Internet of Things device does not support the device virtualization service that needs to be enabled. After the enabling of the device virtualization service is completed, the DMSDP of the electronic device uses the enabled device virtualization service as a key and the capability of the enabled device virtualization service as a value to form a key-value pair; the DMSDP of the electronic device stores the key-value pair in the capability buffer. When the application accesses the target capability of the enabled device virtualization service, the DMSDP of the electronic device uses the enabled device virtualization service as a key, and when the value corresponding to the target capability is obtained in the capability buffer, it determines that the Internet of Things device supports the target capability; otherwise, it determines that the Internet of Things device does not support the target capability.

[0359] Therefore, the design of the above device capability management module can ensure that in the entire virtualization service application process, the virtualization services that can be provided by the IoT side and the capabilities of the virtualization services are verified in time before preparation work, avoiding crashes in the process and improving efficiency and user experience.

[0360] Based on the compatibility verification method for device virtualization services provided in the above embodiments, the present application also provides an electronic device.

[0361] Continue to see Figure 2a Schematic diagram of the electronic device shown.

[0362] The electronic device provided in the embodiment of the present application includes: a memory (ie, an internal memory 121 ) and a processor 110 .

[0363] The memory 121 is coupled to the processor 110 .

[0364] The memory 121 stores program instructions. When the processor 110 executes the program instructions, the electronic device implements the compatibility verification method for the device virtualization service described in the above embodiment.

[0365] Based on the compatibility verification method for device virtualization services provided in the above embodiments, the present application also provides an Internet of Things device.

[0366] Continue to see Figure 3a Schematic diagram of IoT devices shown.

[0367] The Internet of Things provided in the embodiment of the present application includes: a camera 201, a memory 203 and a processor 210.

[0368] The memory 203 is coupled to the processor 210, and the camera 201 is coupled to the processor 210. In some embodiments, there may be multiple cameras 201.

[0369] Utilizing the electronic device provided by the embodiment of the present application, each time the DMSDP version of the electronic device is updated, the version number of the DMSDP increases monotonically. In order to enable the lower version of the DVSDK interface module to access the higher version of the DMSDP, it is avoided to modify the existing AIDL interface. If modification is really necessary, a new addition method is used instead. Whenever a new AIDL interface is added, ensure that the new AIDL interface is added at the end of the AIDL interface file so that the AIDL interface file that is not updated on the front end remains unchanged. Therefore, even if the DMSDP module is upgraded, applications that have integrated a lower version of the DVSDK can also use the capabilities of the DMSDP. The compatibility verification process for the DMSDP can be performed before the IoT device discovery phase, ensuring that users can accurately know whether the IoT control process can proceed normally and determine whether the DMSDP version needs to be upgraded earlier, thereby improving efficiency.

[0370] In addition, the IoT device can send version information to the electronic device, indicating the version number of the IoT device's DMSDP. The electronic device then verifies the compatibility of the IoT-side DMSDP based on this version information. This compatibility verification process occurs before the virtual camera service is enabled, ensuring that users can accurately determine whether the desk lamp control process can proceed normally and whether the DMSDP version on the IoT side needs to be upgraded, thereby improving efficiency.

[0371] Furthermore, based on the electronic devices and Internet of Things devices provided in the above embodiments, the embodiments of the present application also provide a collaborative working system.

[0372] See also Figure 13 , which is a schematic diagram of a collaborative work system provided in an embodiment of the present application.

[0373] The collaborative working system 30 includes an electronic device 10 and an IoT device 20 .

[0374] The electronic device 10 is also the central side device. For the specific implementation of the electronic device 10 and the IoT device 20, please refer to the relevant description in the above embodiments, and the embodiments of this application will not be repeated here.

[0375] In summary, in the collaborative work system provided by the embodiment of the present application, each time the DMSDP version of the electronic device is updated, the version number of the DMSDP increases monotonically. In order to enable the low-version DVSDK interface module to access the high-version DMSDP, avoid modifying the existing AIDL interface. If modification is really necessary, use the new addition method instead. Whenever a new AIDL interface is added, ensure that the new AIDL interface is added at the end of the AIDL interface file so that the AIDL interface file that is not updated on the front end remains unchanged. Therefore, even if the DMSDP module is upgraded, applications that integrate a low-version DVSDK can also use the capabilities of DMSDP. The compatibility verification process for DMSDP can be performed before the IoT device discovery phase, ensuring that users can accurately know whether the IoT control process can proceed normally and determine whether the DMSDP version needs to be upgraded earlier, thereby improving efficiency.

[0376] Furthermore, it can verify the compatibility of DMSDP on the IoT device side. This compatibility verification process occurs during the virtual camera service enablement phase, ensuring that users can accurately determine whether the desk lamp control process can proceed normally at an earlier stage, thereby determining whether the DMSDP version on the IoT device side needs to be upgraded, thereby improving efficiency. Furthermore, it ensures that the entire virtual camera application process verifies the capabilities of the IoT device side in a timely manner before preparation, avoiding crashes during the process and improving efficiency and user experience.

[0377] This embodiment also provides a computer storage medium, which stores computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the compatibility verification method of the device virtualization service in the above-mentioned embodiment.

[0378] This embodiment further provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the compatibility verification method of the device virtualization service in the above-mentioned embodiment.

[0379] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer execution instructions, and when the device is running, the processor can execute the computer execution instructions stored in the memory to enable the chip to execute the compatibility verification method of the device virtualization service in the above-mentioned method embodiments.

[0380] Among them, the electronic devices (such as tablets, mobile phones, IOT devices, etc.), computer storage media, computer program products or chips provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0381] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

Claims

1. A compatibility verification method for a device virtualization service, characterized in that: Applied to an electronic device, the electronic device is installed with an application, a device virtualization software development kit DVSDK, and a distributed mobile sensing development platform DMSDP, and the electronic device is used to connect to an Internet of Things device. The method includes: When the application accesses the device virtualization service of the DMSDP of the electronic device through the DVSDK, the DVSDK requests a first version number from the DMSDP of the electronic device; the first version number monotonically increases as the DMSDP version of the electronic device is updated, and when the DMSDP of the electronic device is updated, a new Android Interface Definition Language (AIDL) interface is added to the end of the AIDL interface file of the DMSDP of the electronic device; When it is determined based on the version number of the DVSDK and the first version number that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification of the DMSDP of the electronic device fails.

2. The compatibility verification method for device virtualization services according to claim 1, characterized in that: When it is determined, based on the version number of the DVSDK and the first version number, that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification of the DMSDP of the electronic device fails, specifically including: When the version number of the DVSDK is lower than or equal to the first version number, it is determined that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, and the compatibility verification of the DMSDP of the electronic device is passed; When the version number of the DVSDK is higher than the first version number, it is determined that the version of the DVSDK is higher than the version of the DMSDP of the electronic device, and the compatibility verification of the DMSDP of the electronic device fails.

3. The compatibility verification method for device virtualization services according to claim 1, characterized in that: When it is determined, based on the version number of the DVSDK and the first version number, that the version of the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device passes; otherwise, the compatibility verification of the DMSDP of the electronic device fails, specifically including: Determine the minimum version supported by the DVSDK according to the version number and mapping relationship of the DVSDK; When the minimum version supported by the DVSDK is lower than or equal to the version of the DMSDP of the electronic device, the compatibility verification of the DMSDP of the electronic device is passed; When the minimum version supported by the DVSDK is higher than the version of the DMSDP of the electronic device, compatibility verification of the DMSDP of the electronic device fails.

4. The compatibility verification method for device virtualization services according to claim 1, characterized in that: The method further comprises: When the DMSDP of the electronic device is updated, the first version number is incremented by 1 each time a new AIDL interface is added.

5. The compatibility verification method for device virtualization services according to claim 1, characterized in that: When the compatibility verification of the DMSDP of the electronic device fails, the method further includes: An error code indicating that the compatibility verification of the DMSDP of the electronic device fails is returned to the application.

6. The compatibility verification method for device virtualization services according to claim 1, characterized in that: When the DMSDP compatibility verification of the electronic device is passed, the method further includes: authenticating the application; After the authentication of the application is passed, the application is allowed to continue accessing the device virtualization service of the DMSDP of the electronic device.

7. The compatibility verification method for device virtualization services according to claim 6, characterized in that: The authenticating the application program specifically includes: When the authentication identifier of the application is obtained and the authentication identifier is the specified authentication identifier, the authentication of the application passes; otherwise, it is determined whether the application has been registered for the cloud service. If it has been registered for the cloud service, the authentication of the application passes; if it has not been registered for the cloud service, the authentication of the application fails.

8. The compatibility verification method for device virtualization services according to claim 7, characterized in that: When the authentication of the application fails, the method further includes: The DMSDP of the electronic device returns an error code indicating authentication failure to the DVSDK, and blocks the DVSDK from accessing the DMSDP of the electronic device.

9. The compatibility verification method for device virtualization services according to any one of claims 1 to 8, characterized in that: The method further comprises: After establishing a connection channel with the IoT device, the DMSDP of the electronic device receives version number information sent by the IoT device, where the version number information is used to indicate the DMSDP version number of the IoT device; The DMSDP of the electronic device determines, based on the version number information, a lowest version number between the first version number and the version number of the DMSDP of the IoT device; When it is determined, based on the version number of the DVSDK and the minimum version number, that the version of the DVSDK is lower than or equal to the version corresponding to the minimum version number, the compatibility verification of the DMSDP of the IoT device passes; otherwise, the compatibility verification of the DMSDP of the IoT device fails.

10. The compatibility verification method for device virtualization services according to claim 9, characterized in that: When the compatibility verification of the DMSDP of the IoT device fails, the method further includes: An error code indicating that the compatibility verification of the DMSDP of the IoT device fails is returned to the application.

11. The compatibility verification method for device virtualization services according to claim 9, characterized in that: The version number information is carried in the device capability information sent by the IoT device to the electronic device. The device capability information is also used to indicate the device virtualization services supported by the IoT device, where the device virtualization services include at least one of a virtualized camera service and a virtualized microphone service.

12. The compatibility verification method for device virtualization services according to claim 11, characterized in that: When the compatibility verification of the DMSDP of the IoT device passes, the method further includes: The DMSDP of the electronic device caches the device capability information in a cache object; When the application enables the device virtualization service of the DMSDP of the electronic device, the DMSDP of the electronic device determines whether the IoT device supports the device virtualization service that needs to be enabled based on the device capability information cached by the cache object; if it does, the device virtualization service continues to be enabled; otherwise, the enabling fails.

13. The compatibility verification method for device virtualization services according to claim 12, characterized in that: The DMSDP of the electronic device caches the device capability information in a cache object, specifically including: The DMSDP of the electronic device uses the service serial number and the device serial number in the device capability information as a key and stores the key in the cache object.

14. The method for verifying compatibility of a device virtualization service according to claim 13, wherein the DMSDP of the electronic device determines whether the IoT device supports the device virtualization service that needs to be enabled based on the device capability information cached by the cache object, specifically comprising: When the DMSDP of the electronic device finds a key that matches the service serial number and device serial number corresponding to the device virtualization service that needs to be enabled in the key stored in the cache object, it determines that the Internet of Things device supports the device virtualization service that needs to be enabled; otherwise, it determines that the Internet of Things device does not support the device virtualization service that needs to be enabled.

15. The compatibility verification method for device virtualization services according to claim 12, characterized in that: After the device virtualization service is enabled, the method further includes: The DMSDP of the electronic device uses the device virtualization service that is enabled to be terminated as a key and the capability of the device virtualization service that is enabled to be terminated as a value to form a key-value pair; The DMSDP of the electronic device stores the key-value pair in a capability buffer.

16. The compatibility verification method for device virtualization services according to claim 15, characterized in that: The method further comprises: When the application accesses the target capability of the enabled device virtualization service, the DMSDP of the electronic device uses the enabled device virtualization service as the key. When the value corresponding to the target capability is obtained in the capability buffer, it is determined that the Internet of Things device supports the target capability; otherwise, it is determined that the Internet of Things device does not support the target capability.

17. The compatibility verification method for device virtualization services according to claim 16, characterized in that: When the device virtualization service is a virtualized camera service, the capability of the virtualization service is previewing or taking a photo.

18. An electronic device, characterized in that: The electronic device comprises: a memory and a processor, the memory being coupled to the processor; The memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the compatibility verification method for device virtualization services according to any one of claims 1 to 17.

19. A collaborative work system, characterized in that: The system includes at least one electronic device as described in claim 18, and also includes at least one Internet of Things device; wherein, the Internet of Things device includes a camera, a memory and a processor, the memory is coupled to the processor, the camera is coupled to the processor, and the memory stores program instructions. When the program instructions are executed by the processor, the Internet of Things device establishes a transmission channel with the electronic device and sends version number information to the electronic device, where the version number information is used to indicate the DMSDP version number of the Internet of Things device.

20. The collaborative work system according to claim 19, characterized in that: The version number information is carried in the device capability information sent by the IoT device to the electronic device. The device capability information is also used to indicate the device virtualization services supported by the IoT device, where the device virtualization services include at least one of a virtualized camera service and a virtualized microphone service.

Images