Application virtualization in an emulator using an authentication process

Abstract

This paper presents devices and methods that enable the authentication of an MFi stack and a corresponding MFi application within an emulator operating with one or more processors / CPUs. In one aspect, a computer can contain memory and a processor configured to run the operating system. The computer can include a USB bus connected to a dongle via a USB interface. The dongle can contain an authentication coprocessor for use in an I2C-to-USB configuration and an I2C-to-USB computer. The driver code running on the computer can manage the data exchange between the authentication coprocessor and a virtual emulator on the computer. The emulator can include a USB-to-I2C driver that virtualizes the authentication coprocessor as an I2C device running the MFi application, such as CarPlay.

Description

INTRODUCTION

[0001] In recent years, numerous applications have been introduced to leverage the benefits of mobile devices (smartphones) within larger devices. Examples of such larger devices include vehicles. In a typical scenario, vehicle manufacturers can develop Bluetooth-based applications that allow the vehicle driver to make "hands-free" phone calls, thus avoiding the unwanted manual use of the driver's mobile device while driving.

[0002] One challenge with developing software for use in other applications is that different programs are often built using different operating systems and protocols. For example, a dealer may intend to sell an application to a variety of different vehicle manufacturers. However, a significant percentage of these manufacturers may use specific technologies and protocols in their vehicles that are not always compatible with the technology in question. To overcome this obstacle, the provider of these technologies can provide vehicle manufacturers with additional authentication-based devices that allow the buyer, such as a vehicle manufacturer, to authenticate the provider's technology in the buyer's vehicles.

[0003] One such example is Apple™ CarPlay. CarPlay is a technology that allows a consumer's iPhone screen to be projected onto a vehicle's infotainment display for use as part of the infotainment system. To enable non-Apple devices to connect to Apple devices such as CarPlay, Apple has developed an authentication coprocessor that connects to the main processor(s) in an embedded system via an inter-integrated circuit (I2C). In this example, Apple provides the design for the coprocessor and asks the manufacturer to assemble it into a system-on-a-chip (SOC). Accordingly, a vehicle infotainment system that supports CarPlay requires an authentication processor for authentication purposes. Only then can CarPlay be connected for use.This limited scenario creates a problem when adapting CarPlay to a specific vehicle: The manufacturer must use the actual infotainment system to develop and test CarPlay applications. For example, engineers must build the software using the infotainment hardware and then transfer the images to the target hardware for testing. Performing these processes via the vehicle's infotainment system is complex and time-consuming. DESCRIPTION

[0004] To improve productivity and the development and testing of applications such as CarPlay before they are deployed for general use in a vehicle, the principles of this disclosure are introduced to achieve virtualization of the application on an Android emulator running on a desktop or laptop computer, or a plurality thereof.

[0005] Various aspects of "Made for iPhone" (MFi) application virtualization in an emulator, such as an Android emulator, using an authentication coprocessor are presented here. MFi is a protocol from Apple that allows manufacturers to access licensed technology and create specifications and peripherals that work with Apple technology. In one aspect of the present disclosure, a method for MFi virtualization in an Android emulator on a main CPU of a computer is described. A Universal Serial Bus (USB) dongle is provided that includes an authentication coprocessor coupled to a USB-to-I2C converter via an Inter-Integrated Circuit (I2C) interface. The authentication coprocessor enables interfacing from a non-MFi protocol to an MFi protocol. The computer receives data from the USB-to-I2C converter via a USB interface.The data is passed via a USB device passthrough to a virtual USB-to-I2C driver running in an Android emulator, thus virtualizing the authentication coprocessor on the computer. An MFi application can then run seamlessly in the Android emulator.

[0006] In various embodiments, the MFi application includes Apple CarPlay. The MFi application may execute in an upper layer of the Android emulator, accessible through one or more lower layers, including a layer corresponding to the virtual USB-to-I2C driver coupled to the virtualized authentication processor. CarPlay may execute on top of an Apple communications plug-in and an Interface Accessory Protocol ("IAP") stack in the Android emulator. One MFI protocol for communication between an iPhone and an accessory is an IAP, now known as the "iPhone Accessory Protocol." The IAP stack is a communications system that enables transfers between an iPhone and an accessory over USB and other communications protocols.The CarPlay communication plugin and the MFi IAP stack layer can be inserted between the virtual USB-to-I2C driver and the Android emulator's CarPlay or other MFi applications. The Android emulator can be used to develop and test CarPlay directly on the Android emulator, and then optimize CarPlay in a target vehicle's infotainment system. A USB port to which the USB dongle or other external device is connected is controlled by a USB driver, where the USB driver supports USB device passthrough, passing data as a virtual USB device to the USB-to-I2C driver running in the Android emulator's kernel. While a USB dongle is used in this example, in other embodiments, the authentication coprocessor and other elements can be part of another external device connected to the computer.The CarPlay application can obtain a certificate from the virtualized authentication processor. In response to receiving the query results, the application can send query data to request the authentication processor to calculate the query data received from the iPhone. The application then sends the query result back to the iPhone to complete the authentication process.

[0007] In another aspect of the disclosure, a computing device for enabling CarPlay authentication in an Android emulator includes memory storing a computer operating system (OS). The computer further includes a main CPU coupled to the memory and configured to execute the MFi application code. The device includes a USB dongle configured to connect to a USB bus via a bus interface. The USB dongle includes an authentication coprocessor coupled to an I2C-to-USB converter when the USB dongle is connected to a corresponding USB port. The device further includes driver code stored in the memory and executable on the main CPU along with the operating system for managing data exchange between the authentication processor and the main CPU.The main CPU executes code to create an Android emulator that runs a CarPlay application as a virtual component. The Android emulator contains a USB-to-I2C driver configured to virtualize the authentication coprocessor as an I2C device running with the CarPlay application.

[0008] In various embodiments, the device includes USB device pass-through code stored in memory and executed on the main CPU to virtualize the authentication coprocessor as an I2C device in the Android emulator. The USB device pass-through code is further configured to pass USB device data from the USB interface to a USB-to-I2C driver operating virtually in the Android emulator. The Android emulator also includes a CarPlay plugin and an IAP stack to allow the I2C device data converted by the USB-to-I2C driver to communicate with the CarPlay application via the CarPlay plugin and IAP stack. In various embodiments, a user can develop application software for the CarPlay application using the Android emulator to emulate an infotainment system of a target vehicle.The user can test application software for the CarPlay application using the Android emulator to emulate the infotainment system. The Android emulator can be configured to run on a Linux OS kernel, which is stored in memory and executed on the main CPU.

[0009] In yet another aspect of the disclosure, a computer for executing an MFi application in an emulator is described. The computer includes a memory and at least one central processing unit (CPU) coupled to the memory and configured to execute code to provide a virtual emulator. The computer provides code stored in the memory and configured to manage data via a USB interface having a port to which a dongle with an authentication coprocessor can be connected. The computer further includes a USB driver on the PC. The USB driver runs as executable code in an operating system of the PC. The USB driver is configured to provide a pass-through function for the authentication coprocessor. The dongle includes an I2C authentication processor and is configured to connect to the MFi application via a USB-to-I2C converter on the dongle.The USB-to-I2C converter is coupled with the bus interface and the pass-through function.

[0010] In various embodiments, the pass-through feature is configured to deliver data from the authentication processor to a USB-to-I2C converter running in a kernel of the emulator. The USB-to-I2C converter can be virtually coupled to the MFi application in the emulator using an Apple communications plugin and an IAP stack. The MFi application can be Apple CarPlay. In one embodiment, the emulator runs with a Linux kernel. In one embodiment, the emulator is an Android emulator.

[0011] The above summary is not intended to describe every embodiment or aspect of the present disclosure. Rather, the above summary merely illustrates some of the novel concepts and features set forth herein. The above features and advantages, as well as other features and associated advantages of this disclosure, will be readily apparent from the following detailed description of the illustrated examples and representative modes for carrying out the present disclosure, taken in conjunction with the accompanying drawings and the appended claims. Furthermore, this disclosure expressly includes the various combinations and subcombinations of the elements and features set forth above and below. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings, which are incorporated in this specification, illustrate implementations of the disclosure and, together with the description, explain the principles of the disclosure. Fig. 1 is a conceptual diagram of an emulator running in a main CPU of a computer and connected via a USB interface to an authentication coprocessor virtualized within the emulator for use with an MFi application such as CarPlay, according to one aspect of the disclosure. Fig. 2 is a flowchart of a method for authenticating an MFi application in an emulator, according to one aspect of the disclosure. Fig. 3A is a conceptual diagram illustrating an interaction between a physical authentication coprocessor and a CarPlay application running in a main CPU on an Android emulator, according to one aspect of the disclosure. Fig. 3B is a conceptual diagram of an execution thread showing an instance of the emulator and the CarPlay application executing on a CPU, memory, and a USB bus according to an aspect of the disclosure.

[0013] The accompanying drawings are not necessarily drawn to scale and may present a simplified representation of various features of the present disclosure, including, for example, certain dimensions, orientations, positions, and shapes. In some cases, readily apparent features may be omitted from certain drawings so as not to unduly obscure the concepts of the disclosure. The details associated with such features will be determined in part by the particular intended application and use environment. While the accompanying drawings, together with the disclosure, will provide an adequate description of the subject matter described herein to anyone skilled in the art, in some cases, for the benefit of those skilled in the art, excessive details known in the art may be omitted so as not to unduly obscure key concepts of various embodiments of the disclosure. DETAILED DESCRIPTION

[0014] The present disclosure may be embodied in many different forms. Representative examples of the disclosure are illustrated in the drawings and are described in detail herein as non-limiting examples of the principles disclosed. To this end, elements and limitations described in the "Summary," "Introduction," "Description," and "Detailed Description" sections, but not explicitly recited in the claims, should not be incorporated into the claims, individually or collectively, by implication, inference, or otherwise.

[0015] For the purposes of this specification, the use of the singular includes the plural and vice versa, unless expressly excluded; the terms "and" and "or" apply both subjunctive and disjunctive; and the words "including," "containing," "comprising," "having," and the like mean "including without limitation." Furthermore, words of approximation such as "approximately," "almost," "substantially," "generally," "about," etc. may be used herein to mean "at, near, or almost at," or "within 0-5% of," or "within acceptable manufacturing tolerances," or logical combinations thereof. A component "designed" to perform a particular function is capable of performing the stated function without modification, rather than merely having the potential to perform the stated function after further modifications.In other words, if the hardware described is expressly designed to perform the specified function, it is specifically selected, created, implemented, used, programmed and / or designed to perform the specified function.

[0016] While the principles of the disclosure are described with respect to CarPlay, it will be understood that the disclosure is not so limiting and may well extend to any MFi application distributed and provided for use in a vehicle or other device, the latter, due to its awkward geometry and less than ideal use as a test or development platform, preferably employing the principles described herein prior to actually implementing the corresponding solution in the vehicle or other device.

[0017] As previously mentioned, the principles of this disclosure provide effective virtualization for applications such as CarPlay on an Android emulator running on at least one main CPU corresponding to a desktop or laptop computer, or another computer. In the case of CarPlay, it was discovered that the design of the Apple authentication coprocessor (here an example of an "authentication coprocessor") is distributed with CarPlay to connect to the main CPU in the embedded system described above via an I2C bus. It was further discovered that the main processor(s) of existing desktop or laptop computers cannot directly connect to Apple's authentication processor. Therefore, the CarPlay application cannot be supported for testing and application development using a computer, which would otherwise be faster and more efficient.Examples of application development include the development of CarPlay-compatible applications that maximize the benefits of CarPlay on the vehicle manufacturer's specific infotainment platform, as well as other applications that enhance or enhance the use of the infotainment platform in conjunction with CarPlay. Instead, CarPlay software development, if any, may only be performed on the embedded infotainment system.

[0018] Accordingly, in one aspect of the disclosure, authentication methods are provided that enable virtualization for MFi applications such as CarPlay in an Android emulator using a main CPU on a computer. In various embodiments, these methods enable the I2C-based authentication coprocessor to connect virtually to a computer via a USB interface. The computer used to test the application and develop software to integrate CarPlay into a target vehicle may be a laptop, a desktop computer, a workstation, a server, or, in some cases, two or more of the foregoing. While this and other embodiments refer to a "processor" or "main CPU," for the purposes of this disclosure, the main processor or main CPU may also refer to a plurality of processors or CPUs.The one or more processors or CPUs may operate on a machine, or the one or more processors or CPUs may operate on one computer or a plurality of computers. In each case, the one or more main processors or CPUs are referred to as a "processor," "CPU," or "main CPU" for the purposes of this disclosure.

[0019] Furthermore, the principles of the disclosure encompass both hardware and software. Software, in its broadest sense, may include any type of source code, object code, firmware, middleware, application programming interface, routines, programs, or similar concepts. Code may be used herein as a related term to describe the various types of software, such as object code executing on a main CPU or an authentication coprocessor, depending on the context. The hardware in this disclosure includes at least a computer running the main processor or CPU, a USB dongle containing an authentication coprocessor, and internal computer elements such as memory, one or more buses, USB ports, interfaces, and the like. Because the disclosure encompasses both hardware and software, the application coprocessor (e.g.,The Apple Application Coprocessor (Apple Application Coprocessor) can be virtualized as an I2C device on the computer side, as described below with reference to the various drawings. This virtualization allows applications such as CarPlay to run on an Android emulator on the computer (in the sense of a virtual machine). Running CarPlay or a similar MFi application within the Android emulator, along with the virtual authentication coprocessor on the computer side, in turn, means that the development of CarPlay as used for a specific infotainment system can include productivity and efficiency gains. This means that, in this example, CarPlay does not need to run within the infotainment system as an embedded system during the testing and application development phases.Rather, testing and software development can be optimized on a fast and efficient virtual system that does not have unnecessary restrictions imposed by the complex infotainment system.

[0020] Fig. 1 is a conceptual diagram of an Android emulator 104 running on a computer 102 and connected via a USB interface 108 to an authentication coprocessor 124 virtualized within the Android emulator for use with an MFi application such as CarPlay 114, in accordance with one aspect of the disclosure. An Android emulator, also referred to as an Android virtual machine, is software that emulates the Android operating system and its functionality on a computer. The Android emulator 104 may be beneficial for vehicle infotainment systems running an Android operating system. In particular, the Android emulator 104 may create a virtual representation of a phone or other device running in an Android environment. The Android emulator 104 then runs the Android operating system as if it were running on a physical implementation of that device. Fig. Figure 1 shows a computer 102, e.g., one or more of the computers described above, for use for development and testing purposes. In this case, the computer 102 may be, for example, a laptop computer. For simplicity, such a computer is shown. The computer 102 is connected to a Universal Serial Bus (USB) dongle 110 (a hardware component) via a USB interface 108 (which may include a hardware, software, and virtual component) that may lead to and extend into a port built into the computer 102 (see Fig. 3B). With further reference to Fig. 1, the laptop USB driver 120 is a software module that executes using code in the processor or main CPU 350 of the computer 102 ( Fig. 3B). For the purposes of Fig. 1, it is assumed that the computer 102 includes the elements of a laptop computer, including a main CPU / processor, memory, and the various internal hardware and software interfaces (drivers, buses, combinational logic, northbridge and southbridge chips, non-volatile memory), all under the control of an operating system and various applications and protocols stored in and retrieved from dynamic random access memory.

[0021] The USB dongle 110, connected to the computer 102 via the USB bus interface 108, may be controlled at least in part by the laptop USB driver 120 running within the operating system of the computer 102. In this embodiment, the USB dongle 110 includes an authorization coprocessor 124, which may be, by way of example, an Apple authorization coprocessor as described herein. The authorization coprocessor 124 runs over an inter-integrated interconnect (I2C). An inter-integrated interconnect ("I2C") includes a corresponding I2C interface 112 (sometimes referred to as an "I2C bus") used for data exchange between the authorization coprocessor 124 and the external environment. Here, the USB dongle 110 also contains a USB-to-I2C converter, which allows USB-based data (e.g., authentication data) to be converted into I2C data before it is received in the authorization processor 124.Since the I2C interface 112 can be bidirectional, the converter 122 can convert output data from the authentication processor 124 into USB data. The USB data can then be transmitted via the USB interface 108 to the computer 102 or virtually to the Android emulator.

[0022] As previously mentioned, in the above embodiment, the USB dongle 110 is used to provide the authentication coprocessor and the corresponding hardware for use by the computer. However, in other embodiments, the USB dongle 110 may instead comprise another external device that can be coupled to a suitable interface of the computer to perform the same functions.

[0023] An advantage of the principles of the disclosure is the small size and component count, and thus the relatively low cost, of the combination of USB dongle 110 and computer 102. In the CarPlay embodiment, the authentication coprocessor 124 can be used to decrypt data during the testing and software development phase with a target vehicle. The USB-to-I2C converter 122 and the I2C interface 112 can be developed as custom modules, or they can be provided as commercial-off-the-shelf (COTS) elements along with the USB dongle 110. Accordingly, the principles of the disclosure do not require extensive amounts of additional hardware to achieve their otherwise powerful goals.

[0024] In various embodiments, the operating system of computer 102 may virtually detect a USB device (e.g., USB dongle 110 and data therefrom), which may forward this data to the virtual machine of Android emulator 104. In some embodiments, the operating system (OS) running in the virtual machine is different from the laptop's operating system. In one embodiment, the lower layer (kernel) of the Android emulator's operating system is Linux. The underlying operating system of computer 102 may be Windows or another operating system. In various embodiments, the operating system of computer 102 may therefore need to pass the USB device (embodied by USB dongle 110 and the corresponding USB interface, and possibly the exchanged USB data) running in the virtual machine of Android emulator 104.

[0025] In various embodiments, the Linux kernel driver running in the virtual machine of the Android emulator 104 can assist in virtualizing and converting the USB device into an I2C device. To achieve this, the Linux kernel can provide an Android Linux USB-to-I2C driver 118 that runs on the lowest stack in the Android emulator 104. In the continued example of CarPlay, an Apple Communication Plugin 116 can be provided as an intermediate layer of the Android emulator 104.Using the Apple Communication Plugin 116 and the Android Linux USB-to-I2C driver 118, the Apple CarPlay application 114 can access the remote authentication coprocessor 124 via the USB interface 108 using a virtualized method analogous to the way the local I2C interface 112 in the USB dongle 110 accesses data on an SoC ultimately used in the infotainment system of the target vehicle for which the software in question is being tested and optimized. The CarPlay application 114 can also access MFi-based data via the Apple Communication Plugin 116 within the Android emulator 104.

[0026] As in Fig. 1, the MFi application, such as the CarPlay application 114, runs in the Android emulator 104 as part of a virtual machine. For example, CarPlay may read the authentication certificate stored in and transmitted by the authentication coprocessor 124. The CarPlay application 114 may then, using the Android emulator 104, write the challenge data needed to request the authentication coprocessor 124 (here, the Apple authentication coprocessor) to calculate the challenge response data to the authentication coprocessor 124 via the USB bus 108 and other elements. The CarPlay application 114 may then read the challenge-response data provided by the authentication coprocessor 124 to respond to the MFi mobile device (in this example, an iPhone) and complete the authentication process.

[0027] Fig. 2 is a flowchart 200 of a method for authenticating an MFi application in an emulator, in accordance with one aspect of the disclosure. The steps of Fig. 2 can be performed by one or more computers as described herein, such as a laptop computer or a desktop computer connected to a USB dongle. While different phenomena can occur at different levels of abstraction to perform the steps of Fig. 2, certain of these underlying phenomena may be omitted to clarify the steps taken to establish the Android emulator session. As previously mentioned, a USB dongle is first provided in logic block 202. The USB dongle may include an authentication coprocessor connected via an I2C interface to a USB-to-I2C converter that may be located in the USB dongle. The authentication coprocessor, in these examples, may be configured to enable a non-MFi protocol to interface with an MFi protocol. In the example of Fig. 1, the authentication coprocessor 124 can run as a virtual device within the Android emulator on the computer side, so that, for example, communication (including from and to an iPhone or other mobile device) can be encrypted or decrypted.

[0028] Referring to logic block 204 of Fig. 2, the computer (including the Android emulator) can receive data from the USB dongle's USB-to-I2C converter at a USB port on the computer. The USB dongle can be connected to the computer's USB port via a USB interface. At logic block 206, the data, now converted to USB form, can be forwarded via a USB device pass-through to a virtual USB-to-I2C driver running in a kernel of the Android emulator (e.g., a Linux kernel), thereby virtualizing the authentication coprocessor as an I2C device on the computer side. This simple addition of the USB dongle has significant advantages in terms of flexibility and efficiency when developing software for Apple CarPlay or a similar MFi application specific to the target vehicle's infotainment architecture.

[0029] In the next logic block 208, an MFi application such as CarPlay can be executed in the Android emulator at an upper level. CarPlay is now accessible to the virtualized authentication coprocessor on the computer side. The encrypted communication can now be seamlessly decrypted via the virtualized authentication coprocessor.

[0030] In logic block 210, a plug-in layer required in one embodiment can be integrated to enable an Apple communication plug-in and an IAP stack in the Android emulator for communication with the virtual USB-to-I2C driver and the MFi application of the Android emulator. Through the plug-in, CarPlay can communicate with the lower layers, including the Android Linux USB-to-I2C driver in the embodiment of Fig. 1 communicate easily.

[0031] Referring to logic block 212 of Fig. 2, in an embodiment where the MFi application running in the Android emulator is CarPlay, engineers can test CarPlay and develop software compatible with CarPlay and tailored to the infotainment system in the target vehicle directly on the Android emulator for subsequent optimization of CarPlay in a vehicle dashboard or other location where the embedded main SoC is to be placed. Logic block 214 refers to the embodiment where a Linux kernel is used as the kernel of the Android emulator, which upon receiving the authenticated data via the USB device pass-through mechanism, as in Fig. 1 described, can be helpful.

[0032] Because the identity of the target vehicle changes, engineers can develop different software algorithms compatible with each specific target vehicle. This goal can be achieved without the need to implement CarPlay with an authentication processor on a system-on-chip (SoC). This final step must be realized only after CarPlay has been thoroughly tested for the vehicle in question and the software compatible with that infotainment system has been fully developed.

[0033] Fig. 3A is a conceptual diagram illustrating an interaction between a physical authentication processor and a CarPlay application 332 running in a main CPU on an Android emulator, according to one aspect of the disclosure. More specifically, in the Fig. In the example shown in Figure 3A, three virtual paths 334, 336, and 338 are depicted to perform three interactions between the CarPlay application 332 and the virtualized authentication coprocessor 330. The Android emulator is a collection of code that represents a virtual device that mimics the functionality of the Android operating system on the computer. It can be used to debug, test, or run Android applications. In this case, the Android emulator was designed to virtualize an MFi-based application. The USB device passthrough described in this disclosure is a feature that allows a user to transfer data, charge devices, and connect peripherals over a USB connection. USB passthrough, in some cases, allows a USB device to be connected directly to the system without using a USB hub.Therefore, in some examples, pass-through may eliminate the need for additional connectors or cables. A result of this simplification is faster and more efficient communication. In some embodiments, a pass-through system may be used to simplify various aspects of the communication described in . Fig. 3A described virtual paths can be used.

[0034] As in Fig. 3A, the emulator's virtual machine, within which the CarPlay application 332 is executed, runs on the main CPU 360 side of the test configuration. This means that an instance of a virtual machine is a digital representation that emulates real parts. The authentication coprocessor 330 is physically housed on the USB dongle 362 side of the test configuration. As described in the above embodiments, the collective main CPU 360 side is located on the computer side, and the USB dongle side 362, while located in the USB dongle device, can enable the virtual emulator to execute the CarPlay application 332 on the main CPU 360 side from the perspective of CarPlay. It should be understood that the representation of Fig. 3A shows three interactions for testing the CarPlay application 332 with an iPhone (virtual onboard or discrete) by utilizing the data in the authentication coprocessor 330 virtualized in the Android emulator. However, these three interactions are only exemplary. As the software testing and development progresses, additional and different interactions may take place, regardless of whether the virtualized authentication processor is used. Furthermore, the types of virtual interactions that take place may change with the target vehicle and the respective infotainment system, which in turn may be accommodated by adapting the code running the Android emulator.

[0035] With initial reference to Fig. 3A includes a first virtual path 334, which allows the CarPlay application 332 or the corresponding iPhone to be provided with data required for authentication purposes, such as an authentication certificate, via the Android emulator. Fig. 3A, the iPhone and the authentication coprocessor can communicate by exchanging various messages. In one example, a connection can be established between the authentication coprocessor and an MFi application such as CarPlay. The virtual path 334 is shown in Fig. 1. Brief reference to Fig. 1, the virtual path 334 includes an authorization certificate in the form of I2C data received from the authorization coprocessor 124 (or authentication coprocessor 330 in Fig. 3A) and sent to the USB-to-I2C converter 122 via the I2C interface 112. The bidirectional nature of the converter 122 can be used to convert the I2C data into USB data, which in turn is sent to the Android emulator via the USB interface through a USB device passthrough 106 (which can be controlled by the computer operating system, the emulator kernel, and the USB driver 120). The USB data is converted back into I2C-formatted data by the driver 118, and the Apple communication plug-in 116 can be used to provide the authentication certificate for the CarPlay application 114. Back to Fig. 3A: The virtual path 334 is completed when the CarPlay application 332 receives the authentication certificate.

[0036] As in Fig. 3A, the CarPlay application 332 running in the Android emulator may read the provided certificate and then respond by writing challenge data to request the authentication processor 330 to decrypt the data via a next virtual path 336. The virtual path 336 may be physically implemented in reverse as described for the virtual path 334. Other embodiments may provide dedicated physical channels for bidirectional communication. In this case, the virtual path 334 transmits the challenge data back to the authentication coprocessor 330. The authentication coprocessor 330 may read the received challenge data and then send decrypted data in the form of challenge response data back to the CarPlay application 332 on the main CPU side 360 ​​via a third virtual path 338.The physical form of the third virtual path 332 is identical to that of the virtual path 338, except for the data content. The decrypted data now received in the CarPlay application 332 from the authentication coprocessor 330 via the virtual path 338 can be used to respond back to a corresponding iPhone to complete the authentication process.

[0037] In general, any virtual communication in the Android emulator physically passes through an I2C interface, a USB-to-I2C converter (which may be bidirectional in some embodiments and dedicated to one direction in other embodiments), and a USB interface. The USB device and corresponding data are virtualized using the computer's driver and operating system in conjunction with the USB device passthrough. The resulting data passes through a USB-to-I2C driver and, in some embodiments, a suitable Apple communication plugin before finally reaching the virtual instance of CarPlay running on the Android emulator.

[0038] As mentioned previously, one MFI protocol for communication between an iPhone and an accessory is iAP, now known as the iPhone Accessory Protocol. The IAP stack is a communication system that enables transfers between an iPhone and an accessory via USB and other communication protocols. An example of using the IAP protocol for authentication and communication between an iPhone, corresponding to a CarPlay or other MFi application, and an authentication coprocessor is shown in Fig. 3B.

[0039] Fig. 3B is a conceptual diagram of physical devices that create a thread of execution during an instance of the emulator and the CarPlay application executing on a processor (main CPU), memory, and a USB bus according to one aspect of the disclosure. Fig. Figure 3B shows the main processor / CPU 350, which is the physical processor in the computer 102 in which the Android emulator 104 is executed. As already mentioned in previous embodiments, the main processor / CPU 350 may actually consist of a plurality of processors, each of which may include one or more central processing units (CPUs) and / or cores. The main processor / CPU 350 is configured to execute the code that creates the virtual emulator 104. Since the virtual emulator 104 is Fig. 3B at a given point in time, this figure can be understood as conceptually illustrating one or more threads of execution captured at a given point in time. A thread is a sequence of execution. In some definitions, it is the smallest sequence that can be individually scheduled by an operating system scheduler. Here, however, a thread refers only to the main CPU and other components performing an action.

[0040] Furthermore, Fig. 3B, dynamic random access memory (DRAM) 355 is shown, although other memory types may be used. DRAM 355 is likely the memory in which the code used for execution on processor 350 is temporarily stored to perform tasks quickly and efficiently. Unlike in Fig. 3B, the main processor / CPU may be separate from memory, as is the case in most common computer architectures. For simplicity, the main processor / CPU 350 is shown with DRAM 355. However, in other embodiments, the main processor / CPU 350 may be mounted on a motherboard and communicate with the DRAM 355 through one or more bridge interface circuits. In some embodiments, the processor includes a cache memory that stores frequently used data for fast access. Bus 352 is also shown. In one aspect, bus 352 represents physical conductors that allow the main processor / CPU 350 to exchange data and code with the DRAM 355.

[0041] In another aspect, the bus 352 may represent a virtual means for exchanging data within the computer 102. In a virtual representation of Fig.3, for example, the CarPlay application 332 runs in the Android emulator 104. The Android emulator 104, in turn, is coupled to other components via the bus 352 and the virtual interface 356, which may be a USB interface. The circuitry that converts USB to another serial form of communication (and vice versa) on the motherboard is not shown for clarity. Also shown conceptually is the USB driver 120, which is physically represented by code running in the main processor / CPU 350 within the operating system of the computer 102. Shown adjacent to the driver 120 is the USB device passthrough 106, which assists in transferring data from a USB port 353 via the interface 356 to the Android emulator 332.

[0042] In alternative embodiments, the combination of bus 352 and USB interface 356 can be conceptually viewed as a data exchange between the authentication coprocessor 330 and the CarPlay application 332. Physically, the authentication coprocessor 330 is located in the USB dongle 363. Virtually, from the perspective of CarPlay, the authentication coprocessor 330 is located as a component within the Android emulator 104. Furthermore, in practice, the Android emulator 104 is executed digitally as a virtual machine using the main processor / CPU 350 based on the code stored in the DRAM 355 (and in some cases, on another computer-readable medium such as a flash drive, hard drive, etc.) and the authentication coprocessor 330. While the authentication coprocessor 330 is physically located on the dongle 363, it is virtually located on the side of the computer 102 running in the Android emulator.

[0043] It should also be noted that the computer's operating system may be stored in non-volatile memory, such as a magnetic disk drive or a solid-state drive. Relevant portions of the operating system, including the kernel, may then be loaded into DRAM 355 when the computer 102 is first turned on. Furthermore, a Linux or other separate operating system, or a kernel of the operating system, may be stored in DRAM 355. All operating systems may be executed by the processor 332 to enable the computer's activities and to implement the Android emulator, which may, for example, use a Linux kernel.

[0044] The detailed description and the drawings or figures are supportive and descriptive of the present teachings, but the scope of the present teachings is defined solely by the claims. While some of the best modes and other embodiments for carrying out the present teachings have been described in detail, various alternative designs and embodiments exist for carrying out the present teachings defined in the appended claims. Furthermore, this disclosure expressly includes combinations and subcombinations of the elements and features presented above and below.

Claims

[1] A method for MFi application virtualization in an Android emulator on a computer, comprising: Providing a Universal Serial Bus (USB) dongle with an authentication coprocessor coupled to a USB-to-I2C converter via an Inter-Integrated Circuit (I2C) interface, wherein the authentication coprocessor is used to enable a non-MFi protocol on an interface with an MFi protocol, Receiving data from the USB to I2C converter to the computer via a USB interface; Passing the data via a USB device pass-through to a virtual USB-to-I2C driver running in an Android emulator to virtualize the authentication coprocessor on the computer; and Running an Apple communication plugin and an IAP stack simultaneously with the MFi application in the Android emulator. [2] The method of claim 1, further comprising executing the MFi application in an upper layer of the Android emulator accessible through one or more lower layers, including a layer corresponding to the virtual USB to I2C driver coupled to the virtualized authentication processor. [3] The method of claim 1, further comprising executing the MFi application at an Apple communication plugin and IAP stack layer in the Android emulator, wherein the Apple communication plugin and IAP stack layer is above the virtual USB to I2C driver layer. [4] The method of claim 1, wherein the MFi application comprises Apple CarPlay. [5] The method of claim 4, further comprising developing and testing CarPlay directly on the Android emulator for subsequent optimization of CarPlay in an infotainment system of a target vehicle. [6] A computer for running an MFi application in an emulator, comprising: a memory; at least one main CPU coupled to the memory and configured to execute code to provide a virtual emulator; Code stored in the memory and configured to manage data via a USB interface having a connector into which a dongle with an authentication coprocessor is pluggable; and a USB driver on the PC, the USB driver running in an operating system of the PC, the USB driver configured to provide a pass-through feature for the authentication coprocessor; wherein the dongle includes an I2C authentication coprocessor and is configured to connect to the MFi application using a USB-to-I2C converter on the dongle, the USB-to-I2C converter coupled to the bus interface and the pass-through feature. [7] The computer of claim 6, wherein the pass-through feature is configured to provide data from the authentication coprocessor to a USB-to-I2C converter running in a kernel of the emulator. [8] The computer of claim 7, wherein the USB to I2C converter is virtually coupled to the MFi CarPlay application in the emulator using an Apple communications plug-in and an IAP stack. [9] The computer of claim 6, wherein the MFi application includes Apple CarPlay. [10] The computer of claim 6, wherein the emulator is executed using a Linux kernel.

Images