Core App Quality Guidelines

App follows Android Design guidelines and uses common UI patterns and icons:

1. App does not redefine the expected function of a system icon (such as the Back button).
2. App does not replace a system icon with a completely different icon if it triggers the standard UI behavior.
3. If the app provides a customized version of a standard system icon, the icon strongly resembles the system icon and triggers the standard system behavior.
4. App does not redefine or misuse Android UI patterns, such that icons or behaviors could be misleading or confusing to users.

App supports standard system Back button navigation and does not make use of any custom, on-screen "Back button" prompts.

All dialogs are dismissable using the Back button.

Notifications follow Android Design guidelines. In particular:

1. Multiple notifications are stacked into a single notification object, where possible.
2. Notifications are persistent only if related to ongoing events (such as music playback or a phone call).
3. Notifications do not contain advertising or content unrelated to the core function of the app, unless the user has opted in.

App uses notifications only to:

1. Indicate a change in context relating to the user personally (such as an incoming message), or
2. Expose information/controls relating to an ongoing event (such as music playback or a phone call).

Related resources:

• Android Design — Overview of design and user experience best practices for Android apps.
• Navigation with Back and Up — Android Design document describing standard navigation patterns.
• Action Bar — Android Design document describing how to use the Action Bar.
• Iconography — Android Design describing how to use various types of icons.
• Notifications — Android Design document describing how to design and use notifications.

App does not request permissions to access sensitive data (such as Contacts or the System Log) or services that can cost the user money (such as the Dialer or SMS), unless related to a core capability of the app.

App functions normally when installed on SD card (if supported by app).

Supporting installation to SD card is recommended for most large apps (10MB+). See the App Install Location developer guide for information about which types of apps should support installation to SD card.

App supports both landscape and portrait orientations (if possible).

Orientations expose largely the same features and actions and preserve functional parity. Minor changes in content or views are acceptable.

App uses the whole screen in both orientations and does not letterbox to account for orientation changes.

Minor letterboxing to compensate for small variations in screen geometry is acceptable.

App correctly handles rapid transitions between display orientations without rendering problems.

App should not leave any services running when the app is in the background, unless related to a core capability of the app.

For example, the app should not leave services running to maintain a network connection for notifications, to maintain a Bluetooth connection, or to keep the GPS powered-on.

App correctly preserves and restores user or app state.

App preserves user or app state when leaving the foreground and prevents accidental data loss due to back-navigation and other state changes. When returning to the foreground, the app must restore the preserved state and any significant stateful transaction that was pending, such as changes to editable fields, game progress, menus, videos, and other sections of the app or game.

1. When the app is resumed from the Recents app switcher, the app returns the user to the exact state in which it was last used.
2. When the app is resumed after the device wakes from sleep (locked) state, the app returns the user to the exact state in which it was last used.
3. When the app is relaunched from Home or All Apps, the app restores the app state as closely as possible to the previous state.
4. On Back keypresses, the app gives the user the option of saving any app or user state that would otherwise be lost on back-navigation.

Related resources:

• Making Android Apps that Play Nice — Developer blog post discussing the audio lifecycle and expected audio behaviors for Android apps.
• Tasks and Back Stack — Developer guide describing how to implement back-navigation.
• Recreating an Activity — Android Training class the shows how to preserve and restore app state.

App displays graphics, text, images, and other UI elements without noticeable distortion, blurring, or pixelation.

1. App provides high-quality graphics for all targeted screen sizes and form factors, including for larger-screen devices such as tablets.
2. No aliasing at the edges of menus, buttons, and other UI elements is visible.

App displays text and text blocks in an acceptable manner.

1. Composition is acceptable in all supported form factors, including for larger-screen devices such as tablets.
2. No cut-off letters or words are visible.
3. No improper word wraps within buttons or icons are visible.
4. Sufficient spacing between text and surrounding elements.

Related resources:

• Using StrictMode — Developer blog post discussing StrictMode and how to use it for performance monitoring in your app.
• Designing for Responsiveness — Developer guide describing best practices for keeping your app responsive.
• Multithreading for Performance — Developer blog post discussing ways to improve performance through multi-threading.

App maturity level is set appropriately, based on the Content Rating Guidelines.

Especially, note that apps that request permission to use the device location cannot be given the maturity level "Everyone".

App feature graphic follows the guidelines outlined in this blog post. Make sure that:

1. The app listing includes a high-quality feature graphic.
2. The feature graphic does not contain device images, screenshots, or small text that will be illegible when scaled down and displayed on the smallest screen size that your app is targeting.
3. The feature graphic does not resemble an advertisement.

Related resources:

• Launch Checklist — Recommendations on how to prepare your app for publishing, test it, and launch successfully on Google Play.
• Google Play Developer Program Policies — Guidelines for what is acceptable conent in Google Play. Please read and understand the and understand the policies before publishing.

• Rating your application content for Google Play — Help Center document describing content ratings levels and how to choose the appropriate one for your app.
• Graphic Assets for your Application — Details about the graphic assets you need to upload before publishing.
• Google Play Featured Image Guidelines — Blog post discussing how to create an attractive, effective Featured Image for your app.
• Supporting your users — Help Center document describing options for supporting users.

Navigate to all parts of the app — all screens, dialogs, settings, and all user flows.

1. If the application allows for editing or content creation, game play, or media playback, make sure to enter those flows to create or modify content.
2. While exercising the app, introduce transient changes in network connectivity, battery function, GPS or location availability, system load, and so on.

Repeat Core Suite with app installed to device SD card (if supported by app).

To move the app to SD card, you can use Settings > App Info > Move to SD Card.

Repeat Core Suite with hardware acceleration enabled.

To force-enable hardware acceleration (where supported by device), add hardware-accelerated="true" to the <application> in the app manifest and recompile.

Repeat Core Suite with StrictMode profiling enabled as described below.

Pay close attention to garbage collection and its impact on the user experience.