BACKGROUND SYNCHRONIZATION WITHIN A MULTI-ENVIRONMENT OPERATING SYSTEM

FIELD OF THE INVENTION

The present invention relates generally to multi-environment operating systems and methods for synchronizing backgrounds (wallpaper) in a multi-environment operating system.

BACKGROUND OF THE INVENTION

Some mobile devices have the capability to utilize multiple run-time environments simultaneously. A user of such a device may operate a first operating environment (e.g., Android) and a second operating environment (e.g., GNU Linux) simultaneously. When operating such a device, at least two co-existing independent middleware operating environments coupled to a core kernel are provided where the middleware operating environments each have a corresponding application component.

When a single display device is utilized as a user interface to a mobile device running multiple environments (e.g., Android and GNU Linux), there may exist two wallpapers or background displays. A first wallpaper is on a first window (Android window) which runs the Android environment. The other is wallpaper exists on the GNU Linux desktop or window. To give a consistent look, it would be beneficial to give a user an option to synchronize the wallpaper when multiple runtime environments are simultaneously utilized. Therefore a need exists for a method and apparatus for synchronizing backgrounds (wallpaper) among multiple windows in a multi-environment operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary perspective view of a mobile device;

FIG. 2 is a block diagram representing an exemplary operating system;

FIG. 3 is a block diagram of an exemplary operating system;

FIG. 4 is a block diagram of a runtime co-existence schema of an exemplary operating system;

FIG. 5 is block diagram of a inter-environment communication schema of an exemplary operating system;

FIG. 6 is a flow chart identifying steps in a booting sequence for an exemplary operating system;

FIG. 7 is a flow chart identifying exemplary steps for launching an application in a first operating environment while an exemplary operating system is controlled by a second operating environment;

FIG. 8 is a message sequence chart identifying exemplary steps for launching a second operating environment application while a first operating environment has primary control;

FIG. 9 is a flow chart identifying exemplary steps associated with switching from a first operating environment to a second operating environment;

FIG. 10 is a message sequence chart identifying exemplary steps for switching from a first operating environment to a second operating environment;

FIG. 11 is a message sequence chart identifying exemplary steps for switching from a second operating environment to a first operating environment;

FIG. 12 is a flow chart identifying exemplary use of an application controlled by a first operating environment while a second operating environment has primary control of a computing device.

FIG. 13 illustrates a user interface running multiple operating environments.

FIG. 14. is a block diagram of a device capable of running multiple operating environments.

FIG. 15 is a flow chart showing operation of the device of FIG. 14.

FIG. 16 is a flow chart showing operation of the device of FIG. 14.

FIG. 17 is a flow chart showing operation of the device of FIG. 14.

FIG. 18 is a flow chart showing operation of the device of FIG. 14.

FIG. 19 is a flow chart showing operation of the device of FIG. 14.

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Those skilled in the art will further recognize that references to specific implementation embodiments such as “circuitry” may equally be accomplished via replacement with software instruction executions either on general purpose computing apparatus (e.g., CPU) or specialized processing apparatus (e.g., DSP). It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.

DETAILED DESCRIPTION OF THE DRAWINGS

In order to alleviate the above-mentioned need, a device and method for synchronizing background images within a multi-environment operating system is provided herein. During operation, a processor running a first operating system environment will utilize a first background image for a first graphical user interface on the device. The first operating system will save the first background image to a shared image file. A second operating system environment being run by the processor will access the shared image file and utilize the first background image for a second GUI on an external display. Because background images are synchronized between GUIs, a more-consistent look is provided to the user.

The present invention encompasses a device for synchronizing background images within a multi-environment operating system. The device comprises a processor running a first operating system environment utilizing a first background image for a first graphical user interface (GUI), the first operating system environment saving the first background image to a shared image file. The processor additionally runs a second operating system environment accessing the shared image file and utilizing the first background image for a second GUI on an external display.

The present invention additionally encompasses a device for synchronizing background images within a multi-environment operating system. The device comprises a processor running a first operating system environment utilizing an animated background for a first graphical user interface (GUI) on the device, the processor saving a snapshot of the animated background to a shared image file, The processor additionally runs a second operating system environment accessing the shared image file and utilizing the snapshot of the animated background for a second GUI on an external display.

The present invention additionally encompasses a method for synchronizing background images within a multi-environment operating system. The method comprises the steps of running a first operating system environment on a device utilizing a first background image for a first graphical user interface (GUI), saving the first background image to a shared image file, and accessing the shared image file by a second operating environment system running on the device. The first background image is utilized by the second operating system environment for a second GUI on an external display.

The present invention additionally encompasses a method for synchronizing background images within a multi-environment operating system. The method comprises the steps of running a first operating system environment on a device utilizing an animated background image for a first graphical user interface (GUI), saving by the first operating system environment, a snapshot of the animated background image to a shared image file, and accessing the shared image file by a second operating system running on the device. The snapshot is utilized by the second operating system for a second GUI on an external display.

Turning now to the drawings, where like numerals designate like components, FIG. 1 is a block diagram showing a mobile telephone 10. The telephone 10 includes a GUI 12 and a plurality of data input buttons 14. The mobile device 10 is selected from the group including, but not limited to, a mobile personal computer (PC), a netbook, a mobile telephone, a laptop computer, a handheld computer and a smart phone. Although the device 10 is mobile, it is intended to have significant computing power, with a processor speed in excess of 500 mHz, although slower processors are not excluded. Considering the computing power, a user can connect the device 10 to a variety of peripheral devices (not shown). The peripheral devices are selected from a group including, but not limited to, computer monitor, a laptop computer, a desktop computer, a tablet PC, and a screen projector.

Now referring to FIG. 2, a block diagram of an exemplary operating system (OS) 16 in communication with a kernel 18 is provided. The OS 16 can be a Linux distribution system, a Linux-based operating system or a non-Linux-based operating system. The device hardware 20 is also in communication with the Linux kernel 18. The operating system 16 includes a first operating system environment 22 and a second operating system environment 24 in communication with a single Linux kernel 18. By example, the second middleware operating system environment 24 is a standard Linux distribution and the first middleware operating system environment 22 is an embedded operating system environment intended for use in mobile devices, such as an Android™ (Open Handset Alliance, www.openhandsetalliance.com) operating system. A Linux distribution 16 is in communication with the Linux kernel 18, which is in communication with the device hardware 20. The device hardware 20 can be a memory storage device (not shown) coupled to a processor (not shown) which stores computer executable instructions which are configured to perform various functions and operations, as described herein.

An exemplary operating system 16 includes Ubuntu® (Canonical Ltd., www.ubuntu.com) for the Linux-based operating system environment 24. It is specifically intended that multiple middleware operating system environments co-exist independent of the other(s). Exemplary environments that can be included in operating system 16include Android™, Ubuntu® (Canonical Ltd., www.ubuntu.com), standard Linux-based environments, Symbian (Symbian Foundation Ltd., www.symbian.com), and Windows-based environments. In an alternative embodiment, it is envisioned that greater than two operating system environments are configured to independently co-exist on the same core kernel 18.

Referring to FIG. 3, a block diagram of an exemplary operating system is provided. In the present exemplary embodiment, the first OS environment 22 is an Android™ based operating environment and the second OS environment 24 is Linux-based. The first operating system environment 22 includes a portal service module 26, a portal activity module 28, an OS services module 30 and an OS applications module 32. The second operating system environment 24 includes a resource manager 34, an Android in a window (AIW) module 36, a second OS applications module 38 and a second OS services module 40.

The AIW module 36 is configured to display a first OS 22 application window on the GUI 12 while the second OS 24 is the primary operating environment.

The portal service module 26 contains a set of instructions configured to allow service for the first OS 22 and directs all communication with the resource manager 34. While the device 10 is operating the portal service module 26 is preferably running at all times. Additionally, the portal service module 26 is connected to activity associated with the portal activity module 28, as well as first OS 22 broadcast events. The portal activity module 28 is an application, or set of computer executable instructions, which represents a second OS 24 application located on the first OS 22 stack. By example, if the second OS 24 is Ubuntu® the portal activity module 28 can represent a specific Ubuntu application, and when the portal activity module 28 has focus, Ubuntu is in view through the GUI 12. Numerous applications can run simultaneously, also referred to as a stack of running applications, within any given operating environment. Logically speaking, the topmost application is deemed to have “focus”.

The kernel 18 includes a set of drivers 42 and an AEV module 44. Included with the drivers 42 are input device drivers for hardware components 20. The AEV 44 is a kernel module that takes absolute coordinate and keyboard events from AIW 36 and passes them to an event hub.

The co-existing environments within operating system 16 communicate with each other. The resource manager 34, which is part of the second OS 24, communicates directly with the portal service module 26, which is part of the first OS 22. Furthermore, the portal service module 26, which is part of the first OS 22, communicates directly with the resource manager 34. The resource manager 34 is a set of instructions configured to manage the resources shared by the first OS 22 and second OS 24. The shared resources include display devices, input devices, power management services and system state information. Furthermore, the resource manager 34 is configured to control OS 22, 24 access to the hardware 20. Additionally, the resource manager 34 identifies and controls which OS 22,24 user interface is displayed through the GUI 12.

According to the present embodiment, the portal service 26 is the source of all communications from the first OS 22 to the resource manager 34. Additionally, the portal service 26 is a sink for all callbacks from the resource manager 34 to the first OS 22. The resource manager provides a status discoverable application programming interface (API) to the portal service 26. This API is configured to be called by the resource manager 34 at any time. The resource manager 34 is configured to obtain and process runtime status, which allows for the resource manager to maintain a state machine. For the first OS 22, the portal service 26 provides runtime status to processes that require them. Similarly, the portal service 26 requests and receives status updates from processes which provide status information. A similar communication for the second OS 24 is controlled by the resource manager 34, which provides runtime status to the processes that require them. Resource manager 34 requests and receives status updates from various processes that provide status information. Device drivers 42 logically associated with the kernel 18 communicate directly with the resource manager 34 as well as the processes that provide runtime status information. By example, the API arbitrates access to user interface devices, such as displays, touch screens or the GUI 12. Yet another example, the API arbitrates access to power input devices, such as batteries and/or AC/DC wall plugs.

The first OS 22 and the second OS 24 are independent from the other, and co-exist with respect to the other. Each OS 22, 24 is a fully functioning operating system environment, and does not need the other operating system environment to function. The two operating system environments exist on the same device 10 with 100% independence with respect to the other. As identified above, the first and second OS 22, 24 do not co-exist in a virtualization or emulation scheme, but in fact operate on a single kernel 18. Instead, there is runtime co-existence in which both OS 22, 24 run in their respective native environments and neither OS 22, 24 is recompiled, as there is no need to leverage a common C runtime environment. Applications can be accessed by a user which are coded purely for one or the other OS 22, 24 without an interruption to a user's computing experience.

Referring to FIG. 4, a block diagram provides an exemplary co-existence scheme for an Android® OS 22 and an Ubuntu™ OS 24. Each OS 22, 24 operates on a separate runtime environment, which provides software services for programs and/or processes while the device 10 is operating. Android processes 46 and Android libraries 48 access a Bionic C Library 50, which is optimized and modified specifically for the Android environment. Ubuntu processes 52 and Ubuntu libraries 54 access a Glibc C Library 56, which is a GNU C library used in many standard desktop Linux-based systems. Each OS environment runs on its respective C libraries without conflicting another operating environment.

Referring to FIG. 5, a more detailed communication path between the first OS 22 and the second OS 24 described in FIG. 4 is provided. An inter-process communication (IPC) system is configured to manage the inter-environment communication flow between the first OS 22 and the second OS 24. The portal service 26 communicates with a DBUS Binding 58, which is a software package containing programming language and executable instructions configured to communicate with a DBUS library 60. The resource manager 34 communicates with a Glib DBUS binding 62, which also is a software package containing programming language and executable instructions configured to communicate with a DBUS library 64 configured for the second OS 24. Both the first OS 22 DBUS library 60 and the second OS 24 library 64 communicate through a DBUS Daemon 66, which is logically part of the second OS 24, and acts as the communication link between the two operating environments.

Referring to FIG. 6, a flow chart representing a boot sequence is provided. The boot sequence includes both common and operating system environment-specific steps. The actual boot sequence is dependent upon rules associated with a predetermined device state that dictates the booting sequence. By example, if the device is connected to a peripheral device, such as a monitor, the device state is considered to be in docked mode, and the second OS 24 is the default primary environment. Alternatively, if the device 10 is not connected to a peripheral device, then it is in mobile mode, and the first OS 22 is the default primary operating environment. However, the secondary operating environment is launched simultaneously with the primary environment, and operates in the background in case the device 10 state changes and the secondary environment is switched to become the primary environment. By example, when the device 10 is in docked mode and the peripheral device is unplugged, there is an automatic switch to mobile mode, which results in the secondary environment becoming the primary environment, and vice versa.

The boot sequence is initiated at step 68, followed by launching the core Linux kernel 18 at step 70. A bootloader program initializes prior to launching the kernel. After the Linux kernel 18 is initialized, the kernel launches user space scripts at step 72. The resource manager 34 is launched at step 74, followed by identifying the mode state at step 76. Once the mode state is identified a reference library is accessed at step 78 to determine the criteria associated with and/or dictated by the mode state that is identified. At step 80, the services common to both the first OS 22 and the second OS 24 are launched. The mode state determined at step 76 is referenced at step 82. If the mobile state is identified then the first OS 22 is the primary operating environment, then the first OS initialization scripts are launched at step 84, followed by the second OS initialization scripts launched at step 86. If the docked state is referenced at step 82, then the second OS 24 is the primary operating environment, and then the second OS 24 initialization scripts are launched at step 88 followed by launching the first OS 22 initialization scripts at step 90. Regardless of which environment is the primary, both environments are launched and running before the device 10 is operational at step 92. Since the common services are launched first at step 80, for all intents and purposes the primary and secondary environments are launched in parallel. However, the primary environment-specific services, based upon the device state, are launched immediately before the secondary environment-specific services. By separating the common services launch with the environment-specific launch, the device 10 can be quickly operational with multiple co-existing and independent operating environments.

Referring to FIG. 7, a flow chart identifying steps for launching a second OS 24 application while the device 10 is in mobile mode 94 and the first OS 22 has primary control. A second OS 24 application, Mobile PC, is selected at step 96. Mobile PC is an application in the first OS 22 which provides a full PC view, alternatively referred to as a netbook view, while the device 10 is operating in mobile mode and the first OS 22 is in primary control. In an alternative embodiment, individual applications from the second OS 24 can be listed in a first OS 22 menu and individually launched, which can be similar to a netbook view.

The portal service 26 sends a status update communication to the resource manager 34 at step 98 indicating that the portal activity 28 has gained focus. Thereafter, the resource manager 34 disables the first OS 22 input and switches a virtual terminal at step 100. The mobile PC application is displayed on the GUI 12 at step 102. While operating the mobile PC application an unsolicited event can occur at step 104 or a user-solicited event can occur at step 106. Unsolicited events include time critical and non-time critical events. By example, a time critical unsolicited event includes a phone call or a scheduled or unscheduled alarm. Furthermore, by example, a non-time critical unsolicited event includes a SMS message, an email message or a device update notification. After an event 104,106 occurs the portal service 26 sends a communication to the resource manager 34 indicating that the portal activity 28 has lost focus at step 108. At step 110, the resource manager 34 requests the first OS 22 to enable input event flow and switches the virtual terminal. By example, the present embodiment includes separate virtual terminals for switching display control between the first OS 22 and the second OS 24. Broadly speaking, a virtual terminal is a Linux application that allows a system user to switch display controls between Windows based view and a system console.

When an unsolicited event occurs or a user selects the “Home” key at step 112, the portal activity 28 is switched to the background at step 114 while the unsolicited event continues or the user operates another application from the “Home” menu of the GUI 12. Alternatively, if the user selects the “Back” key at step 112, then the portal activity 28 exits the application and the device 10 reverts to the idle main menu at step 94. User-initiated events, such as selecting the Home key, Back key, or initiating a new application are exemplary solicited events. When an event occurs a decision is made at step 118, and the first OS 22 is interrupted at step 120 if the event is an unsolicited event. Alternatively, if the event is a solicited event, such as the user selecting the “Home” key, then the device reverts to the idle main menu at step 94. After the OS interruption at step 120, the interrupting application exits and the portal activity 28 regains focus at step 122 and the device 10 reverts to step 98.

In an alternative embodiment, the virtual terminal facility is not utilized. Rendering a second OS 24 application while in the mobile mode can be accomplished through a VNC-like application. The second OS 24 application, such as Ubuntu, can be rendered remotely into the VNC client. Additionally, this embodiment doesn't take physical display control away from the first OS 22.

In yet another alternative embodiment, non time-critical notifications generated by the first OS 22 are identified and listed in a panel within the second OS 24 view. By listing the notifications in a panel the first OS 22 status information is integrated with the second OS 24 view when the second OS 24 is the primary OS. At the user's leisure, the panel is accessed to reveal non time-critical status notifications. When the panel is engaged the first OS 22 becomes the primary OS and allows the notifications to be viewed. By example, the panel can be a pull-down list that comes down from a status area with a slide gesture.

Referring to FIG. 8, a message sequence chart identifying the steps for launching a second OS 24 application while the first OS 22 has primary control is provided. The sequence chart provides a step wise flow, from top to bottom, of the signals transmitted between the portal activity module 28 and the resource manager 34. The portal activity 28 receives a signal 124 to launch the portal and disable the input. The first OS 22 has primary control before signal 126 changes the mode state to the second OS 24 obtaining primary control. Signal 126 is sent from the portal activity 28 to the resource manager 34, which then generates a responsive signal 128 sent to the portal activity 28 indicating that the second OS 24 is the primary OS. Signal 130 is received by the portal activity 28 and enables the input. Signal 132 is sent from the portal activity 28 to the resource manager 34 changing the mode state of from the second OS 24 to the first OS 22. After receiving signal 132 the resource manager 34 switches the virtual terminal. The resource manager 34 then sends a status update signal 134 to the portal activity 28 indicating that the first OS 22 is primary.

Referring to FIG. 9, a flow chart identifying steps associated with switching from a first operating environment to a second operating environment is provided. The device 10 is idle in the mobile mode (OS122) at step 136. At step 138 the device 10 is connected to a docking station, or connected to a peripheral device. By example, an HDMI connection can be established between the device 10 and a monitor or a television. The resource manager 34 is notified of the updated connection status at step 140 and the first OS 22 is disabled at step 142 in response to the connection status change. The first OS 22 portal switches the shared memory frame buffer at step 144, followed by the resource manager 34 switching the virtual terminal at step 146. If the Mobile PC application is in view at step 148, then the portal activity 26 exits at step 150. Alternatively, if the Mobile PC application is not in view, then the docked mode is enabled at step 152. In the event that the device state changes at step 154, then the resource manager 34 receives a status state update at step 156. By example, the state of the system changes when a user removes an HDMI cable, or similar connector, which is used for connecting the device 10 to a peripheral device. Following an event state update 156, the first OS 22 is enabled 158 and the device operates in mobile mode. A frame buffer switch is requested at step 160 and a virtual terminal switch is requested at step 162, both of which are performed by the portal activity 26. Following step 162, the device reverts to an idle state in the mobile mode 136.

Referring to FIG. 10, a message sequence chart identifying the steps performed when the device 10 transitions from mobile mode (OS1) to docked mode (OS2) is provided. The device 10 is operating in mobile mode and the first OS 22 is the primary OS. A cable signal 164 is received by the resource manager 34, which indicates that an HDMI or alternate hardwire plug has been attached to the device 10. The cable signal 164 is an exemplary mode state initialization change signal. In an alternative embodiment, the plug can be wireless communication between the device 10 and a peripheral device, and disabling the wireless communication would cause a mode state initialization change signal to be generated. A sequence of signals transitioning the device from mobile mode to docked mode is initiated. Signal 164 is sent from the resource manager 34 to the portal activity 28 indicating a mode status transition and disabling the main data input. The portal activity 28 sends signal 168 to the resource manager 34 identifying the second OS 24 is now primary and switching the virtual terminal. Signal 170 is sent from the resource manager 34 to the portal activity identifying the second OS 24 as the primary and has taken ownership of the framebuffer. A mode state change confirmation signal 172 is sent from the portal activity 28 to the resource manager 34 identifying that the device is now in docked mode and that the second OS 24 is the primary OS. A system mode update signal is sent from the resource manager 34 to AIW 36.

Referring to FIG. 11, a message sequence chart identifying the steps performed when the device 10 transitions from docked mode (OS2) to mobile mode (OS1) is provided. A cable signal 176 is received by the resource manager 34, which indicates that an HDMI or alternate hardwire plug has been removed from the device 10. Removal of the plug indicates that a peripheral device (not shown) is no longer in communication with the device 10. In an alternative embodiment, the plug can be wireless communication between the device 10 and a peripheral or alternate device (not shown). A sequence of signals transitioning the device from docked mode to mobile mode is initiated. Signal 178 is sent from the resource manager 34 to the portal activity 28 indicating a mode status transition and enabling the main data input and the main frame buffer. The portal activity 28 sends signal 180 to the resource manager 34 identifying the first OS 22 is now primary and switching the virtual terminal. Signal 182 is sent from the resource manager 34 to the portal activity identifying the first OS 22 as the primary and has taken ownership of the frame buffer. A mode state change confirmation signal 184 is sent from the portal activity 28 to the resource manager 34 identifying that the device is now in mobile mode and that the first OS 22 is the primary OS. A system mode update signal is sent from the resource manager 34 to AIW 36.

Referring to FIG. 12, the device 10 is idle in docked mode and the second OS 24 is the primary operating environment at step 188. If an unsolicited event occurs at step 190 or the user selects the OS122 in a window application at step 192, then the OS122 in a window application is launched at step 194. By example, if Android is the mobile operating environment 22, then the Android in a Window (AIW) application is launched. The AIW application enables a user to access Android applications while the device is operating in the docked mode. The resource manager 34 is also notified of the status update at step 194. Input to the first OS 22 is enabled at step 196, followed by the transmission of first OS display update notifications at step 198. The AIW application is operating and has focus at step 200. If the AIW application is exited at step 202 or a user removes AIW from focus at step 204, then the first OS 22 input is disabled at step 206. The first OS 22 display is stopped at step 208. If the AIW application is exited at step 210, then the system reverts to the idle docked mode 188. Alternatively, if the AIW application is defocused then the application operates in this state at step 212. In the event of an unsolicited event at step 214 or a solicited interaction with the AIW application at step 216, the AIW regains focus at step 218. While the AIW is defocused a user can select the AIW application and continue interaction with the AIW window, which refocuses the AIW and notifies the resource manager 34 of the status update. After the AIW regains focus the first OS 22, which is Android for the present embodiment, input is enabled at step 220. The first OS 22 display update notifications are transmitted to the resource manager 34 at step 222, followed by the system reverting to step 200, where AIW is enabled and in focus. When an application is in focus, that application is at the logical top of a stack of running applications.

In an alternative embodiment, it is contemplated that the device 10 can transition between mode states based upon events other than docking or undocking the device 10. By example, if the device 10 is stationary for a preset period of time the device 10 can be programmed to operate in the most energy efficient mode state, regardless of the device status otherwise. In yet another example, a user can transition the mode state from docked to mobile even if the device has a connection with a peripheral device. Additionally, the type of peripheral device connected to the device 10 can dictate whether an automatic mode state change sequence is initiated or a user is provided a mode state change request. The user thereby being able to select the mode state in which to operate the device 10. In yet another alternative embodiment, additional mode states are contemplated based upon the particular device 10 usage and the applications available in the device memory 20.

FIG. 13 illustrates one embodiment of device 10 operating in a docked mode, docked to a peripheral device (external display 1301). Screen 12 serves as a first GUI for a first operating system environment. External display 1301 serves as a second GUI for a second operating system environment, and may comprise such things as an external monitor, TV, Lap dock, smart dock, etc.

In this particular embodiment, external display 1301 comprises an external monitor attached to device 10 via a High Definition Multimedia Interface (HDMI). As shown, external display 1301 comprises window 1302 and desktop/window 1303 serving as the second GUI. In this particular embodiment, window 1302 serves as a GUI representing a first operating system environment (e.g., OS 22), while desktop/window 1303 represents a second operating system environment (e.g., OS 24). It should be noted that window 1302 may replicate GUI 12. As discussed above, the first OS 22 and the second OS 24 are independent from the other, and co-exist with respect to the other. Each OS 22, 24 is a fully functioning operating system environment, and does not need the other operating system environment to function. The two operating system environments exist on the same device 10 with 100% independence with respect to the other.

It should be noted that although not shown, each window 1302 and 1303 will contain icons and graphics that represent standard applications that me be run within each operating system environment.

FIG. 14. is a block diagram of device 10 and monitor 1301 of FIG. 13. Device 10 preferably comprises processor 1402 that runs OS 16. OS 16 is preferably a Linux distribution system, a Linux-based operating system or a non-Linux-based operating system. The device hardware 20 is also in communication with the Linux kernel 18. The operating system 16 run by processor 1402 includes first operating system environment 22 and second operating system environment 24 in communication with a single Linux kernel 18.

The device hardware 20 comprises a memory storage such as random-access memory coupled to processor 1402 which stores computer executable instructions which are configured to perform various functions and operations, as described herein. As shown, monitor 1301 is coupled to operating system 16 such that first OS 22 and second OS 24 each output a GUI in a first and a second window on monitor 1301. One of the windows may comprise the whole desktop window, while another window may sit above the desktop window.

As mentioned above, when a single display device 1301 is utilized as a user interface to device 10 running multiple environments (e.g., Android and GNU Linux), there may exist two wallpapers or background displays. A first wallpaper is on first window (Android window) 1302 which runs the Android environment. The other is wallpaper exists on the GNU Linux window 1303. To give a consistent look, it would be beneficial to give a user an option to synchronize the wallpaper when multiple runtime environments are simultaneously utilized. In order to address this issue, OS 22 will create an image file 1401 of its background (wallpaper) and store this image file for access by OS 24. This image file 1401 will be stored in storage 20 and continuously updated by OS 22. With reference to FIG. 13, processor 1402 runs a first operating system environment utilizing a first background image for a first graphical user interface (GUI 12). The first operating system environment saves the first background image to a shared image file 1401. Processor 1402 also runs a second operating system environment accessing the shared image file 1401 and utilizes the first background image for a second GUI 1303 on external display 1301.

FIG. 15 is a flow chart showing operation of the device of FIG. 14 for a first embodiment. In particular, FIG. 15 shows those steps taken by a first OS (OS 22) during docking to monitor 1301 (i.e. after 172 of FIG. 10). Prior to entering the logic flow of FIG. 15, processor 1402 is running a first operating system environment on device 10 utilizing a first background image for a first graphical user interface (GUI). Thus, the wallpaper of OS 22 was already set by the user of device 10. The logic flow that follows is preferably stored as part of portal services 26.

The logic flow begins at step 1501 where device 10 where device 10 has been docked. At step 1503 OS 22 determines if live wallpaper is being utilized as a background image. Because live wallpaper is continuously changing and OS 22 does not have logic to take a current snapshot of the wallpaper, no current image will be saved, and the logic flow continues to step 1507. If, however, live wallpaper is not being utilized, the logic flow continues to step 1505 where OS 22 saves current wallpaper (background image) to a shared image file. This shared image file exists on storage 20. At step 1507 the appropriate image (e.g., live wallpaper or image that exists within the shared image file) is used as wallpaper for window 1302 on monitor 1301.

FIG. 16 a flow chart showing operation of the device of FIG. 14 for the first embodiment. In particular, FIG. 16 shows those steps taken by a second OS (OS 24) during docking. These instructions are preferably stored as one of Linux Applications 38 which is responsible for drawing a desktop background for OS 24. The logic flow begins at step 1601 where device 10 is docked to monitor 1301. At step 1602 OS 24 launches a desktop application to utilize monitor 1301 as a GUI. The logic flow then continues to step 1603 where OS 24 determines if wallpaper has been saved by OS 22 in storage 20. If no wallpaper image has been saved by OS 22 in storage 20, the logic flow continues to step 1609 where a default image is used as wallpaper for window 1303 on monitor 1301.

If, however, at step 1603 it is determined by OS 24 that a shared wallpaper image file exists, OS 24 accesses the shared image file and sets the current wallpaper to the shared image file. The logic flow continues to step 1607. At step 1607 the appropriate image is used as wallpaper for window 1303 on monitor 1301.

FIG. 17 is a flow chart showing operation of the device of FIG. 14 for a second embodiment. In particular, FIG. 17 shows those steps taken by a first OS (OS 22) when docked and when a notification (e.g., an android broadcast intent) when the android wallpaper has been changed to indicate wallpaper has been updated. These instructions are preferably stored as part of portal services 26. Thus, in this particular embodiment the first operating system environment detects that the first background image has changed/updated for the first GUI, updates the shared image file, and sends a notification to the second operating system environment that the background image has changed. The second operating system environment receives the notification and updates the second GUI with the changed background image.

The logic flow begins at step 1701 where device 10, and in particular, OS 22 determines if wallpaper being utilized by OS 22 has been updated. If not, the logic flow simply returns to step 1701. If, however, device 10/OS 22 has determined that wallpaper has been updated then the logic flow continues to step 1703 where OS 22 determines if live wallpaper is being utilized as a background image. Because live wallpaper is continuously changing, no current image will be saved, and the logic flow continues to step 1706 where the current image file (if any) is removed. If, however, live wallpaper is not being utilized, the logic flow continues to step 1705 where OS 22 saves/updates the shared image file with the current wallpaper. This shared image file exists on storage 20. At step 1707, a notification is sent to OS 24 indicating that the wallpaper has been updated. In one embodiment of the present invention an iNotify event is sent to OS 24. In particular, an iNotify event comprises a Linxu kernel subsystem (18 in FIG. 2) that notices changes to the file system, and reports those changes to applications. If a Linux application adds a watch on certain file path, iNotify will start watching on the inode that the file path is pointing to. Whenever there is any change in inode's state, an event will be notified to the application that has added the watch. In this particular embodiment iNotify is being used to notify OS 24 for a wallpaper change by OS 22. In an alternate embodiment a notification mechanism dbus (which is shown in FIG. 5) may be utilized for notification.

FIG. 18 a flow chart showing operation of the device of FIG. 14 for the second embodiment. In particular, FIG. 16 shows those steps taken by a second OS (OS 22) when a notification event is received indicating that wallpaper has been updated by OS 22. These instructions are preferably stored as part of Linux Applications 38. The logic flow begins at step 1801 where device 10, and in particular, OS 24 determines if a notification has been received. If not, the logic flow simply returns to step 1801. If, however, device 10/OS 24 has determined that a notification has been received then the logic flow continues to step 1803 where OS 24 determines if wallpaper has been saved by OS 22 in storage 20. If no wallpaper image has been saved by OS 22 in storage 20, the logic flow continues to step 1809 where a default image is used as wallpaper for window 1303 on monitor 1301.

If, however, at step 1803 it is determined by OS 24 that a shared wallpaper image file exists, OS 24 sets the current wallpaper to the shared image file and the logic flow continues to step 1807. At step 1807 the appropriate image is used as wallpaper for window 1303 on monitor 1301.

FIG. 19 is a flow chart showing operation of the device of FIG. 14 for a third embodiment. In particular, FIG. 19 shows those steps taken by a first OS (OS 22) during docking when a snapshot is taken of live wallpaper to be used by a second OS (OS 24). These instructions are preferably stored as part of portal services 26. During this embodiment processor 1402 is running a first operating system environment utilizing an animated background for a first graphical user interface (GUI) on the device, the processor saves a snapshot of the animated background to a shared image file. Processor 1402 also runs a second operating system environment accessing the shared image file and utilizes the snapshot of the animated background for a second GUI on an external display.

The logic flow begins at step 1901 where device 10, and in particular, OS 22 determines if device 10 has been docked. If not, the logic flow simply returns to step 1901. If, however, device 10/OS 22 has determined that it has been docked then the logic flow continues to step 1903 where OS 22 determines if live wallpaper is being utilized as a background image. If, at step 1903 it is determined that live wallpaper is being utilized, then the logic flow continues to step 1907 where a snapshot of the live wallpaper is taken by OS 22 and saved to storage 20 (step 1909).

If, however, live wallpaper is not being utilized, the logic flow continues to step 1905 where OS 22 saves current wallpaper to a shared image file. This shared image file exists on storage 20. At step 1911 the appropriate image is used as wallpaper for window 1302 on monitor 1301.

While the invention has been particularly shown and described with reference to a particular embodiment, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. For example, although several embodiments were given, it is understood that these embodiments may be combined to form further embodiments. It is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein, but include modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims.

BACKGROUND SYNCHRONIZATION WITHIN A MULTI-ENVIRONMENT OPERATING SYSTEM

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims