Cross-environment communication using application space api

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This Application is a continuation-in-part and claims the benefit of the filing date of U.S. patent application Ser. No. 13/217,099, filed Aug. 24, 2011, entitled “Cross-Environment Communication Framework,” which claims the benefit of U.S. Provisional Application Nos. 61/389,117, filed Oct. 1, 2010, entitled “Multi-Operating System Portable Docking Device”; 61/507,199, filed Jul. 13, 2011, entitled “Dockable Mobile Software Architecture”; 61/507,201, filed Jul. 13, 2011, entitled “Cross-Environment Communication Framework”; 61/507,203, filed Jul. 13, 2011, entitled “Multi-Operating System”; 61/507,206, filed Jul. 13, 2011, entitled “Auto-Configuration of a Docked System in a Multi-OS Environment”; and 61/507,209, filed Jul. 13, 2011, entitled “Auto-Waking of a Suspended Secondary OS in a Dockable System,” wherein the entire contents of all of the foregoing priority applications are herein incorporated by reference for all purposes.

BACKGROUND

00021. Field

0003This Application relates generally to the field of mobile computing environments, and more particularly to supporting multiple user environments through the use of multiple operating systems in a single mobile computing device.

00042. Relevant Background

0005Mobile computing devices are becoming ubiquitous in today's society. For example, as of the end of 2008, 90 percent of Americans had a mobile wireless device. At the same time, the capabilities of mobile devices are advancing rapidly, including smartphones that integrate advanced computing capabilities with mobile telephony capabilities. Mobile providers have launched hundreds of new smartphones in the last three years based upon several different platforms (e.g., Apple iPhone, Android, BlackBerry, Palm, and Windows Mobile). In the U.S., smartphone penetration reached almost 23% by the middle of 2010, and over 35% in some age-groups. In Europe, the smartphone market grew by 41% from 2009 to 2010, with over 60 million smartphone subscribers as of July 2010 in the five largest European countries alone.

0006While smartphones are gaining in popularity and computing capability, they provide a limited user experience. Specifically, they typically have an operating system that is modified for mobile device hardware and a restricted set of applications that are available for the modified operating system. For example, many smartphones run Google's Android operating system. Android runs only applications that are specifically developed to run within a Java-based virtual machine runtime environment. In addition, while Android is based on a modified Linux kernel, it uses different standard C libraries, system managers, and services than Linux. Accordingly, applications written for Linux do not run on Android without modification or porting. Similarly, Apple's iPhone uses the iOS mobile operating system. Again, while iOS is derived from Mac OS X, applications developed for OS X do not run on iOS. Therefore, while many applications are available for mobile operating systems such as Android and iOS, many other common applications for desktop operating systems such as Linux and Mac OS X are not available on the mobile platforms.

0007Accordingly, smartphones are typically suited for a limited set of user experiences and provide applications designed primarily for the mobile environment. In particular, smartphones do not provide a suitable desktop user experience, nor do they run most common desktop applications. As a result, many users carry and use multiple computing devices including a smartphone, laptop, and/or tablet computer. In this instance, each device has its own CPU, memory, file storage, and operating system.

0008Connectivity and file sharing between smartphones and other computing devices involves linking one device (e.g., smartphone, running a mobile OS) to a second, wholly disparate device (e.g., notebook, desktop, or tablet running a desktop OS), through a wireless or wired connection. Information is shared across devices by synchronizing data between applications running separately on each device. This process, typically called “synching,” is cumbersome and generally requires active management by the user.

SUMMARY

0009Embodiments of the present invention are directed to providing the mobile computing experience of a smartphone and the appropriate user experience of a secondary terminal environment in a single mobile computing device. A secondary terminal environment may be some combination of visual rendering devices (e.g., monitor or display), input devices (e.g., mouse, touch pad, touch-screen, keyboard, etc.), and other computing peripherals (e.g., HDD, optical disc drive, memory stick, camera, printer, etc.) connected to the computing device by a wired (e.g., USB, Firewire, Thunderbolt, etc.) or wireless (e.g., Bluetooth, WiFi, etc.) connection. In embodiments, a mobile operating system associated with the user experience of the mobile environment and a desktop operating system associated with the user experience of the secondary terminal environment are run concurrently and independently on a shared kernel.

0010According to one aspect consistent with various embodiments, a method comprises receiving, in a first operating system, a first remote method call of a first inter-process communication type directed to a first application running within the first operating system through a first inter-process communication channel from a second application, the second application running within a second operating system, the first and second operating systems running concurrently on a shared kernel, the first remote method call including a first data parcel, translating, in the first operating system, the first remote method call into a second remote method call of a second inter-process communication type, the second remote method call including a second data parcel, and sending, by the first operating system, the second remote method call through a second inter-process communication channel to the first application.

0011According to other aspects consistent with various embodiments, the translating in the first operating system may include unparceling the first data parcel and reparceling data into the second data parcel included in the second remote method call. The first remote method call may be a synchronous remote method call while the second remote method call may be an asynchronous remote method call. The first remote method call may be performed using a unix socket and the second remote method call may be performed using the Binder IPC mechanism. The first application may be registered in the first operating system to receive calls to the second remote method. Translating the remote method calls may be performed in a service of the first operating system.

0012According to other aspects consistent with various embodiments, a method comprises instantiating, by a first application running within a first operating system, a method of an application programming interface of the first operating system, the method implementing a sink for a predetermined remote communication request, requesting, by the method of the application programming interface, an extended inter-process communication interface, instantiating, by the first operating system, the extended inter-process communication interface, registering, by the first operating system, the extended inter-process communication interface to receive the predetermined remote communication requests directed to the first application, receiving, by the first operating system, a request to instantiate a proxy for the predetermined remote communication request within a second application running within a second operating system, the first and second operating systems running concurrently on a shared kernel, and passing, by the first operating system, a reference to the extended inter-process communication interface to the second application.

0013According to other aspects consistent with various embodiments, the predetermined remote communication request may be specific to a category of applications that includes the first and second applications. The sink may obtain a connected endpoint of an inter-process communication interface instantiated by a remote communication service of the first operating system.

0014According to other aspects consistent with various embodiments, the method may include receiving, by the first operating system, a request to instantiate a second proxy for the predetermined remote communication request within a third application, and passing, by the first operating system, the reference to the extended inter-process communication interface to the third application. Registering of the extended inter-process communication interface by the first operating system may include associating the inter-process communication with a name key of the application.

0015According to other aspects consistent with various embodiments, a mobile computing device includes a first application running within a first operating system, the first application instantiating a sink for a predetermined remote communication request, a second application running within a second operating system, the second operating system running concurrently with the first operating system on a shared kernel, the second application instantiating a proxy for the predetermined remote communication request, and a remote communication service of the first operating system, the remote communication service establishing a connection between the proxy and the sink through an extended inter-process communication interface.

0016According to other aspects consistent with various embodiments, the sink may include a method of an application programming interface of the first operating system. The application programming interface may be provided within an application space of the first operating system. The application programming interface may include classes of sinks, the classes of sinks associated with categories of applications. The application programming interface may include a java archive file. The method of the application programming interface may request the extended inter-process communication interface from the remote communication service. The remote communication service may register the sink to receive inter-process communication through the extended inter-process communication interface. Upon registration by the remote communication service, the extended inter-process communication interface may be pushed by the remote communication service. The first operating system may be an Android mobile operating system while the second operating system may be a Linux operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

0017Embodiments of the present invention are illustrated in referenced figures of the drawings, in which like numbers refer to like elements throughout the description of the figures.

0018<figref idref="DRAWINGS">FIG. 1</figref> illustrates a computing environment that provides multiple user computing experiences, according to various embodiments.

0019<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary system architecture for a mobile computing device, according to various embodiments.

0020<figref idref="DRAWINGS">FIG. 3</figref> illustrates an operating system architecture for a computing environment, according to various embodiments.

0021<figref idref="DRAWINGS">FIG. 4</figref> illustrates one embodiment of a mobile operating system for a mobile computing device, according to various embodiments.

0022<figref idref="DRAWINGS">FIG. 5</figref> illustrates aspects of an operating system architecture for a computing environment, according to various embodiments.

0023<figref idref="DRAWINGS">FIG. 6</figref> illustrates a desktop operating system that may be employed in a multiple operating system computing architecture, according to various embodiments.

0024<figref idref="DRAWINGS">FIG. 7</figref> illustrates aspects of a cross-environment communications framework, according to various embodiments.

0025<figref idref="DRAWINGS">FIG. 8</figref> illustrates a communication flow employing aspects of the cross-environment communications framework, according to various embodiments.

0026<figref idref="DRAWINGS">FIG. 9</figref> illustrates an alternative communication flow employing aspects of the cross-environment communications framework, according to various embodiments.

0027<figref idref="DRAWINGS">FIG. 10</figref> illustrates an alternative communication flow employing aspects of the cross-environment communications framework, according to various embodiments.

0028<figref idref="DRAWINGS">FIG. 11</figref> illustrates an alternative communication flow employing aspects of the cross-environment communications framework, according to various embodiments.

0029<figref idref="DRAWINGS">FIG. 12</figref> illustrates a computing environment that provides support for cross-environment inter-process communication using IPC translation, according to various embodiments.

0030<figref idref="DRAWINGS">FIG. 13</figref> illustrates a process flow for cross-environment communication using IPC translation, according to various embodiments.

0031<figref idref="DRAWINGS">FIG. 14</figref> illustrates a computing environment that uses an application programming interface layer to extend IPC interfaces to provide category specific remote communication calls, according to various embodiments.

0032<figref idref="DRAWINGS">FIG. 15</figref> illustrates a computing environment that implements application communication APIs to provide app-to-app communication, according to various embodiments.

0033<figref idref="DRAWINGS">FIG. 16</figref> illustrates a process flow for app-to-app communication through an application communication API, according to various embodiments.

0034<figref idref="DRAWINGS">FIG. 17</figref> illustrates a process flow that includes further aspects of app-to-app communication through an application communication API, according to various embodiments.

0035<figref idref="DRAWINGS">FIG. 18</figref> illustrates a process flow for communication through an application communication API, according to various embodiments.

DETAILED DESCRIPTION

0036Traditionally, handheld mobile telephony devices (i.e., “handsets”) were developed independently and served a separate and distinct purpose from that of personal computers (“PCs”) such as desktops and laptops. Handheld mobile telephony devices were focused primarily on communication while PCs were focused on computing tasks such as creating and editing documents, text-based communication (e.g., email, etc.), multimedia, and web browsing. However, mobile telephony devices are including ever-increasing computing ability and users increasingly desire convergence of communication and computing capabilities into multi-use mobile devices.

0037For example, mobile telephony devices called “smartphones” that include computing capabilities are increasing in popularity. Many of these smartphones include a mobile operating system (“OS”) running on a mobile processor. While mobile processors and mobile OSs have increased the capabilities of these devices, smartphones have not tended to replace PC environments such as desktop or notebook computers at least because of the limited user experience provided. In particular, for some tasks such as typing or editing documents, a full-size keyboard and large display are easier to use than the user interface components typically found on a smartphone. For example, smartphones typically use a small thumb-style QWERTY keyboard, touch-screen display, click-wheel, and/or scroll-wheel as user interface components. Selecting menu options or items typically involves either using a touch-screen display, or using the click-wheel or scroll-wheel to navigate menus and select items. This interface is suited to the small display screens and limited menu options typically found in smartphones, but not suited to controlling more traditional programs with a larger number of menu options, larger screen area, and user interface built around a pointing device such as a traditional mouse.

0038Embodiments of the invention are directed to an innovative cross-environment communications framework (“CECF”) that allows for fast communications between applications and services of multiple operating systems running independently and concurrently on the same shared kernel. For example, embodiments allow fast communication between applications and services of an Android mobile OS running on a shared kernel and applications and services of a Linux desktop OS running on the same shared kernel.

0039Embodiments include an extension to the Android “Binder” inter-process communication (“IPC”) mechanism that allows for app-to-app communications within the Android OS. For example, Android OS applications within can register with the remote communication service to be able to communicate (e.g., synchronize data, settings, etc.) in a synchronous and/or asynchronous way. Other embodiments include base classes of the Binder mechanism for a Linux desktop OS that allow communication between applications of the Linux desktop OS and Android OS applications and services. For example, Android applications running on the Android OS can share data, settings, and preferences with Linux applications running on the Linux desktop OS.

0040Further embodiments support inter-process communication between OSs that use incompatible IPC mechanisms. For example, a first OS may use a first IPC mechanism for communication across process boundaries. On a second OS running concurrently with the first OS on a shared kernel, applications may use a second IPC mechanism for communication across process boundaries for processes running in the second OS.

0041Yet further embodiments are directed to simplifying app-to-app sharing of data, content, and settings through the use of an application programming interface (“API”) layer that provides application category-specific functions and methods for requesting and providing information between applications. Notably, the applications may be in active concurrent execution within a first OS, or running on independent OSs running on the same shared kernel.

0042<figref idref="DRAWINGS">FIG. 1</figref> illustrates a computing environment <b>100</b> that provides multiple user computing experiences, according to various embodiments. Computing environment <b>100</b> includes mobile computing device <b>110</b>. Mobile computing device <b>110</b> includes mobile computing hardware and software components. Hardware components of mobile computing device <b>110</b> include mobile processor <b>114</b>, display <b>116</b>, I/O device(s) <b>118</b>, and/or port <b>120</b>. Software components of mobile computing device <b>110</b> include a first OS <b>130</b> and a second OS <b>160</b>. In one embodiment, first OS <b>130</b> is a mobile OS and second OS <b>160</b> is a desktop OS. When mobile computing device <b>110</b> is operated as a stand-alone mobile device, mobile OS <b>130</b> presents a typical mobile computing user experience through display <b>116</b> and I/O device(s) <b>118</b>. The mobile computing experience provided by mobile OS <b>130</b> typically includes mobile telephony capabilities and a graphical user interface (“GUI”) suited to the mobile environment including display <b>116</b> and I/O device(s) <b>118</b>. For example, display <b>116</b> may be a touch-screen display and application programs (i.e., “Apps”) running on mobile OS <b>130</b> may be controlled through the GUI of mobile OS <b>130</b> on touch-screen display <b>116</b>.

0043Mobile computing device <b>110</b> may be connected to I/O devices <b>144</b>, <b>146</b> and/or <b>148</b> through port <b>120</b>. I/O devices <b>144</b>, <b>146</b>, and/or <b>148</b> may make up a secondary terminal environment <b>140</b>. In some instances, secondary terminal environment <b>140</b> may be more suited to desktop OS <b>160</b> than mobile OS <b>130</b>. For example, secondary terminal environment <b>140</b> may include a keyboard <b>144</b>, pointing device <b>146</b>, and a display device <b>148</b>. In these instances, desktop OS <b>160</b> can be associated with secondary terminal environment <b>140</b> to provide the full capabilities of a notebook or desktop computer environment through secondary terminal environment <b>140</b>. In other instances, secondary terminal environment <b>140</b> may be more suited for mobile OS <b>130</b> than desktop OS <b>160</b>. For example, secondary terminal environment <b>140</b> may include a touch-screen display. In these instances, mobile OS <b>130</b> may be associated with secondary terminal environment <b>140</b>.

0044In <figref idref="DRAWINGS">FIG. 1</figref>, port <b>120</b> is shown as connected to port <b>142</b> of secondary terminal environment <b>140</b> through interface <b>120</b>. However, port <b>120</b> may include separate connections to each I/O device <b>144</b>, <b>146</b> and <b>148</b> through interface <b>122</b>. Interface <b>122</b> may be any suitable wired or wireless interface or combination of wired and wireless interfaces for connecting devices such as keyboards, monitors, pointing devices, etc. For example, interface <b>122</b> may be a combination of a display interface (e.g., VGA, DVI, HDMI, etc.) and a device communications interface (e.g., USB, Bluetooth, Firewire, other serial communications interface, etc.). Alternatively, interface <b>122</b> may be a single communications interface that supports both video and device communications signals (e.g., Thunderbolt, etc.).

0045Traditionally, the hardware and software development paths for the handset environment and the PC environment have been completely independent because of different use models and competing constraints on product design. PCs, including desktop and laptop computers, are designed to be flexible and powerful. Specifically, PC hardware architecture is typically based around a general purpose PC processor connected to memory, graphics, and external components through various general purpose interfaces on a motherboard. For example, a personal computer motherboard may include a processor connected through a logic chipset to a graphics processor, system memory (e.g., RAM), and various other components through communication interfaces (PCI, USB, ISA, IDE, etc.). Some more highly integrated PC processors include an interface to a graphics processor (e.g., AGP, etc.) and/or interface to system memory (e.g., SDR, DDR, DDR2, DDR3, DRDRAM, etc.) on the processor.

0046PC processors are optimized for high processor clock speed and computationally intensive tasks. The personal computer market is presently dominated by processors based on the x86 CPU architecture. Current x86-based PC processors for desktop computers have multiple 64-bit central processing units (‘CPUs”) (or “cores”) with clock speeds exceeding 2.5 GHz and power consumption approaching 100 Watts. Current x86-based PC processors for laptop computers typically run at clock speeds up to 2.0 GHz and have power consumption in the range of 15-45 Watts. Because of the large power consumption of these processors, desktop and laptop computers may require cooling devices such as fans or heat-sinks to remove waste heat from the processor. In addition, the battery life of laptop computers using x86-based PC processors is typically less than four hours.

0047In contrast, mobile processors for handsets are optimized for low power consumption and a high level of integration to reduce the overall size of the handset. For example, mobile processors for handsets such as smartphones typically run at clock speeds lower than 2.0 GHz, have power consumption of less than <b>1</b> Watt, and integrate functions common to the mobile environment such as graphics controllers, communications interfaces, and camera controllers. The most common mobile processor architectures are reduced instruction set computing (“RISC”) processor architectures. Specifically, the “ARM” mobile processor architecture is currently the predominant architecture for mobile processors designed for smartphones and other ultra-portable and low power computing devices. Some PC processor manufacturers also refer to PC processors designed for use in laptop computers as “mobile processors.” However, as used herein, the term “mobile processor” refers to a processor suited for use in a handset or smartphone, typically consuming less than 1 Watt and integrating mobile functionality.

0048Personal computers and handsets also typically have different system resources, input/output (“I/O”) devices, and peripherals. For example, desktop and laptop computers typically have much larger amounts of system memory and storage capacity than handsets. While a typical laptop computer may have more than 2 GB of RAM and a hard-drive with a capacity of more than 250 GB, handsets typically have less than 512 MB of RAM and a solid-state drive with a capacity of less than 32 GB. User interface components of personal computers typically include a display screen larger than 9 inches diagonally, a full keyboard, and pointing device(s) for user input. In contrast, handsets typically include a display screen smaller than 7 inches diagonally and user interface components such as a thumb-style QWERTY keyboard, touch-screen display, click-wheel, and/or scroll-wheel. Peripherals found on personal computers typically include an optical disk drive (e.g., CD, DVD, DVD-RW, etc.), expansion ports (e.g., PCMCIA, SCSI, Express Card, etc.), video output port (e.g., VGA, DVI, HDMI, etc.), and generic device ports (e.g., USB, etc.). In contrast, handsets typically do not have optical disk drives or expansion ports. However, other devices are typically integrated into handsets including wireless communications interface(s) (e.g., GSM, CDMA, LTE, EDGE, WiFi, WiMax, etc.), GPS chipset, accelerometer, camera(s), and/or solid-state memory port (SD, Memory Stick, etc.).

0049Software for personal computers and handsets has also traditionally been developed independently. For example, personal computers including desktops and laptops typically run different operating systems than mobile devices. An operating system is software that manages computer hardware and resources and provides common services for execution of applications software on the computer hardware. Operating systems are generally described as having various abstraction layers, where each layer interfaces with the layer below through an interface.

0050Generally, the kernel of an operating system refers to the core OS layer that manages the computing devices resources such as the CPU(s) (CPU scheduling), memory, and I/O (including peripheral and file system access). A kernel will usually provide features for low-level scheduling of processes (dispatching), inter-process communication, process synchronization, context switching, manipulation of process control blocks, interrupt handling, process creation and destruction, and process suspension and resumption. The OS kernel may or may not include device drivers. Other layers of the OS interface with the kernel through system calls or an application programming interface (“API”) layer.

0051Generally, other OS layers include the libraries layer, application framework layer, and application layer. The libraries layer typically includes system libraries and other user libraries. The application framework layer includes services, managers, and runtime environments. The application layer includes user applications, which may run within a runtime environment of the application framework layer. A user interacts with the OS through the OS GUI. The GUI presents menus, buttons, and controls that the user selects to control and use applications running on the OS. Commonly, the term “desktop environment” is used to refer to a style of GUI through which the user interfaces with the OS using icons, windows, toolbars, folders, and/or desktop widgets, and is not limited to a desktop OS. For example, a mobile OS could have a desktop environment, referring to the look and feel of the mobile OS GUI.

0052Operating systems for personal computers (desktop OSs) were designed for multi-tasking, larger screen areas, and to provide a flexible environment for application developers. As used herein, the term desktop OS refers to an operating system designed for use with a personal computer environment, for example a desktop or laptop use environment. Examples of desktop OSs include various distributions of Linux, Mac OS X, and Windows 7, among many others.

0053Operating systems for mobile devices (mobile OSs) were developed for the smaller screen area, lower processing power, smaller memory, and smaller disk space typically found on handsets and smartphones. Example mobile OSs include Android, Apple's iOS (for the iPhone and iPad), Microsoft's Windows Mobile (superseded by Windows Phone 7), Nokia's Symbian, and Palm's Palm OS (superseded by HP webOS). As used herein, the term mobile OS refers to an operating system designed for use with a mobile environment including running on a low-power processor with reduced system resources compared to the PC environment (i.e., desktop or laptop computer system).

0054Mobile operating systems generally have a particular application development environment that is used to create application programs (i.e., “apps”) that run on the mobile OS. The application development environment both facilitates application development by providing common tools and APIs for accessing system resources and services, and limits what applications are allowed to do such that the mobile device is able to continue to provide other required functions. For example, incoming phone calls and texts may interrupt a running application to notify the user of the incoming call or text.

0055The most widely adopted mobile OS is Google's Android. While Android is based on Linux, it includes modifications to the kernel and other OS layers for the mobile environment and mobile processors. In particular, while the Linux kernel is designed for the x86 CPU architecture, the Android kernel is modified for ARM-based mobile processors. Android device drivers are also particularly tailored for devices typically present in a mobile hardware architecture including touch-screens, mobile connectivity (GSM/EDGE, CDMA, Wi-Fi, etc.), battery management, GPS, accelerometers, and camera modules, among other devices.

0056In Android, applications run within the Dalvik virtual machine on an object-oriented application framework designed specifically for the memory and processor speed constraints of mobile hardware architectures. Applications are developed for the Dalvik virtual machine through the Android SDK. In addition, Android does not have a native X Window System nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing GNU/Linux applications or libraries to Android.

0057Apple's iOS operating system (run on the iPhone) and Microsoft's Windows Phone 7 are similarly modified for the mobile environment and mobile hardware architecture. For example, while iOS is derived from the Mac OS X desktop OS, common Mac OS X applications do not run natively on iOS. Specifically, applications are developed for iOS through an SDK to run within the “Cocoa Touch” runtime environment of iOS, which provides basic application infrastructure and support for key iOS features such as touch-based input, push notifications, and system services. Therefore, applications written for Mac OS X do not run on iOS without porting them through the iOS SDK. In addition, it may be difficult to port Mac OS X applications to iOS because of differences between user libraries and application framework layers of the two OSs, and differences in system resources of the mobile and desktop hardware.

0058Because of the differences in processing requirements, system resources, and application development, applications developed for desktop OSs typically do not run on mobile OSs. Additionally, desktop applications may not be easily ported to mobile OSs because they are optimized for a larger screen area, more processing speed, more system memory, different libraries, and commonly a different GUI. As a result, users typically use separate computing devices for each user environment, including a smartphone, tablet computer, laptop computer, and/or desktop computer. In this instance, each device has its own CPU, memory, file storage, and OS.

0059Connectivity and file sharing between smartphones and other devices involves linking one device (e.g., smartphone, running a mobile OS) to a second, wholly disparate device (e.g., notebook, desktop, or tablet running a desktop OS), through a wireless or wired connection. Information is shared across devices by synchronizing data between applications running separately on each device. This process, typically called “synching,” is cumbersome and generally requires active management by the user.

0060Recently, some attempts have been made to provide a more complete user experience with a single mobile computing device. For example, a smartphone may be connected to an external monitor and input devices such as a full keyboard to provide a more desktop-like user experience, with the mobile OS graphical user interface extended to the larger screen and accepting input from the input devices. However, because the external monitor and input devices are only an extension of the smartphone's operating system and user interface, the capabilities of the docked environment are limited by the smartphone's mobile OS. For example, many software applications available on desktop OSs are not available or have limited functionality on mobile OSs. Accordingly, these devices do not present a full desktop user experience when connected to an external environment.

0061Referring still to <figref idref="DRAWINGS">FIG. 1</figref>, computing environment <b>100</b> provides multiple user computing experiences without the above limitations. Specifically, because mobile computing device <b>110</b> includes multiple OSs, where each OS is suited to a particular computing environment, mobile computing device <b>110</b> may be adapted with external devices to provide a broad range of user experiences with a single mobile computing device. For example, a user may have a mobile computing device <b>110</b> and a secondary terminal environment <b>140</b> that provides the user experience of a laptop when connected to mobile computing device <b>110</b>. In this instance, desktop OS <b>160</b> of the mobile computing device is associated with the secondary terminal environment <b>140</b> when the secondary terminal environment is connected to mobile computing device <b>110</b>. To the user, the full capabilities of desktop OS <b>160</b> are available through secondary terminal environment <b>140</b>.

0062<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary hardware system architecture for mobile computing device <b>110</b>, according to various embodiments. Mobile computing device hardware <b>112</b> includes mobile processor <b>114</b> that includes one or more CPU cores <b>204</b> and external display interface <b>220</b>. Generally, mobile computing device hardware <b>112</b> also includes I/O device(s) <b>118</b>, memory <b>206</b>, storage device(s) <b>208</b>, touch-screen display controller <b>210</b> connected to touch-screen display <b>116</b>, power management IC <b>214</b> connected to battery <b>216</b>, cellular modem <b>218</b>, communication device(s) <b>222</b>, and/or other device(s) <b>224</b> that are connected to processor <b>114</b> through various communication signals and interfaces. I/O device(s) <b>118</b> generally includes buttons and other user interface components that may be employed in mobile computing device <b>110</b>. For example, I/O device(s) <b>118</b> may include a set of buttons, (e.g., back, menu, home, search, etc.), off-screen gesture area, click-wheel, scroll-wheel, QWERTY keyboard, etc. Other device(s) <b>224</b> may include, for example, GPS devices, LAN connectivity, microphones, speakers, cameras, accelerometers, and/or MS/MMC/SD/SDIO card interfaces. External display interface <b>220</b> may be any suitable display interface (e.g., VGA, DVI, HDMI, etc.).

0063Processor <b>114</b> may be an ARM-based mobile processor. In embodiments, mobile processor <b>114</b> is a mobile ARM-based processor such as Texas Instruments OMAP3430, Marvell PXA320, Freescale iMX51, or Qualcomm QSD8650/8250. However, mobile processor <b>114</b> may be another suitable ARM-based mobile processor or processor based on other processor architectures such as, for example, x86-based processor architectures or other RISC-based processor architectures.

0064While <figref idref="DRAWINGS">FIG. 2</figref> illustrates one exemplary hardware implementation <b>112</b> for mobile computing device <b>110</b>, other architectures are contemplated as within the scope of the invention. For example, various components illustrated in <figref idref="DRAWINGS">FIG. 2</figref> as external to mobile processor <b>114</b> may be integrated into mobile processor <b>114</b>. Optionally, external display interface <b>220</b>, shown in <figref idref="DRAWINGS">FIG. 2</figref> as integrated into mobile processor <b>114</b>, may be external to mobile processor <b>114</b>. Additionally, other computer architectures employing a system bus, discrete graphics processor, and/or other architectural variations are suitable for employing aspects of the present invention.

0065<figref idref="DRAWINGS">FIG. 3</figref> illustrates OS architecture <b>300</b> that may be employed to run mobile OS <b>130</b> and desktop OS <b>160</b> concurrently on mobile computing device <b>110</b>, according to various embodiments. As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, mobile OS <b>130</b> and desktop OS <b>160</b> are independent operating systems. Specifically, mobile OS <b>130</b> and desktop OS <b>160</b> may have independent and incompatible user libraries and/or framework layers. Functions and instructions for OS architecture <b>300</b> may be stored as computer program code on a tangible computer readable medium of mobile computing device <b>110</b>. For example, instructions for OS architecture <b>300</b> may be stored in storage device(s) <b>208</b> of mobile computing device hardware <b>112</b>.

0066As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, mobile OS <b>130</b> has libraries layer <b>330</b>, application framework layer <b>340</b>, and application layer <b>350</b>. In mobile OS <b>130</b>, applications <b>352</b> and <b>354</b> run in application layer <b>350</b> supported by application framework layer <b>340</b> of mobile OS <b>130</b>. Application framework layer <b>340</b> includes manager(s) <b>342</b> and service(s) <b>344</b> that are used by applications running on mobile OS <b>130</b>. For example, application framework layer <b>340</b> may include a window manager, activity manager, package manager, resource manager, telephony manager, gesture controller, and/or other managers and services for the mobile environment. Application framework layer <b>340</b> may include a mobile application runtime environment that executes applications developed for mobile OS <b>130</b>. The mobile application runtime environment may be optimized for mobile computing resources such as lower processing power or limited memory space. The mobile application runtime environment may rely on the kernel for process isolation, memory management, and threading support. Libraries layer <b>330</b> includes user libraries <b>332</b> that implement common functions such as I/O and string manipulation (“standard C libraries”), graphics libraries, database libraries, communication libraries, and/or other libraries.

0067As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, desktop OS <b>160</b> has libraries layer <b>360</b>, framework layer <b>370</b>, and application layer <b>380</b>. In desktop OS <b>160</b>, applications <b>382</b> and <b>384</b> run in application layer <b>380</b> supported by application framework layer <b>370</b> of desktop OS <b>160</b>. Application framework layer <b>370</b> includes manager(s) <b>372</b> and service(s) <b>374</b> that are used by applications running on desktop OS <b>160</b>. For example, application framework layer <b>370</b> may include a window manager, activity manager, package manager, resource manager, and/or other managers and services common to a desktop environment. Libraries layer <b>360</b> may include user libraries <b>362</b> that implement common functions such as I/O and string manipulation (“standard C libraries”), graphics libraries, database libraries, communication libraries, and/or other libraries.

0068In various embodiments of the present disclosure, desktop OS <b>160</b> runs in a separate execution environment from mobile OS <b>130</b>. For example, mobile OS <b>130</b> may run in a root execution environment and desktop OS <b>160</b> may run in a secondary execution environment established under the root execution environment. Processes and applications running on mobile OS <b>130</b> access user libraries <b>332</b>, manager(s) <b>342</b> and service(s) <b>344</b> in the root execution environment. Processes and applications running on desktop OS <b>160</b> access user libraries <b>362</b>, manager(s) <b>372</b> and service(s) <b>374</b> in the secondary execution environment.

0069Generally applications developed for mobile OS <b>130</b> do not run directly on desktop OS <b>160</b>, and applications developed for desktop OS <b>160</b> do not run directly on mobile OS <b>130</b>. For example, application <b>382</b> running in application layer <b>380</b> of desktop OS <b>160</b> may be incompatible with mobile OS <b>130</b>, meaning that application <b>382</b> could not run on mobile OS <b>130</b>. Specifically, application <b>382</b> may use manager(s) <b>372</b> and service(s) <b>374</b> of application framework layer <b>370</b> of desktop OS <b>160</b> that are either not available or not compatible with manager(s) <b>342</b> and service(s) <b>344</b> in application framework layer <b>340</b> in mobile OS <b>130</b>. In addition, application <b>382</b> may attempt to access user libraries <b>362</b> that exist in libraries layer <b>360</b> of desktop OS <b>160</b> but are either not available or not compatible with user libraries <b>332</b> available in libraries layer <b>330</b> of mobile OS <b>130</b>.

0070In OS architecture <b>300</b>, mobile OS <b>130</b> and desktop OS <b>160</b> run concurrently on shared kernel <b>320</b>. This means that mobile OS <b>130</b> and desktop OS <b>160</b> are running on shared kernel <b>320</b> at the same time. Specifically, mobile OS <b>130</b> and desktop OS <b>160</b> both interface to shared kernel <b>320</b> through the same kernel interface <b>322</b>, for example, by making system calls to shared kernel <b>320</b>. Shared kernel <b>320</b> manages task scheduling for processes of both mobile OS <b>130</b> and desktop OS <b>160</b>. In this regard, mobile OS <b>130</b> and desktop OS <b>160</b> are running independently and concurrently on shared kernel <b>320</b>. In addition, shared kernel <b>320</b> runs directly on mobile processor <b>114</b> of mobile computing device hardware <b>112</b>, as illustrated by hardware interface <b>312</b>. Specifically, shared kernel <b>320</b> directly manages the computing resources of mobile computing device hardware <b>112</b> such as CPU scheduling, memory access, and I/O. In this regard, hardware resources are not virtualized, meaning that mobile OS <b>130</b> and desktop OS <b>160</b> make system calls through kernel interface <b>322</b> without virtualized memory or I/O access.

0071There are several known techniques for providing multiple OSs on the same computing device. However, none of these techniques provide multiple different OSs running concurrently and independently on a shared kernel. More particularly, none of these techniques provide a solution for a mobile OS and a desktop OS running on a shared kernel.

0072In one technique, known as dual-boot, multiple OSs are loaded on the computing device one at a time. For example, at boot time, a user may select one OS from multiple available OSs to be run on the device, where each OS has its own kernel, libraries, framework, and applications. The system then boots up into that operating system and the other OS(s) are not running (i.e., no processes of the other OS(s) are loaded concurrently with the running OS). Therefore, this technique does not run multiple OSs on a shared kernel, nor does this technique run multiple OSs concurrently.

0073Another technique for running multiple OSs on the same device is to use a Virtual Machine Manager (“VMM”), or “Hypervisor.” A VMM or Hypervisor runs directly on the hardware and separates the individual kernels of each OS from the hardware, controlling which computer hardware resources are available to each OS at any given time. A Hypervisor effectively creates multiple virtual machines from one device, such that each OS sees a separate virtual machine. Therefore, multiple OSs running on the same device through Hypervisor and VMM are not running on a shared kernel. The Hypervisor adds system overhead due to each OS having to access system resources through virtualization in the Hypervisor. Additionally, because the Hypervisor must allocate CPU and other computing resources, each OS may not be able to effectively schedule processes and tasks.

0074Yet another technique for running multiple OSs on the same device is to use a hosted virtual machine. In this technique, each OS has its own kernel, with the kernel of the guest OS running on a virtual machine in the host OS. The virtual machine may be a virtualized hardware platform different than the physical hardware platform. The virtual machine in the host OS may be implemented in the kernel of the host OS. In this instance, the kernel of the host OS acts as a hypervisor through which the kernel of the guest OS accesses the processor and hardware resources. Regardless of where the virtual machine is implemented in this technique, the host OS and the guest OS have separate kernels. Therefore, hosted virtual machines do not have multiple OSs running on a shared kernel. System performance using this technique may be reduced due to virtualization of hardware resources for the guest OS.

0075Another form of virtualization is operating system level virtualization. In this technique, multiple isolated user-space instances may be created on the kernel of an operating system, which look like separate OS instances from the point of view of users of each user-space instance. In this technique, the host OS and guest OS(s) must be the same OS. Accordingly, this technique does not provide a solution for a mobile OS and desktop OS running independently and concurrently on a shared kernel. Further, similarly to a hosted virtual machine, this technique uses disk space and memory virtualization for the guest OS(s). Accordingly, this technique does not provide direct access to memory and system resources for each concurrent OS.

0076These techniques of running multiple OSs have limitations with regard to running both operating systems concurrently and independently. For example, virtualization involves setting up a distinct address space for the guest OS and simulating I/O to the guest OS. Therefore, access to hardware including system memory has higher overhead for the guest OS using virtualization. Additionally, techniques using Hypervisors result in lack of certainty in process control of each OS. Specifically, the Hypervisor manages the amount of CPU time allocated to each OS, and each OS then allocates CPU time for processes within the OS, without knowledge of what is occurring in the other OS. In this regard, high priority processes within one OS may not be given the required CPU time to complete their tasks because the OS is sharing CPU time through the Hypervisor, which cannot account for the relative priorities of processes running within each OS. Because processing power may be limited in mobile processor architectures relative to desktop processor architectures, techniques that depend on virtualization, including hypervisors, and operating system level virtualization, may not offer optimal performance for a desktop OS running concurrently with a mobile OS on a mobile processor.

0077In one embodiment consistent with OS architecture <b>300</b>, an Android mobile OS and a full Linux OS run independently and concurrently on a modified Android kernel. In this embodiment, the Android OS may be a modified Android distribution while the Linux OS (“Hydroid”) may be a modified Debian Linux desktop OS. <figref idref="DRAWINGS">FIGS. 4-6</figref> illustrate Android mobile OS <b>430</b>, Android kernel <b>520</b>, and Hydroid OS <b>660</b> that may be employed in OS architecture <b>300</b> in more detail, according to various embodiments.

0078As illustrated in <figref idref="DRAWINGS">FIG. 4</figref>, Android OS <b>430</b> includes a set of C/C++ libraries in libraries layer <b>432</b> that are accessed through application framework layer <b>440</b>. Libraries layer <b>432</b> includes the “bionic” system C library <b>439</b> that was developed specifically for Android to be smaller and faster than the “glibc” Linux C-library. Libraries layer <b>432</b> also includes inter-process communication (“IPC”) library <b>436</b>, which includes the base classes for the “Binder” IPC mechanism of the Android OS. Binder was developed specifically for Android to allow communication between processes and services. Other libraries shown in libraries layer <b>432</b> in <figref idref="DRAWINGS">FIG. 4</figref> include media libraries <b>435</b> that support recording and playback of media formats, surface manager <b>434</b> that managers access to the display subsystem and composites graphic layers from multiple applications, 2D and 3D graphics engines <b>438</b>, and lightweight relational database engine <b>437</b>. Other libraries that may be included in libraries layer <b>432</b> but are not pictured in <figref idref="DRAWINGS">FIG. 4</figref> include bitmap and vector font rendering libraries, utilities libraries, browser tools (i.e., WebKit, etc.), and/or secure communication libraries (i.e., SSL, etc.).

0079Application framework layer <b>440</b> of Android OS <b>430</b> provides a development platform that allows developers to use components of the device hardware, access location information, run background services, set alarms, add notifications to the status bar, etc. Framework layer <b>440</b> also allows applications to publish their capabilities and make use of the published capabilities of other applications. Components of application framework layer <b>440</b> of Android mobile OS <b>430</b> include activity manager <b>441</b>, resource manager <b>442</b>, window manager <b>443</b>, dock manager <b>444</b>, hardware and system services <b>445</b>, desktop monitor service <b>446</b>, multi-display manager <b>447</b>, and remote communication service <b>448</b>. Other components that may be included in framework layer <b>440</b> of Android mobile OS <b>430</b> include a view system, telephony manager, package manager, location manager, and/or notification manager, among other managers and services.

0080Applications running on Android OS <b>430</b> run within the Dalvik virtual machine <b>431</b> in the Android runtime environment <b>433</b> on top of the Android object-oriented application framework. Dalvik virtual machine <b>431</b> is a register-based virtual machine, and runs a compact executable format that is designed to reduce memory usage and processing requirements. Applications running on Android OS <b>430</b> include home screen <b>451</b>, email application <b>452</b>, phone application <b>453</b>, browser application <b>454</b>, and/or other application(s) (“App(s)”) <b>455</b>.

0081For these reasons, applications written for Android do not generally run on Hydroid OS <b>660</b> and applications written for standard Linux distributions do not generally run on Android OS <b>430</b>. In this regard, applications for Android OS <b>430</b> and Hydroid OS <b>660</b> are not bytecode compatible, meaning compiled and executable programs for one do not run on the other.

0082<figref idref="DRAWINGS">FIG. 5</figref> illustrates modified Android kernel <b>520</b> in more detail, according to various embodiments. Modified Android kernel <b>520</b> includes touch-screen display driver <b>521</b>, camera driver(s) <b>522</b>, Bluetooth driver(s) <b>523</b>, shared memory allocator <b>524</b>, IPC driver(s) <b>525</b>, USB driver(s) <b>526</b>, WiFi driver(s) <b>527</b>, I/O device driver(s) <b>528</b>, and/or power management module <b>530</b>. I/O device driver(s) <b>528</b> includes device drivers for external I/O devices, including devices that may be connected to mobile computing device <b>110</b> through port <b>120</b>. Modified Android kernel <b>520</b> may include other drivers and functional blocks including a low memory killer, kernel debugger, logging capability, and/or other hardware device drivers.

0083<figref idref="DRAWINGS">FIG. 6</figref> illustrates Hydroid OS <b>660</b> in more detail, according to various embodiments. Hydroid is a full Linux OS that is capable of running almost any application developed for standard Linux distributions. In particular, libraries layer <b>662</b> of Hydroid OS <b>660</b> includes Linux libraries that support networking, graphics processing, database management, and other common program functions. For example, user libraries <b>662</b> may include the standard Linux C library (glibc) <b>664</b>, Linux graphics libraries <b>662</b> (e.g., GTK, etc.), Linux utilities libraries <b>661</b>, Linux database libraries, and/or other Linux user libraries. Applications run on Hydroid within an X-Windows Linux graphical environment using X-Server <b>674</b>, window manager <b>673</b>, and/or desktop environment <b>672</b>. Illustrated applications include word processor <b>681</b>, email application <b>682</b>, spreadsheet application <b>683</b>, browser <b>684</b>, and other application(s) <b>685</b>.

0084In one embodiment, Hydroid OS <b>660</b> includes components of a cross-environment communication framework that facilitates communication with Android OS <b>430</b> through shared kernel <b>520</b>. These components include IPC library <b>663</b> that includes the base classes for the Binder IPC mechanism of the Android OS and remote communications service <b>671</b>.

0085In one embodiment, Hydroid OS <b>660</b> is run within a chrooted (created with the ‘chroof’ command) secondary execution environment created within the Android root environment. Processes and applications within Hydroid OS <b>660</b> are run within the secondary execution environment such that the apparent root directory seen by these processes and applications is the root directory of the secondary execution environment. In this way, Hydroid OS <b>660</b> can run programs written for standard Linux distributions without modification because Linux user libraries <b>662</b> are available to processes running on Hydroid OS <b>660</b> in the chrooted secondary execution environment.

0086In preemptive multi-tasking operating systems, direct communication between independent processes is typically prevented for security and reliability reasons. Instead, a form of IPC must be used to send information across process boundaries (i.e., between process address spaces). Objects sent from one process to another process must be marshaled across the process boundaries. Marshaling is the process of packaging and unpackaging data and parameters so an IPC communication can take place. Some forms of IPC can be used to pass information between processes on different computers on a network. One method of IPC is to allow a process in one address space to cause a subroutine or procedure to execute in another address space. This method of IPC is called a remote procedure call (“RPC”).

0087Some methods of IPC are platform independent. For example, Internet sockets or network sockets are a mechanism of bidirectional IPC across an Internet Protocol (“IP”) based computer network. Internet sockets can be used to deliver data packets to application processes or threads based on local or remote IP addresses and port numbers. The operating systems of each local or remote machine maintain mappings of each socket to the appropriate application process or thread.

0088Referring back to <figref idref="DRAWINGS">FIG. 3</figref>, OS architecture <b>300</b> includes OS <b>130</b> and desktop OS <b>160</b> running concurrently on shared kernel <b>320</b>. As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, mobile computing device <b>110</b> can be docked with secondary terminal environment <b>140</b>. Secondary terminal environment <b>140</b> may have a user experience profile that is associated with desktop OS <b>160</b>. In this instance, mobile OS <b>130</b> provides a mobile computing experience through touch-screen display <b>116</b> and I/O devices <b>118</b> of mobile computing device hardware <b>112</b>. At the same time, desktop OS <b>160</b> provides a desktop computing experience through secondary terminal environment <b>140</b>.

0089Accordingly, the user is able to use and interact with mobile applications (for example, applications <b>352</b> and <b>354</b>) running on mobile OS <b>130</b> through the mobile computing experience provided on the user interface components of mobile computing device <b>110</b> while using and interacting with desktop applications (for example, applications <b>382</b> and <b>384</b>) running on desktop OS <b>160</b> through secondary terminal environment <b>140</b>. In this instance, applications of mobile OS <b>130</b> are independent from applications of desktop OS <b>160</b>. In this regard, settings, user preferences, user data, and application states of applications of mobile OS <b>130</b> are separate and independent from settings, user preferences, user data, and application states of applications of desktop OS <b>160</b>. For example, application <b>352</b> of mobile OS <b>130</b> and application <b>382</b> of desktop OS <b>160</b> may be spreadsheet applications. When the user opens a spreadsheet file with application <b>352</b> and begins editing data, the spreadsheet file and associated data are locked by application <b>352</b>. Application <b>382</b> is not able to access the edited spreadsheet data as that data is maintained in the process space of application <b>352</b>.

0090Embodiments of the invention include a cross-environment communications framework that extends IPC between applications and services of a mobile OS running on a shared kernel and applications and services of a desktop OS running on the same shared kernel. The cross-environment communications framework supports communication between applications of the desktop OS and applications and services of the mobile OS. The cross-environment communications framework also supports communication between mobile OS applications and other mobile OS applications.

0091<figref idref="DRAWINGS">FIG. 7</figref> illustrates one embodiment of a cross-environment communications framework. In cross-environment communications framework <b>700</b>, mobile application <b>352</b>, service <b>741</b>, and other mobile application(s) and service(s) <b>354</b> run on mobile OS <b>130</b> while desktop applications <b>382</b> and <b>384</b> run on desktop OS <b>160</b>. Each application and service includes one or more processes, with each process having its own process space.

0092Services are components that perform background operations (i.e., not directly involving user interaction with the application) for applications and/or assist in interactions between applications and hardware. While various operating systems may refer to these components by other names, a service, as used herein, is intended to be construed broadly as a component including one or more processes that implements functionality not directly involving user interaction that may be used by applications, the operating system, and/or other services.

0093As illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, desktop application <b>382</b>, running on desktop OS <b>160</b>, communicates with service <b>741</b> running on mobile OS <b>130</b> through an inter-process communication channel that includes IPC driver <b>721</b> in kernel <b>320</b>. Initially, desktop application <b>382</b> sends a call through IPC driver <b>721</b> to bind to service <b>741</b>. Service <b>741</b> creates an instance of a remotable object <b>742</b>, which defines the IPC interface through which desktop application <b>382</b> communicates with service <b>741</b>. Service <b>741</b> returns remotable object <b>742</b> to desktop application <b>382</b> through IPC driver <b>721</b>. Subsequently, desktop application <b>382</b> can make calls to remotable object <b>742</b> to communicate with service <b>741</b> through IPC driver <b>721</b>.

0094In one form of communication of cross-environment communication framework <b>700</b>, desktop application <b>382</b> may call remotable methods of service <b>741</b> by making calls to remotable object <b>742</b>. A call to remotable object <b>742</b> may include zero or more parameters passed to a remotable method of service <b>741</b> and/or zero or more parameters to be returned from the remotable method of service <b>741</b>. Parameters are parceled by the IPC interface to the remotable object and marshaled across process boundaries by IPC driver <b>721</b>. In this regard, desktop application <b>382</b> may pass parameters in a call to remotable object <b>742</b> in the form of a parcel object. IPC driver <b>721</b> marshals the parcel object to the process space of service <b>741</b>. Service <b>741</b> unparcels the parcel object and performs the remotable method in its process space using the unparceled parameters and returns another parcel object to desktop application <b>382</b>. The returned parcel object may include a reference to the remotable object.

0095Calls to the remotable object may be synchronous or asynchronous. For example, if desktop application <b>382</b> makes a synchronous call to the remotable object, the calling thread in desktop application <b>382</b> blocks and waits for the return from the remotable object before continuing. Alternatively, if desktop application <b>382</b> makes an asynchronous call to the remotable object, the calling thread in desktop application <b>382</b> continues and does not wait for the call to the remotable object to return.

0096Remotable object <b>742</b> allows desktop application <b>382</b> and service <b>741</b> to both access a shared memory space in a thread-safe manner. For example, a reference to the shared memory space may be included in parcel objects passed by calls to remotable object <b>742</b>. Because remotable object <b>742</b> is reference counted across process boundaries, application <b>382</b> and service <b>741</b> can share memory across process boundaries in a thread-safe manner. In various instances, the reference to a shared memory space may be a file descriptor or file handle.

0097In embodiments, service <b>741</b> may be a core service of the mobile OS such as a telephony service, camera service, location service. Service <b>741</b> may also be a custom service that performs operations related to an application of mobile OS <b>130</b> or desktop OS <b>160</b>.

0098In one embodiment, service <b>741</b> may be a service that enables app-to-app communication. For example, service <b>741</b> may be a remote communications service that implements aspects of the cross-environment communications framework to provide app-to-app communication between applications running on mobile OS <b>130</b>. The remote communication service may also enable communication between desktop applications running on desktop OS <b>160</b> and mobile applications running on mobile OS <b>130</b>. In one embodiment, remote communication service <b>448</b> of Android OS <b>430</b> facilitates app-to-app communication between applications running on Android OS <b>430</b> and/or Hydroid OS <b>660</b>.

0099For example, mobile application <b>352</b> may bind to service <b>741</b>. Service <b>741</b> then instantiates remotable object <b>742</b> and returns remotable object <b>742</b> to mobile application <b>352</b>. Mobile application <b>354</b> may also bind to service <b>741</b> and service <b>741</b> may return remotable object <b>742</b> to mobile application <b>354</b>. With mobile applications <b>352</b> and <b>354</b> may communicate through calls to remotable object <b>742</b>. For example, mobile application <b>352</b> may pass parcel objects using calls to remotable object <b>742</b>. The parcel objects may include data and/or references to shared memory. Mobile application may access the shared memory by also making calls to remotable object <b>742</b>. In the same manner, desktop application <b>382</b> may also bind to service <b>741</b> and communicate with mobile applications <b>352</b> and <b>354</b> using calls to remotable object <b>742</b>.

0100In one embodiment, Android mobile OS <b>430</b> and a Linux desktop OS <b>660</b> run concurrently on shared kernel <b>520</b>. The Android OS includes a lightweight remote procedure call mechanism called “Binder.” The Binder mechanism uses shared memory to achieve efficient, secure IPC. The Binder mechanism includes Binder IPC driver <b>525</b> in the Android kernel <b>520</b> and user class libraries including Binder IPC library <b>436</b> that contain the base classes for Binder objects. In Android OS <b>430</b>, Binder IPC library <b>436</b> is compiled against Bionic C library <b>439</b>. A Binder reference is a descriptor maintained by Binder driver <b>525</b> to an interface of a remotable Binder object. A process can call the remotable Binder object through the interface. The Android Binder mechanism provides reference counting and manages mapping of object references across processes. However, the Android Binder mechanism only provides communication between Android applications and globally registered Android services. Therefore, Android applications may not communicate directly with each other through the Binder mechanism.

0101The IPC mechanisms available in the Linux OS are pipes, named pipes, system V message queues, system V semaphores, system V shared memory segments, and networking sockets. These IPC mechanisms are not directly compatible with the Binder IPC mechanism in the Android OS or the Binder kernel driver used for the Android Binder IPC mechanism. Therefore, Linux applications running cannot use these standard Linux IPC mechanisms to communicate with applications and/or service(s) running on an Android OS.

0102In one embodiment, the cross-environment communications framework extends the Binder mechanism to allow applications of Linux desktop OS <b>660</b> to access services of Android OS <b>430</b>. In one embodiment, the cross-environment communication framework includes a remote communication service that allows app-to-app communication within Android OS <b>430</b>. In other embodiments, the remote communication service allows Linux applications running on Linux desktop OS <b>660</b> to communicate with Android applications running on Android OS <b>430</b>.

0103In embodiments, the cross-environment communications framework also supports use of the user datagram protocol (“UDP”) for cross-environment communication. UDP is part of the suite of protocols of the Internet Protocol (“IP”). UDP is an asynchronous data transmission mechanism without an implicit handshaking dialogue. Accordingly, UDP does not provide a reliable transmission protocol, not does it guarantee data ordering or data integrity during transmission. However, because UDP has minimal overhead, it may be a preferable transmission mechanism for time-sensitive information in a real-time system. For example, where dropping packets is preferable to delaying transmission, UDP may be a preferred transmission mechanism.

0104<figref idref="DRAWINGS">FIG. 8</figref> illustrates communication flow <b>800</b> employing aspects of the cross-environment communications framework, according to various embodiments. In communication flow <b>800</b>, Android application <b>852</b>, running on Android OS <b>430</b>, registers with remote communication service <b>448</b> by calling a method of the Android OS context as illustrated by process step <b>802</b>. In response, remote communication service <b>448</b> returns an interface to a remotable object <b>804</b> (e.g., Binder object) at step <b>806</b>. At step <b>808</b>, Android application <b>854</b> registers with remote communication service <b>448</b>. Remote communication service <b>448</b> returns an interface to the same remotable object <b>804</b> to Android application <b>854</b> at step <b>810</b>.

0105Android application <b>852</b>, running on Android OS <b>430</b>, can communicate with Android application <b>854</b> using remotable object <b>804</b> by making calls to the remotable object. Calls to the remotable object may include remote method invocations and/or parceled data. The parceled data may include various data types including integers, strings, arrays, and/or file descriptors, among other possible data types. At step <b>812</b> of communication flow <b>800</b>, Android application <b>852</b> invokes remote method FN<b>1</b> of remote communication service <b>448</b>. Kernel IPC driver <b>525</b> marshals the remote call across the process boundaries and remote communication service <b>448</b> receives the call to the remotable object at step <b>814</b>. Remote communication service <b>448</b> then unparcels data of the remote call and runs the remote method in its process space using the data at step <b>816</b>. Remote communication service <b>448</b> returns another parcel object through the interface to the remotable object at steps <b>818</b> and <b>820</b>.

0106At step <b>822</b>, Android application <b>854</b> makes a call to remotable object <b>804</b>. For example, Android application <b>854</b> may invoke a remote method (FN<b>2</b>) of remote communication service <b>448</b>. Application <b>854</b> may pass a parcel object to the remote method that includes parameters for the remote method. Kernel IPC driver <b>525</b> marshals the parcel object to the process space of remote communication service <b>448</b> and remote communication service <b>448</b> receives the parcel object at step <b>824</b>. Remote communication service <b>448</b> then unparcels the data and runs the remote method in its process space using the data at step <b>826</b>. Remote communication service <b>448</b> returns another parcel object through the interface to the remotable object at step <b>828</b>. Kernel IPC driver <b>525</b> marshals the parcel object across the process boundaries and Android application <b>854</b> receives the parcel object at step <b>830</b>.

0107In one embodiment, remote communication service <b>448</b> may be a bound service of Android OS <b>430</b>. In this embodiment, the bound service is created by Android OS <b>430</b> when an client binds to the service through the Context class of Android OS <b>430</b>. The bound service runs as long as clients (applications and/or services that bind to the service) are bound to the service and is destroyed when the last client unbinds from the service. The bound service may implement a shared memory interface allowing clients to share user preferences, settings, and/or user data.

0108Communications flow <b>800</b> provides thread-safe cross-process communication for sharing data between Android applications <b>852</b> and <b>854</b> running on Android OS <b>430</b>. Android applications <b>852</b> and <b>854</b> may share data in a shared memory space in a thread-safe manner by passing references to the shared data using remotable object <b>804</b>. For example, Android applications <b>852</b> and <b>854</b> may pass a parcel object that includes a reference to a shared memory space through remotable object <b>804</b>.

0109Communications flow <b>800</b> illustrates synchronous communication between Android applications <b>852</b> and <b>854</b> and remote communication service <b>448</b>. However, communication between Android applications <b>852</b> and <b>354</b> and remote communication service <b>448</b> may be asynchronous, meaning that Android applications <b>852</b> and <b>854</b> will return immediately from calls to the remotable object and not wait for a result from the remote method invocation.

0110<figref idref="DRAWINGS">FIG. 9</figref> illustrates communication flow <b>900</b> employing aspects of the cross-environment communications framework, according to various embodiments. In communication flow <b>900</b>, application <b>682</b> running on Hydroid OS <b>660</b> communicates with service <b>941</b> of Android OS <b>430</b>.

0111Service <b>941</b> exposes a Binder interface to clients and at step <b>902</b>, Hydroid application <b>982</b> registers with service <b>941</b> by binding to service <b>941</b> using the exposed interface though Binder kernel driver <b>525</b>. Service <b>941</b> returns in interface to a remotable object <b>904</b>, which Hydroid application <b>982</b> receives at step <b>908</b>. At step <b>910</b>, Hydroid application <b>382</b> makes a call to remotable object <b>904</b>. For example, Hydroid application <b>382</b> may invoke a remotable method (FN<b>1</b>) of service <b>941</b>. The remote method call may include a parcel object that includes parameters for the remote method call. Binder driver <b>525</b> marshals the parcel object to the process space of service <b>941</b> and service <b>941</b> receives the data at step <b>912</b>. Service <b>941</b> unparcels the data and runs the method in its process space using the unparceled data at step <b>914</b>. Service <b>941</b> returns a parcel object that includes return values of the method through binder driver <b>525</b> at steps <b>916</b> and <b>918</b>. Using communication flow <b>900</b>, Hydroid application <b>982</b>, running on Hydroid OS <b>660</b>, can access methods and data of service <b>941</b> of Android OS <b>430</b>.

0112Communications flow <b>900</b> provides thread-safe cross-process communication for sharing data between processes of Android OS <b>430</b> and applications of Hydroid OS <b>660</b>. For example, Hydroid application <b>982</b> may access shared data of services of Android OS <b>430</b> through shared memory by passing references to the shared memory using remotable object <b>904</b>.

0113Communication flow <b>900</b> may be used to allow applications running on Hydroid OS <b>660</b> to access various services of Android OS <b>430</b>. For example, service <b>941</b> of Android OS <b>430</b> may be a core service of Android OS <b>430</b> such as a telephony service, camera service, location service, etc. Alternatively, service <b>941</b> may be a custom service such as remote communication service <b>448</b>.

0114<figref idref="DRAWINGS">FIG. 10</figref> illustrates communication flow <b>1000</b> employing the cross-environment communications framework, according to various embodiments. Initially, remote communication service <b>448</b> exposes a binder interface to clients. At step <b>1002</b>, Android application <b>852</b> of Android OS <b>430</b> registers with remote communication service <b>448</b> (i.e., binds to remote communication service <b>448</b>). Remote communication service <b>448</b> instantiates a remotable object <b>1004</b> and returns remotable object <b>1004</b> to Android application <b>852</b> at step <b>1006</b>.

0115At step <b>1008</b>, Hydroid application <b>982</b> of Hydroid OS <b>660</b> registers with remote communication service <b>448</b> by binding to remote communication service <b>448</b> using the exposed interface though binder kernel driver <b>525</b>. Remote communication service <b>448</b> returns remotable object <b>1004</b>, which Hydroid application <b>982</b> receives at step <b>1014</b>.

0116At step <b>1016</b>, Android application <b>852</b> makes a call to remotable object <b>1004</b>. For example, Android application <b>852</b> may invoke a remote method (FN<b>1</b>) of remote communication service <b>448</b>. Android application <b>852</b> may pass a parcel object to the remote method that includes parameters for the remote method. The parcel object may include a reference to a shared memory space. Binder driver <b>525</b> marshals the parceled data across the process boundaries and remote communication service <b>448</b> receives the data at step <b>1018</b>. Remote communication service <b>448</b> unparcels the data and runs the method in its process space using the unparceled data at step <b>1020</b> and returns the remotable object through binder driver <b>525</b> at steps <b>1022</b> and <b>1024</b>.

0117At step <b>1026</b>, Hydroid application <b>982</b> calls a remote method (FN<b>2</b>) of remote communication service <b>448</b> through the remotable object <b>1004</b>. The remote method call may include data that is parceled into remotable object <b>1004</b>. Binder driver <b>525</b> marshals the parceled data across the process boundaries and remote communication service <b>448</b> receives the data at step <b>1028</b>. Remote communication service <b>448</b> then unparcels the data and runs the method in its process space using the data at step <b>1030</b> and returns remotable object <b>1004</b> through binder driver <b>525</b> at steps <b>1032</b> and <b>1034</b>.

0118Communications flow <b>1000</b> provides thread-safe cross-process communication for sharing data between applications of Android OS <b>430</b> and applications of Hydroid OS <b>660</b>. For example, Hydroid application <b>982</b> of Hydroid OS <b>660</b> and Android application <b>852</b> of Android OS <b>430</b> may share data through shared memory by passing references to the shared memory using remotable object <b>1004</b>. In communications flow <b>1000</b>, Android application <b>852</b> and Hydroid application <b>982</b> block on return of the remote method invocation. Accordingly, communications flow <b>1000</b> provides synchronous communication between Android application <b>852</b> and Hydroid application <b>982</b>. However, remote method invocations from Android application <b>352</b> and Hydroid application <b>982</b> may be asynchronous, meaning that applications <b>852</b> and <b>982</b> will return immediately from calls to remotable object <b>1004</b> and not wait for a result to be returned.

0119In one embodiment of communications flow <b>1000</b>, remote communication service <b>448</b> is a bound service of Android OS <b>430</b>. In this embodiment, the bound service is created by Android OS <b>430</b> when either an Android application or a Hydroid application binds to the service. The service may implement a shared memory interface allowing Android applications and Hydroid applications to share user preferences, settings, and/or user data.

0120In one example consistent with communications flow <b>1000</b>, Android application <b>852</b> and Hydroid application <b>982</b> are spreadsheet programs. User data is stored in shared memory accessed through a remotable object. In this example, Android spreadsheet application <b>852</b> and Hydroid spreadsheet application <b>982</b> both may manipulate the user data by passing a parcel object that includes a reference to the shared memory through calls to remotable object <b>1004</b>. In this way, Android spreadsheet application <b>852</b> and Hydroid spreadsheet application <b>982</b> can manipulate user data of a spreadsheet stored in shared memory in a thread-safe manner.

0121Accordingly, communication flow <b>1000</b> allows applications running on Hydroid OS <b>660</b> to communicate with applications running on Android OS <b>430</b> using the Android Binder mechanism. In this way, Android application <b>852</b> running on Android OS <b>430</b> and Hydroid application <b>982</b> running on Hydroid OS <b>660</b> can share settings, user preferences, and/or user data fast and efficiently.

0122<figref idref="DRAWINGS">FIG. 11</figref> illustrates communication flow <b>1100</b> that employs aspects of the cross-environment communications framework, according to various embodiments. As illustrated in <figref idref="DRAWINGS">FIG. 11</figref>, remote communication service <b>448</b> of Android OS <b>430</b> includes UDP communication module <b>1146</b> and remote communication service <b>671</b> of Hydroid OS <b>660</b> includes UDP communication module <b>1176</b>. In communication flow <b>1100</b>, Hydroid application <b>982</b> of Hydroid OS <b>660</b> communicates with Android application <b>852</b> of Android OS <b>430</b> through UDP modules <b>1146</b> of Android OS <b>430</b> and <b>1176</b> of Hydroid OS <b>660</b>.

0123In one example, Android application <b>852</b> binds to a socket of socket driver(s) <b>1121</b> in shared kernel <b>520</b> through UDP module <b>1146</b>. Hydroid application <b>982</b> of Hydroid OS <b>660</b> also binds to the socket of socket driver(s) <b>1121</b> through UDP module <b>1176</b>. Android application <b>852</b> then sends UDP packets to the socket and Hydroid application <b>982</b> receives the UDP packets through UDP module <b>1176</b> of Hydroid OS <b>660</b>.

0124As described above, UDP does not include handshaking for providing reliability or implicit data ordering. Accordingly, communication flow <b>1100</b> may be suitable for communications between applications of Android OS <b>430</b> and Hydroid OS <b>660</b> where data reliability is not a primary concern. For example, communication flow <b>1100</b> may be used for a Linux streaming audio client to receive a streaming audio signal from an Android streaming audio application or service. In this instance, it may be more important for the Linux streaming audio client to keep receiving packets through communication flow <b>1100</b> rather than wait for handshaking or resending of any dropped packets.

0125As described above, mobile OSs (e.g., Android, iOS) and desktop OSs (e.g., Linux, Mac OS X) typically have been developed under different system constraints and for different use models. One difference between mobile OSs and desktop OSs may be the use of different IPC mechanisms for communication between processes within the OSs. As a result, it may be difficult to provide inter-process communication between a process running within a mobile OS and a process running in a desktop OS, where the mobile OS and desktop OS are running on the same shared kernel as illustrated in <figref idref="DRAWINGS">FIG. 7</figref>. A solution provided by various embodiments described above uses a single IPC transport mechanism with support provided for the single IPC transport mechanism in both the mobile OS and desktop OS. The embodiments described below provide an alternative solution using an IPC translation mechanism within one of the mobile OS or desktop OS to translate IPC calls from a first IPC transport mechanism to a second IPC transport mechanism. It may be possible using this technique to provide a solution for inter-process communication between processes running within independent OSs that support different IPC mechanisms with fewer modifications to IPC libraries and/or applications.

0126<figref idref="DRAWINGS">FIG. 12</figref> illustrates computing environment <b>1200</b> that provides support for cross-environment inter-process communication using IPC translation, according to various embodiments. In computing environment <b>1200</b>, a first OS (e.g., mobile OS <b>130</b>) and a second OS (e.g., desktop OS <b>160</b>) run concurrently on shared kernel <b>320</b>. Processes within the first OS use a first IPC mechanism for inter-process communication. For example, the first IPC mechanism may include IPC library <b>1236</b> and a first IPC driver of IPC driver(s) <b>1221</b> in shared kernel. Processes within the second OS use a second, different IPC mechanism for inter-process communication. For example, the second IPC mechanism may include IPC library <b>1266</b> and a second IPC driver of IPC driver(s) <b>1221</b> in shared kernel <b>320</b>. In one of the first OS or the second OS, IPC calls are translated between the first IPC mechanism and the second IPC mechanism transparently such that processes in the two OSs see a direct IPC path to each other. In computing environment <b>1200</b>, IPC translator <b>1242</b> is part of remote communication service <b>1241</b> of mobile OS <b>130</b>. However, in other embodiments, IPC translation may be done in desktop OS <b>160</b>, or implemented in a different manner within mobile OS <b>130</b>.

0127To illustrate cross-environment inter-process communication using IPC translation, consider that mobile OS <b>130</b> uses a first IPC mechanism that is incompatible with a second IPC mechanism used by desktop OS <b>160</b>. Shared kernel <b>320</b> may include IPC driver(s) <b>1221</b> that support both the first IPC mechanism and the second IPC mechanism. This means that processes within mobile OS <b>130</b> may communicate with each other through shared kernel <b>320</b> using the first IPC mechanism, using calls to IPC library <b>1236</b> and IPC transport through a first IPC driver of IPC driver(s) <b>1221</b>. For example, applications <b>352</b> and <b>354</b> may communicate with service <b>1241</b> using the first IPC mechanism. Processes within desktop OS <b>160</b> may communicate with each other using the second IPC mechanism, for example using calls to IPC library <b>1266</b> and IPC transport through a second IPC driver of IPC driver(s) <b>1221</b>. For example, applications <b>382</b> and <b>384</b> may communicate with each other over the second IPC mechanism.

0128In one embodiment, service <b>1241</b> is a remote communication service. Remote communication service <b>1241</b> provides a connection point for cross-environment IPC communication. For example, remote communication service <b>1241</b> may keep a directory or database of IPC communications. In the embodiments described above where a single IPC mechanism is used to communicate between applications in the first and second OS, the remote communication service establishes the link over the IPC mechanism between the applications by passing a reference to an IPC interface to each application. Once each application has a reference to an IPC interface, the applications effectively communicate through the instantiated IPC interface, without further involvement by the remote communication service. In this regard, the remote communication service acts as an IPC interface dealer, linking the applications through the instantiated IPC interfaces, which are then used by the applications to communicate across process boundaries in a thread-safe manner.

0129However, in embodiments where an application of the first OS uses a first IPC mechanism, and an application of the second OS uses a second IPC mechanism, the remote communication service maintains links to both applications through the different IPC mechanisms. The remote communication service then acts as an end-point for IPC communications from each application, and IPC translator <b>1244</b> translates the IPC calls between the two different and incompatible IPC mechanisms. The IPC translation occurring in the remote communication service is transparent to the applications which see the endpoint in the remote communication service as if it were the other party.

0130Consider, as an example, a first application (e.g., word processing application) running in an Android mobile OS and a second application (e.g., also a word processing application) running on a Linux OS, where the Linux and Android OSs run concurrently on a shared kernel. As with other Android applications, the first application has access to the Binder IPC mechanism within Android for inter-process communication (i.e., for communication to Android services). The Linux OS supports IPC but through different IPC mechanisms than Binder (e.g., unix domain sockets, UDP, etc.). The shared kernel supports communication using both Binder and the other IPC mechanisms of the Linux OS. Using IPC transport and IPC translation as described above, the first application can communicate with the second application through the remote communication service with IPC translation between Binder and a second IPC mechanism taking place in the IPC translator of the remote communication service.

0131<figref idref="DRAWINGS">FIG. 13</figref> illustrates process flow <b>1300</b> for cross-environment communication using IPC translation, according to various embodiments. Process flow <b>1300</b> begins at block <b>1310</b>, where a first OS (e.g., mobile OS <b>130</b>) receives a first remote method call of a first inter-process communication type that includes a first data parcel. The first remote method call is directed to a first application running within the first OS through a first IPC channel (e.g., through IPC driver(s) <b>1221</b>) from a second application, the second application running within a second OS (e.g., desktop OS <b>160</b>), the first and second operating systems running concurrently on a shared kernel. At block <b>1312</b>, the first OS translates the first remote method call into a second remote method call of a second inter-process communication type, the second remote method call including a second data parcel. At block <b>1314</b>, the first OS sends the second remote method call through a second inter-process communication channel to the first application. As illustrated by block <b>1316</b>, translating the first remote method call into the second remote method call may include unparceling the first data parcel and reparceling information of the first data parcel into the second data parcel of the second remote method call. As described above in reference to <figref idref="DRAWINGS">FIG. 12</figref>, IPC translation may be done within a service of the first OS. Alternatively, IPC translation may be done within a different component of the first OS or within the second OS.

0132Process flow <b>1300</b> describes IPC transport and translation of a remote method call from a second application running in a second OS to a first application running in a first OS. The IPC translator can similarly perform IPC translation for a reply message from the first application to the second application. For example, the remote method call may include a reply parameter or reply parcel. The second application may pass a remote method call return of the second inter-process communication type and the IPC translator may translate the return call to the first inter-process communication type for reception by the first application. The translation may include translating parameters and/or unparceling and reparceling data included in the IPC reply.

0133In embodiments, the IPC translator may translate between synchronous and asynchronous IPC calls. For example, the IPC translator may receive an asynchronous IPC call through a first IPC mechanism and translate the IPC call to a second, synchronous IPC call of a second IPC mechanism. The IPC translator may receive the return from the second, synchronous IPC call such that the IPC handling in the receiving process of the IPC call is unchanged. In various instances, the IPC translator may be able to translate between a synchronous call from a first process to an asynchronous call in a second process. For example, where the first process does not expect or operate on a return parcel, the IPC translator may be able to pass data from a first process using a synchronous IPC call to a second process using an asynchronous IPC call.

0134IPC transport and IPC translation may be used in a process flow similar to process flow <b>1300</b> to make a remote method call from the first application to the second application. Specifically, the first application may make a remote method call of the second inter-process communication type that is translated by the IPC translator and received in the second application as a remote method call of the first inter-process communication type. Accordingly, remote method calls may be performed from the first application to the second application or from the second application to the first application using different IPC mechanisms through the IPC translator.

0135In the embodiments described above, the remote communication service instantiates a generic IPC interface to link two applications. In other words, the remote communication service establishes the IPC link between applications but does not determine the purpose of the IPC communication or the information passed between applications including the structure of the parcel data that may be passed through the IPC interface. Further embodiments are directed to establishing an application programming interface through which categories of applications can communicate through category-specific remote communication calls. These embodiments may be employed whether the IPC communications take place over a single IPC mechanism as illustrated in <figref idref="DRAWINGS">FIGS. 7-11</figref> or use the IPC transport with IPC translation embodiments illustrated in <figref idref="DRAWINGS">FIGS. 12 and 13</figref>.

0136<figref idref="DRAWINGS">FIG. 14</figref> illustrates computing environment <b>1400</b> that uses an application programming interface layer to extend IPC interfaces to provide category specific remote communication calls, according to various embodiments. Computing environment <b>1400</b> includes similar components as computing environments <b>700</b> and <b>1200</b> illustrated above. Specifically, in computing environment <b>1400</b>, mobile OS <b>130</b> and desktop OS <b>160</b> are running concurrently on shared kernel <b>320</b> of a mobile device. Applications <b>352</b> and <b>354</b> are running within mobile OS <b>130</b>, and applications <b>382</b> and <b>384</b> are running within desktop OS <b>160</b>. Mobile OS <b>130</b> includes remote communication service <b>1441</b> that manages IPC links, meaning that it passes references to IPC interfaces to requesting applications to link applications together over a common IPC interface. Computing environment <b>1400</b> also includes an application communication API <b>1458</b> within mobile OS <b>130</b>, and an application communication API <b>1488</b> within desktop OS <b>160</b>.

0137The application communication APIs of computing environment <b>1400</b> may be in application space within the first and/or second OS. For example, API <b>1458</b> could be implemented as a runtime library of mobile OS <b>130</b>. In one embodiment, API <b>1458</b> is implemented as a JAR file for a Dalvik runtime environment of an Android mobile OS. In other embodiments, the application communication APIs of computing environment <b>1400</b> may be within user libraries or other libraries accessible to applications of the OS. For example, in one embodiment, API <b>1488</b> of desktop OS <b>160</b> is implemented as a shared user library in a Linux OS.

0138Application communication API <b>1458</b> of mobile OS <b>130</b> provides category specific remote calls that extend generic IPC interfaces as proxies (calls to another process) and sinks (calls from another process). Application communication API <b>1488</b> of desktop OS <b>160</b> provides corresponding remote calls (i.e., proxies that correspond to sinks within the other party). For example, API <b>1458</b> of mobile OS <b>130</b> may include sinks and proxies for a specific request of a specific category of application that perform all functionality required to request an IPC interface object <b>1442</b> from remote communication service <b>1441</b>, and parcel data to the IPC interface object in a format tailored for the specific request.

0139The APIs may include remote calls for any category of application for which communication between applications may be desirable. This may include communication between applications running within the same OS, or cross-environment communication between applications running on separate and independent OSs. For example, categories of remote calls in APIs <b>1458</b> and <b>1488</b> may include browser applications, office productivity applications, email clients, games, location-enabled applications (e.g., GPS-enabled), augmented reality applications, and/or any other category for which communication between applications may provide a more seamless computing experience. API <b>1458</b> may be used by an application running on mobile OS <b>130</b> for communication with another application running on mobile OS <b>130</b>, or for communication with applications running on desktop OS <b>160</b> through API <b>1488</b>.

0140Consider that an application may be running on the mobile OS and the user may be interacting with the application through the user environment of the mobile OS while the mobile device is not docked. Through this user interaction, the application may acquire a particular application state (e.g., settings, views, and application data). The user then docks the mobile device with a secondary terminal environment. When the mobile computing device is docked, the desktop OS is associated with the secondary terminal environment. The user may desire to resume interaction, using an application of the desktop OS, with the application data and at the particular application state where the user left off with the corresponding application of the mobile OS. For example, the user may be using a spreadsheet application on the mobile OS before it is docked. When the user docks the mobile device the user may wish to open a spreadsheet program of the desktop OS through the secondary terminal environment and pick up in that program where they left off in the mobile spreadsheet application. The user may desire to do this without closing the file they are working on in the mobile spreadsheet application and re-opening the file using the desktop spreadsheet application. This requires communication between the mobile application and the desktop application of application data and application state information.

0141To provide this user experience, APIs <b>1458</b> and <b>1488</b> may include proxies and sinks for standard communication methods of spreadsheet applications to enable seamless transition of user data from a spreadsheet application running in the first OS (e.g., mobile OS) to a spreadsheet application running in the second OS (e.g., desktop OS). Specifically, API <b>1458</b> may provide sinks that receive requests for spreadsheet application state information and proxies that request spreadsheet application state information from remote sinks For example, spreadsheet application state information may include application characteristics such as file name, sheet, active cell, and current sheet data. API <b>1488</b> includes corresponding proxies and sinks for desktop OS applications.

0142<figref idref="DRAWINGS">FIG. 15</figref> illustrates a computing environment <b>1500</b> that implements application communication APIs to provide app-to-app communication, according to various embodiments. In one example illustrated in <figref idref="DRAWINGS">FIG. 15</figref>, a process <b>1510</b> on the desktop OS (e.g., a process of an application running on desktop OS <b>160</b>) talks to a handler implemented in the mobile OS using an application communication API. In this example, the first process <b>1510</b>, running on the desktop OS, instantiates remote communications sink <b>1512</b> (e.g., using application communication API <b>1488</b> of the desktop OS). A handler process <b>1530</b> of the remote communication service of the mobile OS instantiates a proxy <b>1534</b> for communication to sink <b>1512</b> (e.g., using application communication API <b>1458</b> of the mobile OS). As illustrated in <figref idref="DRAWINGS">FIG. 15</figref>, handler process <b>1530</b> implements a handler <b>1536</b> for the mobile OS framework <b>1540</b>.

0143Also illustrated in <figref idref="DRAWINGS">FIG. 15</figref>, a second process <b>1520</b> running within desktop OS (e.g., a process of the same application as process <b>1510</b>, or of another application running on the desktop OS) communicates with processes of the mobile OS through proxies and sinks using the application communication API layers. Notably, as illustrated in <figref idref="DRAWINGS">FIG. 15</figref>, multiple proxies may call into the same sink. Specifically, proxy <b>1524</b> of process <b>1520</b>, and proxy <b>1514</b> of process <b>1510</b>, both call into sink <b>1532</b> of mobile OS process <b>1530</b>. Also as illustrated in <figref idref="DRAWINGS">FIG. 15</figref>, proxy <b>1534</b> of mobile OS process <b>1530</b> calls into sink <b>1522</b> of desktop OS process <b>1520</b>. Desktop OS process <b>1520</b> also communicates with mobile OS process <b>1550</b> through proxy <b>1528</b>, which makes calls into sink <b>1554</b>, and sink <b>1526</b>, which receives calls from proxy <b>1552</b>.

0144In computing environment <b>1500</b>, remote communication service <b>1441</b> of mobile OS <b>130</b> maintains a database hold on remote communication sinks instantiated through application communication APIs. Remote communication service <b>1441</b> maintains an IPC interface database <b>1542</b> with holds on each sink(s) <b>1544</b>. Any application, running on mobile OS <b>130</b> or desktop OS <b>160</b>, can query a sink and make calls to the sink using a local proxy.

0145<figref idref="DRAWINGS">FIG. 16</figref> illustrates process flow <b>1600</b> for app-to-app communication through an application communication API, according to various embodiments. In process flow <b>1600</b>, one or more applications running on mobile OS <b>130</b> or desktop OS <b>160</b> may establish a link between a proxy in one application and a sink in another application for passing application state information and/or application data. In process flow <b>1600</b>, one or more applications instantiate proxies and sinks for remote communication. When an application instantiates a proxy or sink it is registered with the remote communication service of the mobile OS under the application name. In embodiments, the application name includes a root name (e.g., SPREADSHEET) that provides a key for the remote communication service to link proxies and sinks in the API context.

0146At block <b>1620</b> of process flow <b>1600</b>, one or more application(s) <b>1602</b> begin execution. Application(s) <b>1602</b> may be one or more mobile OS applications (running within the mobile OS) and/or desktop OS applications (running within the desktop OS). At block <b>1622</b>, an application instantiates a proxy <b>1644</b> of proxy class <b>1604</b> within application context <b>1640</b> for a remote communication request. At block <b>1624</b>, an application instantiates a sink <b>1646</b> of sink class <b>1606</b> within application context <b>1640</b> for a remote communication request. As a result, in the mobile OS API context, name sink class <b>1608</b> and mobile OS sink class <b>1610</b> associate the sink with a key at block <b>1628</b>. For example, the mobile OS sink class <b>1610</b> may associate the sink with a name key provided by the application.

0147At block <b>1630</b> of process flow <b>1600</b>, an application connects the proxy <b>1644</b> to a sink to provide remote communication of application data and/or application state. At block <b>1632</b>, the mobile OS proxy class <b>1612</b> registers the interface of the proxy with the named sink. At block <b>1634</b>, library state class <b>1614</b> of the mobile OS API context establishes a connection to the remote communication service, which maintains a database hold on sinks At block <b>1636</b>, the proxy is registered through the remote communication service to establish a link to the sink. Upon registration at block <b>1638</b>, the IPC interface of the sink is being pushed by the remote communication service. At block <b>1640</b>, the mobile OS sink class accepts the IPC interface and at block <b>1642</b>, the proxy is linked through the IPC interface to the sink. Notably, the API context provides the underlying registration and passing of IPC interfaces such that the applications do not need to be concerned with the underlying IPC transport. The application instantiates a proxy for a specific request of a named application and receives the requested data through the proxy.

0148Process flow <b>1700</b> of <figref idref="DRAWINGS">FIG. 17</figref> illustrates further aspects of app-to-app communication through an API, according to various embodiments. Process flow <b>1700</b> illustrates app-to-app communication through the API layers in response to an event. Process flow <b>1700</b> also illustrates unregistering of a proxy-sink interface. At block <b>1702</b> of process flow <b>1700</b>, an incoming message is received over an IPC interface to a sink. This message invokes the remote method handler of the API sink class <b>1610</b> at block <b>1704</b>. The remote method handler identifies the sink through the name sink class <b>1608</b> and makes a virtual function call into the sink at block <b>1706</b>. This part of process flow <b>1700</b> illustrates that the API context handles the IPC transport including receiving the IPC call through the instantiated IPC interface. In the application context, the sink receives a virtual function call from the API context.

0149Blocks <b>1710</b>, <b>1712</b>, <b>1714</b>, and <b>1716</b> illustrate unregistering a sink through the API. At block <b>1710</b>, an event within an application results in the application unregistering proxies and/or sinks of the application. One event that may cause an application to unregisters proxies and/or sinks is exiting, as shown in block <b>1710</b>. At block <b>1712</b>, the proxy class in application context <b>1650</b> is disconnected from connected sinks Block <b>1714</b> shows the proxy being unregistered from a sink. At block <b>1716</b>, the API calls into the IPC interface. On the remote side, this call will unregister the proxy (i.e., the remote communication service will unregister the proxy in the database hold on sinks)

0150<figref idref="DRAWINGS">FIG. 18</figref> illustrates process flow <b>1800</b> for communication through an application communication API, according to various embodiments. Method <b>1800</b> begins at block <b>1802</b>, where a first application, running within a first OS (e.g., mobile OS), instantiates a method of an application programming interface of the first operating system, the method implementing a sink for a predetermined remote communication request. At block <b>1804</b>, the method of the application programming interface requests an extended inter-process communication interface. At block <b>1806</b>, the first operating system instantiates the extended inter-process communication interface. At block <b>1808</b>, the first operating system registers the extended inter-process communication interface to receive the predetermined remote communication requests directed to the first application. At this point, the instantiated sink is available to receive requests from corresponding proxies of applications running in the first or the second OS.

0151At block <b>1810</b>, the first operating system receives a request to instantiate a proxy for the predetermined remote communication request within a second application running within a second operating system, the first and second operating systems running concurrently on a shared kernel. At block <b>1812</b>, the first operating system passes a reference to the extended inter-process communication interface to the second application. At this point the proxy in the second application is linked to the sink of the first application and requests through the proxy will be received and processed by the sink of the first application.

0152As described above, in one embodiment an Android mobile OS and a Linux desktop OS (“Hydroid”) run concurrently on the same shared kernel of a single mobile computing device. The Android mobile OS provides a mobile computing experience through mobile computing hardware and the Linux desktop OS provides a desktop computing experience through a secondary terminal environment having a user experience profile associated with the Linux OS. However, other OS combinations are contemplated as within various embodiments of the invention. For example, various aspects of the invention may be used to run Windows Mobile and Windows 7 on a shared kernel or sharing common kernel-mode processes. As another example, iOS and Mac OS X running on a shared kernel is also within the scope of various embodiments. Furthermore, aspects of the invention may be used advantageously by combinations of embedded OSs and desktop or mobile OSs running on a shared kernel.

0153The foregoing description has been presented for purposes of illustration and description. Furthermore, the description is not intended to limit embodiments of the invention to the form disclosed herein. While a number of exemplary aspects and embodiments have been discussed above, those of skill in the art will recognize certain variations, modifications, permutations, additions, and sub-combinations thereof.

0154The various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and/or software component(s) and/or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor.

0155The various illustrative logical blocks, modules, and circuits described may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array signal (FPGA), or other programmable logic device (PLD), discrete gate, or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

0156The steps of a method or algorithm described in connection with the present disclosure, may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in any form of tangible storage medium. Some examples of storage media that may be used include random access memory (RAM), read only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM and so forth. A storage medium may be coupled to a processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. A software module may be a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across multiple storage media.

0157The methods disclosed herein comprise one or more actions for achieving the described method. The method and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of actions is specified, the order and/or use of specific actions may be modified without departing from the scope of the claims.

0158The functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions on a tangible computer-readable medium. A storage medium may be any available tangible medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other tangible medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray® disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

0159Thus, a computer program product may perform operations presented herein. For example, such a computer program product may be a computer readable tangible medium having instructions tangibly stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. The computer program product may include packaging material.

0160Software or instructions may also be transmitted over a transmission medium. For example, software may be transmitted from a website, server, or other remote source using a transmission medium such as a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology such as infrared, radio, or microwave.

0161Further, modules and/or other appropriate means for performing the methods and techniques described herein can be downloaded and/or otherwise obtained by a user terminal and/or base station as applicable. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can be provided via storage means (e.g., RAM, ROM, a physical storage medium such as a CD or floppy disk, etc.), such that a user terminal and/or base station can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

0162Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Also, as used herein, including in the claims, “or” as used in a list of items prefaced by “at least one of” indicates a disjunctive list such that, for example, a list of “at least one of A, B, or C” means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Further, the term “exemplary” does not mean that the described example is preferred or better than other examples.

0163Various changes, substitutions, and alterations to the techniques described herein can be made without departing from the technology of the teachings as defined by the appended claims. Moreover, the scope of the disclosure and claims is not limited to the particular aspects of the process, machine, manufacture, composition of matter, means, methods, and actions described above. Processes, machines, manufacture, compositions of matter, means, methods, or actions, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein may be utilized. Accordingly, the appended claims include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or actions.