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:
|
| 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. |