Background introduction This article refers to the address: http:// The Open Handset Alliance (OHA), founded by Google, has gone through seven seasons, and the alliance has made the Android operating system more accessible to mobile developers. In a relatively short period of time after its establishment, the Android platform has developed into a mainstream smartphone and tablet operating system, and is now appearing in expanding markets such as automotive and industrial applications. Operating systems such as Apple's iOS and Microsoft's Windows CE are losing market share, and Android-based devices are replacing them. In fact, the number of downloadable and useful Android apps has grown to nearly 1.1 million (source: AppBrain January 2014). Android-based consumer electronics users also want to be able to use their applications and device features while driving or riding. For designers who want to implement Android-based in-vehicle infotainment systems, there are many ways to do this, such as fully customizing the Android operating system and then loading it directly onto the chip platform (bare metal), or the basis of the smartphone and the car. The architecture is simple to link. This article will introduce these approaches and their advantages and disadvantages. Car Android smart device Recently, Google announced at the 2014 International Consumer Electronics Show that the Open Auto Alliance (OAA) mission is to make the Android platform available for cars. In addition to Google, the founding members of the Open Car Alliance include Audi, GM, Honda, Hyundai and nVidia. Other vendors are expected to join the Open Car Alliance, but the details of how the Android platform will be used in cars are still in the discussion stage. Some manufacturers, such as Kia and Renault, have loaded custom Android systems into production cars and have their own well-managed Android app library available in the car. The following table summarizes the differences between the existing features of smartphone Android and the essential features of the car Android. Table 1: Potential requirements for car Android compared to Android smartphones. If the Open Auto Alliance has established a common Android-based platform, existing implementations may soon work, as any new Google-approved Android operating system will undoubtedly reduce maintenance and support costs. Compatibility with earlier Android versions and in-vehicle devices will be an important feature and will be a primary concern for the Open Car Alliance. During the life of the vehicle, it is impossible for the owner to upgrade the vehicle software as frequently as the smartphone user. Google releases a new Android version approximately every nine months (Figure 1), while the Android 4.4 "KitKat" version is in the process of mass production. The various Android versions of the smartphone market have not survived for a long time. In contrast, these versions are likely to be used as built-in car configurations for a longer period of time. Figure 1: Android version and its distributed integration of Android smart devices Considering the popularity of Android, it is highly probable that a driver or passenger will have an Android smart device. Ideally, such a device would be easily connected to certain components of the automotive infrastructure, and there may be multiple forms of connectivity, depending on the application. In the simplest form of integration, users like to charge their smartphones while driving, and each car has a 12V accessory for connecting a USB charger. More complicated is the built-in Bluetooth pairing kit, which allows the music of the smart device to be played through the in-car audio system. Most new cars now have this feature (Figure 2). Figure 2: Level of smart device integration related to implementation costs. New standards that are constantly emerging are improving the level of equipment integration in the car. The Car Connectivity Consortium (CCC) (http://) has been working to promote the establishment of device integration standards for remote management and display on smartphones. Application is possible. The Automotive Connection Alliance has mandated the use of Universal Plug and Play (UPnP) devices to control access to in-vehicle applications. Another standard, Virtual Network Computing (VNC), allows information displayed on the smartphone display to be copied to the infotainment host as a thin client. The app can then be run on a smartphone but can be seen on the infotainment host. Mentor Graphics, a leader in electronic design automation technology, recently released a research report titled "Implementation and Considerations for Car Android Systems." Currently, most integrations are done via a USB cable, but this approach is clumsy and unreliable. Some in-vehicle infotainment consoles now have Wi-Fi capabilities, so there is now another way to integrate smart devices. Integrated smart devices can also provide roaming 3G/4G/LTE connectivity for infotainment hosts. This provides a cheap alternative to the built-in wireless modem, as well as a variety of separate tariffs and data packages. Whether it's cost or integration scale, automotive OEM Audi is at the high end, the company has launched a dedicated 10.2 inch tablet designed for in-vehicle use. "Audi Tablet" has access to a dedicated app store and can connect to the vehicle's navigation and infotainment system via Wi-Fi. The advantage of this approach is that the mobile device solution is under strict management and highly integrated, and the quality of integration with hardware and software is extremely high. Architecture compatible with Android Another way to integrate Android with vehicles is to leverage a flexible but secure multi-domain software architecture. These include setting the Android system as GuestOS, setting it up to an existing operating system (for example, in Linux Container mode), or setting it to a GuestOS in parallel with another operating system (Figure 3). With the support of Linux Container (LXC) technology, the resources, access control and security of the Android client are managed by the host Linux operating system. For system designers interested in Android security, this is a great way to provide Android application access and run other system functions on a standard Linux platform. The Multicore System-on-Chip (SoC) platform makes this architecture even more attractive because enough Linux and Android domain resources allow them to perform well at the same time. In addition to central processing unit (CPU) resources, memory, graphics processing resources, and other peripherals can be shared. The output of the two domains can be reorganized into a common Human Machine Interface (HMI), enabling users to select functions from both domains. Figure 3: Android system in the Linux Container, supporting front and rear vehicle functions. In order to run Android in LinuxContainer, you must make some modifications to the Linux kernel that supports the Container. In a typical use case, there is an infotainment controller on the front screen to control the display of the rear seat Android. Hardware resources that support Android display, such as touch screen information, audio, and graphics input via USB, need to be virtualized and then provided to the user who uses the display. This will help to reproduce the "consumer electronics" experience in the car as much as possible. Audio resources need to be carefully managed: front-seat infotainment users will need access to navigation commands, phone calls, system alerts, multimedia players, etc., as well as optimize channel and mute. The rear seat user uses mono and can be used for music/entertainment purposes. An alternative to Linux Containers is to use a fully embedded hypervisor that manages the available SoC hardware resources and assigns them to multiple domains/operating systems. The hypervisor is configured to precisely manage which resources are available to GuestOS, available to Android, Linux, AUTOSAR, or other operating systems, and to allow some communication between domains. Mentor Graphics recently demonstrated a hybrid domain system in which AUTOSAR data comes from in-vehicle electronic control units (ECUs) that are fed into digital dashboards and infotainment systems running on a single hardware platform (Figure 4). Figure 4: Hybrid vehicle operating system with AUTOSAR, dashboard and infotainment system running on a single SoC. in conclusion Android has become a common practice. More and more smart device users want to access Android apps in the car. Manufacturers have multiple implementation options with multiple levels of cost, integration and functionality. Standardization efforts such as Google's Open Auto Alliance and the Automotive Connection Alliance's initiative to promote integrated devices will further accelerate the development of in-car Android systems. Vendors of these solutions must be careful to cover a wide range of Android APP choices while maintaining the security and integrity of the in-car computing system. Are cars now ready to be classified as consumer electronics devices? The days of redefining "mobile devices" will not be long. connector, terminal connector, cable connector, wire connector, battery connector, power connector, harness connector etc connector, terminal connector, cable connector, wire connector, battery connector, power connector, harness connector Ningbo HanCheng(HC) Electronic Co.,Ltd , https://www.hcwires.com
