Welcome to Knowledge Base!

The app correctly preserves and restores user or app state.

The 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 should restore the preserved state and any significant stateful transaction that was pending. Examples include: 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 the 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, it should do one of the following, depending on how much time has passed since it was last used:
   
   
   
   • If the app was last used a short time ago (minutes), restore the app state as close as possible to its previous state.
     
   • If more time has passed since the app was last used, try to restore the app as close as possible to its previous state;
     or start it from its home screen or some other default state.
     
   
   
   
   

Notifications follow Material Design guidelines. In particular:

1. Notifications are not used for cross-promotion, or advertising another product, as this is strictly prohibited by the Play Store.
   
2. Appropriately define Notification Channels according to best practices, rather than serving all notifications from one channel.
   
3. Selecting the correct notification priority.
   
4. Multiple notifications are stacked into a single notification group, where possible.
   
5. Set timeouts for notifications where appropriate.
   
6. Notifications are persistent only if related to ongoing events, such as music playback (more under the Functionality section) or a phone call.

For messaging / social apps and conversations:

1. Use the MessagingStyle notifications for conversations.
   
2. Support the direct reply action.
   
3. Support conversation shortcuts, and implement best practices for getting the best direct share ranking.
   
4. Support bubbles.

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

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

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

1. The app should use vector drawables where possible.
   
2. The app provides high-quality graphics for all targeted screen sizes and form factors.
   
3. No aliasing at the edges of menus, buttons, and other UI elements is visible.

The app displays text and text blocks in an acceptable manner for each of the app’s supported languages.

1. Composition is acceptable in all supported form factors.
   
2. No cut-off letters or words are visible.
   
3. No improper word wraps within buttons or icons are visible.
   
4. There is sufficient spacing between text and surrounding elements.

When the user initiates audio playback, the app should do one of the following within one second:

1. Start playing the audio.
   
2. Provide a visual indicator that the audio data is being prepared.

• Maintaining a network connection for notifications
  
• Maintaining a Bluetooth connection
  
• Keeping the GPS powered-on

Learn how to choose the right solution for your work.

In terms of battery usage, developers can use the Android Studio energy profiler or the Battery Historian tool, combined with planned background work, to diagnose unexpected battery use.

The app should only request permission to access sensitive data (such as
SMS, Call Log, or
Location)
or services that cost money (such as Dialer or SMS) if it’s directly related to the core
use cases of the apps. Implications related to these permissions should be prominently disclosed to the user.

Depending on how you are using the permissions, there might be an
alternative way
to fulfill your app's use case without relying on access to sensitive information. For example, instead of
requesting permissions related to a user’s contacts, it may be more appropriate to request access
by using an implicit intent.

The app should design its UX to clearly convey why certain permissions are needed. If that’s
not possible, it should follow the recommended flow to
explain why a feature in your app needs a permission.

The app should gracefully degrade when
users deny or revoke a permission. The app should not prevent the user from accessing the app altogether.

This includes activities, services, broadcast receivers, and especially content providers.

Always set the android:exported attribute explicitly to minimize confusion on the default value.

All intents and broadcasts follow best practices:

1. Use explicit intents if the destination application is well defined.
   
2. Use Intents to defer permissions to a different app that already has the permission.
   
3. Share data securely across apps.
   
4. Intents that contain a payload are verified before use.
   
5. If you need to pass an Intent to another app, so that the receiving app can invoke and expect a callback in the calling app, do not include a nested intent in the extras. Use a PendingIntent.
   
6. When setting up your PendingIntents, explicitly set the immutable flag, where applicable.

On Android 6.0 and above, use HTML message channels instead.

Starting August 2021, the use of Android App Bundles will become mandatory for all new apps in the Google Play store.

The app’s feature graphic follows the guidelines outlined in this
support article. 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.

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 test those flows.


2. While testing the app, introduce interruptions from other apps, such as receiving a notification or a phone call; and apply transient changes to device attributes, such as network connectivity, battery function, GPS availability, and system load.


3. Enter and test all in-app purchase flows

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

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

Pay close attention to alarms, timers, notifications, syncs, and so on. See Testing with Doze and App Standby for requirements and guidelines.