Create a sign-in flow (optional)

If users must sign in to your app, you need to supply a sign-in flow for AAOS that will work on the car screen.

On Android Auto, a sign-in flow for the car screen is less essential, since the app is projected from a phone that should already have its own sign-in experience. However, if you create a sign-in flow as described below, it will work for both AAOS and Android Auto (in a parked state only, because signing in while driving would be distracting).

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 (example: Sign in to the app while parked).
• Validate usability, making sure 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

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

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

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 do not 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

Rationale

• Consistent media experience. Sign-in screens designed for one media app should provide an experience that is broadly consistent with sign-in screens for other media apps.
• Consistent look and feel. Sign-in screens should support the basic design principles and visual foundations for Android Automotive OS.