Create a sign-in flow (optional)

  • Apps for Android Automotive OS require a dedicated sign-in flow for use on the car screen, while Android Auto leverages the phone's existing sign-in.

  • Developers can utilize pre-built templates from the Android for Cars App Library to streamline the creation of car-optimized sign-in experiences.

  • Google sign-in should be the preferred sign-in method if supported, with options for phone or standard sign-in as backups for broader compatibility.

  • Usability and consistency are crucial, ensuring sign-in flows are intuitive, adhere to design guidelines, and align with user expectations in a vehicle context.

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).
Example login page
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