Guest OS Sensor Data Access via Host Mediator
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In dual operating system (DuOS) computing devices, Android OS as a guest operating system cannot access hardware sensors when the Windows OS boots, leading to malfunctioning or undefined states due to the Windows OS enumerating and taking over hardware, making it transparent to the Android OS.
Innovation Solution
A method is provided to detect changed sensor data indicative of rotation events by sensors, retrieve this data, and send it to a Windows application via drivers within the kernel of the host OS, which then forwards it to the Android OS's application framework for calculating the device's rotation, allowing Android applications to access sensor data through the Windows OS.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Windows OS boots and enumerates hardware, then Windows OS gains full hardware control, but Android OS as guest cannot access sensor hardware
Solution Approach 1:
The patent implements a Windows application as an intermediary layer between the Android guest OS and sensor hardware. The Windows application receives sensor data requests from Android applications, retrieves actual sensor data through Windows hardware interfaces, and forwards the data to Android applications. This mediator approach allows Android to access sensors without compromising Windows hardware control.
Solution Approach 2:
The system segments sensor access functionality into separate components: Windows OS maintains hardware control, a Windows application handles data retrieval and translation, and Android applications consume the translated data. This segmentation allows each layer to operate independently with clearly defined responsibilities, resolving the conflict between Windows control and Android access.
2Adaptability or versatility
If Android OS runs as guest in Windows OS, then dual operating system functionality is achieved, but sensor data access fails for Android applications
Solution Approach 1:
The Windows application serves as a mediator that translates Android sensor access requests into Windows-compatible hardware interface calls. It receives data requests from the Android application framework, retrieves sensor data through Windows drivers and hardware abstraction layers, and returns the data to Android applications, ensuring reliable sensor access in the DuOS environment.
Solution Approach 2:
The system creates a virtual sensor interface for Android that copies the functionality of physical sensors. Instead of giving Android direct hardware access, the Windows application creates a software-based sensor interface that replicates sensor behavior by retrieving data from actual sensors through Windows interfaces, allowing Android to operate as if it had direct sensor access.
3Stability of the object's composition
If Windows OS takes over hardware upon boot, then system stability is improved, but Android sensor access becomes undefined or malfunctioning
Solution Approach 1:
The Windows application acts as a stable intermediary that operates within the Windows OS environment while serving Android applications. It maintains system stability by working through Windows hardware interfaces and drivers, while simultaneously providing reliable sensor data access to Android applications through standardized data transmission protocols.
Solution Approach 2:
The system implements a feedback mechanism where the Windows application continuously monitors sensor data availability and transmission status. It retrieves sensor data at appropriate intervals, validates the data format, and ensures proper delivery to Android applications, creating a stable and reliable data flow that maintains both system stability and sensor functionality.
Data Source
AI summary
A guest operating system is provided with access to sensor data indicative of a rotation event from sensors associated with a computing device including a processor executing a host operating system. The guest operating system is launched as a virtual operating system and is executed as a guest of the host operating system. Responsive to changed sensor data indicative of the rotation event detected by at least one sensor associated with the computing device, the changed sensor data is sent to a first application associated with the host operating system via at least one driver executing within a kernel of the host operating system. The changed sensor data is sent from the first application to an application framework associated with the guest operating system. The application framework calculates rotation of the computing device based on the changed sensor data. The calculated rotation is sent to a second application associated with the guest operating system.