Middleware interface and middleware interface generator

A computer system exposes a hardware access library providing an interface for commanding an input/output device of the computer system. The computer system launches an agent process that can receives a request from a remote process to command the I/O device. The agent process invokes a first call to a middleware driver, the middleware driver invokes a second call to the client proxy, and the client proxy invokes a third call to a server stub, and the server stub accesses the input/output device responsive to receiving the third call via the hardware access library.

TECHNICAL FIELD

The following disclosure relates to the technical field of operating platforms and/or operating systems.

BACKGROUND

An operating platform for a computing device can include two layers: a system layer and a framework layer. The system layer can include an operating system kernel, libraries for accessing functionality of the operating system kernel, and an abstraction layer for interfacing with hardware. The framework layer can include services that can be used by applications executing on the operating platform and the applications. In some applications, the operations performed by the system layer and the framework layer are split among computing systems. For example, the system layer's operations may be performed by a mobile device, while the framework layer operations are performed by a server in a cloud computing configuration.

When the system and framework layers execute on separate computing devices, components of the framework layer may communicate with components of the system layer via custom streaming channels implemented in the framework layer.

SUMMARY

In one aspect, a method for creating a middleware interface for an operating platform includes accessing a file describing an interface definition and generating a server stub for communicating with a hardware access library of the operating platform based on the interface definition. The hardware access library can provide access to hardware of a computing device executing the operating platform. The method can also include generating a client proxy for communicating with a server stub based on the interface definition and generating a middleware interface specification based on the interface definition. The middleware interface specification can include one or more control flows, and the one or more control flows can include function operation descriptions for allowing a process to access the hardware of the computing device. The method can also include generating, using the middleware interface specification, a middleware driver for communicating with the client proxy, the middleware driver also in communication with an agent for receiving communications from a plurality of processes.

Various implementations of this aspect may include one or more of the following features. In some implementations, the operating platform includes the agent. In some implementations, at least one of the plurality of processes are executed on the computing device, and in some implementations at least one of the plurality of processes are executed by a remote computer system different from the computer system. In some implementations, the first complier performs generating the server stub, generating the client proxy and generating the middleware interface specification, and a second complier performs the generating the middleware driver. In some implementations, the method also includes deploying the server stub, the client proxy, and the middleware driver to the computing device executing the operating platform. The operating platform may be an open source platform.

Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method summarized above.

In another aspect, a system includes a first processor, an input/output device, and, a memory storing instructions that when executed by the first processor cause the first processor to perform operations including exposing a hardware access library providing access to an interface for commanding the input/output device and launching an agent process for receiving a request from a remote process to command the input/output device. The operations can also include instantiating a middleware driver, instantiating a client proxy, instantiating a server stub, and commanding the input/output device responsive to the server stub accessing the interface. In some implementations the agent process invokes a first call to the middleware driver responsive to the receiving of the request from the remote process, the middleware driver invokes a second call to the client proxy responsive to receiving the invocation of the first call, the client proxy invokes a third call to a server stub responsive to receiving the invocation of the second call, and the server stub for accesses the input/output device responsive to receiving the third call.

Various implementations of this aspect can include, for example, the first processor executing the remote process or a second processor of a remote computer system executing the remote process. In some implementations, the client proxy, the server stub, and a middleware interface specification are generated based on an interface definition, and the middleware driver is generated based on middleware interface specification. In some implementations, the instructions stored in the memory further cause the first processor to perform operations including invoking a fourth call on the server stub responsive to a request transmitted from the input/output device to the hardware access library, invoking a fifth call on the client proxy responsive to the invocation of the fourth call, and invoking a sixth call on the middleware proxy responsive to the invocation of the fifth call. The operations may also include communicating, via the agent process, a message to the remote process responsive the invocation of the sixth call.

Other embodiments of this aspect include corresponding methods configured to perform the operations of the processor of the regression testing system according to the instructions stored in the regression testing system's memory.

In another aspect, a method for accessing hardware of a remote computing device includes receiving from the remote computing device, a middleware interface specification and dynamically generating a class based on the middleware interface specification using reflection. The class can include a method that when invoked generates a remote procedure call to an agent process executing on the remote computing device, and the remote procedure call can cause the agent process to access a hardware abstraction layer of the remote computing device. The method can also include invoking the method of the class.

In some implementations of this aspect, the middleware interface specification is based on an interface definition used to generate a client proxy and a server stub on the remote computing device, and the client proxy can expose a first application programming interface for accessing the server stub. In some implementations, the server stub can expose a second application programming interface for accessing the hardware abstraction layer of the remote computing device. The middleware interface specification can include a control flow for the method, a range of expected values for the method, or can be received from the agent process executing on the remote computing device according to some implementations.

Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method summarized above.

DETAILED DESCRIPTION

The use of custom streaming channels between the system layer and the framework layer can cause compatibility issues if the application programming interface (API) for the system layer changes because the custom streaming channels will no longer be compatible and will need to be rewritten and/or redesigned to accommodate the updated system layer API.

Accordingly, the present disclosure describes a middleware interface. In some implementations, the middleware interface can be automatically generated. It can interface between the system layer (or lower layer) and the framework layer (or upper layer) of the operating platform without the need for custom streaming channels or other application specific communication mechanisms by providing a consistent interface between the system layer and the framework application layer.

According to some embodiments, the middleware interface is generated using a hardware abstraction layer interface definition language (or “HIDL”). A first complier accesses a hardware abstraction layer interface definition language file corresponding with a hardware abstraction layer (or a hardware access library that is part of the hardware abstraction layer). The first complier generates a server stub, a client proxy, and middleware interface specification. The server stub can interface with the hardware abstraction layer on a first computing device. The client proxy can communicate with the server stub to allow one or more processes access to hardware of the first computing device. The middleware interface specification includes a control flow describing the operation of functions of an application that accesses the hardware of the computer device. A second complier accesses the middleware interface specification to generate a middleware driver that can be read by an agent process executing on the first computing device. The agent process can communicate one or more remote processes.

During operation, the agent process receives a remote call for accessing the hardware. The agent process invokes a function in the middleware driver corresponding to the received remote call. The middleware driver then invokes a function in the client proxy to implement one or more operations required to satisfy the remote call. The client proxy invokes a function on the server stub implementing functionality needed to respond to the call from the middleware driver. The server stub invokes a portion of the hardware abstraction layer in response to the call from the client proxy.

In one implementation, the agent process provides the middleware interface specification to a test runner process. The test runner process generates, at runtime, classes with methods that when called, result in invocation of one or more functions in the hardware abstract layer.

FIG. 1illustrates, in block form, system100for middleware interface use and generation consistent with disclosed embodiments. In the embodiment illustrated inFIG. 1, developer computer system110, user computer system120, and remote computer system160can communicate using network190.

System100outlined inFIG. 1can be computerized, wherein each of the illustrated components comprises a computing device that is configured to communicate with other computing devices via network190. For example, developer computer system110can include one or more computing devices, such as a desktop, notebook, or handheld computing device that is configured to transmit and receive data to/from other computing devices via network190. Similarly, user computer system120and remote computer system160can include one or more computing devices that are configured to communicate data via the network190. In some embodiments, user computer system120can be a general-purpose computer system operated by an end-user. For example, user computer system120can be a desktop, notebook, mobile device, or handheld computing device that can perform general-purpose computing tasks such as sending and receiving email, browsing the Internet, word processing functions, spreadsheet functions, and the like. In some embodiments, user computer system120can be a mobile device with telephone capabilities. In some embodiments, remote computer system160can be a mobile device, smart phone, or other handheld computing device. In some embodiments, remote computer system160can be a server, server network, or multiple computing systems. For example, remote computer system160can include one or more servers or computing clusters. In some embodiments, these computing systems can be implemented using one or more computing devices dedicated to performing the respective operations of the systems as described herein.

According to some embodiments, developer computer system110performs one or more functions and/or operations to generate stubs and proxies used for middleware interface communication. For example, developer computer system110can include HIDL compiler113and middleware interface compiler118. In some embodiments, HIDL compiler113can accept as input a file or data structure written in a programming language that HIDL compiler113uses to generate server stub140and client proxy150. In some embodiments, the input file accepted by HIDL compiler113is written in a hardware abstraction layer interface definition language, or HIDL (described in more detail below with respect toFIG. 3).

According to some embodiments, HIDL compiler113can also create an output file that is used by middleware interface compiler118. Middleware interface compiler118can generate middleware driver145from the output file of HIDL compiler113according to some embodiments. The output file can include a middleware interface specification that describes the functions of the middleware interface, their control flow, and their normal values (as described in more detail below with respect toFIG. 3).

In some embodiments, developer computer system110generates one or more server stubs140, middleware drivers145, and client proxies150and communicates them to user computer system120. In some embodiments, server stub140, middleware driver145, and client proxy150are packaged and deployed to user computer system120as part of operating platform130. In some embodiments, developer computer system110communicates server stub140, middleware driver145, and client proxy150to user computer system120separately from operating platform130.

According to some embodiments, user computer system120can include agent125, operating platform130, hardware and I/O devices135, and one or more server stubs140, middleware drivers145and client proxies150. In some embodiments, agent125is an executable process that manages communications between remote processes and local proxies and stubs. For example, agent125may open one or more TCP ports and manage communication between user computer system120and remote computer system160via the one or more TCP ports. Agent125can also communicate with middleware driver145in some embodiments. As discussed in greater detail below, events triggered from user input to hardware and I/O devices135can result in the invocation of a function in server stub140, which can result in the invocation of a function call in client proxy150, which can also result in the invocation of a function in middleware driver145. Middleware stub145may make a call to agent125which then can make a remote process call to remote computer system160, for example.

In some embodiments, user computer system120includes operating platform130.FIG. 2shows an example architecture diagram for operating platform130consistent with disclosed embodiments. In some embodiments, operating platform130can be an open source operating platform—the source code for the operating platform may be available to third parties installing the operating platform on computing devices and/or the public. Operating platform130can include, in some embodiments, a general-purpose operating system executing on a general-purpose computing device such as a laptop, desktop, or other general-purpose computing device, or a mobile computing device such as a mobile phone, smartphone, or tablet computing device. Operating platform130may support basic functions of the computing device such as scheduling tasks, executing applications, controlling peripheral devices, and/or managing resources of the general-purpose computing device.

In some embodiments, operating platform130includes several abstraction layers which can be divided into upper abstraction layers and lower abstraction layers. For example, operating platform130as shown inFIG. 2, is divided along line210into an upper abstraction layer, or framework layer220, and a lower abstraction layer, or system layer230.

In some embodiments, framework layer220can include two sublayers, for example, application layer240and application framework layer250. Applications layer240can include, in some embodiments, an application or user space in which user applications such as provided applications242and third-party applications246execute. For example, provided applications242can include applications such as an email client, a phone application, a web browser application, and/or a notetaking application. Third-party applications246can include applications that a user downloads and installs from third-party application providers. Third-party applications246can include, for example, word processing applications, spreadsheet applications, social media applications, and games. In some embodiments, users of the computing device executing operating platform130have direct access to the functionality of application layer240.

According to some embodiments, applications installed within application layer240can interface with services or managers in application framework layer250to access functionality provided by system layer230. Users, in some embodiments, may not access application framework layer250, but rather, may access it indirectly through the applications of application layer240. For example, application framework layer250can include various services251that can be used by applications installed in application layer240, such as input output services, Bluetooth services, or database services as just some examples. In some embodiments, application framework layer250may also include various managers such as location manager252activity manager253, package manager254, resource manager255, and telephony manager256which may manage one or more background processes (e.g., processes without a user interface). For example, location manager252may provide an API that provides applications executing within application layer240with location information (such as GPS coordinates) regarding the current location of the device executing operating platform130. Activity manager253, for example, may provide information to applications executing within application layer240regarding threads, processes or other resources of the device executing operating platform130. Package manager254, in some embodiments, may provide functionality for installing, uninstalling, upgrading, or configuring applications installed within application layer240. In some embodiments, resource manager255may provide functionality for managing resources such as CPU execution cycles or memory. In some embodiments, operating platform130provides an application allowing telephone calls over an IP network or over a cellular network and in such embodiments, application framework layer250may include telephony manager256that provides functionality to the telephone application.

In some embodiments, system layer230includes three sublayers, library layer260, hardware abstraction layer280, and kernel layer290. In some embodiments, library layer260includes one or more libraries that provide common functionality to applications within application layer240or services or managers located within application framework layer250. For example, library layer260can include database libraries262which provide libraries for accessing and utilizing databases executing on operating platform130. Library layer260can also include Internet libraries264which can provide functionality to application layer240or application framework layer250for using Internet protocols. According to some embodiments, library layer260can also include graphics library266which can provide functionality for rendering graphics on the display of the device executing operating platform130. Common libraries268can include, for example, common functionality that may be used by application layer240or application framework layer250. Such common functionality might include, for example, interprocess communication libraries, input/output libraries, or data management libraries. In some embodiments, library layer260can include runtime270. Runtime270may include core libraries273and virtual machines277which provide functionality to the computing device executing operating platform130to execute services, managers (in application framework layer250) and applications (in application layer240). For example, in some embodiments, applications within application layer240may execute on in one or more virtual machines, and in such embodiments, these one or more virtual machines may be located within runtime270of library layer260.

In some embodiments, system layer230of operating platform130includes hardware abstraction layer280. Hardware abstraction layer280can provide, in some embodiments, an abstraction layer between the physical hardware of the computing device executing operating platform130and the software running on the computing device. According to some embodiments, hardware abstraction layer280can include a hardware access library that allows access to the physical hardware of the computing device including for example, input/output devices such as displays, networking components, Bluetooth functionality, and the like.

System layer230can also include kernel layer290. Kernel layer290can provide functionality for the central core of operating platform130. For example, kernel layer290can provide functionality for managing startup of operating platform130, input/output requests from application layer240and application framework layer250(e.g., via drivers292), management of process start-up and termination (via process management296), management of power (via power management294), and management of memory operations (via memory management298). In some embodiments, application layer240and application framework layer250

With reference back toFIG. 1A, user computer system120can also include hardware and I/O devices135. Hardware and I/O devices135can include hardware components of user computer system120which provide input and output to users, or perform functional operations of user computer system120(e.g., processors, memory, buses). Examples of hardware and I/O devices135are described below with respect toFIG. 9.

In some embodiments, applications accessible by user computer system120may execute on remote computer system160. In such embodiments, herein referred to as a “split architecture” for ease of discussion only, the applications may interact with hardware and I/O devices135of user computer system120while remote computer system160performs application processing. In some split architecture embodiments, framework layer220functionality of operating platform130is performed on remote computer system160while system layer230functionality is performed on user computer system120. One advantage of using a split architecture is that version control for applications and services can be localized to remote computer system160as opposed to be distributed across multiple user computer systems120. Another advantage can be that remote computer system160, which may be a server or computing cluster in some embodiments, may have more processing power than what is available on user computing device120, which may be a mobile computing device or smartphone is some embodiments.

To accommodate a split architecture, user computer system120may use a middleware interface. The middleware interface can be implemented, in some embodiments, through server stub140, middleware driver145, and client proxy150. In some embodiments, server stub140exposes functions or methods that when called invoke a call to access hardware and I/O devices135. For example, server stub140may expose a method called “drawImage” for displaying graphics on a touchscreen display of user computer system120. When the “drawImage” function is called, server stub140may perform operations to access a driver for the touchscreen display of user computer system120so that the touchscreen display renders an image according to the parameters of the “drawImage” function. In some embodiments, server stub140may make a call to hardware abstraction layer280, which in turn makes a call to a driver to access the hardware.

According to some embodiments, the middleware interface may also includes client proxy150. Client proxy150can expose functions or methods that when called invoke a call to a corresponding function or method of server stub140. For example, client proxy150may include a function called “drawImageProxy” that when called invokes a “drawImage” function in server stub140. In some embodiments, applications or services executing on operating platform130of user computer system120can call the functions or methods of client proxy150to access functionality of hardware and I/O devices135, which may occur indirectly through a subsequent call to server stub140by client proxy150in some embodiments. For example, an application executing on user computer system120may make a call to a service of operating platform130. The service may then make a call on a function of client proxy150, such as “drawImageProxy.” When client proxy150receives the call, it may invoke a corresponding function in server stub140, such as “drawImage.” Server stub140may then access hardware and I/O devices through a driver or through a hardware abstraction layer depending on the embodiment.

To facilitate application processing on remote computer system160, the middleware interface can also include middleware driver145. Middleware stub145can expose functions and operations for accessing hardware and I/O devices135of user computer system120through client proxy150and server stub140. According to some embodiments, middleware driver145may communicate with agent125to facilitate communication with remote computer system160. For example, agent125may expose or communicate an API for middleware driver145to remote computer system160. When a function or method of middleware driver145is invoked, it may in turn invoke a function or method on client proxy150.

The use of middleware driver145provides an additional layer of abstraction to hardware and I/O devices135. One advantage is that should the API of client proxy150change, processes executing on remote computer system160need not change calls to middleware driver145because middleware driver145can expose a consistent API make any necessary adjustments to function calls of client proxy150. Thus, applications executing on remote computer system160need not be updated on an update to the API of client proxy150(or server stub140or the hardware abstraction layer).

Another advantage is providing stronger encapsulation. For example, functionality for communicating with agent125can be localized to middleware driver145without including it in client proxy150. As noted above, client proxy150may receive calls originating from applications executing locally on user computing device120or calls originating from applications executing on remote computing system160. Thus, client proxy150need not include functionality for communicating with agent125as that may not be needed.

In some embodiments, remote computer system160may include one or more virtual computing environments170. Virtual computing environment170can include, for example, a virtual computing system that executes operating platform130. Virtual computing environment170may also include one or more applications that interact with hardware and I/O devices135of user computer system120in a split architecture via the middleware interface. For example, virtual computing environment170may include an augmented reality application that annotates images. The augmented reality application may be computationally intensive and require processing power beyond the capabilities of user computer system120. As a result, such processing may occur on remote computer system160which can be a server or cluster computer in some embodiments. The augmented reality application may need to access a camera and be responsive to touch screen input events detected by the touchscreen of user computer system120. As a result, the augmented reality application may process the application and access the camera and touchscreen of user computer system120through the middleware interface (e.g., server stub140, middleware driver145, and client proxy150) and agent125.

Remote computer system160can include multiple virtual computing environments170, where each virtual computing environment170includes an instance of operating platform130and one or more applications executing on operating platform130. In such embodiments, remote computer system160may be in communication with the plurality of user computer systems.

In some embodiments, remote computer system160may execute operating platform130outside of a virtual computing environment. For example, as shown inFIG. 1B, remote computer system160includes operating platform130and does not include virtual computing environment170. In such embodiments, remote computer system160similarly can communicate with hardware and I/O devices135of user computer system120via the middleware interface and agent125.

According to some embodiments, remote computer system160includes test runner165. When testing operating platform130of user computer system120, test runner165may use one or more test suites. But, the point of entry for these test suites is typically in either application layer240or application framework layer250because testing generally occurs on devices that are ready for user use, and access to system layer230may be prevented. As a result, if the execution of a test case on operating platform results in a defect, it may be difficult to identify the location of the fault causing the defect within operating platform130. For example, if a test case makes a call on an application that uses telephony resources, and the test case triggers a defect, it may be difficult to determine whether the fault causing the defect is located within application layer240(or provided applications242), within application framework layer250(or within telephony manager256), within library layer260(or one of common libraries268, core libraries273, virtual machines277), within hardware abstraction layer280, or kernel layer290.

Accordingly, test runner165can perform functions and operations that access functionality of hardware and I/O devices135of user computer system120using the middleware interface and agent125independently from the framework layer220of operating platform130. In some embodiments, test runner165can bypass framework layer220of operating platform130to test system layer230of operating platform130independently from framework layer220. For example, test runner165, via agent125, can invoke a function in middleware driver145, which in turn will invoke a function in client proxy150, which will in turn invoke a function and server stub140, which invokes a function to access hardware and I/O devices135. In such an example, hardware and I/O devices135were accessed without the use of the framework layer220of operating platform130.

One advantage of using test runner165to access system layer230of operating platform130is that the lower level functionality of operating platform130in system layer230can be tested independently of the upper layer functionality of operating platform130. As operating platform130can be an open source platform in some embodiments, manufacturers of computing devices running operating platform130may make modifications to the source code of operating platform130to accommodate for the specific hardware components of the computing devices they manufacture and sell. Such modifications are typically tested on user ready devices and as noted above, system layer230may not be directly accessible. The use of test runner165and the middleware interface can improve fault localization in some embodiments since faults detected using test runner165would be in system layer230as test runner165bypasses framework layer220.

Depending on the embodiment, network190can include one or more of any type of network, such as one or more local area networks, wide area networks, personal area networks, telephone networks, and/or the Internet, which can be accessed via any available wired and/or wireless communication protocols. For example, network190can comprise an Internet connection through which user computer system120and remote computer system160communicate. Any other combination of networks, including secured and unsecured network communication links are contemplated for use in the systems described herein.

FIG. 3shows a data flow300for middleware interface generation consistent with disclosed embodiments. Data flow300begins with HIDL compiler113accepting as input hardware abstraction layer interface definition file310. Hardware abstraction layer interface definition file310can be a text file including HIDL. HIDL can be, in some embodiments, an interface definition language that can describe functions used to access functionality provided by a hardware abstraction layer. In some embodiments, HIDL allows for function definitions including parameters that are passed into the function, values that are returned from the function, and function names. In some embodiments, HIDL also allows for in-line comments that are not processed by HIDL compiler113. In some embodiments, hardware abstraction layer interface definition file310can include definitions of functions for accessing drivers, hardware directly, or the hardware abstraction layer depending on the embodiment.

According to some embodiments, HIDL allows for definitions of control flows between functions. A control flow can include a series of function calls starting with an entry function and ending with a terminal function. In some embodiments, control flows can correspond to operations and functionality available through the hardware abstraction layer. In some embodiments, hardware abstraction layer interface definition file310can include flags or tags to indicate entry functions, terminal functions, and the functions that are part of a control flow.

In some embodiments, HIDL allows for the definition of normal values for functions. Normal values can include, for example, typical data values for a function or boundary condition values for a function. In some embodiments, normal values can be used for testing purposes. As described in greater detail below, in some embodiments, test runner165can reflectively create test cases. In such embodiments, normal values can be used by test runner165to create sample input to provide to test cases it generates.

According to some embodiments, once HIDL compiler113reads and compiles hardware abstraction layer interface definition file310, it outputs middleware interface specification file350, client proxy150, and server stub140. As described above, server stub140and client proxy150are part of the middleware interface providing access to hardware and I/O devices of a user computer system. Middleware interface specification file350can include function definitions, control flows, entry function identifications, terminal function identifications, and normal values for functions that are part of the middleware interface. In some embodiments, middleware interface specification file350is formatted such that middleware interface compiler118can accept it as input and read it, although middleware interface specification file may not include human readable text. In some embodiments, however, middleware interface specification file may be human readable allowing for developers to modify middleware interface specification file350after his been output by HIDL compiler113and before is provided as input to middleware interface compiler118.

Data flow300continues where middleware interface compiler118generates middleware driver145from middleware interface specification file350. As noted above, middleware driver145is part of the middleware interface and according to some embodiments, communicates with agent125providing access for remote computer devices to the hardware and I/O devices of a user computer system.

FIGS. 4A and 4Bshow block diagram400for the flow of operations between components of user computing system120and remote computer system160during middleware interface operation according to some embodiments.FIG. 4Ashows the flow of operations for accessing hardware and I/O devices135of user computer system120from an application executing locally on user computer system120.FIG. 4B, on the other hand, shows the flow of operations for accessing hardware and I/O devices135of user computer system120from an application executing on remote computer system160in a split architecture embodiment.

InFIG. 4A, an application executed by user computer system120may reside in application layer240of the user computer system120. To communicate with hardware and I/O devices135, code in application layer240invokes a function or method in application framework layer250. For example, an application in application layer240may make a call on the API of a service in the application framework layer250. Responsive to the invocation of the function by application layer240, application framework layer250may invoke a corresponding function call on client proxy150. Client proxy150may, in turn, invoke a corresponding function call on server stub140, and server stub140may make a call to hardware abstraction layer280to access functionality of hardware and I/O devices135.

According to some embodiments, the flow of operations is bidirectional—applications in application layer240may make calls through the operation flow to hardware and I/O devices135, and hardware and I/O devices135invoke functionality of the application through the same operational flow going in the other direction. In some embodiments, hardware and I/O devices135invoke functionality of application layer240using a callback invocation, either synchronous or asynchronous, or through return values corresponding to functions that are part of the hardware abstraction layer. For example, a touchscreen event may register a callback to an event handler in application layer240that performs some function in response to the touchscreen event occurring. In such an embodiment, a touchscreen event may be detected by hardware and I/O devices135resulting in a callback function being invoked in hardware abstraction layer280. In an asynchronous call back, for example, the callback function invocation in hardware abstraction layer280may result in a call to server stub140. Server stub140may make a corresponding function call on client proxy150. Client proxy150may invoke a callback function on application framework layer250, which in invokes a call to the event handler in the application layer240, and the application may execute or perform functionality in response.

InFIG. 4B, an application executed by remote computer system160may reside in application layer240of remote computer system160. The flow of operations inFIG. 4Bis similar to the flow of operations inFIG. 4Aexcept that the flow of operations forFIG. 4Bincludes agent125and middleware driver145. When application layer240of remote computer system160needs to access hardware and I/O devices135of user computer system120, code in application layer240invokes a function or method in application framework layer250. Responsive to the invocation of the function by application layer240, application framework layer250may invoke a corresponding function call on middleware driver145via agent125. Middleware stub145may then make a corresponding call on client proxy150. Client proxy150may then, in response, invoke a corresponding function call on server stub140, and server stub140may make a call to hardware abstraction layer280to access functionality of hardware and I/O devices135of user computer system120. Like the operational flow described with respect toFIG. 4A, the operational flow described inFIG. 4Bmay also be bidirectional depending on the embodiment. For example, input events registered by hardware and I/O devices135of user computer system120may initialize the operational flow and application of application layer240of remote computer system160may receive notification of the input event.

FIG. 5shows a block diagram500for the flow of operations when using the middleware interface in a testing embodiment. As shown inFIG. 5, remote computer system160includes test runner165. Test runner165, in some embodiments, can reflectively create and instantiate test classes520based on information in the middleware interface specification file350. According to some embodiments, agent125provides middleware interface specification file350to test runner165. Agent125may provide middleware interface specification file350to test runner165after middleware interface compiler118creates it, or at a later time. In some embodiments, middleware interface specification file350for a particular hardware abstraction layer may be deployed to user computer system with the other components of the middleware interface (e.g., server stub140, middleware driver145, and client proxy150).

As described above, middleware interface specification file350can include the definitions of functions that are part of the middleware interface specification (e.g., the functions exposed by middleware driver145, client proxy one or50, and server stub140). Middleware interface specification file350can also include control flows, identification of entry functions, identification of terminal functions, and normal values. In some embodiments, middleware interface specification file350can include an API specification (e.g., describing names of functions, arguments to those functions, and their return values) and a data specification (e.g., data types such as struct, vector, scalar, array, etc.) In some embodiments, the middleware interface specification file can be written in a known scripting or programming language (e.g., Python, Perl) that can be executed by test runner165consistent with disclosed embodiments.

In some embodiments, test runner165can use this information to create test classes520. For example, test runner165can create test classes using reflection that invokes the entry function of a control flow and provides input to the entry function the based on normal values associated with it in the middleware interface specification file350. And, as the middleware interface specification file350includes the terminal function of the control flow, it can also create code for test classes520that receive return values from the terminal function and compare it to the normal values in the middleware interface specification file350associated with the terminal function.

For example, the hardware abstraction layer for the camera of user computer system120may have functions related to taking, editing, and saving photos called “takeSnapshot,” “editSnapshot,” and “saveSnapshot.” In the example, one use case results in a control flow of takeSnapshot calling editSnapshot, and editSnapshot calling saveSnapshot. The takeSnapshot may receives parameters X, Y, and Z and saveSnapshot may return a boolean value corresponding to whether the method call was successful. Accordingly, the HIDL for the camera hardware abstraction layer will include a function definition for takeSnapshot with parameters X, Y, and Z, a function definition for editSnapshot, a function definition for saveSnapshot with a return parameter of W, a control flow with takeSnapshot as the entry function and saveSnapshot as the terminal function, and normal values of A, B, and C for takeSnapshot (corresponding with parameters X, Y, and Z) and “true” for saveSnapshot (corresponding with parameter W). When HIDL compiler113process the HIDL for the camera hardware abstraction layer, HIDL compiler113may output server stub140and client proxy150with functions corresponding to takeSnapshot, editSnapshot, and saveSnapshot. HIDL compiler113will also output middleware interface specification file350which will also include definitions of takeSnapshot, editSnapshot, and save Snapshot, the control flow, and the normal values for the functions. Agent125can pass middleware interface specification file350to test runner165. Test runner165can read middleware interface specification file350and create a test class520that includes a call to takeSnapshot and use normal values A, B, and C when running the test class corresponding to the takeSnapshot function. Test class520may also include code to handle any return value from saveSnapshot and compare it to W.

Similar to the embodiments described with respect to FIG. For4A and4B, the flow of operations shown in block diagram500can be bidirectional, in some embodiments.

FIG. 6shows a flowchart representing an example middleware interface generation process600that may be performed by one or more components of developer computer system110such as HIDL compiler113and middleware interface compiler118. Although the following discussion describes middleware interface generation process as being performed by developer computer system110, other computer systems or other components of other computer systems can perform middleware interface generation process600without departing from the spirit and scope of the present disclosure.

Middleware interface generation process600begins at step610where an HIDL compiler accesses an interface definition file. The interface definition file can be a file written in HIDL in some embodiments. Consistent with disclosed embodiments, the HIDL compiler will then compile the interface definition file to generate a server stub, a client proxy, and a middleware interface specification file at step620. At step630, a middleware interface compiler may compile the middleware interface specification to generate a middleware driver, consistent with disclosed embodiments.

FIG. 7shows a flowchart for a middleware interface use process700that may be performed by user computer system120. Although the following discussion describes middleware interface use process700as being performed by user computer system, components of a remote computer system (such as remote computer system160) may perform some or all steps of middleware interface use process700without departing from the spirit and scope of the present disclosure.

Middleware interface use process700begins at step710where the user computer system launches a process corresponding to the agent. After launching the agent process, the user computer system instantiates the middleware driver, the client proxy, and the server stub (at step720) consistent with disclosed embodiments. At step730, the user computer system receives a request from a remote process, and in some embodiments, the request from the remote process may received the agent process launched in step710. At step740the agent may invoke a call to the middleware driver based on the received request from the remote process. The middleware driver may invoke a corresponding call to the client proxy at step750, and the client proxy may invoke a call to the server stub at step760. Responsive to receiving the call from the client proxy, the server stub access hardware at step770. As described above, and consistent with disclosed embodiments, server stub may access the hardware via hardware abstraction layer.

FIG. 8shows a flowchart for testing process800for testing an operating platform using a middleware interface consistent with disclosed embodiments. According to some embodiments, testing process800may be performed by a test runner component such as test runner165of remote computer system160for example. Although the following discussion describes testing process800as being performed by a test runner, other components of a computer system configured to perform testing of an operating platform can perform testing process800without departing from the spirit and scope of the present disclosure.

Testing process800begins at step810where the test runner receives a middleware interface specification file. The test runner may receive the middleware interface specification file via an agent executing on a user computing device connected with a remote computing device. At step820, the test runner may generate a test class from the middleware interface specification using reflection. Once the test classes have been generated and instantiated, test runner165may invoke one of the methods from the generated test class at step830. Once invoking the method of the generated test class, the test runner may initiate remote procedure call to an agent process executing on a user computing device connected with the remote computing device executing the test runner.

Computing device900includes a processor902, memory904, a storage device906, a high-speed interface908connecting to memory904and high-speed expansion ports910, and a low speed interface912connecting to low speed bus914and storage device906. The processor902can be a semiconductor-based processor. The memory904can be a semiconductor-based memory. Each of the components902,904,906,908,910, and912, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor902can process instructions for execution within the computing device900, including instructions stored in the memory904or on the storage device906to display graphical information for a GUI on an external input/output device, such as display916coupled to high speed interface908. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices900may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

The memory904stores information within the computing device900. In one implementation, the memory904is a volatile memory unit or units. In another implementation, the memory904is a non-volatile memory unit or units. The memory904may also be another form of computer-readable medium, such as a magnetic or optical disk.

The high speed controller908manages bandwidth-intensive operations for the computing device900, while the low speed controller912manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In one implementation, the high-speed controller908is coupled to memory904, display916(e.g., through a graphics processor or accelerator), and to high-speed expansion ports910, which may accept various expansion cards (not shown). In the implementation, low-speed controller912is coupled to storage device906and low-speed expansion port914. The low-speed expansion port, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

The computing device900may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server920, or multiple times in a group of such servers. It may also be implemented as part of a rack server system924. In addition, it may be implemented in a personal computer such as a laptop computer922. Alternatively, components from computing device900may be combined with other components in a mobile device (not shown), such as device950. Each of such devices may contain one or more of computing device900,950, and an entire system may be made up of multiple computing devices900,950communicating with each other.

Computing device950includes a processor952, memory964, an input/output device such as a display954, a communication interface966, and a transceiver968, among other components. The device950may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. Each of the components950,952,964,954,966, and968, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

The processor952can execute instructions within the computing device950, including instructions stored in the memory964. The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor may provide, for example, for coordination of the other components of the device950, such as control of user interfaces, applications run by device950, and wireless communication by device950.

Processor952may communicate with a user through control interface958and display interface956coupled to a display954. The display954may be, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display) or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface956may comprise appropriate circuitry for driving the display954to present graphical and other information to a user. The control interface958may receive commands from a user and convert them for submission to the processor952. In addition, an external interface962may be provide in communication with processor952, so as to enable near area communication of device950with other devices. External interface962may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.

The memory964stores information within the computing device950. The memory964can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory974may also be provided and connected to device950through expansion interface972, which may include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory974may provide extra storage space for device950, or may also store applications or other information for device950. Specifically, expansion memory974may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory974may be provide as a security module for device950, and may be programmed with instructions that permit secure use of device950. In addition, secure applications may be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

The computing device950may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone980. It may also be implemented as part of a smart phone982, personal digital assistant, or other similar mobile device.

The algorithms and systems presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.

It is to be understood that the above description is intended to be illustrative and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the disclosure should, therefore, be determined with reference to the aspects enumerated below, along with the full scope of equivalents to which such aspects are entitled.