Structure your media app 4) Adapt sign-in flow

4) Adapt sign-in flow

If sign-in is required for your app, you need to supply a sign-in flow featuring one or more of the suggested sign-in methods.

You can create this flow by adapting the provided sample code. The process involves these steps:

  • Choosing a primary sign-in method (and any backup methods)
  • Adjusting the content of the sign-in screens
  • Customizing the visual styling

The sample code is provided in the Universal Android Music Player (UAMP) Automotive app. This code is designed to adapt to a variety of screen sizes, so you don’t need to deal with questions of portrait vs. landscape mode.

As you adapt the sample code for your app, the guidelines provided here will help you make sure your sign-in experience remains vehicle-optimized.

Technical note:
The sample code discussed in this section involves implementing sign-in as a dedicated Sign-in activity, for cases where sign-in is required to use the app. If some functions of your app can be accessed anonymously, another option is to implement sign-in as a settings workflow. For details, consult Add a Settings activity.

Choose sign-in methods Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Your first step in adapting the sample code is to decide which of the 3 available sign-in methods you want to offer.

Sign-in method

How it works

A) Google sign-in

(strongly recommended)

Enter Google account and password

B) Phone sign-in

(recommended as a backup option – or primary option, if your app doesn’t support Google sign-in)

Enter PIN code from car screen on phone, or vice versa

C) Standard sign-in

(best as a back-up option)

Enter username (or email) and password for the app

Google sign-in should be presented as the primary option if your app supports it, because it is easiest for users. If your app doesn’t support Google sign-in, phone sign-in is the next best choice as primary option.

The sign-in flow in the sample code includes screens for all three methods. Once you’ve decided which options you’re supporting (both the primary option and any backup options you may want to support), you can disable any remaining options in the sample code and focus on customizing the remaining screens.

Technical note:
Each sign-in option in the sample code is associated with an ENABLE constant with that can be toggled on and off. For example, to disable the Google sign-in option, you would set ENABLE_GOOGLE_SIGN_IN to “false.” These constants are specified in SignInLandingPageFragment.kt, which is part of the Universal Android Music Player (UAMP) Automotive app.

A) Google sign-in Expand and collapse content An arrow that points down when collapsed and points up when expanded.

If your app supports Google sign-in and Google sign-in is available in the system, it’s best to make this method the primary option in your sign-in flow. It’s easy for users because they simply need to confirm their existing Google account.

If you offer phone sign-in or standard sign-in, those should be presented as backup options available from text links at the bottom of the landing screen.

Landing page featuring “Sign in with Google” button

Here, Google sign-in is offered as the primary sign-in method, as recommended, while the other methods are offered as backup options.

Google sign-in flow

With Google sign-in, the landing page is the only screen you need to design, unless you are also offering backup options (visit Phone sign-in and Standard sign-in for screens and flows for those options).

Flow chart of Google sign-in screens

If a user selects Google sign-in on the landing page (rather than one of the backup options, if they are offered), Google takes care of the remainder of the sign-in process

B) Phone sign-in Expand and collapse content An arrow that points down when collapsed and points up when expanded.

If your app doesn’t support Google sign-in, it’s best to offer phone sign-in as the primary option in your sign-in flow. (Phone sign-in can also be offered as a backup option for Google sign-in.) With phone sign-in, users don’t need to remember a username or password. Instead, they enter a PIN that is supplied to them.

Phone sign-in can be done either of 2 ways:

  • Users see a PIN on the car screen and enter it on their phones
  • Users look up a PIN on their phones and enter it on the car screen

If the standard username-and-password method is also offered, it should be presented as a backup option available from a text link at the bottom of the landing screen.

Landing page on car screen displaying a PIN for users to enter on their phones

In one version of phone sign-in, users see a PIN to enter on their phones

Landing page on car screen instructing users to enter a PIN from their phones

In the other version of phone sign-in, users can enter a PIN obtained from their phones

Note:
To avoid excessive cognitive load for users, it’s important to keep PIN codes to 8 digits or fewer in length, as specified in the Sign-in guidelines.

Phone sign-in flow

With Phone sign-in, you can choose from two versions of the landing page: one that displays a PIN for entry on the phone, and one that lets users enter a PIN supplied on the phone.

The screen for the landing page is the only one you need to design, unless you are also offering Standard sign-in as a backup option.

Flow chart of Phone sign-in screens

When phone sign-in is the primary option, sign-in is complete when users have entered a PIN as the landing page instructs them to do (unless a backup option is offered and chosen)

C) Standard sign-in Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Standard sign-in for an app requires a user to enter a username (or email) on the landing page, then enter a password on the next page.

Standard sign-in can be offered as a backup option to Google sign-in or phone sign-in. Or, if neither of the other two options are supported, it can be the primary sign-in option. Standard sign-in is not recommended as a primary option, however, because it involves multiple steps and remembering usernames and passwords.

Because users may not always remember usernames and passwords, it’s important to offer options for retrieving or resetting them. These options should be offered via text links at the bottom of the entry screens, so they don’t compete for attention with the primary actions of username and password entry.

Landing page displaying a text-entry box for username or email

Step 1 of standard sign-in involves entering a username or email

Page displaying a text-entry box for password entry

Step 2 of standard sign-in involves entering a password

Username retrieval page

Users who don’t remember their usernames are sent to this page

Password reset page

Users who don’t recall their passwords are sent to this page

Standard sign-in flow

The flow for standard sign-in is a sequence of 2 screens (username entry and password entry), with optional side trips to 2 other screens. You will need versions of all 4 screens.

Flow chart of standard sign-in screens

If users remember their usernames and passwords, they complete 2 entry screens before being signed in; otherwise, they are directed to one or two extra screens with instructions

Adjust content of screens Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Once you have determined which sign-in methods your app will support, you will know which screens will be in your sign-in flow. Depending on what you choose to support, you may have anywhere from 1 to 6 screens for which you need to determine the content (and styling, as discussed in Customize styling).

If you choose Google sign-in or phone sign-in with no backup options, you’ll have 1 sign-in screen to create. On the other hand, if you choose Google sign-in with both other options as backups, you’ll have 6 screens (1 for Google sign-in, 1 for Phone sign-in, and 4 for Standard sign-in).

Examples of these screens are shown in the Google sign-in, phone sign-in, and standard sign-in sections. If you are working from the sample code, you can modify the versions of these screens created in the code. If you are not using the sample code, you should still use these examples as a model.

You’ll need to make some adjustments to the content of these screens, including the following:

  • Replace the logo for the fictional Aural app with your app logo
  • Modify text and links to reference your app and your related content
  • Adjust the PIN-display logic

Logo replacement and PIN-display logic are discussed in more detail below.

Replace app logo

After removing screens you don’t need from the sample code, you’ll want to make sure the remaining screens display your app logo instead of the logo for the fictional Aural app. This replacement may affect other aspects of page design, as discussed below.

Technical note:
The app logo is defined as one of the drawable resources for the sample sign-in app, which is part of the Universal Android Music Player (UAMP) Automotive app.

BEFORE: The landing page displays the logo for a fictional music app called Aural

AFTER: The customized version replaces Aural’s logo with the logo for a specific app

Replacing the logo may lead you to other fine-tuning, such as customizing the colors of other page elements or adjusting the clearance around the logo.

Customizing colors to go with the logo

To ensure that your app logo blends in well with surrounding page elements, you can customize the sign-in code to use your app’s accent color. Styling customization is discussed in the next step, Customize styling.

customizing colors to logo

The accent color for the fictional Aural app (blue #57D9F7) is used to customize page elements such as buttons and links in the sample app and in the examples in this section

Adjusting the logo clearance

After replacing the Aural logo with your app’s logo, which will be scaled to the same size as the Aural logo, check the spacing around the logo. If the amount of clear space doesn’t meet your brand guidelines, you can add space around the edges of the logo in the logo file.

offsetting logo to follow clear space guidelines

To increase logo clearance, add space around the logo in the logo file, offsetting the logo size in the bounding box

Another approach would be to adjust the spacing on the screen. However, with this approach,you would need to adjust the spacing around the logo individually for each layout. For this reason, adding space within the logo file is the easiest way to increase the clear space around the logo.

Adjust PIN-display logic

The sample sign-in flow generates PIN codes randomly using a simple RAND function. To implement a PIN-generation method based on more robust business logic, you need to modify the relevant code in PinCodeSignInFragment.kt, which is part of the Universal Android Music Player (UAMP) Automotive app.

Note:
To avoid excessive cognitive load for users, it’s important to keep PIN codes to 8 digits or fewer in length, as specified in the Sign-in guidelines.

The links shown in this example and the logic that generates the PIN should be customized for your app

Customize styling Expand and collapse content An arrow that points down when collapsed and points up when expanded.

After adjusting the content of your sign-in screens, you can apply global, brand-appropriate styling to aspects of the UI that affect multiple screens.

You may want to customize any or all of the following to reflect your brand styling:

  • Input field style: filled, outlined, or underlined
  • Button style: rounded or rectangular
  • Colors: accent, button fill and text, form fill and stroke, form error
  • Typography: font, text size

Examples of some of these customization options are below. Keep in mind that customized styling must maintain contrast, minimum sizes for text and touch targets, and other requirements described in Guidelines for custom screens.

Technical note:
Styling is specified in the styles.xml file for the sample sign-in app, which is part of the Universal Android Music Player (UAMP) Automotive app.

Customizing input fields and buttons

Input fields and buttons

The sample sign-in flow uses outlined input fields and rounded buttons as its default styles. Go ahead and change these default styles if different ones – for example, rectangular buttons instead of rounded ones – would better express your brand.

mixed

Colors

Customizing the accent and error-state colors used in forms and buttons is a helpful way to express your brand throughout the sign-in flow. Customizing these colors is also important for making sure that input fields, buttons, and links look good on the same page with your app logo, rather than clashing with it.

Make sure that any colors you specify maintain a contrast ratio of at least 4.5:1 between adjacent page elements. For additional guidance about color, as well as details about the color palette used in Android Automotive OS, consult Visual foundations: Color.

mixed

Typography

While typography in the sample sign-in flow can be customized, be cautious about making any changes that could affect legibility. Consult Visual foundations: Typography for information about fonts, minimum type sizes, and other considerations with respect to readability of text on car screens.

Sign-in guidelines Expand and collapse content An arrow that points down when collapsed and points up when expanded.

The guidelines in this section relate to how sign-in should work, for optimal usability, in Android Automotive OS. The sample sign-in flow provided in the Universal Android Music Player (UAMP) app meets these guidelines, for the most part. It does not provide a way to create an account, because that would require app-specific logic.

If you have followed the customization process described in this section and have not otherwise changed how the code works, your sign-in flow should be in good shape with respect to the guidelines below. However, be sure to check that your customized styling meets the general requirements specified in Guidelines for custom screens.

If you have made more substantial modifications to the sign-in screens or code, beyond what is described in this section, check your sign-in flow with respect to the general Guidelines for custom screens and also the specific sign-in guidelines below.

Requirement level

Guidelines

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 onscreen 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 or 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.