Key terms & concepts
Stay organized with collections
Save and categorize content based on your preferences.
This section explains some key terms used in these guidelines, as well as the abbreviations used in the specs.
Meaning of Must, Should & May
The Android for Cars design guidelines use the terms MUST, SHOULD, and MAY according to definitions published by the IETF. Both car makers and app developers need to understand the meanings of these terms.
Throughout these guidelines, the terms MUST, SHOULD, and MAY appear frequently (both capitalized in tables and lowercase in running text). The use of these terms conforms to the definitions provided by the IETF to clarify various requirement levels in specifications.
For full details, see the IETF definitions, which are the authoritative source for the way these terms are used in these guidelines and in the Android Compatibility Definition Document (CDD).
To ensure that Android for Cars systems work consistently and reliably across all implementations, car makers and app developers need to keep the following in mind:
| Term |
Meaning |
| MUST |
The guideline is an absolute requirement (cannot be omitted or ignored). Such requirements are enforced either at the API level or by:
- Google's design review process for car makers using Google Automotive Services
- Google Play store's review process for third-party apps
|
| SHOULD |
There may be valid reasons in particular circumstances to ignore the guideline, but the full implications must be understood and carefully weighed before choosing a different course.
|
| MAY |
The guideline is truly optional. One car maker or app developer may choose to follow the guidelines to meet specific market or product needs, while another may omit the same item.
An implementation that does not include a particular option MUST be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. In the same vein, an implementation that does include a particular option MUST be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides.)
|
Driving states
These guidelines occasionally refer to differences in the user experience that depend on the car’s driving state – that is, whether it’s parked, idling, or moving. The decisions about what is allowed in various driving states and speed ranges depend on the car maker and on the relevant regulatory requirements in different regions.
In some cases, for example, a certain action might be allowed only if the car is stopped with the parking brake on. In others, the action might be allowed only if the car is moving at or below a certain speed, such as 5 mph.
Layout labels
The following labels are used throughout these guidelines in depictions of spec layouts.
| Label |
Description |
 |
Edge: Indicates width and height boundaries of the available window.
|
 |
Margin: Defines the left and right boundaries of the app canvas, measured from the nearest edge. For a discussion of how margin width varies with screen size, visit App working space.
|
 |
Keyline: A value that is proportional to screen width, used to specify the horizontal distance between an element and the nearest margin or component edge. For the keyline values associated with specific screen-width categories, visit Keylines.
|
 |
Padding: Value used to specify spacing between elements on the screen according to their relationships. In general, the closer the relationship is between two elements, the narrower the padding. For details of the padding values used in spec layouts, visit padding.
|
 |
Flex: Term used to specify a vertically or horizontally centered element in a container, or a distance that can grow or contract according to the adjacent elements. Flex-layout dimensions are sometimes assigned a minimum or maximum value, as discussed in Scaling strategies.
|
 |
Corner Radius: Specifies the curvature of a corner, with zero indicating a square corner and higher values indicating more rounding.
|
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-07-23 UTC.
[null,null,["Last updated 2024-07-23 UTC."],[[["\u003cp\u003eThis document clarifies key terms like MUST, SHOULD, and MAY, aligning with IETF definitions for consistent understanding across car makers and app developers.\u003c/p\u003e\n"],["\u003cp\u003eDriving state context is crucial, as the car's state (parked, idling, moving) influences permissible actions and user experience, subject to car maker decisions and regional regulations.\u003c/p\u003e\n"],["\u003cp\u003eLayout labels like Edge, Margin, Keyline, Padding, Flex, and Corner Radius are used throughout the guidelines to illustrate specifications for app design and screen elements.\u003c/p\u003e\n"],["\u003cp\u003eFor in-depth information, refer to linked resources detailing IETF definitions, Android Automotive library, and layout specifications.\u003c/p\u003e\n"]]],[],null,["# Key terms & concepts\n\n\u003cbr /\u003e\n\nThis section explains some key terms used in these guidelines, as well as the abbreviations used in the specs.\n\n*** ** * ** ***\n\nMeaning of Must, Should \\& May\n------------------------------\n\nThe Android for Cars design guidelines use the terms **MUST** , **SHOULD** , and **MAY** according to definitions published by the IETF. Both car makers and app developers need to understand the meanings of these terms.\n\nThroughout these guidelines, the terms **MUST** , **SHOULD** , and **MAY** appear frequently (both capitalized in tables and lowercase in running text). The use of these terms conforms to the definitions provided by the IETF to clarify various requirement levels in specifications.\n\nFor full details, see the IETF definitions, which are the authoritative source for the way these terms are used in these guidelines and in the Android Compatibility Definition Document (CDD).\n\nTo ensure that Android for Cars systems work consistently and reliably across all implementations, car makers and app developers need to keep the following in mind:\n\n| Term | Meaning |\n|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| MUST | The guideline is an absolute requirement (cannot be omitted or ignored). Such requirements are enforced either at the API level or by: - Google's design review process for car makers using Google Automotive Services - Google Play store's review process for third-party apps |\n| SHOULD | There may be valid reasons in particular circumstances to ignore the guideline, but the full implications must be understood and carefully weighed before choosing a different course. |\n| MAY | The guideline is truly optional. One car maker or app developer may choose to follow the guidelines to meet specific market or product needs, while another may omit the same item. An implementation that does not include a particular option **MUST** be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. In the same vein, an implementation that does include a particular option **MUST** be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides.) |\n\n[IETF definitions of MUST, SHOULD, MAY\nand related terms](https://www.ietf.org/rfc/rfc2119.txt)\n\n*** ** * ** ***\n\nDriving states\n--------------\n\nThese guidelines occasionally refer to differences in the user experience that depend on the car's driving state -- that is, whether it's parked, idling, or moving. The decisions about what is allowed in various driving states and speed ranges depend on the car maker and on the relevant regulatory requirements in different regions.\n\nIn some cases, for example, a certain action might be allowed only if the car is stopped with the parking brake on. In others, the action might be allowed only if the car is moving at or below a certain speed, such as 5 mph. \n[Android Automotive Library: android.car.drivingstate\nAdditional technical details for developers](https://developer.android.com/reference/android/car/drivingstate/package-summary)\n\n*** ** * ** ***\n\nLayout labels\n-------------\n\nThe following labels are used throughout these guidelines in depictions of spec layouts.\n\n| Label | Description |\n|-------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Edge:** Indicates width and height boundaries of the available window. |\n| | **Margin:** Defines the left and right boundaries of the app canvas, measured from the nearest edge. For a discussion of how margin width varies with screen size, visit [App working space](/cars/design/automotive-os/design-system/layout#app_working_space). |\n| | **Keyline:** A value that is proportional to screen width, used to specify the horizontal distance between an element and the nearest margin or component edge. For the keyline values associated with specific screen-width categories, visit [Keylines](/cars/design/automotive-os/design-system/layout#keylines). |\n| | **Padding:** Value used to specify spacing between elements on the screen according to their relationships. In general, the closer the relationship is between two elements, the narrower the padding. For details of the padding values used in spec layouts, visit [padding](/cars/design/automotive-os/design-system/layout#padding). |\n| | **Flex:** Term used to specify a vertically or horizontally centered element in a container, or a distance that can grow or contract according to the adjacent elements. Flex-layout dimensions are sometimes assigned a minimum or maximum value, as discussed in [Scaling strategies](/cars/design/automotive-os/design-system/layout#scaling_strategies). |\n| | **Corner Radius:** Specifies the curvature of a corner, with zero indicating a square corner and higher values indicating more rounding. |\n\n[Layout\nMargins, keylines, and padding for various screen sizes](/cars/design/automotive-os/design-system/layout)"]]
