[0001] This application claims priority to U.S. Provisional Application Serial No. 63/371,445, entitled “CONTEXT AWARE SAFETY FEATURES FOR VEHICLE OPERATING SYSTEMS,” filed August 15, 2022, and U.S. Provisional Application Serial No. 63/371,451, entitled “SINGLE-INSTANCE MULTI-USER SUPPORT FOR VEHICLE OPERATING SYSTEMS,” filed August 15, 2022, each of which is incorporated by reference as if set out in their respective entireties herein.

BACKGROUND

[0002] A vehicle head unit (which may be referred to as an infotainment system) may be configured to execute a vehicle operating system to facilitate control of, to provide a few examples, entertainment (such as music, video, images, etc.), information, navigation, and voice calls, as well as vehicle systems, such as heating, ventilation, and air conditioning (HVAC) systems, lighting systems, and seat control systems (including heating and/or cooling, seat adjustment, etc.). Vehicle operating systems may generally limit access to certain features in order to avoid and/or reduce distractions to an operator of the vehicle. These safety limitations may be hard coded (or, in other words, statically coded) into the vehicle operating system to satisfy certain safety concerns and are often difficult to override despite changes in the operating context.

SUMMARY

[0003] In general, various aspects of the techniques set forth in this disclosure are directed to context aware safety features for vehicle operating systems. Rather than statically determine when a protected operating mode may apply regardless of context, various aspect of the techniques described in this disclosure may enable one or more instances of a vehicle operating system to determine an operating context in which the vehicle is currently operating, and enter, based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle.

[0004] The operating context may include a usage of an instance of the vehicle operating system by one or more passengers of the vehicle, a presence of the one or more passengers in the vehicle, weather conditions in which the vehicle is currently operating, and an operational state of the vehicle (e.g., whether the vehicle has been in an accident, a level of a battery for hybrid electric and/or fully electric vehicles, etc.). Responsive to these different aspects of the operating context, the vehicle operating system may reduce power consumption (for example, in the case of folly electric vehicles) by one or more displays (e.g., reduce brightness of or power off such displays), currently executing application (e.g., by going to a night mode or other panic mode execution that reduces current processing and/or displayrequirements), and the like.

[0005] In this respect, various aspects of the techniques may improve operation of the vehicle head unit itself by dynamically entering into the protected operating mode to potentially improve a safety level associated with operating the vehicle. In the context of battery life for example, the vehicle operating system may disable or reduce operation of the displays to preserve battery- life such that the vehicle may reach an intended destination without exhausting the battery powering the vehicle, which may improve safety especially when weather conditions may otherwise pose a significant risk to the operator and/or passengers health (e.g., when it is very cold or hot outside the controlled environment of the vehicle). As such, various aspects of the techniques described in this disclosure may improve upon operation of the vehicle itself in terms of providing safety for the operator and/or passengers (which in the context of autonomous vehicles may include the “operator”).

[0006] Furthermore, by dynamically entering into the protected operating mode only when certain conditions are met (or, in other words, when the operating context warrants entering into the protected operating mode), various aspects of the techniques may reduce errant entry into the protected operating mode in operating contexts that do not warrant entry into such protected operating mode. By avoiding unnecessary entry into the unwarranted protected operating mode, the vehicle operating system may improve the user experience while also potentially still addressing operator and/or passenger safety in a number of different ways. [0007] In one example, this disclosure describes a method comprising: executing, by a vehicle head unit of a vehicle, an instance of a vehicle operating system; determining, by the instance of the vehicle operating system, an operating context in which the vehicle is currently operating; and entering, by the instance of the vehicle operating system, and based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle.

[0008] In another example, this disclosure describes a computing device comprising: a memory configured to store an instance of a vehicle operating system; and one or more processors to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: determine an operating context in which the vehicle is currently operating; and enter, based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle. [0009] In another example, this disclosure describes a non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: execute an instance of a vehicle operating system; determine, by the instance of the vehicle operating system, an operating context in which the vehicle is currently operating; and enter, by the instance of the vehicle operating system, and based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle.

[0010] In another example, this disclosure describes an apparatus comprising: means for executing an instance of a vehicle operating system; means for determining an operating context in which the vehicle is currently operating; and means for entering, based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle.

[0011] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.

BRIEF DESCRIPTION OF DRAWINGS

[0012] FIG. 1 is a block diagram illustrating an example computing system that is configured to provide a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure.

[0013] FIG. 2 is a diagram illustrating an example of a vehicle that includes a computing system configured to execute a vehicle operating system that operates in accordance with various aspects of the single-instance multi-user techniques described in this disclosure. [0014] FIG. 3 is a diagram illustrating different interaction models with multiple displays including interactions that occur via single instance multi-user models and multi-instance multi-user models in accordance with the vehicle operating system techniques described in this disclosure.

[0015] FIG. 4 is a diagram illustrating an example vehicle that includes a vehicle head unit configured to control audio content in accordance with various aspects of the single-instance multi-user vehicle operating system techniques described in this disclosure.

[0016] FIGS. 5 and 6 are diagrams illustrating audio control in a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure.

[0017] FIG. 7 is a flowchart illustrating example operation of the computing system shown in FIG. 1 in executing a vehicle operating system configure to perform various aspects of the safety techniques described in this disclosure.

DETAILED DESCRIPTION

[0018] FIG. 1 is a block diagram illustrating an example computing system that is configured to provide a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure. As shown in the example of FIG. 1, a computing system 100 includes a computing device 102. Although described with respect to a vehicle, the computing system 100 may be utilized in different contexts, including standalone computing systems (including laptop computers, desktop computers, workstations and the like), gaming systems, cellular telephones (including so-called “smartphones”), media systems (including streaming media systems), audio/visual (A/V) receivers, televisions (including so-called ‘‘smart televisions”), smart speakers, smart watches, thermostats (including so-called “smart thermostats”), smart glasses, or any other computing system.

[0019] In any event, computing device 102 is an example of vehicle computing device, such as a vehicle head unit. FIG. 1 illustrates only one particular example of computing device 102, and many other examples of computing device 102 may be used in other instances and may include a subset of the components included in example computing device 102 or may include additional components not shown in FIG, 1.

[0020] As shown in the example of FIG . 1, computing device 102 includes presence-sensitive display 112, one or more processors 140, one or more communication units 142, one or more input components 144, one or more output components 146, and one or more storage devices 148, and communication channels 149. Communication channels 149 may interconnect each of the components 112, 140, 142, 146, and/or 148 for inter-component communications (physically, communicatively, and/or operatively) and thereby allow components 112, 140, 142, 146, and 148 to communicate with one another. In some examples, communication channels 149 may include a system bus, a network connection, one or more inter-process communication data structures, or any other components for communicating data (also referred to as information). Although shown as including components 112, 140, 142, 146, and 148, vehicle head unit 102 may include other components or less components than those shown, where such components may be included in other control units such as a telematic control unit (TCU).

[0021] One or more communication units 142 of computing device 102 may communicate with external devices by transmitting and/or receiving data. For example, computing device 102 may use one or more of communication units 142 to transmit and/or receive radio signals on a radio network such as a cellular radio network. In some examples, communication units 142 may transmit and/or receive satellite signals on a satellite network such as a Global Positioning System (GPS) network. Examples of communication units 142 include a network interface card (e.g. an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication units 142 may include short wave radios (e.g., NFC, BLUETOOTH (including BLE)), GPS, 3G, 4G, 5G, and WIFI radios found in mobile devices as well as Universal Serial Bus (USB) controllers and the like.

[0022] One or more input components 144 of computing device 102 may receive input. Examples of input are tactile, audio, kinetic, and optical input, to name only a few examples. Input components 144 of computing device 102 include, in one example, a mouse, keyboard, touchpad, voice responsive system, video camera, buttons, scroll wheel, dial, control pad, a microphone (or, in other words, an audio capture device), or any other type of device for detecting input from a human or machine. Input components 144 may include cameras. In some examples, input component 144 may be a presence-sensitive input component, which may include a presence-sensitive screen, touch-sensitive screen, etc. separate from presencesensitive display 112.

[0023] One or more output components 146 of computing device 102 may generate output . Examples of output are tactile, audio, and video output. Output components 146 of computing device 102, m some examples, include a presence-sensitive screen (possibly separate from presence-sensitive display 112), sound card, video graphics adapter card, speaker, cathode ray tube (CRT) monitor, liquid crystal display (LCD), organic light emiting diode (OLED), or any other type of device for generating tactile, audio and/or visual output to a human or machine.

[0024] In some examples, presence-sensitive display 112 of computing device 102 may include fimctionality of input component 144 and/or output components 146. In the example of FIG. 1, presence-sensitive display 112 may include a presence-sensitive input (PSI) component 104 (“PSI component 104”), such as a presence-sensitive screen or touch- sensitive screen. In some examples, presence-sensitive input component 104 may detect an object at and/or near the presence-sensitive input component. As one example range, presence-sensitive input component 104 may detect an object, such as a finger or stylus that is within two inches or less of presence-sensitive input component 104. Presence-sensitive input component 104 may determine a location (e.g., an (x,y) coordinate) of tire presencesensitive input component at which the object was detected. In another example range, presence-sensitive input component 104 may detect an object two inches or less from presence-sensitive input component 104 and other ranges are also possible. Presencesensitive input component 104 may determine the location of presence-sensiti ve input component 104 selected by a user’s finger using capacitive, inductive, and/or optical recognition techniques.

[0025] In some examples, presence-sensitive display 112 may also provide output to a user using tactile, audio, or video stimuli as described with respect to output component 146. For instance, presence-sensitive display 112 may include display component 103 that displays a graphical user interface. Display component 103 may be any type of output component that provides visual output, such as described with respect to output components 146. While illustrated as an integrated component of computing device 102, presence-sensitive display 112 may, in some examples, be an external component that shares a data or information path with other components of computing device 102 for transmitting and/or recei ving input and output. For instance, presence-sensitive display 112 may be a built-in component of computing device 102 located within and physically connected to the external packaging of computing device 102 (e.g., an in-vehicle screen mounted in a dashboard of a vehicle). In another example, presence-sensitive display 112 may be an external component of computing device 102 located outside and physically separated from the packaging of computing device 102 (e.g., a monitor, a projector, etc. that shares a wired and/or wireless data path with a electronic control unit of the vehicle). In some examples, presence-sensitive display 112, when located outside of and physically separated from the packaging of computing device 102, may be implemented by two separate components: a presence-sensitive input component 104 for receiving input and a display component 103 for providing output.

[0026] One or more storage devices 148 within computing device 102 may store information for processing during operation of computing device 102 (e.g., computing device 102 may store data accessed by operating system (OS) 160A and OS 160B during execution at computing device 102). As shown in the example of FIG. 1, one ormore storage devices 148 may store a first instance of an operating system 160A (OS 160A) and a second instance of operating system 160B (OS 160B). In some examples, storage devices 148 include temporary memory , meaning that a primary purpose of one or more storage devices 148 is not long-term storage. Storage devices 148 of compu ting device 102 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

[0027] Storage devices 148, in some examples, also include one or more computer-readable storage media. Storage devices 148 in some examples include one or more non-transitory computer-readable storage mediums. Storage devices 148 may be configured to store larger amounts of information than typically stored by volatile memory . Storage devices 148 may- further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Storage devices 148 may store program instructions and/or information (e.g., data) associated with OS 160A and/or 160B. Storage devices 148 may include a memory configured to store data or other information (which is not shown for ease of illustration purposes) associated with OS 160A and OS 160B.

[0028] One or more processors 140 may implement functionality- and/or execute instructions associated with computing device 102. Examples of processors 140 include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configure to function as a processor, a processing unit, or a processing device. OS 160A and/or 160B may- be operable (or, in other words, executed) by processors 140 to perform various actions, operations, or functions of computing device 102. That is, OS 160A and/or OS 160B may form executable bytecode, which when executed, cause processors 140 to perform specific operations (and thereby causing computing device 102 to become a specific-purpose computer by which to perform) in accordance with various aspects of the techniques described herein. For example, processors 140 of computing device 102 may retrieve and execute instructions stored by storage devices 148 that cause processors 140 to perform the operations described herein that are attributed to OS 160A and/or 160B. The instructions, when executed by processors 140, may cause computing device 102 to store information within storage devices 148. [0029] As described above, computing system 100 may be integrated or otherwise included within a vehicle. The vehicle may include one or more of a bicycle, a tricycle, a unicycle, a motorcycle, an automobile, farm equipment (such as a tractor, combine, etc.), construction equipment (a dump truck, crane, etc.), military' vehicle or equipment (a tank, armament, etc.), a truck, a semi-tractor (or, in other words, a semi-trailer), aviation equipment (such as a plane), nautical equipment (such as a boat, carrier, submarine, etc.), or any other type of vehicle.

[0030] Computing device 102 (which may be, as noted above, referred to as vehicle head unit 102 and also as an infotainment system 102) may be configured to execute a vehicle operating system, such as one or more of OS 160A and 160B (which as a result may also be referred to as vehicle OS 160A - VOS 160A - and VOS 160B), to facilitate control of, to provide a few' examples, entertainment (such as music, video, images, etc.), information, navigation, and voice calls, as well as vehicle systems, such as heating, ventilation, and air conditioning (HVAC) systems, lighting systems, and seat control systems (including heating and/or cooling, seat adjustment, etc.). In some instances, vehicle operating systems may allow a single user profile to access a given instance of the vehicle operating system at once, where the single user profile is typically the operator of the vehicle.

[0031] This vehicle operating system may be referred to as a single-instance, single-user vehicle operating system. That is, a single instance of the vehicle operating system may only allow a single user profile to access the single instance of the vehicle operating system and require a user profile switch in which the single user profile is replaced with another single user profile. In this respect, only a single user profile can access a single instance of the vehicle operating system at any given time.

[0032] To enable multiple concurrent user profiles, processors 140 may execute another instance of the vehicle operating system, which may require additional processors and/or higher processing capacity processors (which are typically more expensive). However, there may be difficulties in enabling efficient communication between both instances of the vehicle operating system such that users associated with the multiple user profiles are unable to share content between one another, thereby potentially limiting the user experience.

[0033] As such, while the instance of the vehicle operating system may support multiple user profiles, the instance of the vehicle operating system may only allow a single user profile of the multiple user profiles to access (or in other words “log into”) the instance of the vehicle operating system. The instance of the vehicle operating system may limit access to a single user profile to ensure that the operator of the vehicle does not become distracted by oilier user profile behavior while operating the vehicle.

[0034] In accordance with various aspects of the techniques described in this disclosure, computing system 100 may implement a single instance of a vehicle operating system, such as VOS 160A and/or 160B (“VOS 160”), that provides concurrent multi-user support. Rather than limit access to a single user profile for the single instance of VOS 160, a single instance of the VOS 160 described m this disclosure may allow multiple user profiles to access the single instance of VOS 160. As vehicles have begun integrating increasingly more displays, such as supporting presence-sensitive displays 150A-150N (“supporting presence-sensitive displays 150,” which may also be referred to as “displays 150”) in a cabin of the vehicle, more users may safely interface with VOS 160 without distracting an operator of the vehicle (considering that in some examples, the operator either has limited view of these displays 150 or has no direct view of these displays 150, which may be disposed behind the operator for rear seat passengers). As such, multiple users associated with multiple user profiles may access VOS 160 and interact with computing device 102 to control various functionality provided via computing device 102, such as entertainment, information, navigation, and voice calls as well as various vehicle systems (which may be, to some extent, dependent on the multiple user locations within the vehicle).

[0035] The multiple users may also interface with VOS 160 to jointly coordinate activities among the multiple users, such as sharing content between the multiple users, reviewing content viewed by other users of the multiple users, control audio playback between the multiple users (such as change audio playback volume, coordinate on playlists, etc.), messaging between the multiple users, collaborating by the multiple users jointly on navigation directions, and the like. In some instances, the multiple users may use gestures, such as a swipe gesture, a pinch gesture, and a tap gesture, to indicate sharing of such content, which may allow- for intuitive control of sharing between the multiple users.

[0036] In operation, computing device 102 may, as shown in the example of FIG. 1 , interface with displays 150, which may be similar to if not substantially similar to presence-sensitive display 112, However, rather than integrate into computing device 102 similar to presencesensitive display 112, displays 150 may be communicatively coupled (via wire or wirelessly) to computing device 102 and integrated throughout the cabin of the vehicle or separate from the vehicle. That is, displays 150 may also, m some instances, represent tablets, smartphones, laptops, portable gaming device, portable video devices, or any other device capable of interfacing wdth computing device 102 to present a user interface associated with VOS 160 (and/or applications executing in an application space presented by VOS 160, which may be

<) separate from a privileged kernel space in which VOS 160 executes to facilitate interactions between the applications and underlying hardware, such as components 112, and 140-148). [0037] In any event, processors 140 may execute an instance of a vehicle operating system , such as VOS 160A or VOS 160B, wherein VOS 160A and/or 160B facilitates concurrent access by multiple user profiles that are shown in the example of FIG. 1 as user profiles (UP) 161 A- 16 IN (“UP 161”) for VOS 160A and UP 163A-163N (“UP 163”) for VOS 160B. UP 161/163 may each define a set of access rights (or in other words privileges), preferences (e.g., for user interfaces, A ⁷ 0S 160 settings, etc.), and other user-specific configuration data or information. UP 161/163 may each be associated with a different user, although UP 161 and UP 163 may include user profiles for the same user. For example, UP 161 A and UP 163 A may be associated with the same user,

[0038] Processors 140 may execute, as one example, VOS 160A and authorize multiple user profiles of UP 161 to interface with VOS 160A. To authorize multiple user profiles of UP 161 , each of the users may register with VOS 160A, entering a username (associated with a given one of UP 161) and a password to log into VOS 160A. Alternatively, any other way by which to log into VOS 160A may be enabled, such as scanning a quick response (QR) code with a camera of a smartphone, entering a personal identification number (PIN), performing a biometric process (e.g., a fingerprint scan, a retina scan, etc.), facial recognition or any other way by which to register a given user profile of Ups 161 with VOS 160A. OS 160A may compare the entered information with authentication information stored to UP 161 to authorize (or in other words authenticate) each of the multiple user profiles of UP 161 to interface with VOS 160A.

[0039] While discussed with respect to authentication, VOS 160 A may also allow guest user profiles (as one of UP 161) in which authorization is provided without requiring any authentication. In this respect, guest user profiles may provide a limited experience (compared to authenticated UP 161) in terms of maintaining preferences, applications, etc. across different sessions but still enable functionality described below with respect to sharing content between multiple UP 161 and the like.

[0040] In any event, VOS 160A may present multiple user interfaces across multiple displays (such as display 112 and one or more of displays 150) communicatively coupled to computing device 102. VOS 160A may, for authenticated UP of UP 161, present the user interface specific for each of the authenticated UP that maintains preference in teams of application organization, user interface theme, various VOS 160 A settings (e.g., regarding notifications, accessibility, display configuration in terms of brightness, resolution, orientation, and the like, and any other type of OS setting). In any event, each of the multiple user interfaces are associated with one or more of UP 161.

[0041] VOS 160A may next interface, via the multiple user interfaces, with multiple users associated w'ith multiple UP of UP 161 to enable the multiple users to interface with VOS 160A for purposes of controlling functionality associated with computing device 102. Ulis functionality may include controlling navigation, changing content playback, changing user interface setings, controlling HVAC settings, sharing content between UP 161, and other functionality described below' in more detail.

[0042] In some examples, processors 140 may represent a high processing capacity processor (which may be referred to as “processor 140A”) and a low processing capacity processor (which may be referred to as “processor 140B”). In some instances, processor 140 may represent a processor capable of variable processing capacity having two or more distinct operating voltages that enable, at high voltages, high processing capacity and, at low' voltages, low processing capacity. In this sense a single processor may represent both processor 140A and processor 140B, switching between the different processing modes (e.g., high and low' processing modes) to facilitate power conservation. Processor 140A may provide additional processor cores compared to processor 140B (or in the instance where a single processor switches between processing mode, enable additional cores in the high processing mode when compared to the low' processing mode).

[0043] Processor 140A may execute VOS 160A, while processor 140B may execute VOS 160B. Processor 140A may execute VOS 160A fortasks that require higher processing, such as gaming, video conferencing, navigation, and other processor intensive tasks/applications. Processor 140B may execute VOS 160B for tasks that require lower processing, such as streaming audio, telephone calls, viewing images, text messaging, or other less processor intensive tasks/applications.

[0044 ] In some examples, processor 140A may execute VOS 160A concurrent to processor 140B executing VOS 160B. In instances of concurrent execution of VOS 160A and 160B, V OS 160A may present an interface by winch V OS 160B may communicate with VOS I60A to facilitate various functionalities of computing device 102. This interface may represent an application programming interface that VOS 160B may invoke to facilitate inter-VOS communication between VOS I60A and VOS 160B to cooperatively facilitate support to functionality provided by computing device 102.

[0045] Utilizing different processing capacity processors may facilitate energy consumption. Further, it may be cost prohibitive to install high processing capacity processor 140 capable of all of the functionality supported by computing device 102. where a low processing capacity processor 140 may allow the manufacturer to upgrade over time to add additional processors having high processing capacity (and/or possibly low processing capacity). Providing a framework for inter-V OS communication may allow for manufacturers to upgrade over time without having to configure a separate inter-VOS communication interface by which to facilitate access to the functionality of computing device 102 described in more detail below.

[0046] As further shown in the example of FIG. 1, computing device 102 may also interface with supporting audio capture devices 152A-152N (“supporting audio capture devices 152” or “audio capture devices 152'’). Audio capture devices 152 may each represent a microphone or other transducer configured to capture audio data representative of a soundfield. Supporting audio capture devices 152 may also be referred to as “’microphones 152.” In some examples, audio capture devices 152 may be integrated throughout one or more zones of the cabin of the vehicle that includes computing device 102. These zones may include an operator zone, one or more front passenger zones, and one or more rear passenger zones. As described below in more detail, these microphones 152 may capture (or, in other words, record, detect or otherwise sense) audio data that VOS 160 may use to adjust audio playback as well as support additional functionality provided by computing device 102.

[0047] In this way, various aspects of the techniques may facilitate a better user experience when traveling in the vehicle while still preserving safety concerns with distracting the operator of the vehicle. As a result of permitting multiple UP 161/163 to access VOS 160A/160B, VOS 160A/160B may tailor the user experience to each individual UP of UP 161/163 allowing for preferences to be applied that are specific to each individual UP. VOS 160A/160B system may also allow the multiple users to coordinate on activities (as noted above) that may improve the user experience while traveling in the vehicle. Given that additional displays 150 (which may be separate from a main display, e.g., presence-sensitive display 112, of vehicle head unit 102) may be located in the cabin where the operator of the vehicle cannot directly see the content being presented, VOS 160A/160B may permit increased permissions in terms of access to content while also potentially limiting any distractions to the operator.

[0048] In addition, vehicle operating systems may generally limit access to certain features in order to avoid and/or reduce distractions to an operator of the vehicle. These safety limitations may be hard coded (or, in other words, statically coded) into the vehicle operating system to satisfy certain safety concerns and are often difficult to override despite changes in the operating context. The vehicle operating system may include these safety limitations given that standard infotainment systems generally only include a single or possibly two or three different displays that are all associated with the same single access user profile.

[0049] In the context of multiple user profiles having concurrent access to the single instance of the vehicle operating system, these safety limitations may fail to address the operating context in which the vehicle operating system exists, as various safety limitations may only enable the operator to invoke certain safety functions that may otherwise facilitate more proactive safety measures that may help both the operator and the one or more passengers during emergency or other situations. As such, vehicle operating systems may limit functionality to the operator when such functionality, given the context, may be extended to the one or more passengers. Furthermore, the vehicle operating system may enter into the protected operating mode when the context does not warrant this protected operating mode, potentially frustrating the user experience with the vehicle operating system (that may result in wasted processing resources, such as processing cycles, memory consumption, bus bandwidth consumption, and associated power consumption).

[0050] In accordance with various aspects of the techniques described in this disclosure, VOS 160A may provide context aware safety features. Rather than statically determine when a protected operating mode may apply regardless of context, various aspect of the techniques described in this disclosure may enable V OS 160A and/or VOS 160B (“VOS 160”) to determine an operating context in which the vehicle is currently operating, and enter, based on the operating context, a protected operating mode in which VOS 160 dynamically adapts one or more operational features of the VOS 160 to facilitate safety of the operator of the vehicle.

[0051] The operating context may include a usage of an instance of the vehicle operating system by one or more passengers of the vehicle, a presence of the one or m ore passengers in the vehicle, weather conditions in which the vehicle is currently operating, and an operational state of the vehicle (e.g., whether the vehicle has been in an accident, a level of a battery for hybrid electric and/or folly electric vehicles, etc,). Responsive to these different aspects of the operating context, VOS 160 may reduce power consumption (tor example, in the case of folly electric vehicles) presence-sensitive displays 112, 150 (e.g., reduce brightness of or power off such displays), currently executing application (e.g., by going to a night mode or other panic mode execution that reduces current processing and/or display requirements), and the like.

[0052] In operation, processors 140 of computing device 102 may execute an instance of a vehicle operating system (e.g., VOS 160A). VOS 160Amay determine an operating context in which the vehicle is currently operating. VOS 160A may interface with any number of different vehicle sensors to determine the operating context, such as speed sensors, global positioning system (GPS) sensors, occupant sensors (winch, e.g., may sense weight applied to a seat), cameras, microphones, weather sensors (e.g., humidity, moisture, temperature, etc.), accelerometers, gyroscopes, infrared sensors, seat belt sensors, tire pressure sensors, or any other sensors capable of communicating with computing device 102 (where such sensors may be represented by input components 144 and/or output components 146).

[0053] To determine the operating context, VOS 160Amay perform one or more of determining a usage of the VOS 160A by one or more passengers in the vehicle, determine a presence of the one or more passengers in the vehicle (e.g., via one or more of occupancy sensors, cameras, microphones, etc.), determine weather conditions in which the vehicle is currently operating, and determine an operational state of the vehicle. VOS 160Amay also determine a state of a passenger interaction status element (e.g., a physical button disposed out of reach of the operator of the vehicle within the cabin of the vehicle, such as on a passenger door).

[0054] VOS 160Amay enter, based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of tlie vehicle operating system to facilitate safety of an operator of the vehicle. For example, V OS 160A may enter the protected operating mode in which VOS 160A dynamically adjusts power settings of the vehicle to reduce power consumption of a battery powering the vehicle (e.g., in either hybrid or fully electric vehicles).

[0055] As noted above, VOS 160Amay present multiple user interfaces across multiple displays 150 communicatively coupled to vehicle head unit 102, where each of the multiple user interfaces associated with one or more of the multiple user profiles. VOS 160A may, in this context, disable one or more of displays 150 based on one or more of the usage of the instance of the vehicle operating system, the presence of the one or more passengers of the vehicle, the weather conditions, and the operational state of the vehicle,

[0056] In this way, various aspects of the techniques may address issues with multiple displays 112/150, as a multi display configuration may be likely to use more power because monitors are one of the most power-consuming modules. Supplying power to displays 112/250 may be adjusted according to the surrounding conditions (as represented by the operating context). VOS 160 may manage power of multiple displays 112/150 on single with respect to usage, user presence, weather conditions, battery life, etc. to dynamically switch the power settings. Switching the power settings may provide power savings in harsh conditions like lower temperature, while also continuing power supply to all displays in case of emergency to help passengers report the accident/issue.

[0057] In some instances, as noted above, the operational state of the vehicle includes a battery life. VOS 160A may present enter the protected operating mode that results in disabling one or more of displays 112/150 based on the weather conditions and tire battery life. That is, when it is very’ cold outside (e.g., sub-zero degrees Celsius), the battery' may not perform optimally (compared to wanner temperatures) and thereby see a significant decrease in battery' life that may reduce milage for hybrid or fully electric vehicles. As a result, VOS 160Amay disable certain displays 112/150 or limit operation of displays 112/150 to prolong the battery' life such that the operator/passengers may' reach an intended destination without having to stop to recharge the battery- (or in instances where rechargers are not available, run out of battery' and become stranded).

[0058] VOS 160 A may', in conjunction or as an alternative to the above instances, enter, based on one or more of the weather conditions and the battery' life, an emergency mode in which one or more applications executed by the vehicle operating system are executed in a restricted access mode to preserve the batery life. In this example, VOS 160Amay execute in the emergency mode to execute applications in so-called “dark mode” in which the display is dimmed or adapted to present applications using mostly dark colors that do not consume as much power to display, reduce execution of applications to resemble a low processing capacity processor state, or otherwise execute applications (or possible stop executing certain high power consumption applications, such as streaming video applications) to conserve a life of a battery powering the vehicle.

[0059] VOS 160A may determine the operational state as an emergency state m which safety of the vehicle is compromised. VOS 160A may utilize the above noted vehicle sensors to determine that the vehicle has suffered a collision or other accident (e.g., a flat tire via the tire pressure sensors) that reduces safe operation of the vehicle. In these instances, rather than disable all of displays 112/150, V OS 160A may enable all of displays 112/150 based on the emergency state to enable the multiple user profiles to report the emergency state of the vehicle.

[0060] In this way, various aspects of the techniques may address various issues when driving on dangerous or extreme outside conditions to preserve any auto resource (like battery’) as much as possible. Examples of dangerous or extreme outside conditions are driving a fully electric car with low battery on roads were stopping may not be recommended (e.g. dangerous road) and/or driving a fully electric car with low batery when outside temperatures can be considering life threatening (very low or very high temperatures). VOS 160 may include an auto display service to ran all entertainment apps in emergency mode (or even shutdown) when vehicle conditions and current situation (outside temperature or driving in a dangerous road/area) are not ideal. VOS 160 may disable passenger's displays 150 or any other related entertainment hardware, while restricting the operator’s display 112 to run and show only essential applications (e.g., as indicated by an emergency mode access control list - ACL).

[00611 As an alternative or in conjunction with the above examples, VOS 160 may enter the protected operating mode by disabling all audio playback by computing device 102 based on the emergency state. In this example, V OS 160 may lower the audio to enable the operator of tlie vehicle to potentially better focus on the emergency state. In some instances, VOS 160 may disable all audio control except for audio controls related to the emergency state.

[0062] VOS 160 may automatically communicate a state of the operator of the vehicle while in the emergency state. VOS 160 may report the state of the operator to emergency services, private security services, etc. VOS 160 may next transfer audio control of VOS 160 to the one or more passengers based on the state of the operator of the vehicle. That is, if the operator of the vehicle is incapacitated, VOS 160 may transfer audible control of VOS 160 to tlie one or more passengers so that the one or more passengers can act on behalf of the operator to contact emergency services. VOS 160 may, in other words, enable the one or more passengers to initiate an emergency telephone call to the emergency sendees.

[0063] VOS 160 may include a service that allows for a signal to be sent from OEM as an emergency signal. This signal would be used to disable all sounds in the car and disable controls for non emergency audio use cases. This emergency service can also be used to signal if the driver has been incapacitated and possibly transfer audio system controls to the other users in the car. This could also automatically enable other user to control main cabin emergency system in general. Thus a user could perform phone call in case the driver becom es incapacitated .

[0064] As noted below, vehicle head unit 102 may be located in a center console of the front dashboard of the vehicle and includes a main display 112 by which the operator of the vehicle interfaces with vehicle head unit 102. VOS 160 may determine whether tlie operator of the vehicle or the one or more passengers of the vehicle are using main display 112 of vehicle head unit 102. VOS 160 may next disable, responsive to determining the one or more passengers of the vehicle are using main display 112, the protected operating mode to allow the one or more passengers to interface with V OS 160 via main display 112.

100651 VOS 160 may determine whether the one or more passengers of the vehicle are using main display 112 by, at least in part, determining speed of the vehicle, determining an occupancy of the one or more passengers, and determining a state of a passenger interaction status element. VOS 160 may then disable, based on one or more of the speed of the vehicle, tire occupancy of the one or more passengers, and tire state of the passenger interaction status element, the protected operating mode to allow the one or more passengers to interface with VOS 160 via main display 112. The passenger interaction status element may include a physical button disposed out of reach of the operator of the vehicle.

[0066] In other words, various aspects of the techniques described in this disclosure include vehicle head unit 102, a speed senor, an occupancy senor, and additional button (passenger UX button) for requesting the lift of the restriction. Speed senor: with this senor, vehicle head unit 102 may identify if the car is parked, or moving. Occupancy senor: with this senor, vehicle head unit 102 may identify if there is really a passenger is seating in the passenger seat. Passenger UX Button: this button should be placed out of the reach of the driver and mostly can be placed in the passenger door control panel.

[0067] The following is the algorithm to apply this policy:

® When the car starts, it should check the status of Passenger UX Button, if the button is on initially, we can assume that the buton is broken and this lifting restriction will stop to work.

® When the car moves and the head unit is showing some UX.

® If the button is off, the head unit applies the car UX restriction by definition.

® If the button is on and the occupancy senor indicates there is a passenger, then the vehicle head unit 102 can lift the car UX restriction while the button is on (or it can apply some timeout).

[0068] As noted above, VOS 160 may determine an emergency state in which safety of the vehicle is compromised . VOS 160 may, responsive to determining the emergency state, present a panic mode user interface that includes a panic button by which to automatically request emergency services. VOS 160 may initiate, responsive to receiving an input corresponding to selection of the panic button, communication with the emergency services. [0069] In this way, displays 112/150 enter in a panic mode after a car accident. Panic mode represents the easiest way for asking for help. One example of panic mode is when all displays show one 'panic' button that when pressed it automatically asks for help (e.g. car calling 911 with or without automated message).

[0070] VOS 160 may, when determining the operating context, determine that the vehicle is entering a potentially unsafe operating context in which the operator of the vehicle requires additional attention. VOS 160 may enter the protected operating mode by entering, responsive to entering the potentially unsafe operating context, the protected operating mode in which VOS 160 lowers a volume of audio play back by the vehicle head unit. When configured to determine that the vehicle is potentially entering the potentially unsafe operating context, VOS 160 may determine, as one example, that the vehicle is passing another vehicle by crossing into oncoming traffic. As such, the vehicle lower displays volume or any other entertainment potential distraction when it detects a stressfill situation (e.g, another approaching vehicle in opposite direction during a trespass).

[0071 ] in this respect, various aspects of the techniques may improve operation of vehicle head unit 102 itself by dynamically entering into the protected operating mode to potentially improve a safety level associated with operating the vehicle. In the context of batten' lite for example, VOS 160 may disable or reduce operation of displays 112/150 to preserve battery life such that the vehicle may reach an intended destination without exhausting the battery powering the vehicle, which may improve safety especially when weather conditions may otherwise pose a significant risk to the operator and/or passengers health (e.g., when it is ven' cold or hot outside the controlled environment of the vehicle). As such, various aspects of the techniques described in this disclosure may improve upon operation of the vehicle itself in terms of providing safety for the operator and/or passengers (which in the context of autonomous vehicles may include the “operator’).

[0072] Furthermore, by dynamically entering into the protected operating mode only when certain conditions are met (or, in other words, when the operating context warrants entering into the protected operating mode), various aspects of the techniques may reduce errant entry into the protected operating mode in operating contexts that do not warrant entry' into such protected operating mode. By avoiding unnecessary entry into the unwarranted protected operating mode, VOS 160 may improve the user experience while also potentially still addressing operator and/or passenger safety' in a number of different ways.

[0073] FIG. 2 is a diagram illustrating an example of a vehicle that includes a computing system configured to execute a vehicle operating system that operates in accordance with various aspects of the single-instance multi-user techniques described in this disclosure. As shown in the example of FIG . 2, an interior (which may be referred to as a “cabin”) of vehicle 200 may include a computing system in the form of vehicle head unit 202, which represents £in example of computing device 102.

[0074] Vehicle head unit 202 is, in the example of FIG. 2, integrated into approximately a center portion (e.g., a center console) of a front dashboard 220. Vehicle head unit 202 includes a display 212, which may represent one example of presence-sensitive display 112. Vehicle 200 may also include displays 250A, 250B, and 250C, which may represent examples of displays 150 described above with respect to FIG. 1. Display 250A is integrated into a passenger side of the front dashboard 220. Although not shown in the example of FIG. 2, a display similar to display 250A may be integrated into an operator side of front dashboard 220. Displays 250B and 250C are integrated into a rear passenger compartment of the cabin (i.e., in headrests of the front seats in the example of FIG. 2) on both the operator side (display 250B) and a passenger side (display 250C).

[0075] As described above, VOS 160A may interface, via a first user interface (presented for example by display 250A) associated with a first user profile (e.g., UP I61A), with a first user (a front passenger) to interact with content presented by a second user interface (e.g., presented for example by display 250B) associated with a second user profile (e.g., UP 16 IB) of multiple UP 161. In some instances, VOS 160A may interfacing with the first user to one or more of view or initiate playback, at the first user interface, the content presented by the second user interface.

[0076] VOS 160A may also interface with the first user to control audio playback by the second user interface presented by display 250B. VOS 160A may interface with the first user to, via the first user interface presented by display 250A, change an audio volume associated with the audio playback by the second user interface presented by display 250B.

[0077] VOS 160A may also interface with the first user to enable the first user and the second user (e.g., an operator-side rear passenger) to jointly interact with the content presented by the second user interface presented by display 250B. In this example, VOS 160A may interface with the first user to enable the first user and the second user to jointly contribute to audio playback by the second user interface (such as by jointly collaborating on building an audio playlist). VOS 160A may also, as another example, interface with the first user to enable the first user and the second user to jointly contribute to a multi-user activity presented by the second user interface, where such multi-user activity may include a navigation activity in which both the first user and the second user contribute to navigation of vehicle 200 that includes vehicle head unit 202 and/or a multi-player video game presented by the second user interface. [0078] While shown as multiple physical displays 212/250, various aspects of the techniques may operate with respect to a single physical display (or multiple physical displays) having separate logically separated displays (or so-called virtual displays). That is, a single physical display 212/250 may be logically split (e.g., via software) to represent two distinct physical displays (from the perspective of the instance of VOS 160). In this respect, a single physical display may represent multiple different displays and displays 212/250 may each represent a logically separate virtual display.

[0079] In this respect, various aspects of the techniques described herein may enable a number of different use cases, including the following:

» A parent would like to see what their children are watching;

» Parent or driver would like to control the volume from the children's displays;

« Two or more passengers may want to contribute to some shared playlist; and

® Two or more passengers may want to interact on the same content (like a multi -game player).

The following use cases may be enabled given that the techniques allow for the following:

® Mirror displays contents when running on Android Auto;

» Allow drivers and passengers mirror their display contents; and

» Let driver or passenger send inputs, like (key, rotary, dpad, touch, etc events) to other's passenger displays.

[0080] In other words, various aspects of the techniques described herein m ay address problems associated wdth enabling mobile apps to interact with each other (same or different app) across concurrent multiple risers on single Android instance. As such, the techniques may enable interaction from rear seat to operator for adding a stop in navigation and/or interaction from an operator to rear seat (such as a child) for playing video.

[0081] VOS I60A may also interface, via the first user interface associated with UP I61A, with a first user (front passenger) of the multiple users to share content presented by the first user interface with a second user interface of the multiple user interfaces associated with UP 161 B . For example, VOS 160A may receive, at the first user interface presented as an example by display 250A, a gesture that indicates the content presented by the first user interface is to be shared with the second user interface presented for example by display 250B. The gesture may include one or more of a swipe gesture, a pinch gesture, a tap gesture, or any other gesture associated with using presence-sensitive displays, such as display 250A. [0082] VOS 160 A may be configured to, in some instances, present, at the first user interface, an animation indicating initiation of the content being shared. In addition or alternatively, VOS 160A may play audio indicating initiation of the content being shared. In some examples, VOS 160A may, when playing audio indicating initiation of the content being shared, play spatialized audio to reflect a position of the first user interface relative to a position of the second user interface.

[0083] In this respect, various aspects of the techniques may make cross-display interaction, such as sharing screens, more immersive using advanced user interface technologies. Based on the locational relationship between passenger zones in the vehicle, the techniques may enable the following:

® Sending content from one display to another using gesture (swipe, click, etc,);

® Visualizing the interaction using animation; and

» Using spatial audio to show' where the content is moving to make it more immersive. [0084] FIG. 3 is a diagram illustrating different interaction models with multiple displays including interactions that occur via single instance multi-user models and multi-instance multi-user models in accordance with the vehicle operating system techniques described in this disclosure. As discussed in this disclosure, vehicle displays, such as displays 212 and 250, are evolving from operator centric to whole car experiences, where passengers can have the following:

® Personal curated experiences while commuting to work;

® Communal experiences to enjoy a family fun trip; and

» Shared experiences, while in an ride-sharing environment

[0085] Original equipment manufacturers (OEMs) may recognize these needs and are building cars to provide users with these experiences. These are no more seen as premium experiences but a value for a desirable vehicle.

[0086] In this respect, users may look for concurrent experiences across displays for a seamless and immersive experience, such as:

® Navigation - add stops to driver from their display for ongoing journey;

» Entertainment - Play and control video for kids in backseat or play games to keep them engaged & entertained;

• Users - Access their own curated apps, content and data for entertainment and/or productivity; and

« Personalization - Control my seat settings, HVAC control, alerts for my seat. [0087] OEMs are thinking about following user interaction models, based on anticipation of user behaviors. There are 3 types of interactions models (shown in the example of FIG. 3):

1 . In-vehicle infotainment (IVI) Display is the primary controller for content on front seat entertainment (FSE) and rear seat entertainment (RSE); a. FSE and RSE have minimal controls - audio, play/pause, on/off etc.

2. IVI Screen is mirrored across FSE/RSE, with passenger displays cannot select content or controls; and

3. Content can be shared across all the screens, with each screen having its own individual controls.

[0088] There are the following user personas for multi-display scenarios:

® Driver: o Interacting with cluster & IVI screens for driving and interacting with oilier screens in car

® Front seat passenger: o Assisting to driver for navigation and passengers content using FSE

® Rear seat passengers: o Interacting with RSE for content, controls and suggestions to driver tor navigation

» Guest: o Temporary riding in the car and wants to access some apps on passenger displays

[0089] FIG. 4 is a diagram illustrating an example vehicle that includes a vehicle head unit configured to control audio content in accordance with various aspects of the single-instance multi-user vehicle operating system techniques described in this disclosure. In the example of FIG. 4, a vehicle 400 may represent an example of vehicle 200 (shown in FIG. 2) in which a vehicle head unit 202 may enable privacy and sharing between different audio zones 404A- 404D (“audio zones 404") within vehicle 400. Audio zone 404A may represent a front seat operator-side zone (also denoted a ‘"front operator zone 404A”). Audio zone 404B may represent a front seat passenger-side zone (also denoted a ‘"front passenger zone 404B ”).

Audio zone 404C may represent an operator-side rear passenger zone, while audio zone 404D may represent a passenger-side rear passenger zone.

[0090] In each of audio zones 404, vehicle 200 may include a respective one of audio capture devices 452A-452D (“audio capture devices 452”) and a respective one of speakers 454A- 454D (“speakers 454”). Audio capture devices 452 may represent examples of audio capture devices 152. Both audio capture devices 452 and speakers 454 may represent transducers capable of converting, in the instance of audio capture devices 452, sound pressure into electrical signals representative of a soundfield and, in the instance of speakers 454, electrical signals representative of a soundfield into the corresponding soundfield.

[0091] Although described as having a single one of audio capture devices 452 and a single one of speakers 454 in each of audio zones 404, each of audio zones 404 may include more or less audio capture devices 452 and more or less speakers 454. Further, while described as being transducers, any type of device capable of capturing audio data (transformed from the electrical signals captured by the audio capture devices 452) and reproducing a soundfield from electrical signals (transformed from audio data) may be utilized in one or more of audio zones 404. In addition, while four audio zones 404 are shown in the example of FIG. 4, vehicle 400 may include more or less audio zones 404.

[0092} In any event, VOS 160 A may interface with the multiple users to control audio playback within one or more of zones 404 of a cabin of vehicle 400 that includes vehicle head unit 202. VOS 160A may, for example, interface with the multiple users to control audio volume in a single one of zones 404 of the cabin. As another example, VOS 160A may interface with the multiple users to control a focus of audio playback in at least one of zones 404 of the cabin.

[0093] As such, various aspects of the techniques may provide a central service for audio controls concurrently for all users (e.g,, driver and/or passengers) to control audio settings (volume up/down, mute, unmute, or any other control). To facilitate this control, VOS 160A may provide a service to manage audio controls (e.g., volume, mute, settings, ducking, interruptions, etc.) so as to provide the following:

® Manage controls independently for each user in their respective audio zones;

® Manage focus for other users in separate zone;

• While taking into consideration current safety restrictions; and

® While taking into consideration current user roles (Driver, passenger, disable passenger, rear seat passenger).

[0094] In addition, one or more of audio capture devices 452 may capture audio data representative of a soundfield at each of one or more zones 404 (which is another way to refer to audio zones 404). VOS 160A may determine, based on the audio data representative of the soundfield occurring at each of zones 404, that a first user of the multiple users in a first zone (e.g., zone 404C) of the one or more zones is speaking in an attempt to audibly interface with vehicle head unit 202. VOS 160A may adjust, based on the audio data representative of the soundfield occurring at each of zones 404, audio playback at zones 404. [0095] In terms of adjusting audio playback, VOS 160A may determine, based on the audio data representative of the soundfield occurring at each of zones 404, a noise level. VOS 160A may next adjust, based on the noise level, the audio playback at one or more of zones 404.

[0096] In this respect, various aspects of the techniques may address how to enable multi-mic support for VOS 160A. VOS 160A may, using audio data captured by audio capture devices 452, determine and/or perform the following:

® Use mic to know which user is speaking, talking to adjust the volume controls by recognizing user;

» Map to display being used;

• Provide better assistant response for the (speaking) user;

« Detect noise level for each user (around their respective areas) and perform required audio changes for audio playback for comfortable audio listening;

® Also combine audio information for each user to determine noise levels in the car and apply changes to speaker for a better listening environment;

[0097] FIGS. 5 and 6 are diagrams illustrating audio control in a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in tliis disclosure. In some instances, vehicle operating systems have limited scope in that such vehicle operating systems can only send audio from one zone to another for that particular application unique identifier (UID). Various aspects of the techniques described in this disclosure enable zones 404 to share audio to the cabin with the following objectives:

® Share media audio from passenger to the main cabin;

» Provide a mechanism for passengers not in main cabin to request for audio playback to main zone (e.g., operator zone 404A);

» Provide a mechanism for driver to allow audio playback in the main zone;

® Provide mechanism to share audio focus between two different zones; and

® Disable volume control from non-cabin owner from controlling volume;

[009§] For example, a passenger listening to media in the rear seat entertainment (RSE) zone (e.g., one of zones 404C or 404D) may send audio to the mam cabin to allow for everyone m the car to listen to audio. While the passenger in the back seat RSE would select to send audio to the main cabin, the operator (or main cabin user) would still maintain control of allowing the audio play, as well as retaining control of the volume and other audio settings. [0099] FIG. 5 shows a high-level overview of the current audio architecture. Audio zones 404 are defined in configuration are used to set up the audio routing for each audio zone 404. Each of audio zones 404 is defined as a collection of volume groups; each group contains a set of devices that are controlled on volume changes on the volume group. Each device can have different audio context’s routed into the device. The vehicle audio service may use the routing information on each audio zone to define a set of audio mixes, which VOS 160 A may use to configure the audio routing for each of zones 404.

[0100] Referring next to FIG. 6, a configuration set-up is shown between the vehicle audio service and vehicle occupant zone service. For audio, the vehicle audio service may read the audio zone ( audioZoneld ) to occupant zone Id ( occupantZoneld ) mapping from the configuration. This information may be sent to the car occupant zone sendee to set up the occupant zone configuration during initialization. Occupant zone service may maintain information about the occupant zone configuration and display port mapping, which may be read from the different configuration information.

[0101] The car audio service may register a Vehicle OccupantZoneCailback on the occupant zone service. VOS 160A may trigger this service when there are any of the following changes in the vehicle occupant zone:

« Display activation;

® Audio Config changes;

® Occupant Zone user assignments;

» Passenger Start; and

® Passenger Stop.

[0102] When the audio sendee receives the onOccupantZoneConfigChanged signal from the callback, the audio service of VOS 160A may automatically assign the users to their corresponding audio zone as follows:

« Unloads previous user settings;

® Removes previous user audio policy routing;

» Loads audio settings for the new user;

» Set up audio policy routing tor the new user; and ® Resets the audio focus mapping for the new user.

[0103] The audio service of VOS 160A may use the audio focus mapping to determine where the incoming focus request should be assigned.

[0104] To allow for the passenger to send audio to the main cabin there a couple of things that need to be in place:

® Handle focus request in main cabin; and

® Route passengers audio to the main Cabin

Once the focus request has successfully changed from the passenger's own audio zone in vehicle 400. the audio routing can take place. For audio playback not yet started, the focus handling will automatically request focus in the main cabin zone with the rules already set with regards to audio usage priority (e.g., audio for media will be rejected by current phone call).

[0105] The passenger should be able to request to send audio to the main cabin, a prompt would pop up for the driver to accept. Alternatively, the driver can enable an automatic allow for passengers to play audio. If accepted the audio focus request can be transferred to the main cabin, if needed, and the playback can commence. If not accepted the passenger can be prompted with a message.

[0106] Because one goal of the functionality is to play media from passengers in the main cabin, the focus request for the passenger can be restricted to media only. Focus requests for oilier sounds (e.g. alarm, call, notification, etc.) should remain in the passenger’s respective zone. For the media focus request the logic could be as follow:

» Send transient focus loss to passenger’s media apps;

® Request Focus for passengers media app in main cabin;

» Send focus gain if focus request is granted; and

» If not granted due to higher priority sound (emergency, phone call): o Set focus request as delayed focus;

⁸ Focus will be granted once higher priority focus is done; and o Alternative: Send focus back to the users zone

[0107] For passengers, where the user Id is used, a possible driver for audio routing may be the user id device affinity routing. This can still be utilized for sending the passengers audio to the main cabin as follows:

® Find the main's cabin media device (preferably a separate high quality device); and

® Reset the passenger device affini tie’s to share the cabin’s media device.

[0108] In addition, multi-zone audio (MZA) may facilitate playback of audio by various users, all playing audio on each individual audio zone 404. This may allow for users in the main cabin to play media or any other sounds, while users in a rear entertainment system also play media in their respective zones. This enables OEMs to potentially design complex audio infotainment systems where each passenger can tailor their own experience in vehicle 400.

[0109] Example use cases include the following:

• In the car, the driver can play music while users in the backseat can have their own music / media played;

• Users in the backseat can control their music volume without affecting the music playback of the driver;

• First party music apps launched in the backseat can play sound in the backseat without any change.

[0110] One mechanism used for MZA is based on the dynamic audio policy , in particular uses the UID / userid based routing. This may allow for the audio policy to define routing based on audio attribute usages, UID, or userid. This may allow' for applications or services to leverage the automatic routing of audio as configured by the dynamic audio policy. However, there exist APIs that can be used to route audio outside of tire assigned audio devices. This has some impact in the car as applications are able to send audio to a particular zone without the users permission for example:

® Rear seat entertainment (RSE) application from user A sending audio directly to the output device for the driver user in the main cabin.

• RSE application from user A sending audio directly to the output device for a different RSE assigned to user B.

This may raise some concerns for the driver safety as the main driver could be distracted upon arrival of an unwanted audio in the main cabin.

[0111] One possible goal of this aspect of the techniques is to allow the current dynamic audio policy to continue working but also limit the playback of audio for users (and their respective application/services) to play audio outside of a set of assigned zones, irrespective of the mechanism used to select devices for audio playback. A potential benefit for the users in the car is that such users will be able to consistently listen to audio in the car in a private and consistent manner.

[0112] The dynamic audio policy may provide a. mechanism to set devices that can be used by a user for automatic routing via an audio policy API. This audio policy API may either be used or extended to limit application using the audio routing relative to a set of preferred devices to route audio outside of the limits of the audio policy user assignment. Tills should potentially limit the “forced” routing for devices defined within the audio policy.

[0113] FIG. 7 is a flowchart illustrating example operation of the computing system shown in FIG. 1 in executing a vehicle operating system configure to perform various aspects of the safety techniques described in this disclosure. As described above, processors 140 of computing device 102 may execute an instance of a vehicle operating system (e.g., VOS 160A) (700). VOS 160A may determine an operating context in which the vehicle is currently operating (702). VOS 160A may interface with any number of different vehicle sensors to determine the operating context, such as speed sensors, global positioning system (GPS) sensors, occupant sensors (which, e.g., may sense weight applied to a seat), cameras, microphones, weather sensors (e.g., humidity, moisture, temperature, etc.), accelerometers, gyroscopes, infrared sensors, seat belt sensors, tire pressure sensors, or any other sensors capable of communicating with computing device 102 (where such sensors may be represented by input components 144 and/or output components 146).

[0114] To determine the operating context, VOS 160A may perform one or more of determining a usage of the VOS 160A by one or more passengers in the vehicle, determine a presence of the one or more passengers in the vehicle (e.g., via one or more of occupancy sensors, cameras, microphones, etc.), determine weather conditions in which the vehicle is currently operating, and determine an operational state of the vehicle. V OS 160A may also determine a state of a passenger interaction status element (e.g., a physical button disposed out of reach of the operator of the vehicle within the cabin of the vehicle, such as on a passenger door).

[0115] VOS 160 A may enter, based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle (704). For example, VOS 160A may enter the protected operating mode in which VOS 160A dynamically adjusts power settings of the vehicle to reduce power consumption of a battery powering the vehicle (e.g., in either hybrid or fully electric vehicles).

[0116] In this way, the above described techniques may enable the following examples:

[0117] Example 1 . A method comprising:executing, by a vehicle head unit of a vehicle, an instance of a vehicle operating system; determining, by the instance of the vehicle operating system, an operating context in which the vehicle is currently operating; and entering, by the instance of the vehicle operating system, and based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicL

[0118] Example 2, The method of example 1 , wherein entering the protected operating mode comprises entering the protected operating mode in which the vehicle operating system dynamically adjusts power settings of the vehicle to reduce power consumption of a batery powering the vehicle.

[0119] Example 3. The method of any combination of examples 1 and 2, wherein determining the operating context comprises one or more of: determining a usage of the instance of the vehicle operating system by one or more passengers in the vehicle; determining a presence of the one or more passengers in the vehicle; determining weather conditions in which the vehicle is currently operating; and determining an operational state of tlie vehicle.

[0120] Example 4. Ihe method of example 3, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the method further comprises presenting, by the instance of the vehicle operating system, multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles, and wherein entering the protected operating mode comprises disabling one or more of the multiple displays based on one or more of the usage of the instance of the vehicle operating system, the presence of the one or more passengers of the vehicle, the weather conditions, and the operational state of the vehicle ,

[0121] Example 5. The method of example 4, wherein the one or more passengers of the vehicle are associated with at least one of the multiple user profiles.

[0122] Example 6. The method of any combination of examples 3-5, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the operational state of the vehicle comprises a battery life, wherein the method further comprises presenting, by the instance of the vehicle operating system, multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles, and wherein entering the protected operating mode comprises disabling one or more of the multiple displays based on the weather conditions and the battery life.

[0123] Example 7, The method of any combination of examples 3-6, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the operational state of the vehicle comprises a batery life, wherein the method further comprises presenting, by the instance of the vehicle operating system, multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles, and wherein entering the protected operating mode comprises entering, based on one or more of tiie weather conditions and the battery' life, an emergency mode in which one or more applications executed by the vehicle operating system are executed in a restricted access mode to preserve the battery’ life.

[0124] Example 8. Tire method of any combination of examples 3-7, wherein determining the operational state of the vehicle comprises determining an emergency state in which safety of the vehicle is compromised, wherein the method further comprises presenting, by the instance of the vehicle operating system, multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of multiple user profiles, and wherein entering tire protected operating mode comprises enabling all of the multiple displays based on the emergency’ state to enable the multiple user profiles to report the emergency state of the vehicle.

[0125] Example 9. The method of any combination of examples 3-8, wherein determining the operational state of the vehicle comprises determining an emergency state in which safety of the vehicle is compromised, and wherein entering the protected operating mode comprises disabling all audio playback by the vehicle head unit based on the emergency state.

[0126] Example 10. Hie method of any combination of examples 3-9, wherein determining the operational state of the vehicle comprises determining an emergency’ state in which safety of the vehicle is compromised, and wherein entering the protected operating mode comprises disabling all audio control except for audio controls related to the emergency state.

[0127] Example 11. The method of any combination of examples 3-10, wherein determining the operational state of the vehicle comprises determining an emergency state in which safety of the vehicle is compromised, and wherein entering the protected operating mode comprises: automatically' communicating a state of the operator of the vehicle while in the emergency state; and transferring audio control of the vehicle operating system to the one or more passengers based on the state of the operator of the vehicle.

[0128] Example 12. The method of example 11, wherein transferring the audio control of the vehicle operating system enables the one or more passengers to initiate an emergency telephone call to an emergency’ service .

[0129] Example 13 . The method of any combination of examples 3-12, wherein the vehicle head unit is located in a center console of the a front dashboard of the vehicle and includes a main display by which the operator of the vehicle interfaces with the vehicle head unit, wherein determining the usage of the instance of the vehicle operating system comprises determining whether the operator of the vehicle or the one or more passengers of the vehicle are using the main display of the vehicle head unit, and wherein entering the protected operating mode comprises disabling, responsive to determining the one or more passengers of the vehicle are using the main display, the protected operating mode to allow the one or more passengers to interface with the vehicle operating system via the main display.

[0130] Example 14. Hie method of example 13, wherein determining whether the one or more passengers of the vehicle are using the main display comprises one or more of: determining a speed of the vehicle: determining an occupancy of the one or more passengers; and determining a state of a passenger interaction status element.

[0131] Example 15. The method of example 14, wherein entering the protected operating mode comprises disabling, based on one or more of the speed of the vehicle, tire occupancy of the one or more passengers, and the state of the passenger interaction status element, the protected operating mode to allow the one or more passengers to interface with the vehicle operating system via the main display.

[0132] Example 16. The method of any combination of examples 14 and 15, wherein the passenger interaction status element includes a physical buton disposed out of reach of the operator of the vehicle.

[0133] Example 17 . Hie method of any combination of examples 3-16, wherein determining the operational state of the vehicle comprises determining an emergency state in which safety of the vehicle is compromised, and wherein entering the protected operating mode comprises: presenting a panic mode user interface that includes a panic button by which to automatically request emergency services; and initiating, responsive to receiving an input corresponding to selection of the panic button, communication with the emergency services.

[0134] Example 18 . The method of any combination of examples 1-17, wherein determining the operating context comprises determining that the vehicle is entering a potentially unsafe operating context in which the operator of the vehicle requires additional attention, and wherein entering the protected operating mode comprises entering, responsive to entering the potentially unsafe operating context, the protected operating mode in which the vehicle operating system lowers a volume of audio playback by the vehicle head unit. [0135] Example 19. Tire method of example 18, wherein determining that the vehicle is potentially entering the potentially unsafe operating context comprises determining that the vehicle is passing another vehicle by crossing into oncoming traffic.

[0136] Example 20 . The method of any combination of examples 1-19, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the method further comprises: authorizing, by the instance of the vehicle operating system, the multiple user profiles to interface with the instance of the vehicle operating system; presenting, by the instance of the vehicle operating system, multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles; and interfacing, via the multiple user interfaces, with multiple users associated with the one or more of the multiple user profiles to enable the multiple users to interface with the instance of tire vehicle operating system for purposes of controlling functionality associated with the vehicle head unit.

[0137] Example 21 . The method of example 20, wherein the instance of a vehicle operating system comprises a first instance of the vehicle operating system, wherein the method further comprises executing a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0138] Example 22. The method of example 21, wherein the vehicle head unit includes a high processing capacity processor that executes the first instance of the vehicle operating system, wherein the vehicle head unit includes a low processing capacity processor that executes the second instance of the vehicle operating system, and wherein the high processing capacity processor provides more processing capacity than the low processing capacity processor.

[0139] Example 23. Hie method of any combination of examples 20 and 21, wherein the multiple displays are di splaced about a cabin of a vehicle that includes the vehicle head unit. [0140] Example 24. Tire method of any combination of examples 20-23, wherein the multiple displays includes two or more of: a first display integrated into an operator side of a front dashboard of a cabin of a vehicle that includes the vehicle head unit: a second display integrated into a center console of the front dashboard; a third display integrated into a passenger side of the front dashboard; and a fourth display integrated into a rear passenger compartment of the cabin. [0141] Example 25. Tie method of any combination of examples 20-24, wherein the multiple displays include one or more computing devices associated with at least one of the multiple users that is a passenger of a vehicle that includes the vehicle head unit.

[0142] Example 26. A computing device comprising: a memory'- configured to store an instance of a vehicle operating system: and one or more processors to execute the instance of tire vehicle operating system, wherein the instance of the vehicle operating system is configured to: determine an operating context in which the vehicle is currently operating; and enter, based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle.

[0143] Example 27. The computing device of example 26, wherein the instance of the vehicle operating system is configured to enter the protected operating mode in which the vehicle operating system dynamically adjusts power settings of tlie vehicle to reduce power consumption of a battery powering the vehicle.

[0144] Example 28. Tie computing device of any combination of examples 26 and 27, wherein the instance of the vehicle operating system is configured to perform one or more of: determine a usage of the instance of the vehicle operating system by one or more passengers in the vehicle; determine a presence of the one or more passengers in the vehicle; determine weather conditions in which the vehicle is currently operating; and determine an operational state of the vehicle.

[0145] Example 29. The computing device of example28, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the instance of the vehicle operating system is further configured to present multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles, and wherein the instance of the vehicle operating system is configured to disable one or more of tire multiple displays based on one or more of the usage of tire instance of the vehicle operating system, the presence of the one or more passengers of the vehicle, the weather conditions, and the operational state of the vehicle.

[0146] Example 30. Tie computing device of example 29, wherein the one or more passengers of the vehicle are associated with at least one of the multiple user profiles.

[0147] Example 31. The computing device of any combination of examples 2.8-30, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the operational state of the vehicle comprises a battery life, wherein the instance of the vehicle operating system is further configured to present mul tiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles, and wherein the instance of the vehicle operating system is configured to disable one or more of die multiple displays based on the weather conditions and the battery life.

[0148] Example 32. The computing device of any combination of examples 28-31, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles, wherein the operational state of the vehicle comprises a battery life, wherein the instance of the vehicle operating system is further configured to present multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of the multiple user profiles, and wherein entering die protected operating mode comprises entering, based on one or more of die weather conditions and the battery' life, an emergency mode in which one or more applications executed by the vehicle operating system are executed in a restricted access mode to preserve the battery' life.

[0149] Example 33. The computing device of any combination of examples 28-32, wherein the instance of the vehicle operating system is configured to determine an emergency state in which safety-’ of the vehicle is compromised, wherein the instance of the vehicle operating system is further configured to present multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces associated with one or more of multiple user profiles, and wherein the instance of the vehicle operating system is configured to enable all of the multiple displays based on the emergencystate to enable the multiple user profiles to report the emergency state of the vehicle.

[0150] Example 34. 'the computing device of any combination of examples 28-33, wherein the in stance of the vehicle operating system is configured to determine an emergency state in which safety of the vehicle is compromised, and wherein the instance of the vehicle operating system is configured to disable all audio playback by the vehicle head unit based on the emergency state.

[0151] Example 35. Hie computing device of any combination of examples 28-34, wherein the instance of the vehicle operating system is configured to determine an emergency state in which safety of the vehicle is compromised, and wherein the instance of die vehicle operating system is configured to disable all audio control except for audio controls related to the emergency state. [0152] Example 36. Hie computing device of any combination of examples 28-35, wherein the instance of the vehicle operating system is configured to determine an emergency state in which safety of the vehicle is compromised, and wherein the instance of the vehicle operating system is configured to: automatically communicate a state of the operator of the vehicle while in the emergency state; and transfer audio control of the vehicle operating sy stem to the one or more passengers based on the state of the operator of the vehicle.

[0153] Example 37. The computing device of example 36, wherein the instance of the vehicle operating system is configured to transfer the audio control of the vehicle operating system to enable the one or more passengers to initiate an emergency telephone call to an emergency service.

[0154] Example 38 . The computing device of any combination of examples 28-37, wherein the vehicle head unit is located in a center console of the a front dashboard of the vehicle and includes a mam display by which the operator of the vehicle interfaces with the vehicle head unit, wherein the instance of the vehicle operating system is configured to determine whether the operator of the vehicle or the one or more passengers of the vehicle are using the main display of the vehicle head unit, and wherein the instance of the vehicle operating system is configured to disable, responsive to determining the one or more passengers of the vehicle are using the main display, the protected operating mode to allow the one or more passengers to interface with the vehicle operating system via the main display.

[0155] Example 39. The computing device of example 38, wherein the instance of the vehicle operating system is configured to perform one or more of: determine a speed of the vehicle; determine an occupancy of the one or more passengers; and determine a state of a passenger interaction status element.

[0156] Example 40. The computing device of example 39, wherein the instance of the vehicle operating system is configured to disable, based on one or more of the speed of the vehicle, the occupancy of the one or more passengers, and the state of the passenger interaction status element, the protected operating mode to allow the one or more passengers to interface with the vehicle operating system via the main display.

[0157] Example 41 . Hie computing device of any combination of examples 39 and 40, wherein the passenger interaction status element includes a physical button disposed out of reach of the operator of the vehicle.

[0158] Example 42. The computing device of any combination of examples 28-41, wherein the instance of the vehicle operating system is configured to determine an emergency state in which safety of the vehicle is compromised, and wherein the instance of the vehicle operating system is configured to: present a panic mode user interface that includes a panic button by which to automatically request emergency services; and initiate, responsive to receiving an input corresponding to selection of the panic button , communication with the emergency services.

[0159] Example 43. The computing device of any combination of examples 26-42, [0160] wherein the instance of the vehicle operating system is configured to: determine that the vehicle is entering a potentially unsafe operating context in which the operator of the vehicle requires additional attention; and enter, responsive to entering the potentially unsafe operating context, the protected operating mode in which the vehicle operating system lowers a volume of audio playback by the vehicle head unit.

[0161] Example 44. The computing device of example 43, wherein the instance of the vehicle operating system is configmed to determine that the vehicle is passing another vehicle by crossing into oncoming traffic.

[0162] Example 45. The computing device of any combination of examples 26-44, wherein the instance of a vehicle operating system comprises a. first instance of the vehicle operating system, wherein the one or more processors are further configured to execute a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of tlie vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0163] Example 46. The computing device of example 45, wherein the one or more processors include a high processing capacity processor that executes the first instance of the vehicle operating system, wherein one or more processors include a low processing capacity processor that executes the second instance of the vehicle operating system, and wherein the high processing capacity processor provides more processing capacity than the low processing capacity- processor.

[0164] Example 47. The computing device of any combination of examples 45 and 46, wherein the multiple displays are displaced about a cabin of a vehicle that includes the vehicle head unit.

[0165] Example 48. Hie computing device of any combination of examples 45-47, wherein the multiple displays includes two or more of: a first display integrated into an operator side of a front dashboard of a cabin of a vehicle that includes the vehicle head unit; a second display integrated into a center console of the front dashboard; a third display integrated into a passenger side of the front dashboard; and a fourth display integrated into a rear passenger compartment of the cabin. [0166] Example 49. Hie computing device of any combination of examples 45-48, wherein the multiple displays include one or more computing devices associated with at least one of the multiple users that is a passenger of a vehicle that includes the vehicle head unit.

[0167] Example 50. A non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: execute an instance of a vehicle operating system; determine, by the instance of the vehicle operating system, an operating context in which the vehicle is currently operating; and enter, by the instance of the vehicle operating system, and based on the operating context, a protected operating mode in which the vehicle operating system dynamically adapts one or more operational features of the vehicle operating system to facilitate safety of an operator of the vehicle.

[0168] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer- readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium ,

[0169] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, ultra Blu-ray, etc. where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0170] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described. In addition, in some aspects, the functionality described may be provided within dedicated hardware and/or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.

[0171] The techniques of tins disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.

[0172] Various examples have been described. These and other examples are within the scope of the following claims.