Create a sign-in flow (optional)

Sign-in flows designed for the car screen are not as critical on Android Auto because the app is projected from a phone that already has its own sign-in experience. Signing in while driving can be unsafe and can cause driver distraction, so it is available only while parked.

You can create a sign-in flow for the car screen using templates from the Android for Cars App Library, which are vehicle-optimized. The design process involves these tasks:

Choose a primary sign-in method and any backup methods from the available sign-in methods.
Plan the task flow, designing a sequence of templates to lead users through the sign-in task. For example: sign in to the app while parked.
Validate usability, ensuring that your planned flow meets the UX requirements for the Android for Cars App Library.

To learn more about designing with the templates, see Build apps with templates.

Sign-in examples

Example login page — This example provides two different ways that the user can verify their identity (Android Auto).

Example Google login — This example features Google sign-in, or two other options (AAOS).

Sign-in requirements

The requirements in this section relate to how sign-in should work, for optimal usability, in Android Automotive OS.

Requirement level	Requirements
SHOULD	App developers should: Present Google sign-in as the primary option if the app and system support it Present phone sign-in (if supported) as the primary option if the app and system don't support Google sign-in Keep the length of the PIN for phone sign-in to 8 digits or fewer For standard sign-in, separate entry of username and password into two steps Put a label in the input box ("Enter password") and keep it visible somewhere on screen after user starts typing Provide users with the ability to show the password (which is generally hidden) while it's being typed Provide guidance for accessing a forgotten username or password Provide a way to create an account
MAY	App developers may: Provide standard app sign-in (username and password) as the primary option if neither Google sign-in nor phone sign-in can be supported Provide phone sign-in, standard sign-in, or both as backup options when Google sign-in is the primary option Provide standard sign-in as a backup option when phone sign-in is the primary option

Requirement level

Requirements

SHOULD

App developers should:

Present Google sign-in as the primary option if the app and system support it
Present phone sign-in (if supported) as the primary option if the app and system don't support Google sign-in
Keep the length of the PIN for phone sign-in to 8 digits or fewer
For standard sign-in, separate entry of username and password into two steps
Put a label in the input box ("Enter password") and keep it visible somewhere on screen after user starts typing
Provide users with the ability to show the password (which is generally hidden) while it's being typed
Provide guidance for accessing a forgotten username or password
Provide a way to create an account

MAY

App developers may:

Provide standard app sign-in (username and password) as the primary option if neither Google sign-in nor phone sign-in can be supported
Provide phone sign-in, standard sign-in, or both as backup options when Google sign-in is the primary option
Provide standard sign-in as a backup option when phone sign-in is the primary option