Application virtualization in simulator using authentication processor

Abstract

Apparatuses and methods are presented for enabling an MFi stack and a corresponding MFi application to be authenticated in a simulator operating using one or more processors / CPUs. In one aspect, a computer may include a memory and a processor configured to execute an operating system. The computer may include a USB bus coupled to a softdog through a USB interface. The softdog may include an authentication coprocessor for use in an integrated circuit (I2C) to USB configuration, and an I2C to USB computer. Driver code running on the computer may manage data exchanged between the authentication coprocessor and a virtual simulator on the computer. The simulator may include a USB to I2C driver that virtualizes the authentication coprocessor as an I2C device that runs with an MFi application, such as a CarPlay.

Description

[0001] introduction In recent years, many applications have been introduced for utilizing the benefits of mobile devices or smart phones in the context of larger devices. Examples of such larger devices include vehicles. In a typical scenario, a vehicle manufacturer may develop a Bluetooth-based application to enable a vehicle driver to speak "hands free" in a manner that avoids undesired manual use of the driver's mobile device while driving the vehicle.

[0002] An inherent challenge in developing software for use in other applications is that different programs are often produced using different operating systems and protocols. A dealer, for example, may intend to sell an application to a variety of different vehicle manufacturers. However, a significant percentage of those manufacturers may use specific technologies and protocols in their vehicles that are not always compatible with the technology in question. To overcome this obstacle, providers of these technologies may distribute additional authentication-based devices to vehicle manufacturers to enable purchasers (such as vehicle manufacturers) to authenticate the provider's technology in the purchaser's vehicle.

[0003] One such example is Apple TM CarPlay. CarPlay is a technology that can be used to project a consumer's iPhone screen to a vehicle infotainment display for use as part of an infotainment system. In order to enable non-Apple devices to connect to Apple devices (such as CarPlay), Apple designed a certified coprocessor to connect to (one or more) main processors in an embedded system via an internal integrated circuit ("I2C"). In this example, Apple provides the coprocessor design and requires manufacturers to assemble it together within a system on a chip (SOC). Therefore, a vehicle infotainment system that supports CarPlay requires a certified processor for certification purposes. Only then can CarPlay be connected for use. When customizing CarPlay for use with a specific vehicle, this restrictive scenario creates the following problem: manufacturers must use the actual infotainment system to develop applications for CarPlay and test CarPlay. For example, engineers need to use infotainment hardware to build software and then flash the image to the target hardware for testing. Performing these processes through the vehicle's infotainment system is complex and time-consuming. Summary of the invention

[0004] To improve productivity and to develop and test applications (such as CarPlay) before they are provided for mainstream use in vehicles as intended, the principles of the present disclosure are introduced to virtualize the application on an Android emulator running on one or more desktop or laptop computers.

[0005] Various aspects of "Made for iPhone" ("MFi") application virtualization in an emulator (such as the Android emulator) using an authenticator coprocessor are provided herein. 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, which includes an authentication coprocessor coupled to a USB to I2C converter via an inter-integrated circuit (I2C) interface. The authentication coprocessor enables non-MFi protocols to interface with MFi protocols. The computer receives data from the USB to I2C converter via the USB interface. The data is forwarded to a virtual USB to I2C driver running in the Android emulator using USB device passthrough, thereby virtualizing the authentication coprocessor on the computer. MFi applications can then be executed seamlessly in the Android emulator.

[0006] In various embodiments, MFi applications include Apple CarPlay. MFi applications can be executed in an upper layer of an Android emulator accessible via one or more lower layers, including a layer corresponding to a virtual USB to I2C driver coupled to a virtualized authentication coprocessor. CarPlay can be executed on top of the Apple communication plug-in and interface accessory protocol ("IAP") stack in the Android emulator. The MFI protocol for communication between iPhone and accessories is IAP-now known as the "iPhone Accessory Protocol". The IAP stack is a communication system that facilitates transmission between iPhone and accessories using USB and other communication protocols. The CarPlay communication plug-in and the MFi IAP stack layer can be layered between the virtual USB to I2C driver and the CarPlay or other MFi applications of the Android emulator. The Android emulator can be used to develop and test CarPlay directly on the Android emulator for subsequent optimization of CarPlay in the infotainment system of the target vehicle. The USB port to which the USB dongle or other external device is coupled is regulated by a USB driver that helps the USB device passthrough as a virtual USB device to pass the data to the USB to I2C driver running in the kernel of the Android emulator. Although 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 receive a certificate from the virtualized authentication coprocessor. In response to receiving the challenge result, the application can send challenge data to request the authentication coprocessor to calculate the challenge data received from the iPhone. The application will then send the challenge result back to the iPhone to complete the authentication process.

[0007] In another aspect of the present disclosure, a computer device for enabling CarPlay authentication in an Android emulator includes a memory storing a computer operating system (OS). The computer further includes a main CPU coupled to the memory and configured to execute MFI application code. The device includes a USB dongle configured to be connected to a USB bus through a bus interface. The USB dongle includes an authentication coprocessor, and when the USB dongle is connected to the corresponding USB port, the authentication coprocessor is coupled to an internal integrated circuit (I2C) to USB converter. The device further includes a driver code stored in the memory and executable on the main CPU with the OS for managing data exchange between the authentication coprocessor and the main CPU. The main CPU executes code to generate an Android emulator that runs a CarPlay application as a virtual component. The Android emulator includes a USB to I2C driver, which is configured to virtualize the authentication coprocessor as an I2C device running with the CarPlay application.

[0008] In various embodiments, the apparatus includes a USB device pass-through code stored in a memory and configured to enable the authentication coprocessor to be virtualized as an I2C device in an Android emulator when executed on the main CPU. The USB device pass-through code is further configured to forward USB device data from a USB interface to a USB to I2C driver that operates virtually within the Android emulator. The Android emulator further includes a CarPlay plug-in and an IAP stack so that the I2C device data converted by the USB to I2C driver can communicate with the CarPlay application via the CarPlay plug-in and the IAP stack. In various embodiments, a user can use the Android emulator to simulate the infotainment system of a target vehicle to develop application software for CarPlay applications. A user can use the Android emulator to simulate an infotainment system to test application software for CarPlay applications. The Android emulator can be configured to run on a Linux OS kernel that is stored in a memory and executed on the main CPU.

[0009] In still another aspect of the present disclosure, a computer for running an MFi application in a simulator is described. The computer includes a memory and at least one central processing unit (CPU) coupled to the memory and configured to execute code for providing a virtual simulator. The computer provides code stored in the memory and configured to manage data through a USB interface having a port, and a dongle with an authentication coprocessor is configured to be connected to the port. The computer further includes a USB drive on the PC. The USB drive runs as executable code in the operating system of the PC. The USB drive is configured to provide a pass-through feature for the authentication coprocessor. The dongle includes an internal integrated circuit (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 is coupled to the bus interface and the pass-through feature.

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

[0011] The present application provides the following embodiments: 1. A method for running a Made for iPhone (MFi) protocol for communicating between an iPhone and an iPhone Accessory Protocol (IAP) using application virtualization in an Android emulator on a computer, wherein the iPhone Accessory Protocol (IAP) facilitates transfers between the iPhone and the accessory using USB and other communication protocols, the method comprising: providing a Universal Serial Bus (USB) dongle or other external device including an authentication coprocessor coupled to a USB to I2C converter via an Inter-Integrated Circuit (I2C) interface, the authentication coprocessor being used to enable non-MFi protocols to interface with MFi protocols, receiving data from the USB to I2C converter at a computer via a USB interface; forwarding the data to a virtual USB to I2C driver running in an Android emulator using USB device passthrough, thereby virtualizing the authentication coprocessor on a computer; and The Apple communication plugin and IAP stack are executed concurrently with the MFi application in the Android emulator.

[0012] 2. The method according to embodiment 1 further includes executing the MFi application in an upper layer of the Android emulator that is accessible via one or more lower layers, wherein the one or more lower layers include a layer corresponding to a virtual USB to I2C driver layer coupled to a virtualized authentication coprocessor.

[0013] 3. The method according to embodiment 1 further includes executing the MFi application on top of an Apple communication plug-in and an IAP stack layer in the Android emulator, wherein the Apple communication plug-in and the IAP stack layer are on top of the virtual USB to I2C converter.

[0014] 4. The method of embodiment 1, wherein the MFi application comprises Apple CarPlay.

[0015] 5. The method according to Example 4 further includes developing and testing CarPlay directly on the Android emulator for subsequent optimization of CarPlay in the infotainment system of the target vehicle.

[0016] 6. A method according to embodiment 1, wherein the USB port to which the USB dongle or other external device is coupled is regulated by a USB driver, which helps the USB device to pass through as a virtual USB device to pass the data to the USB to I2C driver running in the kernel of the Android emulator.

[0017] 7. The method according to embodiment 1, further comprising: receiving, at the MFi application, a credential from a virtualized authentication coprocessor; and In response to receiving the challenge response data, the challenge data is sent from the MFi application to request the authentication coprocessor to calculate the challenge response data, and then send the challenge response data back to the corresponding iPhone to complete the authentication.

[0018] 8. An apparatus for enabling CarPlay authentication in an Android emulator, comprising: a memory storing a computer operating system (OS); a main central processing unit (CPU) coupled to the memory and configured to execute OS code; a universal serial bus (USB) dongle configured to connect to a USB bus through a bus interface, the USB dongle or other external device including an authentication coprocessor coupled to an inter-integrated circuit (I2C) to USB converter when the USB dongle is connected to a corresponding USB port; and A driver code stored in the memory and executable together with the OS on the main CPU, for managing data exchange between the authentication coprocessor and the main CPU; The main CPU executes code to generate an Android emulator that runs the CarPlay application as a virtual component, the Android emulator including a USB to inter-integrated circuit ("I2C") driver configured to virtualize the authentication coprocessor as an I2C device that runs with the CarPlay application.

[0019] 9. The apparatus according to embodiment 8 further comprises a USB device pass-through code, which is stored in a memory and configured to enable the authentication coprocessor to be virtualized as an I2C device in the Android emulator when executed on the main CPU.

[0020] 10. The apparatus of embodiment 9, wherein the USB device passthrough code is further configured to forward USB device data from a USB interface to a USB to I2C driver operating virtually within the Android emulator.

[0021] 11. An apparatus according to embodiment 8, wherein the Android emulator further includes an Apple communication plug-in and an Interface Accessory Protocol (IAP) stack so that the I2C device data converted by the USB to I2C driver can communicate with the CarPlay application via the Apple communication and Made for iPhone (MFi) plug-ins.

[0022] 12. The apparatus of embodiment 8, wherein a user is configured to use the Android emulator to simulate an infotainment system of a target vehicle to develop application software for the CarPlay application.

[0023] 13. The apparatus of embodiment 12, wherein a user is configured to use the Android emulator to simulate the infotainment system to test application software for the CarPlay application.

[0024] 14. The apparatus of embodiment 8, wherein the Android emulator is configured to run on a Linux OS kernel stored in a memory and executed on a main CPU.

[0025] 15. A computer for running an MFi app made for an iPhone in a simulator, comprising: Memory; at least one main central processing unit (CPU) coupled to the memory and configured to execute code for providing a virtual simulator; code stored in the memory and configured to manage data through a universal serial bus (USB) interface having a port into which a dongle or other external device having an authentication coprocessor is configured to connect; 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 or other external device includes an Inter-Integrated Circuit (I2C) authentication coprocessor and is configured to connect with the MFi application using a USB to I2C converter on the dongle or other external device, the USB to I2C converter being coupled to the bus interface and the pass-through feature.

[0026] 16. The computer of embodiment 15, 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.

[0027] 17. The computer of embodiment 16, wherein the USB to I2C converter is virtually coupled to an MFi CarPlay application in the simulator using an Apple communication plug-in and an Interface Accessory Protocol (IAP) stack.

[0028] 18. The computer of embodiment 15, wherein the MFi application comprises Apple CarPlay.

[0029] 19. The computer of embodiment 15, wherein the simulator runs using a Linux kernel.

[0030] 20. The computer of embodiment 15, wherein the emulator comprises an Android emulator.

[0031] The above summary of the invention is not intended to represent every embodiment or every aspect of the present disclosure. On the contrary, the above summary of the invention merely provides examples of some novel concepts and features set forth herein. When considered in conjunction with the accompanying drawings and the appended claims, the above-mentioned features and advantages of the present disclosure and other features and attendant advantages will become apparent from the following detailed description of the illustrated examples and representative modes for implementing the present disclosure. In addition, the present disclosure clearly includes various combinations and sub-combinations of the elements and features presented above and below. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate implementations of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0033] Figure 1 is a conceptual diagram of an emulator according to one aspect of the present disclosure, which runs in the main CPU of a computer and is attached to a certification coprocessor via a USB interface, which is virtualized for use with MFi applications (such as CarPlay) in the emulator.

[0034] Figure 2 is a flowchart of a method for authenticating an MFi application in an emulator according to an aspect of the present disclosure.

[0035] Figure 3A is a conceptual diagram illustrating the interaction between a physical authentication coprocessor and a CarPlay application running in a main CPU on top of an Android emulator according to an aspect of the present disclosure.

[0036] Figure 3B is a conceptual diagram of execution threads according to an aspect of the present disclosure, showing instances of a simulator and a CarPlay application running on a CPU, memory, and a USB bus.

[0037] The drawings are not necessarily drawn to scale, and may present simplified representations of various features of the present disclosure, including, for example, specific dimensions, orientations, positions, and shapes. In some cases, well-known features may be omitted in certain drawings to avoid unduly obscuring the concepts of the present disclosure. The details associated with such features will be determined in part by the specific intended application and use case environment. Although the drawings and the disclosure together provide a sufficient description to any technician in the subject area of ​​this article, for the benefit of those same technicians, excessive details known in the relevant art may be omitted in some cases to avoid unduly obscuring the central concepts of the different embodiments of the present disclosure. DETAILED DESCRIPTION

[0038] The present disclosure allows for embodiments in many different forms. Representative examples of the present disclosure are shown in the accompanying drawings and described in detail herein as non-limiting examples of the disclosed principles. For this reason, elements and limitations described in the abstract, introduction, summary, and detailed description but not explicitly set forth in the claims should not be incorporated into the claims individually or collectively by implication, inference, or otherwise.

[0039] For the purposes of this description, unless otherwise stated, the use of the singular includes the plural, and vice versa, the terms "and" and "or" shall be both conjunctive and disjunctive, and the words "comprising", "containing", "including", "having", etc. shall mean "including but not limited to". In addition, approximate words such as "about", "almost", "substantially", "substantially", "approximately", etc. may be used herein in the sense of "at, close to, or nearly at", or "within 0-5% of..." or "within an acceptable manufacturing tolerance", or a logical combination thereof. As used herein, a component that is "configured to" perform a specified function is capable of performing the specified function without modification, not merely having the potential to perform the specified function after further modification. In other words, the described hardware, when explicitly configured to perform a specified function, is specifically selected, created, implemented, utilized, programmed and / or designed for the purpose of performing the specified function.

[0040] While the principles of the present disclosure are described with respect to CarPlay, it will be appreciated that the present disclosure is not limited thereto and may well extend to any MFi application distributed and provided for use in a vehicle or other device, the latter's cumbersome geometry and non-ideal use as a test or development platform making the use of the principles of this document preferred prior to actually implementing a corresponding solution in a vehicle or other device.

[0041] As noted, the principles of the present disclosure provide effective virtualization for applications (such as CarPlay) on an Android emulator executed on at least one main CPU, which corresponds to a desktop or laptop computer or (one or more) other computers. In the case of CarPlay, it is noted that the design of an Apple-certified coprocessor (an example of a "certified coprocessor" in this article) is distributed with CarPlay to connect to the main CPU in the above-mentioned embedded system via an I2C bus. It is further noted that the (one or more) main processors or (one or more) main CPUs of existing desktop or laptop computers cannot be directly connected to Apple's certified processor. As a result, CarPlay applications cannot be supported for testing and application development using computers, which would have been faster and more efficient. Examples of application development include developing applications that are consistent with CarPlay and maximize the utility of CarPlay on a specific infotainment platform of a vehicle manufacturer, and other applications that enhance or bolster the infotainment platform used in conjunction with CarPlay. Instead, if CarPlay software development is carried out, it may only be carried out when it is implemented based on an embedded infotainment system.

[0042] Therefore, in one aspect of the present invention, an authentication method is provided that provides virtualization of MFi applications (such as CarPlay) in an Android emulator using a main CPU on a computer. In various embodiments, these methods enable an I2C-based authentication coprocessor to be virtually connected to a computer using a USB interface. The computer used to test applications and to develop software to integrate CarPlay into a target vehicle may be a laptop computer, a desktop computer, a workstation, a server, or in some cases two or more of the foregoing. Although this embodiment and other embodiments refer to a "processor" or "main CPU" for clarity, for the purposes of this disclosure, a main processor or main CPU may also refer to multiple processors or CPUs. One or more processors or CPUs may run on a machine, or one or more processors or CPUs may run on a computer or multiple computers. In any case, for the purposes of this disclosure, one or more main processors or CPUs are collectively referred to as "processors", "CPUs" or "main CPUs".

[0043] In addition, the principles of the present disclosure include both hardware and software. Software can broadly include any kind of source code, object code, firmware, middleware, application programming interface, routine, program or similar concepts. Code can be used as a related term to describe various types of software in this article, such as the object code executed on the main CPU or certification coprocessor when appropriate in this context. The hardware in the present disclosure includes at least a computer on which the main processor or main CPU is running, a USB dongle including a certification coprocessor, and internal computer elements including memory, one or more buses, USB ports, interfaces, etc. Because the present disclosure includes both hardware and software, the application coprocessor (e.g., Apple application coprocessor) can be virtualized as an I2C device on the computer side, as described below with reference to the various figures. This virtualization enables applications (such as CarPlay) to run on the Android emulator on the computer (in the jargon of the virtual machine (vernacular)). In turn, executing CarPlay or similar MFi applications in the Android emulator, together with executing a virtual certification coprocessor on the computer side, means that the development of CarPlay for a specific infotainment system can include an increase in productivity and efficiency. That is, in this example, CarPlay does not need to run as an embedded system within the infotainment system during the testing and application development phase. Instead, testing and software development can be optimized on a fast and efficient virtual system that does not have the unnecessary constraints introduced by a complex infotainment system.

[0044] Figure 11 is a conceptual diagram of an Android emulator 104 according to one aspect of the present disclosure, which runs in a computer 102 and is attached to a certification coprocessor 124 via a USB interface 108, which is virtualized for use with MFi applications (such as CarPlay 114) in the Android emulator. The Android emulator, also known as an Android virtual machine, is a software that simulates the Android OS and its functionality on a computer. The Android emulator 104 can be beneficial for a vehicle infotainment system running an Android OS. It is worth noting that the Android emulator 104 can 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 the device. Figure 1 A computer 102 is shown for development and testing purposes, such as one or more of any of the computers discussed above. In this case, for purposes of illustration, the computer 102 may be a laptop computer. For simplicity, one such computer is shown. The computer 102 is attached to a Universal Serial Bus (USB) dongle 110 (a hardware component) via a USB interface 108 (which may include hardware, software, and virtual components) that may lead to and extend within a port built into the computer 102 (see Figure 3B ). Continue to refer to Figure 1 , the laptop USB drive 120 is a computer 102 processor or main CPU 350 ( Figure 3B ) is a software module that executes the code in Figure 1 For purposes of this disclosure, it is assumed that computer 102 comprises the elements of a laptop computer, including a main CPU / processor, memory, and various internal hardware and software interfaces (drivers, buses, combinational logic, north bridge and south bridge 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.

[0045] The USB dongle 110 coupled to the computer 102 via the USB bus interface 108 can be controlled at least in part by a 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 for exemplary purposes can be an Apple authorization coprocessor as discussed herein. The authorization coprocessor 124 operates using an internal integrated connection (I2C). The internal integrated connection ("I2C") includes a corresponding I2C interface 112 (sometimes referred to as an "I2C bus"), which is used to exchange data between the authorization coprocessor 124 and the external environment. Here, the USB dongle 110 also includes a USB to I2C converter, which enables USB-based data (e.g., authentication data) to be recast into I2C data before being received at the authorization processor 124. Similarly, since the I2C interface 112 can be bidirectional, the converter 122 can transform the output data from the authentication coprocessor 124 into USB data. The USB data can then be provided to the computer 102 via the USB interface 108, or virtually provided to the Android emulator.

[0046] As noted, USB dongle 110 is used in the above-described embodiments to provide an authentication coprocessor and corresponding hardware for use with a computer. However, in other embodiments, USB dongle 110 may instead include another external device that can be coupled to a suitable interface of a computer to perform the same function.

[0047] One benefit of the principles of the present disclosure is the small size and number of components of the USB dongle 110 and computer 102 combination, and therefore the relatively low cost. In the CarPlay embodiment, the authentication coprocessor 124 can be used to decrypt data during the testing and software development phases involving the target vehicle. The USB to I2C converter 122 and the I2C interface 112 can be designed as custom modules, or they can be provided as commercial off-the-shelf (COTS) components together with the USB dongle 110. Therefore, the principles of the present disclosure do not require a large amount of additional hardware to achieve their otherwise powerful goals.

[0048] In various embodiments, the operating system of the computer 102 can virtually identify the USB device (e.g., USB dongle 110 and data from USB dongle 110), and the operating system can pass the data to the virtual machine of the Android emulator 104. In some embodiments, the operating system (OS) running in the virtual machine is different from the OS of the laptop computer. In one embodiment, the lower layer (kernel) of the operating system of the Android emulator is Linux. The underlying OS of the computer 102 can be Windows or another operating system. Therefore, in various embodiments, the OS of the computer 102 may need to be passed through the USB device running in the virtual machine of the Android emulator 104 (embodied in the USB dongle 110 and the corresponding USB interface and the USB data being exchanged (where applicable)).

[0049] In various embodiments, the Linux kernel driver running in the virtual machine of the Android emulator 104 can help virtualize USB devices and convert USB devices into I2C devices. To achieve this, the Linux kernel can provide an Android Linux USB to I2C driver 118, which runs at the lowest stack in the Android emulator 104. In the continued example of CarPlay, an Apple communication plug-in 116 can be provided as an intermediate layer of the Android emulator 104. Using the Apple communication plug-in 116 and the Android Linux USB to I2C driver 118, the Apple CarPlay application 114 can access the remote authentication coprocessor 124 through the USB interface 108 in a virtualized method, which is similar to the way the local I2C interface 112 in the USB dongle 110 accesses data on the SoC, which will eventually be used in the infotainment system of the target vehicle for which the subject software is tested and optimized. In addition, the CarPlay application 114 can access MFi-based data through the Apple communication plug-in 116 within the Android emulator 104.

[0050] Still reference Figure 1, MFi applications, such as the CarPlay application 114 running in the Android emulator 104, run as part of a virtual machine. For example, CarPlay can read the authentication certificate stored on and passed from the authentication coprocessor 124. The CarPlay application 114 using the Android emulator 104 can then use the USB bus 108 and other components to write challenge data to the authentication coprocessor 124, which is required to request the authentication coprocessor 124 (here, the Apple authentication coprocessor) to calculate the challenge response data. The CarPlay application 114 can then read via the challenge response data provided by the authentication coprocessor 124 to respond back to the MFi mobile device (iPhone in this example), thereby completing the authentication process.

[0051] Figure 2 is a flowchart 200 of a method for authenticating an MFi application in an emulator according to an aspect of the present disclosure. Figure 2 The steps of can be performed by one or more computers as described herein, such as a laptop or desktop computer connected to a USB dongle. Although various phenomena may occur at different abstraction levels to accomplish Figure 2 , but in order to illustrate the steps taken to establish the Android emulator link, some of these low-level phenomena may be omitted. Initially referring to logic block 202, as noted, a USB dongle is provided. The USB dongle may include an authentication coprocessor connected to a USB to I2C converter via an I2C interface, which USB to I2C converter may be within the USB dongle. In these examples, the authentication coprocessor may be configured to enable non-MFi protocols to interface with the MFi protocol. Figure 1 In the example of , the authentication coprocessor 124 can be run as a virtual device within the Android emulator on the computer side so that, for example, communications (including those to and from an iPhone or other mobile device) can be encrypted or decrypted respectively.

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

[0053] Referring next to logic block 208, MFi applications such as CarPlay can be executed in the upper layer in the Android emulator. CarPlay is now accessible to the virtualized authentication coprocessor on the computer side. Encrypted communications can now be seamlessly decrypted using the virtualized authentication coprocessor.

[0054] At logic block 210, a plug-in layer required in an embodiment may be included to facilitate the communication between the Apple communication plug-in and the IAP stack in the Android emulator and the virtual USB to I2C driver and the MFi application of the Android emulator. Figure 1 In an embodiment of the present invention, CarPlay can easily communicate with the underlying layers including the Android Linux USB to I2C driver.

[0055] Then, refer to Figure 2 Logic block 212, in an embodiment where the MFi application running in the Android emulator is CarPlay, engineers can test CarPlay directly on the Android emulator and develop software that is compatible with CarPlay and customized for the infotainment system in the target vehicle for subsequent optimization of CarPlay, which is in the vehicle dashboard or in other locations where the main embedded SoC is intended to be placed. Logic block 214 refers to an embodiment where a Linux kernel is used as an Android emulator kernel, which can help Figure 1 The USB device passthrough mechanism described in Receive Authentication Data.

[0056] Beneficially, as the identity of the target vehicle changes, engineers can design different software algorithms that are made compatible with each specific target vehicle. This effort can be accomplished without the need to implement CarPlay with a certification coprocessor on a system-on-chip (SoC). This latter step only needs to become implemented after CarPlay is rigorously tested for the vehicle in question and the software compatible with the infotainment system is fully developed.

[0057] Figure 3A is a conceptual diagram illustrating the interaction between a physical authentication coprocessor and a CarPlay application 332 running in a main CPU on top of an Android emulator according to an aspect of the present disclosure. More specifically, in Figure 3A In the example shown in , three virtual paths 334, 336, and 338 are shown for performing 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 features of the Android OS on a computer. It can be used to debug, test, or run Android applications. In this instance, the Android Emulator has been configured to virtualize MFi-based applications. The USB device pass-through described in this disclosure is a feature that allows users to transfer data, charge devices, and connect peripherals over a USB connection. USB pass-through allows USB devices to be connected directly to the system in some cases without the use of a USB hub. Therefore, in some examples, the pass-through can eliminate the need for additional ports or cables. One result of this simplification is faster and more efficient communication. In some embodiments, a pass-through system can be used to simplify Figure 3A Aspects of the virtual path described in .

[0058] like Figure 3A As shown in , the main CPU 360 side of the test configuration runs a simulator virtual machine, within which the CarPlay application 332 is executing. That is, an instance of the virtual machine is a digital representation that simulates a real component. The USB dongle 362 side of the test configuration physically houses the authentication coprocessor 330. As described in the above embodiments, the collective main CPU 360 side resides in the computer side, and the USB dongle 362 side, although residing in the USB dongle device, enables the virtual simulator to run the CarPlay application 332 on the main CPU side 360 ​​from the perspective of CarPlay. It should be understood that Figure 3AThe diagram shows three interactions for testing a CarPlay application 332 with an iPhone (virtually onboard or discrete) by utilizing data in a certification coprocessor 330 that is virtualized in an Android emulator. However, these three interactions are exemplary in nature. As software testing and development progresses, additional and different interactions may occur, whether or not a virtualized certification coprocessor is used. Furthermore, the types of virtual interactions that occur may vary depending on the target vehicle and unique infotainment system, which in turn can be accounted for by adjusting the code running the Android emulator.

[0059] Initial reference Figure 3A , including a first virtual path 334, which enables the CarPlay application 332 to be provided via the Android emulator with data required for authentication purposes of the CarPlay application 332 or the corresponding iPhone, such as authentication certificates. Figure 3A In the example, the iPhone and the authentication coprocessor can communicate by exchanging different messages. In one example, a connection can be established between the authentication coprocessor and an MFi application such as CarPlay. Figure 1 Virtual path 334 is described in . Brief reference Figure 1 , the virtual path 334 requires an authorization certificate in the form of I2C data, which comes from the authorization coprocessor 124 (or Figure 3A The authentication coprocessor 330 in the Apple communication plug-in 116 is 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 the USB device passthrough 106 (which can be regulated by the computer operating system, the emulator kernel, and the USB driver 120). The USB data is converted back to I2C formatted data by the driver 118, and the Apple communication plug-in 116 can be used to provide the authentication certificate to the CarPlay application 114. Figure 3A , when the CarPlay application 332 receives the authentication certificate, the virtual path 334 is completed.

[0060] Still reference Figure 3A, the CarPlay application 332 running in the Android emulator can read the provided certificate and can then respond by writing challenge data to request the authentication coprocessor 330 to decrypt the data on the next virtual path 336. Virtual path 336 can be physically implemented in a manner opposite to that described with respect to virtual path 334. Other embodiments may involve a dedicated physical channel for two-way communication. In this case, virtual path 334 carries the challenge data back to the authentication coprocessor 330. The authentication coprocessor 330 can read the received challenge data and can then provide the decrypted data in the form of challenge response data back to the CarPlay application 332 running on the main CPU side 360 ​​on the third virtual path 338. Except for the content of the data, the physical form of the third virtual path 332 is the same as that of the virtual path 338. The decrypted data that has been received from the authentication coprocessor 330 on the virtual path 338 and is now at the CarPlay application 332 can be used to respond back to the corresponding iPhone to complete the authentication process.

[0061] Typically, each virtual communication in the Android emulator physically traverses an I2C interface, a USB to I2C converter (which can be bidirectional in some embodiments, and each dedicated to a single direction in other embodiments), and a USB interface. The USB device and corresponding data are virtualized using the computer's drivers and operating system in conjunction with USB device passthrough. The resulting data traverses the USB to I2C driver, and in some embodiments, the appropriate Apple communication plugin, before ultimately reaching the virtual instance of CarPlay executing on the Android emulator.

[0062] As noted, the MFI protocol used for communication between the iPhone and accessories is iAP - now referred to as the "iPhone Accessory Protocol". The IAP stack is a communication system that facilitates transfers between the iPhone and accessories using USB and other communication protocols. Figure 3B An example of an IAP protocol for authentication and communication between an iPhone and an authentication coprocessor corresponding to CarPlay or other MFi applications is provided in.

[0063] Figure 3B is a conceptual diagram of a physical device that generates execution threads during an instance of a simulator and CarPlay application running on a processor (main CPU), a memory, and a USB bus according to one aspect of the present disclosure. Figure 3BThe main processor / CPU 350 is a physical processor in the computer 102 in which the Android emulator 104 is running. As noted in the previous embodiments, the main processor / CPU 350 may actually constitute multiple processors, each of which may include one or more central processing units (CPUs) and / or cores. The main processor / CPU 350 is configured to run code that creates the virtual emulator 104. Because the virtual emulator 104 is Figure 3B The diagram is shown at a certain moment, so the diagram can be interpreted as conceptually illustrating one or more execution threads captured at a specific time. A thread is an execution sequence. In some definitions, it is the smallest sequence that a scheduler in an operating system can schedule individually. However, here, a thread is intended to refer only to the main CPU and other components that perform actions.

[0064] Figure 3B 350, although other types of memory may be used. DRAM 355 is likely to be a memory in which code executed on processor 350 is temporarily stored to perform tasks quickly and efficiently. It will be appreciated that Figure 3B 355. In some embodiments, the main processor / CPU 350 may be different from the memory in most mainstream computer architectures. For simplicity, the main processor / CPU 350 is shown as including DRAM 355. However, in other embodiments, the main processor / CPU 350 can be installed on a motherboard and can communicate with DRAM 355 using one or more bridge interface circuits. In some embodiments, the processor has a cache memory that stores frequently used data for fast access. Bus 352 is also shown. In one aspect, bus 352 represents a physical conductor that enables the main processor / CPU 350 to exchange data and code with DRAM 355.

[0065] On the other hand, the bus 352 can provide a virtual means of exchanging data within the computer 102. For example, in the virtual representation of Figure 3, the CarPlay application 332 is running in the Android emulator 104. In turn, the Android emulator 104 is coupled to other components via the bus 352 and the virtual interface 356, which can be a USB interface. For clarity, the circuitry on the motherboard that converts USB to another form of serial communication (and vice versa) is omitted. A USB driver 120 is further conceptually shown, which is physically represented by code running in the main processor / CPU 350 within the operating system of the computer 102. Adjacent to the driver 120, a USB device passthrough 106 is shown to facilitate the transfer of data from the USB port 353 and through the interface 356 to the Android emulator 332.

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

[0067] It should also be noted that the computer's operating system may be stored in a non-volatile memory such as a disk drive or solid-state drive. When the computer 102 is first powered on, the relevant portion of the operating system including the kernel may then be loaded into the DRAM 355. In addition, Linux or other separate operating systems or operating system kernels may be stored in the DRAM 355. All operating systems may be executed by the processor 332 to enable the activities of the computer and to implement an Android emulator using, for example, the Linux kernel.

[0068] This detailed description and the accompanying drawings or figures are support and description of the present teaching, but the scope of the present teaching is limited only by the claims. Although some best modes and other embodiments for implementing the present teaching have been described in detail, there are various alternative designs and embodiments to practice the present teaching defined in the appended claims. In addition, the present disclosure explicitly includes combinations and sub-combinations of the elements and features presented above and below.

Claims

1. A method for running a Made for iPhone (MFi) protocol for communicating between an iPhone and an iPhone Accessory Protocol (IAP) using application virtualization in an Android emulator on a computer, wherein the iPhone Accessory Protocol (IAP) facilitates transfers between an iPhone and an accessory using USB and other communication protocols, the method comprising: providing a Universal Serial Bus (USB) dongle or other external device including an authentication coprocessor coupled to a USB to I2C converter via an Inter-Integrated Circuit (I2C) interface, the authentication coprocessor being used to enable a non-MFi protocol to interface with an MFi protocol, receiving data from the USB to I2C converter at a computer via a USB interface; forwarding the data to a virtual USB to I2C driver running in an Android emulator using USB device passthrough, thereby virtualizing the authentication coprocessor on a computer; as well as The Apple communication plugin and IAP stack are executed concurrently 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 via one or more lower layers, the one or more lower layers including a layer corresponding to a virtual USB to I2C driver layer coupled to a virtualized authentication coprocessor.

3. The method of claim 1 , further comprising executing the MFi application in the Android emulator on top of an Apple communication plugin and an IAP stack layer, the Apple communication plugin and the IAP stack layer being on top of the virtual USB to I2C converter. 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 subsequently optimizing CarPlay in an infotainment system of a target vehicle.

6. The method of claim 1 , wherein the USB port to which the USB dongle or other external device is coupled is regulated by a USB driver that helps the USB device pass-through as a virtual USB device to pass the data to the USB to I2C driver running in the kernel of the Android emulator.

7. The method according to claim 1, further comprising: receiving, at the MFi application, a credential from a virtualized authentication coprocessor; as well as In response to receiving the challenge response data, the challenge data is sent from the MFi application to request the authentication coprocessor to calculate the challenge response data, and then send the challenge response data back to the corresponding iPhone to complete the authentication.

8. An apparatus for enabling CarPlay authentication in an Android emulator, comprising: a memory storing a computer operating system (OS); a main central processing unit (CPU) coupled to the memory and configured to execute OS code; a universal serial bus (USB) dongle configured to connect to a USB bus via a bus interface, the USB dongle or other external device including an authentication coprocessor coupled to an inter-integrated circuit (I2C) to USB converter when the USB dongle is connected to a corresponding USB port; as well as A driver code stored in the memory and executable together with the OS on the main CPU, for managing data exchange between the authentication coprocessor and the main CPU; The main CPU executes code to generate an Android emulator that runs the CarPlay application as a virtual component, the Android emulator including a USB to inter-integrated circuit ("I2C") driver configured to virtualize the authentication coprocessor as an I2C device that runs with the CarPlay application.

9. The apparatus of claim 8, further comprising USB device pass-through code stored in a memory and configured to enable the authentication coprocessor to be virtualized as an I2C device in the Android emulator when executed on the main CPU.

10. The apparatus of claim 9, wherein the USB device passthrough code is further configured to forward USB device data from a USB interface to a USB to I2C driver operating virtually within the Android emulator.

Images