WO2015163938A1 - Hybrid installation application package files for multi-operating system environment - Google Patents

Abstract

Aspects of the invention provide a computing device that includes a first installer, executing within one or more native runtime environments, that responds to a native application package file, e.g., downloaded to or stored on the device, by installing for execution under the native operating system an app contained in that native application package file. A second installer, executing within one of hosted runtime environments, responds to a hosted application package file, e.g., downloaded to or stored on the device, by installing for execution under the hosted operating system an app contained in that hosted application package file. Functionality executing in connection with the first installer responds to a hybrid application package file, e.g., downloaded to or stored on the device, by notifying the second installer of a hosted application package file contained therein and by making that hosted package file accessible to that second installer, where the hybrid application package file comprises that hosted application package file contained within a native application package file.

Description

Hybrid Installation Application Package Files for Multi-Operating System Environment

BACKGROUND OF THE INVENTION

This application claims the benefit of priority of United States Patent Application Serial No. 61/984,539, filed April 25, 2014, entitled HYBRID INSTALLATION APPLICATION PACKAGE FILES FOR MULTI-OPERATING SYSTEM, the teachings of which are incorporated herein by reference.

The invention pertains to digital data processing and, more particularly, to methods and apparatus for executing on a single hardware/software platform applications ("apps") made for execution on multiple different such platforms. The invention has application in supporting cross-platform compatibility among apps for smart mobile devices, e.g., smart phones, tablet computers, set-top boxes, connected televisions, in-vehicle infotainment systems, or in-flight entertainment systems, and the like, all by way of non-limiting example.

The smart mobile device market has grown nearly 40% in the past year, according to analysts. This has been fueled, to a large degree, by the sale of devices running variants of the open-source Linux and Android operating systems. While a boon to the marketplace, those devices suffer as a result of the lack of cross- compatibility of the apps developed for them. Thus, for example, apps developed for mobile devices running the Meego operating system do not run on those executing the Tizen or Android operating systems. That problem is compounded, of course, when one turns to operating systems of entirely different lineages. For example, apps developed for Tizen do not run on those running WebOS or Windows OS, and so forth.

This is not just a problem for consumers who have purchase new mobile devices that lack compatibility with old apps. It is also a problem for manufacturers, carriers and others in the supply chain whose efforts to deliver new hardware/software platforms are stymied by the lack of a large ecosystem of available apps. App developers, too, suffer from fragmentation in the marketplace, since they may be forced to port apps to a variety of platforms in order to establish or maintain product viability.

A few prior art efforts to resolve cross-compatibility issues have met with limited success. For example, Acer's Aspire One supported dual boot modes: one for Windows OS and one for Android. However, the device could not run apps for both operating systems in a single mode.

In view of the foregoing, an object of the invention is to provide improved systems and methods for digital data processing.

Another, more particular, object is to provide such systems and methods as support executing on a single hardware/software platform applications ("apps") made for execution on multiple different hardware/software platforms.

Still another object is to provide such systems and methods as support cross- platform compatibility among apps for smart mobile devices, e.g., smart phones, tablet computers, set-top boxes, connected televisions, in-vehicle infotainment systems, or in-flight entertainment systems and the like, all by way of non-limiting example.

These and other objects are evident in the text that follows and in the drawings.

SUMMARY OF THE INVENTION

The foregoing are among the objects attained by the invention, which provides in some aspects a computing device that includes a central processing unit that executes a native operating system including one or more native runtime environments within which native software applications are executing, where each such native software application has instructions for execution under the native operating system. One or more hosted runtime environments execute within the one or more native runtime environments, each of which hosted runtime environments executes hosted software applications that have instructions for execution under a hosted operating system that differs from the native operating system.

A first installer, executing within one of the native runtime environments, responds to a native application package file, e.g., downloaded to or stored on the device, by installing for execution under the native operating system an app contained in that native application package file. A second installer, executing within one of the hosted runtime environments, responds to a hosted application package file, e.g., downloaded to or stored on the device, by installing for execution under the hosted operating system an app contained in that hosted application package file.

Functionality executing in connection with the first installer responds to a hybrid application package file, e.g., downloaded to or stored on the device, by notifying the second installer of a hosted application package file contained therein and/or by making that hosted package file accessible to the second installer, where the hybrid application package file comprises a native application package file that contains a hosted application package file.

Related aspects of the invention provide a mobile device, e.g., as described above, in which a first native software application executing within the one or more native runtime environments defines the one or more hosted runtime environments within which the hosted software applications are executing. The first installer effects execution of any of an app, script or other code (collectively, "script") supplied with the hybrid application package file in order to detect a presence of the first native software application on the device.

Further related aspects of the invention provide a mobile device, e.g., as described above, in which the script responds to an absence of the first native software application on the device by effecting any of download and installation of that first native software application thereto.

Other related aspects of the invention provide a mobile device, e.g., as described above, in which hosted apps execute within the one or more hosted runtime environments utilizing theming consistent with that of native apps executing within the one or more native runtime environments. Related aspects of the invention provide such a mobile device in which such consistency of theming is effected by the first native software application.

Further aspects of the invention provide methods for operating a computing device of the type described above.

Still other aspects of the invention provide a method of operating a digital data processing system including the steps of storing a hosted application package file to a native application package file-in-creation; storing to the package file-in-creation a manifest file for the native operating system based on information in a manifest file contained in the hosted application package file for the hosted operating system; creating a hybrid application package file by storing to the package file-in-creation any of an app, script or other code (collectively, "script") to detect a presence of the selected native software application on a device on which that script is executed.

Further aspects of the invention provide a digital data processing system operating in accord the foregoing method.

The foregoing and other aspects of the invention are evident in the drawings and in the description that follows. BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the invention may be attained by reference to the drawings, in which:

Figures 1 A-1 C depict a computing device of the type embodying the invention;

Figure 2 depicts a native operating system of the type executing in the device of Figure 1 ;

Figure 3 depicts one or more hosted runtime environments defined by a native software application for execution of hosted software applications in the device of Figure 1 ;

Figure 4 depicts the interaction of components in launching an exemplary hosted software application based on user interaction with that application's launch proxy executing in a native runtime environment, displaying an application window representing operation of the hosted software application via that application's IO proxy, and transmitting user input from that proxy back to the hosted application; and

Figure 5 a digital data processing apparatus and method for creating hybrid application package file according to the invention.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT

Architecture

Figure 1A depicts a computing device 10 of the type embodying the invention. The illustrated device 10 includes a central processing unit (CPU), input/output (I/O), memory (RAM) and nonvolatile storage (MEM) subsections of the type commonly provided computing devices of the type commercially available in the marketplace, all as adapted in accord with the teachings hereof. In the illustrated embodiment, the device 10 comprises a mobile computing device, such as a smart phone or tablet computer, though, in other embodiments it may comprise other computing devices, mobile or otherwise, e.g., a set-top box, connected television, in-vehicle infotainment system, or in-flight entertainment system, just to name a few.

The device 10 may be connected permanently, intermittently or otherwise to one or more other computing devices, servers, or other apparatus capable of digital communications (not shown) by a network, here, depicted by "cloud" 12, which may comprise an Internet, metropolitan area network, wide area network, local area network, satellite network, cellular network, point-to-point network and/or a combination of one or more of the foregoing, in the conventional manner known in the art, as adapted in accord with the teachings hereof.

The CPU of device 10 (e.g., in conjunction with the I/O, RAM and/or MEM subsections) executes a native operating system 14 of the type commercially available in the marketplace, as adapted in accord with the teachings hereof. Examples of such operating systems include the Meego, Tizen, Android, WebOS, and Linux operating systems, to name just a few. More generally and/or in addition, the native operating system 14 can be a Linux-based operating system, such as, by way of nonlimiting example, an Android-based operating system. Native Runtime Environment(s)

Figure 2 depicts a native operating system 14 of the type executing on illustrated device 1 0 of Figure 1 .

Referring to that drawing, the native operating system 14 defines one or more native runtime environments 1 6 of the type known in the art (as adapted in accord with the teachings hereof) within which native software applications of the type known in the art (as adapted in accord with the teachings hereof)— i.e. , applications having instructions for execution under the native operating system— are executing. Such applications are labeled 1 5, 1 8 and 46-52 in the drawing. As used here and elsewhere herein, the terms "application" and "app" are used interchangeably.

The native runtime environment(s) 1 6 may comprise one or more virtual machines or otherwise, as is conventional in the art (as adapted in accord with the teachings hereof), depending on the native operating system 14 and the specifics of its implementation on device 1 0. Illustrated native runtime environment 1 6 includes, by way of nonlimiting example, application resources 1 8 and runtime libraries 20, all of the type known in the art, as adapted in accord with the teachings hereof. That runtime environment 1 6 also includes a kernel 24 of the type known in the art, as adapted in accord with the teachings hereof.

Kernel 24 (or alternate functionality provided in the runtime environment(s) of alternate embodiments) serves inter alia as an interface, in the conventional manner known in the art has adapted in accord with the teachings hereof, between CPU 1 2 (and, more typically, the native applications executing within the native runtime environment 1 6 executing thereon) and hardware devices 24-30 integral or attached to device 1 0. This includes display/touch screen 24 and the frame buffer 26 that drive displays thereon in the conventional manner known in the art, as adapted in accord with the teachings hereof. This can also include, by way of non-limiting example, a keyboard, trackball, touch stick, other user input devices, and/or other integral or peripheral devices of the type known in the art. In the discussion that follows, the display/touch screen 24, the frame buffer 26, and other integral/peripheral devices supporting interactions between the device 10 and its user are referred to as a "hardware interface," regardless of whether they comprise hardware, software or (as is more typically the case) a combination thereof.

A native software application 18, referred to, here, without limitation, as the "Applications Control Layer" or "ACL", executing within the one or more native runtime environments 16 defines one or more hosted runtime environments within which hosted software applications are executing. Each such hosted software application has instructions for execution under a hosted operating system that differs from the native operating system.

Native software applications 46-52 are proxies of hosted software applications 34, 36. Particularly, in some embodiments, hosted software applications executing in hosted runtime environment 32 may have multiple corresponding proxies executing in the native runtime environment 16: a launch proxy and an IO proxy. Here, for illustrative purposes, hosted software application 34 is shown as having a launch proxy 46 and an IO proxy 50. Hosted software application 36 is likewise shown as having a launch proxy 48 and an IO proxy 52. Although, both launch and IO proxies are used in the illustrated embodiment, in other embodiments hosted software applications may have corresponding proxies of only one type (e.g., IO or launch) or otherwise; and, in other embodiments, one or more of the hosted software applications may have no such proxies.

Hosted Runtime Environment(s)

The hosted operating system can be, for example, a Linux-based operating system, such as, by way of nonlimiting example, an Android-based operating system. The native operating system 14 can likewise be, for example, a Linux-based and/or Android-based operating system, albeit, of a different "flavor" than that of the hosted operating system. By way of more particular example, where the native operating system 14 comprises one of the aforementioned Tizen, WebOS, Linux operating systems (as adapted in accord with the teachings hereof), by way of nonlimiting example, the hosted operating system can comprise a "flavor" of the commercially available Android operating system (as adapted in accord with the teachings hereof), again, by way of nonlimiting example.

In some embodiments of the invention, the hosted runtime environments 32 are initialized, e.g., by default, by native software application (ACL) 18, or otherwise, so that theming of apps executing thereunder are consistent with those executing under the native runtime environments 16. Such consistency can be achieved through setting of one and, preferably, more of the following parameters:

Color palette

Element size

Fonts

Padding

Tabs

Scroll bars

Lists

Spinners

Buttons

Text fields

Seek bars and sliders

Progress bars

Check boxes

Radio buttons

On / Off switches

Dialogs

Mapping of hard buttons

Activity indicators

Alerts

Popups Pickers

Soft buttons / soft button bar

The keyboard

Figure 3 depicts one or more hosted runtime environments 32 defined by the native software application 18 (or ACL) for execution of hosted software applications 34, 36 in the device 10 according to the invention. The illustrated hosted runtime environment 32 is of the type known in the art (as adapted in accord with the teachings hereof) within which software applications having instructions for execution under the hosted operating system (i.e., hosted software applications) are built and intended to be executed.

The hosted runtime environment(s) 32 may comprise one or more virtual machines or otherwise, as is conventional in the art (as adapted in accord with the teachings hereof), depending on the type of the hosted operating system and the specifics of its implementation within the runtime environments 32. Illustrated hosted runtime environment 32 is intended for executing Android-based software applications 34, 36 (though, other embodiments may be intended for executing applications designed and built for other operating systems) and includes, by way of non-limiting example, a resource framework 38, virtual machines (VMs) 40, event handler 42 and run-time libraries 44, all by way of non-limiting example and all of the type known in the art, as adapted in accord with the teachings hereof.

The illustrated runtime environment 32 does not include a kernel per se (as might normally be included, for example, in the runtime environment of a Linux- /Android-based operating system) in the sense of running operations in a protected, kernel space of the type known in the art. Instead, some such operations (e.g., operations that might normally be included, for example, in the kernel of a Linux- /Android-based operating system) are executed in user space.

By way of example, are those kernel space operations relied upon by the resource framework 34, virtual machines (VMs) 36, event handler 42, run-time libraries 44, and/or other components of the runtime environment 32 to load graphics to a frame buffer for presentation on a display. Rather than executing in a kernel of hosted runtime environment 32, in the illustrated embodiment those operations are elevated to user space and are employed to load such graphics to a "virtual" frame buffer 54, which (as discussed below) is shared with the native runtime environment 16 and the applications executing there— particularly, the I/O proxy applications 50, 52.

The execution of other such kernel-space operations can be avoided by passing-off to native operating system 14 and its runtime environment 16 operations and, more broadly, functions required for execution of hosted software applications 34, 36 that would otherwise be performed within the runtime environment 32 and, specifically, for example by a kernel thereof.

Such passing-off, in the illustrated embodiment, is effected, for example, by the resource framework 34, virtual machines (VMs) 36, event handler 42, run-time libraries 44, and/or other components of the runtime environment 32, which communicate with and/or otherwise rely on the native software application proxies 46-52 (executing in runtime environment 16) of hosted software applications 34, 36 to perform such functions or alternates thereof.

A further appreciation of the foregoing maybe attained through the discussion that follows and elsewhere herein, as well as within the incorporated-by-reference applications identified below.

Native and Hosted Software Application Installation

Native software applications, e.g., 15 and 18, are installed (upon direction of the user or otherwise) on device 10 and, more particularly, for execution within native runtime environments 16, in the conventional manner of the art for installations of apps within operating systems of the type of operating system 14. Such installation typically involves cooperative action of native operating system 14 and the runtime environments 16 executing an "installer" app (not shown) of the type conventional to OS 14 and typically includes unpacking, from an application package file (e.g., downloaded from a developer site or otherwise), the to-be-installed application's executable file, icon file, other support files, etc., and storing those to designated locations in static storage (MEM) on device 10, again, in the conventional manner known in the art, as adapted in accord with the teachings hereof. Such application package files are referred to herein as "native" application package files.

Hosted software applications 34, 36 are installed (upon direction of the user or otherwise) under control of ACL 18 for execution under hosted runtime environments 32. To that end, the ACL 18 can utilize an installer app the type conventional to the hosted operating system, albeit, modified to unpack from the application package files, or otherwise, the to-be-installed application's executable file, icon file, other support files, etc., to suitable locations in static storage (MEM) on device 10, e.g., locations dictated by native operating system 14, yet, consistent with the hosted operating system, or otherwise. Such application package files are referred to herein as "hosted" application package files.

Unlike other native software applications, e.g., 15 and 18, the native software applications 46-52, if any, that are proxies of a hosted software application 34, 36 are installed, by request from ACL 18 to native operating system 14, in connection with the installation by ACL 18 of each respective hosted software application. Each such proxy 46-52 is installed by the native operating system 14 in the conventional manner, albeit, from application package files (or otherwise) generated by ACL's 18 proxy installer interface 62.

Those package files can include, in lieu of the respective hosted software application 34, 36 executable, a "stub" executable suitable for

(ii) execution under native operating system 14 and, particularly, within native runtime environments 16,

(ii) effecting the functions discussed below (and elsewhere herein) attributable to the launch proxies and the IO proxies, respectively. Those package files can also include icon files that are identical to or variants of those originally supplied with the application package files (or otherwise) for the respective hosted software applications 34, 36. Although, in the illustrated embodiment, two proxies may be associated with each hosted software application, only a single icon is associated with both proxies as displayed on the graphical desktop, e.g., of Figure 1 A.

Multi-Operating System Mobile and Other Computing Devices

The computing device 10 supports the seamless execution of applications of multiple operating systems— or, put another way, it merges the user experience so that applications executed in the hosted runtime environment appear, to the user, as if they are executing within the native operating system 14.

Thus, for example, application windows representing execution of the hosted software applications are presented to the user without interfering with the status bar that forms part of the "desktop" generated as part of the overall graphical user interface by the native operating system 14 and/or native runtime environment 16, thus, making the hosted software applications appear similar to native software applications. This is shown, by way of example, in Figures 1A-1 C.

Referring to Figure 1 A, the native operating system 14 drives the computing device to display, on display/touch screen 24, a graphical desktop with icons 58 representing applications that can be selected for launch or other activation by the user of the device 10. In the illustrated embodiment, these can be native software applications, e.g., 15, and hosted software applications, e.g., 34, 36.

That desktop display includes a status bar 56 of the type conventional in the art — and, particularly, conventional to native operating system 14 (although, some embodiments may vary in this regard). Here, that status bar 56 indicates the current date/time, carrier conductivity signal strength (e.g., Wi-Fi, cellular, etc.), active apps, and so forth, though, in other embodiments, it may indicate other things. Referring to Figure 1 B, when a native software application, e.g. 15, is activated by the operating system 14 and/or runtime environments 16 in response to user selection, the application window 60 generated for it by the native runtime environment 16 (reflecting execution of the application) for presentation on the screen 24 occupies that screen along with the status bar 56— here, particularly, with the status bar 56 on the top fraction of the screen and the application window 60 on the remainder. Put another way, the operating system 14 and/or runtime environments 16 do not overwrite the status bar 56 with the applications window 60. (Of course, it will be appreciated that this is the default mode of operation of the operating system 14 and/or runtime environments 16, and that in other modes, e.g., so called "full screen" modes, the application window 60 may occupy the entirety of the screen).

Referring to Figure 1 C, likewise, in the illustrated embodiment, when a hosted software application 34, 36 is activated, the application window generated for it (reflecting execution in the hosted runtime environments 32) is presented identically on the screen 24 as that of a native software application— that is, it is presented without overwriting the status bar 56 (e.g., at least when displaying in default mode).

Another example of the illustrated computing device's 10 merging the user experience so that applications executed in the hosted runtime environment appear, to the user, as if they are executing within the native operating system 14 is the use of a common notification mechanism, e.g., that of the native operating system 14 and/or runtime environments 16, as discussed in the incorporated-by-reference applications identified below.

Still another example is the consistent activation of running software applications in response to user replies to notifications (and otherwise), whether they are native applications, e.g., 15, or hosted software applications 34, 36, Again, as identified by the incorporated-by-reference applications identified below.

Yet still another example is the use of consistent theming as between the hosted software applications and native software applications, as discussed above. Still other examples will be evident to those skilled in the art from the discussion that follows and otherwise.

Hosted Application Display in Multi-Operating System Mobile and Other Computing Devices

A further understanding of the operation of device 10 in these regards may be appreciated by reference to Figure 4, which depicts the interaction of the components discussed above in launching an exemplary hosted software application 34 (here, labelled "App 1 ") in hosted runtime environments 32 based on user interaction with that app's launch proxy 46 (here, labelled "App #1 Launch Stub") executing in native runtime environments 16, displaying an application window representing operation of hosted software application 34 via that app's IO proxy 50 (here, labelled "App #1 IO Stub"), and transmitting user input from that proxy 50 back to the app 34.

Prior to illustrated step 64, native runtime environments 16 (and/or native operating system 14) present on the above-described graphical desktop (see, e.g., Figure 1 A) icons 58 representing native and hosted software applications that can be selected for launch or other activation by the user of the device 10. As noted above, those icons are provided to native runtime environments 16 and/or native operating system 14 in connection with installation of the respective apps.

As per convention of operating systems of the type of native operating system 14, the native software application that is launch proxy 46 is launched by native runtime environments 16 and/or native operating system 14 upon its selection for activation by the user. See, step 64. Proxy 50 can be simultaneously launched by native runtime environments 16 and/or native operating system 14; alternatively, proxy 50 can be launched by proxy 46 upon its launch. Id.

Upon launch (or other notification of activation from native runtime environments 16 and/or native operating system 14), proxy 46 effects activation of corresponding hosted software application 34. See, step 66. In the illustrated embodiment, proxy 46 does this by transmitting a launch message to the event handler 42 that forms part of the hosted runtime environments 32 and that is common to the one or more hosted software applications 34, 36 (e.g., in that it is the common, shared recipient of system level-events, such as user input to the hardware interface, which events it distributes to appropriate hosted applications or other software executing in the hosted runtime environments 32 or provided as part of the hosted operating system). The launch message, which can be delivered to event handler 42 by proxy 46 using any convention mechanism for inter process communication (IPC), e.g., APIs, mailboxes, etc., includes an identifier of the proxy 46 and/or its corresponding hosted software application 34, as well as any other information required by the hosted operating system and/or hosted runtime environments 32 to effect launch of a hosted software application.

In step 68, the event handler 42 launches the hosted software application 34 in the conventional manner required of hosted operating system and/or the hosted runtime environments 32. Put more simply, that app 34 is launched as if it had been selected by the user of device 10 directly.

Following launch of hosted software application 34, event handler 42 uses IPC, e.g., as described above, to signal that hosted software application 34 has begun execution and, more aptly, to insure launch (if not already effected) and activation of proxy application 50 with the native runtime environments 16. See, step 70.

Following launch, hosted software application 34 runs in the conventional manner within hosted runtime environments 32 and makes such calls to the hosted resource framework 38, hosted event handler 42 and run-time libraries 44, all by way of non-limiting example, as it would otherwise make if it were installed on a device executing a single operating system of the type of the hosted operating system. This is advantageous in that it does not require special recoding (i.e., "porting") of the hosted software application 34 by the developer or publisher thereof in order to make it possible to run in the multi-operating system environment of device 10. Hosted resource framework 38, hosted event handler 42 and run-time libraries 44, and the other components of hosted runtime environments 32 respond to such calls in the conventional manner known of operating systems of the type of hosted operating system, except insofar as evident from the teachings herein. Thus, for example, as noted above, some such operations (e.g., those for loading frame buffers) of the type that might normally be executed in a privileged kernel space by hosted runtime environments 32 are, instead, executed in user space. And, other such operations or, more broadly, functions are passed-off to native operating system 14 and its runtime environment 16, e.g., via the proxies 46-52.

By way of example, in lieu of loading an actual frame buffer with graphics defining an applications window representing execution of the hosted software application 34, the hosted runtime environment 32 loads the virtual frame buffer 54 with such graphics. See, step 72. The hosted runtime environment 32 effects this through use of windowing subsystem that forms part of the hosted runtime environment 32 and that is common to the one or more hosted software applications 34, 36 (e.g., in that it is the common, shared system used by the hosted software applications for generating applications windows for display to the user of device 10.)

The IO proxy 50 of hosted software application 34 effects presentation on screen 24 of the applications windows generated for application 34 by hosted runtime environments 32, e.g., in the manner shown in Figure 1 C and discussed in connection therewith above. See, step 74. IO proxy 50 does this by transferring the graphics defining that applications window from virtual frame buffer 54 to the native frame buffer 26, e.g., using an API provided by native runtime environments 16 for such purpose or otherwise. Although in some embodiments, the hosted runtime environments 32 utilizes messaging to alert IO proxy 50 of the need for effecting such a transfer, e.g., when the window subsystem of hosted runtime environments 32 has generated an updated applications window for hosted software application 34, when hosted software application 34 becomes the active (or foreground) app in hosted runtime environments 32, or otherwise, in other embodiments IO proxy 50 effects such transfers on its own accord on a periodic basis or otherwise. User/ Hosted Application Interaction in Multi-Operating System Mobile and Other Computing Devices

10 proxy 50 utilizes a mechanism paralleling that discussed above in connection with steps 64-68 in order to transmit taps and other input made by the user to device 10 and specifically, for example, to display/touch screen 24, a keyboard, trackball, touch stick, other user input devices. In this regard, a common event handler (not shown) or other functionality of native runtime environments 16 notifies applications executing within them, including the IO proxies 50, 52, of user input made with respect to them via the touch screen 24 or those other input devices. Such notifications are made in the conventional manner known in the art of operating systems of the type of native operating system 14, as adapted in accord with the teachings hereof.

When IO proxy 50 receives such a notification, it transmits information with respect thereto to its corresponding hosted software application 34 via event handler 42, e.g., in a manner similar to that discussed above in connection with step 66. See, step 76. That information, which can be delivered to event handler 42 by IO proxy 50 using any conventional IPC mechanism, can include an identifier of the IO proxy 50 and/or its corresponding hosted software application 34, an identifier of the device to which input was made, the type of input, and relevant information with respect thereto (e.g., location, time, duration and type of touch, key tapped, pressure on pointer, etc. ). That information is received by event handler 42 and applied to the corresponding hosted software application 34 in the conventional manner required of hosted operating system and/or the hosted runtime environments 32, e.g., as if the touch or other user input had been made directly to hosted software application 34. See, step 78.

Hybrid Application Package Files

In some embodiments, illustrated computing device 10 further merges the user experience (so that applications executed in the hosted runtime environment better appear, to the user, as if they are executing within the native operating system 14) through the support of host application package files that are wrapped in native application package files. Or, put another way, by supporting the installation of hosted software applications 34, 36 via native application package files. Use of such "hybrid" application package files, as they are referred to herein, is advantageous where, for example, software developers, publishers, manufacturers, carriers or others in the supply chain wish to make the installation of applications on device 10 similar, from a user perspective, for all applications, regardless of whether native or hosted.

In the illustrated embodiment, hybrid application package files are generally structured in the manner of native application package files and, thus, for example, include icon files and other support files, of the sort common to native application package files (e.g., as defined by industry standards, native operating system support enterprises/organizations or otherwise). However, whereas a native application package file typically includes an "executable" (i.e., an executable file) for a native application to be installed, a hybrid application package file of the illustrated embodiment includes a hosted application package file of the type suitable for installation by an installer app the type conventional to the hosted operating system (e.g., as modified above, to unpack the to-be-installed application's executable and support files, etc., to suitable locations for the native and hosted operating systems).

An example of the foregoing is a Tizen application package file (a "TPK" file) that contains an Android application package file (an "APK" file). Through cooperation of the native installer app within a native Tizen runtime environments 16 and the hosted installer app executing under control of ACL 18 within a hosted Android runtime environment 32, device 10 can install the Android app contained in that APK file for execution within that a hosted Android runtime environment 32. Other examples include APK files wrapped within Windows application package files (APPX), APK files wrapped in WebOS application package files (IPK), and so forth, to name just a few examples.

Figure 5 depicts creation of a hybrid application package file according to one practice of the invention. The steps reflected in the example are executed on digital data processing equipment 80, e.g., typically, operated by and/or on behalf of software developers, publishers, equipment manufacturers, carriers or others in the supply chain (though, they can be executed on digital data processing equipment owned and/or operated by others, instead and/or in addition). Such digital data processing equipment 80 can comprise mainframe computers, mini computers, workstations, personal computers, laptop computers, tablet computers, and so forth, all of the type commercially available in the marketplace as adapted in accord with the teachings hereof.

Illustrated device 80 includes a central processing unit (CPU), input/output (I/O), memory (RAM) and nonvolatile storage (MEM) subsections, of the type commonly provided with the aforesaid devices, as adapted in accord with the teachings hereof. The device 80 may be connected permanently, intermittently or otherwise to one or more of the devices 10 via network 12 in the conventional manner known in the art as adapted in accord with the teachings hereof.

The CPU of device 80 (e.g., in conjunction with the I/O, RAM and/or MEM subsections) is programmed to create hybrid application package files by execution of the steps shown in Figure 5 and described herein. The illustrated steps, which are directed to creation of a hosted application package file, here, an Android application package file, that is wrapped in a native application package file, here, a Tizen application package file, are shown by way of example. Those skilled in the art will appreciate that other combinations of application package files can be combined to create hybrid application package files in accord with the teachings hereof, although, the specifics may vary in a manner that will be evident to those of ordinary skill in the art in view of the teachings hereof.

In step 82, device 80 unzips an APK that is to be wrapped (in a TPK file) in order to gain access to its contained files. The APK file can be generated in the first instance on the device 80, though, typically, it is generated and/or transmitted to device 80 from digital data processing apparatus operated by a developer or publisher, by way of non- limiting example. In step 84, device 80 creates a new blank TPK container file (or, put another way, to a TPK application package file-in-creation), and in step 86 it stores the unmodified APK file in that TPK file.

In step 88, device 80 opens the Android manifest file (AndroidManifest.xml) contained in the APK file, and in step 90 it creates a Tizen manifest including requisite data from the Android manifest and stores it to the TPK file. In this regard, as those skilled in the art will appreciate, native application package files may require a manifest file that contains specific data. Such is the case, for example, with Tizen application package files and, therefore, in the illustrated embodiment, the TPK file created by device 80 includes such data.

Specifically, the manifest of a TPK file contains fields including Tizen privileges along with expected API versions. That data is used for verification of the TPK file, for example, when the TPK file is uploaded to e-commerce sites, such as app stores, for distribution. In step 90, the device 80 maps information provided in the Android manifest (from the APK file) to that required in the TPK's manifest. Required manifest information that does not appear in the Android manifest (such as privileges) can be generated based on other available information. A portion of a sample such mapping appears below:

TPK Requirement Information Supplied from APK

Package type Tizen Native Package (TPK)

Manifest File Name Manifest.xml

API Version As appropriate Privileges Mapped from Android app permissions Features Mapped from Android app feature descriptions Package ID Created by device 80 during wrapping of APK in

TPK In step 92, the device 80 stores an "ACL/Android" installer to the TPK file. When the TPK file is ultimately installed on device 10, this installer script (or other code) insures that the aforementioned native software application 18 (ACL) is present on device 10— since without it, the app contained in the hybrid application package will not run properly on the device 10. That script, which is included in a Tizen app stored by device 80 into the TPK file, when ultimately run during installation of the TPK file on device 10, checks to see if ACL is present and if not, downloads it from a commercially available or other site and installs it.

In step 94, the device 80 creates a package ID and certificate for the TPK file, and then packages them up with manifest, installer, and APK previously stored to the TPK file. In this regard, as those skilled in the art will appreciate, e-commerce sites (such as app stores) from which TPK files are distributed often require that each such file have a unique package ID used to uniquely identify the app and to help manage app updates. They also often require a certificate that is required to guarantee the integrity of the app, identify the app developer, and to provide proof of validation. In step 94, the device 80 executes scripts, e.g, to interface with APIs of such e- commerce sites, in order to create the requisite unique package ID and certificate. The device 80 can also create a cross-reference database within its content delivery system to bind Tizen packages with the appropriate Android information, e.g., to ensure that updates and settlement for purchased apps are handled correctly.

In step 96, the device 80 maps Android app metadata to the format required for listing the TPK file in e-commerce sites, such as app stores. In this regard, as those skilled in the art will appreciate, e-commerce sites may have specific requirements for the format and content of metadata accompanying each TPK file. Those requirements are typically published by the site operator, though, they may be available otherwise. Android apps typically have their own metadata, which is provided by the app developer (or publisher) with each APK file or otherwise. There may be discrepancies in the way the data is structured and tagged as between the APK files and, for example, TPK files. The mapping of step 96 overcomes this by properly tagging and formatting the requisite data from the APK file for inclusion with the TPK file. Hybrid application package files created by device 80 can be transmitted to device 1 0, via network1 2 or otherwise, whence they are installed as discussed above in connection with Figure 2 as adapted in accord with the present discussion.

Thus, in the illustrated embodiment, following transmission of such a hybrid application package file to device 1 0, e.g. , upon user purchase, download request or otherwise, an installer app of the native operating system 14 unpacks that file and executes the ACL/Android installer script it contains.

As noted above, execution of the ACL/Android installer script insures that aforementioned native software application 1 8 (ACL) is present on device 1 0 and, if not, causes it to be downloaded and installed. In the illustrated embodiment, ACL implements a "listener," wake-on-event, or other such functionality executing within the native runtime environments 1 6 to detect installation of a hybrid application package. Upon detecting same, the ACL 1 8 messages or otherwise notifies the hosted operating system (e.g. , using a mechanism of the type described above in connection step 66, et seq.) to launch its installer app to install of the hosted app executable contained in the hosted application package (e.g. , the APK file in the example above) of the hybrid application package (e.g. , the TPK file in the example above). To facilitate this, ACL moves the hosted application package to a location in storage (MEM) accessible to that installer. Installation of that hosted app executable can then proceed as described earlier.

In some embodiments, one or more of the functions attributed to ACL in the foregoing paragraph are implemented, instead or in addition, by extensions to the native operating systems installer.

A more complete understanding of the operation of systems according to the invention may be attained by reference to United States Patent Application Serial No. 14/061 ,288, filed October 23, 201 3 (now, U.S. Patent Publication No. US 2014- 01 15606), and United States Patent Application Serial No. : 61 /892,896, filed October 1 8, 2013, both entitled MULTI-PLATFORM MOBILE AND OTHER COMPUTING DEVICES AND METHODS," the teachings of which are incorporated by reference herein.

Conclusion

Described above and shown in the drawings are devices and methods meeting the desired objects, among others. Those skilled the art will appreciate that the embodiments described and shown here in our merely examples of the invention and that other embodiments, incorporating changes to those here, fall within the scope of the invention, as well.

Claims

Claims

In view thereof, what we claim is A computing device comprising: a central processing unit, the central processing unit executing a native operating system including one or more native runtime environments within which one or more native software applications are executing, where each such native software application has instructions for execution under the native operating system, one or more hosted runtime environments executing within the one or more of native runtime environments, where each of which hosted runtime environments executes hosted software applications that have instructions for execution under a hosted operating system that differs from the native operating system, a first installer, executing within one of the native runtime environments, that responds to a native application package file by installing for execution under the native operating system an app contained in that native application package file, a second installer, executing within one of the hosted runtime environments, that responds to a hosted application package file by installing for execution under the hosted operating system an app contained in that hosted application package file, and functionality executing in connection with the first installer that responds to a hybrid application package file by at least one of (i) notifying the second installer of a hosted application package file contained therein and (ii) making that hosted package file accessible to that second installer, where the hybrid application package file comprises a said hosted application package file contained within a said native application package file.

2. The computing device of claim 1 , in which a first native software application executing within the one or more native runtime environments defines the one or more hosted runtime environments within which hosted software applications are executing.

3. The computing device of claim 2, wherein the first installer effects execution of any of an app, script or other code (collectively, "script") supplied with the hybrid application package file in order to detect a presence of the first native software application on the device.

4. The computing device of claim 3, in which the script responds to an absence of the first native software application on the device by effecting any of download and installation of that first native software application to the mobile device.

5. The computing device of claim 1 , in which hosted apps execute within the one or more hosted runtime environments with theming consistent with that of native apps executing within the one or more native runtime environments.

6. The computing device of claim 5, in which such consistency of theming is effected by the first native software application.

7. The computing device of claim 1 , wherein the computing device is any of a smart phone, tablet computer, mobile computing device, set-top box, connected television, in-vehicle infotainment system, or in-flight entertainment system.

8. A digital data processing method comprising the steps of: storing a hosted application package file to a native application package file-in- creation; storing to the package file-in-creation a manifest file for the native operating system based on information in a manifest file contained in the hosted application package file for the hosted operating system; creating a hybrid application package file by storing to the package file-in- creation any of an app, script or other code (collectively, "script") to detect a presence of a selected native software application on a device on which that script is executed; and transmitting the hybrid application package file to a computing device.

9. The method of claim 8 comprising installing a host app contained within the host application package file of the native application package file on the computing device.

10. The method of claim 9, comprising executing on the computing device a native operating system including one or more native runtime environments within which one or more native software applications are executing, where each such native software application has instructions for execution under the native operating system, executing, within the one or more of the native runtime environments, one or more hosted runtime environments, where each of which hosted runtime environments executes hosted software applications that have instructions for execution under a hosted operating system that differs from the native operating system, executing a first installer within one of the native runtime environments that responds to a native application package file by installing for execution under the native operating system an app contained in that native application package file, executing a second installer within one of the hosted runtime environments that responds to a hosted application package file by installing for execution under the hosted operating system an app contained in that hosted application package file, and executing in connection with the first installer functionality that responds to the hybrid application package file by notifiying the second installer of a hosted application package file contained therein and by making that hosted package file accessible to that second installer.