To provide a solid foundation for a quality app, follow the core app quality guidelines.
The guidelines define the minimum quality that all apps should meet.
Adaptive app quality
Android apps run on a wide variety of devices—everything from compact phones to tablets, foldables, desktops, connected displays, car infotainment systems, TV, and XR. Windowing modes like split‑screen and desktop windowing enable apps to run in resizable portions of a screen.
Follow the adaptive app quality guidelines—in conjunction with the core app quality guidelines—to:
Create apps optimized for all form factors and display sizes
Get your apps ranked higher in Google Play listings and search
Acquire more users and increase user retention
The following core guidelines help you build a basic, high‑quality app.
User experience
Standard Android visual design and interaction patterns provide a consistent and intuitive user experience.
Use Material design components to create your app's user interface in place of Android platform components where possible. Material Design provides a modern Android look and feel along with UI consistency across Android versions.
App fills the app window in both orientations and is not letterboxed because of configuration changes, including device folding and unfolding. Minor letterboxing to compensate for small variations in screen geometry is acceptable.
App handles rapid transitions between display orientations and device folding and unfolding with no display rendering problems and without losing state.
App displays graphics, text, images, and other UI elements without noticeable distortion, blurring, or pixelation. App uses vector drawables where possible App uses high-quality graphics for all targeted screen sizes and form factors No aliasing at the edges of menus, buttons, and other UI elements
App ensures readability of text and text blocks by limiting line length to 45-75 characters (including spaces) for each of the app's supported languages.
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 restores the preserved state and any pending stateful transactions. Examples include changes to editable fields, game progress, menus, videos, and other sections of the app. When the app is resumed from the Recents app switcher, the app returns the user to the exact state in which the app was last used. 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 the app was last used. 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 the app was last used: If the app was last used a short time ago (minutes), restore the app state as closely as possible to its previous state. If more time has passed since the app was last used, try to restore the app as closely as possible to its previous state or start the app from its home screen or some other default state.
Notifications provide relevant information related to your app. Don't use notifications for cross-promotion or advertising of another product, as this is strictly prohibited by the Play Store. Notification channels are defined according to best practices, rather than serving all notifications from one channel. Select the correct notification priority. Stack multiple notifications into a single notification group when possible. Set timeouts for notifications where appropriate. Notifications are persistent only if related to ongoing events, such as music playback or a phone call. For more information, see the Functionality section.
App text and foreground content maintain the following contrast ratios with the app background: 3:1 for large text and graphics 4.5:1 for small text (less than 18 pt or less than 14 pt if text is bold) Learn more about color and contrast.
When the user initiates audio playback, the app should do one of the following within one second: Start playing the audio Provide a visual indicator that the audio data is being prepared
App should support background playback. App must use a foreground service to prevent the system from killing the app process once the app is no longer visible. The app must also display a persistent, non‑dismissible notification in the status bar or on the lock screen to inform the user that the app is running. Users should be able to control playback using the notification or lock screen controls or the controls on a connected accessory.
If the app is in the background and audio is paused, audio resumes when the app returns to the foreground, or the app must indicate to the user that playback is in a paused state.
App supports background playback of video when the app is not the topmost app, including when the app window is: Minimized Behind other windows or system UI (for example, notification shade or home/lock screen) Off the visible desktop screen
App avoids running unnecessarily long services in the background to ensure the smooth running of the user's device. Note: The system applies various restrictions on background services. The following are poor uses of background services: Maintaining a network connection for notifications Maintaining a Bluetooth connection Keeping the GPS powered on For more information, see Background tasks overview.
Performance and stability
Your app should provide optimal performance, stability, compatibility, and responsiveness.
Any Google or third-party SDKs used are up to date. Any improvements to these SDKs related to stability, compatibility, or security should be available to users in a timely manner. For Google SDKs, use SDKs powered by Google Play services when available. These SDKs are backward compatible, receive automatic updates, reduce your app package size, and make efficient use of on-device resources.
App requests only the absolute minimum permissions needed to support the current use case. For some permissions, such as location, app uses a coarse specification in place of fine if possible. See Minimize your permission requests.
App requests permission to access sensitive data (such as SMS or Call Log permission groups or location) or services that cost money (such as Dialer or SMS) only when directly related to the app's core use cases. Implications related to these permissions must be prominently disclosed to the user. Depending on how your app uses the permissions, an alternative way of fulfilling your app's use case might be possible without relying on access to sensitive information. For example, instead of requesting permissions related to a user's contacts, use an implicit intent to request access.
App sets the android:exported attribute explicitly for all activities, services, broadcast receivers, and especially content providers. Only application components that share data with other apps, or components that should be invoked by other apps, are exported.
App strictly adheres to the terms of the Google Play Developer Content Policy, does not offer inappropriate content, and does not use the intellectual property or brand of others.
App feature graphic follows the guidelines outlined in this support article. Make sure that: App listing includes a high-quality feature graphic The feature graphic does not contain device images, screenshots, or small text that's illegible when scaled down and displayed on the smallest screen size that your app is targeting The feature graphic does not resemble an advertisement
Common user-reported bugs in the Reviews tab of the Google Play page are addressed if the bugs are reproducible and occur on many different devices. If a bug occurs on only a few devices, you should still address it if those devices are particularly popular or new.
Set up a test environment as follows:
Emulator testing: Android Emulator is a great way to test your app under different Android versions and screen resolutions. Set up emulated devices (AVDs) to represent the most common form factors and hardware/software combinations for your target user base. Test a variety of form factors using the following emulators (at a minimum):
Foldables: 7.6" fold-in with outer display (this is listed under phones in the AVD Manager)
Tablet: Pixel C 9.94" (2,560px x 1,800px)
Mobile app notification testing: Pair a mobile device / emulator with Wear OS emulator: Wear OS Round 1.84"
Hardware devices: Your test environment should include a small number of actual hardware devices that represent the key form factors and hardware/software combinations that are available to consumers. You don't need to test on every device that's on the market. Focus on a small number of representative devices, even using one or two devices per form factor.
Device test labs:; You can also use third party services, such asFirebase Test Lab, to test your app on a wide variety of devices.
Test with the latest Android version: In addition to testing representative Android versions for your target user base, you should always test against the latest version of Android to ensure thelatest behavior changes don't negatively impact your app's user experience.
For performance testing, enable StrictMode in your app. Use StrictMode to catch operations that could affect performance, network accesses, and file reads and writes. Look for potentially problematic operations both on the main thread and on other threads.
Enable visual notification of policy violations for the ThreadPolicy usingpenaltyFlashScreen().
The core app quality tests help you assess the fundamental quality of your app. You can combine the tests or integrate groups of tests together in your test plan.
User experience
Test for a consistent and intuitive user experience.
Navigate to all parts of the app—all screens, dialogs, settings, and all user flows. Do the following: If the application allows for editing or content creation, game play, or media playback, make sure to test those flows. 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. Enter and test all in-app purchase flows
Set up a screen lock on the device. Press the power button to put the device to sleep (which locks the device). Then, press the power button again to wake the screen and unlock the device.
Perform core functionality tests with the app installed on a device's SD card (if the app supports this installation method). To move the app to an SD card, see the app Settings.
From each app screen, rotate the device between landscape and portrait orientations and folded and unfolded states at least three times. Verify the app does the following: Provides function parity in all display orientations and fold states Fills the app window in all display orientations and fold states and is not letterboxed Maintains state and has no rendering problems during rapid transitions between orientations and device folding and unfolding
Use all features of your app. Verify that all visuals, including graphics, text, images, and other UI elements are free of distortion, blurring, or pixelation.
Review all text blocks in the app. Verify that text and text block line length is limited to 45-75 characters (including spaces) for readability. Verify the following: Composition is acceptable in all supported form factors No cut-off letters or words No improper word wraps within buttons or icons Sufficient spacing between text and surrounding elements
Navigate to all parts of the app—all screens, dialogs, settings, and all user flows. From each app screen, press the Back button or use the back swipe gesture. The app should navigate to the previous or home screen.
Trigger and observe in the notifications drawer all types of notifications that the app can display. Expand notifications where applicable (Android 4.1 and higher), and tap on all available actions.
Verify that touch targets maintain a consistent, accessible size and position for all display sizes and configurations. For information on accessibility, see the Accessibility Scanner.
Initiate audio playback. Verify that within one second the app starts playing the audio or provides a visual indicator that the audio data is being prepared for playback.
Initiate audio playback. Initiate audio playback in another app. Your app should respond to the change in audio focus and stop audio playback or reduce playback volume.
Initiate audio playback. Interact with another non-audio app as the foreground app. The app should continue playing audio in the background and should display a notification in the status bar. Verify that you can manage playback using controls displayed in the notification. Lock the device screen. The app should continue playing audio in the background and should display a notification on the lock screen. Verify that you can manage playback using controls displayed in the notification.
Initiate audio playback. Interact with another non-audio app as the foreground app. Verify that your app continues to play audio in the background and has created a notification styled with MediaStyle. See Playing nicely with media controls.
Initiate audio playback. Interact with another non-audio app as the foreground app. Interact with your app to make it the top app. Audio should resume or volume should be restored. Otherwise, the app should indicate to the user that playback is paused.
Start video playback. Minimize the app window, open another app to move the app window to the background. On desktop‑capable devices, move the app window off the visible desktop. Verify that video playback continues without interruption in all cases.
Create an intent and start an activity by calling startActivity() with the intent as an argument. See Use the Android Sharesheet. Your app should display the Android Sharesheet.
Use all major features of your app. Verify that no long-running background services are started. Switch to another app to send your app to the background. Go to Settings and check whether your app has any services running while in the background. On Android 4.0 and higher, go to the Apps screen and find the app in the Running tab.
Performance and stability
Verify performance, stability, and pixel-perfect visuals.
Use all major features of your app. Verify that the app renders at least 60 frames per second. Use the Profile HWUI rendering option to help test your app.
Enable StrictMode in your app. Use all major features. Verify that the app doesn't produce any StrictMode performance warnings; that is no red flashes are visible when testing the app. Red flashes indicate bad behavior regarding storage, network access, or memory management (such as memory leaks). Pay close attention to garbage collection and its impact on the user experience.
Use all major features of your app. Verify that the app does not crash or block the UI thread causing ANR (Android Not Responding) errors. Review the Google Play pre-launch report to identify potential stability issues.
Run your app on the latest public version of the Android platform. Use all major features. Verify that the app doesn't crash and runs without any loss of core functionality.
Review the Android manifest file and build configuration to ensure the application is built against the latest available SDK (targetSdk and compileSdk).
Use all major app features in Doze and App Standby modes. Verify that alarms, timers, notifications, and syncs function properly in the Doze maintenance window and when the app exits App Standby mode. Test Doze and App Standby behavior using ADB commands (see Test with Doze and App Standby for requirements and guidelines). To diagnose unexpected battery drain, use the Android Studio Power Profiler or the Battery Historian tool combined with planned background work.
Privacy and security
Test for privacy and security protections expected by users.
Use any features of your app that request permissions. Verify that the app requests permission to access sensitive data or services only for core app use cases. Verify that the implications of granting permission to sensitive data and services are clearly communicated to the user.
Use all features of your app that require permissions. Verify that the permissions are requested lazily, that is, only when the features are accessed, rather than during app startup.
Use all features of your app that require permissions. Deny or revoke the permissions. Verify that the app provides an alternative use case and continues to function.
Use all app features that require user input. Verify that the app provides hints to autofill input fields for data such as account credentials and other sensitive information.
Sign in to your app. Verify that the app integrates Credential Manager for Android for a sign-in experience that unifies support for passkeys, federated identity, and passwords.
Use all app features that require authentication. Verify that the app protects financial transactions or sensitive information, such as important user documents, with biometric authentication.
Review all application components defined in the Android manifest file for the appropriate export state. The exported property must be set explicitly for all components.
Sign into the Google Play Developer Console to review your developer profile, app description, screenshots, feature graphic, content rating and user feedback.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.