Make sure that your app offers an interactive UI that responds quickly to user input and, if necessary, compensates for a slow launch. Ensure that your app is designed to be easily localized by accommodating the variations between languages: allow for spacing, density, order, emphasis, and wording variations. Also make sure that date, time, and other units are internationalized and displayed according to the phone’s settings.
Fast and responsive user interface
The user's perception of app performance is formed in large part by the app's responsiveness. For example, interaction with the user and a crisp display are two important characteristics of a performant app. Here you can find tips on how to optimize these and other aspects of an app's speed and responsiveness.
Touch feedback on all touchable items
Touch feedback adds a tactile feeling to the user interface. You should ensure your app provides touch feedback on all touchable elements to reduce the perceived app latency as much as possible.
Responsive interaction encourages deeper exploration of an app by creating timely, logical, and delightful screen reactions to user input. Responsive interaction elevates an app from an information-delivery service to an experience that communicates using multiple visual and tactile responses.
Apps that are unresponsive when performing background activity feel slow and reduce user satisfaction. Ensure your app always has a responsive UI regardless of any background activity. Achieve this by performing network operations or any heavy-duty operations in a background thread—keep the UI thread as idle as you can.
Material Design apps use minimal visual changes when loading content by representing each operation with a single activity indicator. Avoid blocking dialogs with loading indicators.
Empty states occur when a view has no content to show. It might be a list that has no items or a search that returns no results. Avoid empty states using starter, educational, or best match content. When these options aren’t applicable display a non-interactive image and a text tagline that tell the user what they’ll see when there is something to display.
Ensure that your app always runs fast and smoothly, even on low-cost devices.
Overdraw can significantly slow down your app—it occurs when the pixels are being drawn more than once per pass. An example of this is when you have an image with a button placed on top of it. While some overdraw is unavoidable, it should be minimized to ensure a smooth frame rate. Perform Debug GPU overdraw on your app to ensure it’s minimized.
Android devices refresh the screen at 60 frames per second (fps), meaning your app has to update the screen within roughly 16 milliseconds. Profile your app using on-device tools to see if and when your app is not meeting this 16 ms average.
Reduce or remove animations on low-cost devices to lessen the burden on the device’s CPU and GPU. For more information, see Improve layout performance.
An efficient view hierarchy can speed up your app without increasing the app's memory footprint. For more information, see Performance and View Hierarchies.
Use a launch screen on slow to start apps
The launch screen is a user’s first experience of your application. Displaying a blank canvas while launching your app increases the perception of its loading time, so consider using a placeholder UI or a branded launch screen to reduce the perceived loading time.
A placeholder UI is the most seamless launch transition, appropriate for both app launches and in-app activity transitions.
Branded launch screens provide momentary brand exposure, freeing the UI to focus on content.
The best way to deal with slow start speeds is not to have them. Launch-Time Performance provides information that may help you speed up your app's launch time.
User interface best practices
Material Design is a visual language that synthesizes the classic principles of good design with the innovation and possibility of technology and science. Material Design provides a single underlying system that allows for a unified experience across platforms and device sizes. Consider using key Material Design components so that users intuitively know how to use your app.
Ready-to-use Material Design components are available in the Material Design Support library. These components are supported in Android 2.1 (API level 7) and above.
Localization
Your users could be from any part of the world and their first language may not be yours. If you don’t present your app in a language that your users can read, it is a missed opportunity. You should therefore localize your app for key regional languages.
Starting from Android 7.0 (API level 24), the Android framework makes available a subset of the ICU4J APIs, which can help you localize your app into multiple languages. For more information, see ICU4J Android Framework APIs.
Additional resources
To learn more about this topic, view the following additional resources:
Make sure that your app offers an interactive UI that responds quickly to user input and, if necessary, compensates for a slow launch. Ensure that your app is designed to be easily localized by accommodating the variations between languages: allow for spacing, density, order, emphasis, and wording variations. Also make sure that date, time, and other units are internationalized and displayed according to the phone’s settings.
Fast and responsive user interface
The user's perception of app performance is formed in large part by the app's responsiveness. For example, interaction with the user and a crisp display are two important characteristics of a performant app. Here you can find tips on how to optimize these and other aspects of an app's speed and responsiveness.
Touch feedback on all touchable items
Touch feedback adds a tactile feeling to the user interface. You should ensure your app provides touch feedback on all touchable elements to reduce the perceived app latency as much as possible.
Responsive interaction encourages deeper exploration of an app by creating timely, logical, and delightful screen reactions to user input. Responsive interaction elevates an app from an information-delivery service to an experience that communicates using multiple visual and tactile responses.
Apps that are unresponsive when performing background activity feel slow and reduce user satisfaction. Ensure your app always has a responsive UI regardless of any background activity. Achieve this by performing network operations or any heavy-duty operations in a background thread—keep the UI thread as idle as you can.
Material Design apps use minimal visual changes when loading content by representing each operation with a single activity indicator. Avoid blocking dialogs with loading indicators.
Empty states occur when a view has no content to show. It might be a list that has no items or a search that returns no results. Avoid empty states using starter, educational, or best match content. When these options aren’t applicable display a non-interactive image and a text tagline that tell the user what they’ll see when there is something to display.
Ensure that your app always runs fast and smoothly, even on low-cost devices.
Overdraw can significantly slow down your app—it occurs when the pixels are being drawn more than once per pass. An example of this is when you have an image with a button placed on top of it. While some overdraw is unavoidable, it should be minimized to ensure a smooth frame rate. Perform Debug GPU overdraw on your app to ensure it’s minimized.
Android devices refresh the screen at 60 frames per second (fps), meaning your app has to update the screen within roughly 16 milliseconds. Profile your app using on-device tools to see if and when your app is not meeting this 16 ms average.
Reduce or remove animations on low-cost devices to lessen the burden on the device’s CPU and GPU. For more information, see Improve layout performance.
An efficient view hierarchy can speed up your app without increasing the app's memory footprint. For more information, see Performance and View Hierarchies.
Use a launch screen on slow to start apps
The launch screen is a user’s first experience of your application. Displaying a blank canvas while launching your app increases the perception of its loading time, so consider using a placeholder UI or a branded launch screen to reduce the perceived loading time.
A placeholder UI is the most seamless launch transition, appropriate for both app launches and in-app activity transitions.
Branded launch screens provide momentary brand exposure, freeing the UI to focus on content.
The best way to deal with slow start speeds is not to have them. Launch-Time Performance provides information that may help you speed up your app's launch time.
User interface best practices
Material Design is a visual language that synthesizes the classic principles of good design with the innovation and possibility of technology and science. Material Design provides a single underlying system that allows for a unified experience across platforms and device sizes. Consider using key Material Design components so that users intuitively know how to use your app.
Ready-to-use Material Design components are available in the Material Design Support library. These components are supported in Android 2.1 (API level 7) and above.
Localization
Your users could be from any part of the world and their first language may not be yours. If you don’t present your app in a language that your users can read, it is a missed opportunity. You should therefore localize your app for key regional languages.
Starting from Android 7.0 (API level 24), the Android framework makes available a subset of the ICU4J APIs, which can help you localize your app into multiple languages. For more information, see ICU4J Android Framework APIs.
Additional resources
To learn more about this topic, view the following additional resources:
Android apps for cars should avoid driver distraction above all else. You can minimize distractions by following best practices, such as using voice commands and a very simple visual design.
Great car experiences are predictive and predictable. Your app should show timely information to the driver only when it's relevant, and use simple, predictable patterns for common tasks. For more information, refer to the following design guidelines:
You must test your app for the criteria listed on this page before submitting your app to Google Play for review. As applicable, test each of the three ways a driver can access your app:
In addition to the car-specific criteria listed below, apps should meet all relevant core app quality criteria for the Android platform, as detailed in core app quality. Test your app against those criteria to ensure that it meets Android standards for navigation and design. Then test your app against all car-specific criteria, remembering that, when running on a device connected to Android Auto or an Android Automotive OS device, your app must meet the requirements listed on this page.
Car app guidelines
App Categories
Visual design and user interaction
These criteria ensure that your app follows critical design and interaction patterns to offer a consistent, intuitive, and enjoyable user experience in cars. Many elements, such as the navigation drawer, card backgrounds, fonts and icon colors, are set and rendered by the system. Your app-specific design elements must meet the following criteria when running on a car's head unit screen.
Criteria
ID
Description
Screen Animation
SA-1
The app does not display animated elements on the screen such as animated graphics or video.
Visual or Text Ads
AD-1
The app does not display text-based advertising other than the advertiser's name or the product name.
Image Usage
IU-1
App elements do not display any images on the screen. Exceptions include:
Apps may display a single static image for content context in the background of the consumption screen, such as album art or the advertiser's corporate logo.
Apps may display icons in the content navigation drawer.
Apps may display images and photographs to aid in driving decision-making.
Navigation apps may display an image for lane guidance or junction guidance.
Permitted Categories
PC-1
The app does not include features outside the app types intended for cars. (Learn More)
Visual Information on Phone
VI-1
Android Auto only: If the user must go to the phone screen (for example, to act on a permission request), then the app must display a message instructing the user to only look at their phone screen when it’s safe to do so. (Learn How for media, Learn How for navigation, point of interest, and internet of things apps)
App Doesn't Crash
AC-1
Users must be able to complete tasks in the app using five screens or fewer. (Learn How)
Scrolling Text
ST-1
The app does not display automatically scrolling text.
Voice Commands
VC-1
The app must support Google Assistant voice commands. (Learn How for media, Learn How for navigation)
Delayed Response
DR-1
App-specific buttons respond to user actions with no more than a two-second delay.
DR-2
The app launches in no more than 10 seconds.
DR-3
The app loads content in no more than 10 seconds.
Contrast
VD-1
The app provides icons and colors that meet Android Auto’s contrast requirements. (Learn How)
VD-2
The app provides white icon sets that the system colorizes to provide automatic contrast compensation.
VD-3
The app provides colors that the system can optimize for easy in-vehicle readability.
Display Orientation
DO-1
UIs drawn by the app support both landscape and portrait screens.
Functionality
These criteria ensure that your app is configured correctly and provides the expected functional behavior when running on the car's head unit screen.
Criteria
ID
Description
Expected Performance
EP-1
App functionality works as expected or described in the app's Google Play Store listing.
EP-2
When the app is relaunched from the home screen, the app restores the app state as closely as possible to the previous state.
Grey Buttons
GB-1
Interactive elements that are intentionally greyed-out must be non-functional.
Driver Distraction
DD-1
The navigation audio channel may only be used by navigation apps and for navigation instructions. (Learn How)
DD-2
While driving, the video app must not be launchable and the video app's screen must not be visible. The video app's audio must stop when the user starts driving. (Learn How)
Payments
PA-1
The app must have simple flows if purchases are enabled, using shortcuts such as recent or favorite purchases. (Learn How)
The app must not allow any of the following:
Setup of payment methods
Multiple items to be selected for purchase
The user to commit to recurring payments (for example, subscriptions)
Notification Ads
NA-1
The app does not present advertisements through notifications.
Irrelevant Notifications
IN-1
The app displays notifications only when relevant to the driver's needs.
Examples:
Good: Notifying the user that a new message has arrived.
Bad: Notifying the user about a new album release.
Media Autoplay
MA-1
Media apps do not autoplay on startup or without user initiated action to select the app or app media. (Learn How)
The app uses short-form messaging app design patterns. Traditional long-form messaging apps, such as apps for email, are not permitted.
MF-5
The app implements a peer-to-peer messaging service and not notification services such as those for weather, stocks, and sport scores.
Navigation Functionality
NF-1
The app must provide turn-by-turn navigation directions.
NF-2
The app draws only map content on the surface of the navigation templates. Text-based turn-by-turn directions, lane guidance, and estimated arrival time must be displayed on the relevant components of the Navigation template. Additional information relevant to the drive (e.g., speed limit, road obstructions) can be drawn on the safe area of the map.
NF-3
When the app provides text-based turn-by-turn directions, then it must also trigger navigation notifications. (Learn How)
NF-4
When the navigation app provides text-based turn-by-turn directions, it must send next-turn information to the vehicle’s cluster display. (Learn How)
NF-5
The app must not provide turn-by-turn notifications, voice guidance, or cluster information when another navigation app is providing turn-by-turn instructions. (Learn How)
NF-6
The app must handle navigation requests from other Android Auto apps. (Learn How)
NF-7
The app must provide a “test drive” mode that simulates driving. (Learn How)
NF-8
The app must draw a light-themed or dark-themed map when instructed to do so. (Learn How)
Point of Interest Functionality
PF-1
The app must provide meaningful functionality relevant to driving.
Internet of Things Functionality
IT-1
The IOT app may allow the following while driving:
View the current state of devices. For example: to view if a garage door is open or closed, a light bulb is on or off, a security system is armed or disarmed, or a washer is running or completed.
Simple, one-touch features that control on and off functions. For example: the ability to turn various devices on and off or open and close them, including turning lights on and off, turning a thermostat on and off, or opening and closing a garage door or curtain. This also includes turning a pre-programmed scene or routine on and off.
Notify users about an event in the home or another location. For example: receiving notifications for a routine or scene, a security alert, or a change in a door's open or closed status.
The IOT app must not allow the following while driving:
Tasks related to app setup of any kind. For example: the ability to select devices, systems, or locations for use with the IOT app.
Tasks related to creation, modification, or reordering. For example: the ability to create, modify, or reorder a scene or routine, such as a sequence of events when departing or leaving a location, including opening and closing a garage door, or turning lights on and off.
Tasks related to fine-grained device control. For example: the ability to control certain functions, including adjusting thermostat temperatures or the level of lighting luminescence.
Settings Flow
SF-1
App must proceed to the home page after (attempted) sign-in.
Automotive Functionality
AF-1
App does not contain any distraction optimized activities.
CPU Architectures
CP-1
App supports both x86_64 and ARM CPUs.
App Navigability
AN-1
App allows users to navigate through the app without encountering any dead ends.
Frequently asked questions
What happens after I submit my app?
Apps for cars are subject to an additional manual review beyond normal Play Store review processes. Your app will be tested to ensure Driver Distraction Regulation compliance against the criteria described above.
After submitting my app, how will I find out if my app does not meet all the requirements for Android Auto or Android Automotive OS?
If your app does not meet the usability requirements described on this page, the Play Store team will contact you through the email address specified in the Google Play Console account associated with the app.
My app targets more than just Android Auto or Android Automotive OS. If my app does not meet the car requirements, will my new or updated app still appear on Google Play for other devices?
No. When Google begins the approval process, your app will undergo a driver safety review, and any subsequent updates will not be available for distribution until the app is approved. If you need to make updates to your app for other devices, we recommend creating a separate release from the updates to your car app.
Important: Due to this restriction, you should not use your production APK for Auto support prototyping.
The IOT app may allow the following while driving:
View the current state of devices. For example: to view if a garage door is open or closed, a light bulb is on or off, a security system is armed or disarmed, or a washer is running or completed.
Simple, one-touch features that control on and off functions. For example: the ability to turn various devices on and off or open and close them, including turning lights on and off, turning a thermostat on and off, or opening and closing a garage door or curtain. This also includes turning a pre-programmed scene or routine on and off.
Notify users about an event in the home or another location. For example: receiving notifications for a routine or scene, a security alert, or a change in a door's open or closed status.
The IOT app must not allow the following while driving:
Tasks related to app setup of any kind. For example: the ability to select devices, systems, or locations for use with the IOT app.
Tasks related to creation, modification, or reordering. For example: the ability to create, modify, or reorder a scene or routine, such as a sequence of events when departing or leaving a location, including opening and closing a garage door, or turning lights on and off.
Tasks related to fine-grained device control. For example: the ability to control certain functions, including adjusting thermostat temperatures or the level of lighting luminescence.
May 2022
App Categories: "Parking & Charging" has been replaced with "Point of Interest"
Categories affected: Media, Messaging, Navigation, Point of Interest
Previous text:
App elements do not display any images on the screen. Exceptions include:
Apps may display a single static image for content context in the background of the consumption screen, such as album art or the advertiser's corporate logo.
Apps may display icons in the content navigation drawer.
Navigation, parking, and charging apps may display images and photographs to aid in driving decision-making.
Navigation apps may display an image for lane guidance or junction guidance.
New text:
App elements do not display any images on the screen. Exceptions include:
Apps may display a single static image for content context in the background of the consumption screen, such as album art or the advertiser's corporate logo.
Apps may display icons in the content navigation drawer.
Apps may display images and photographs to aid in driving decision-making.
Navigation apps may display an image for lane guidance or junction guidance.
Categories affected: Media, Navigation, Point of Interest
Previous text:
Android Auto only: If the user must go to the phone screen (for example, to act on a permission request), then the app must display a message instructing the user to only look at their phone screen when it’s safe to do so. (Learn How for media, Learn How for navigation, parking, and charging)
New text:
Android Auto only: If the user must go to the phone screen (for example, to act on a permission request), then the app must display a message instructing the user to only look at their phone screen when it’s safe to do so. (Learn How for media, Learn How for navigation and point of interest apps)
The app draws only map content on the surface of the navigation templates. Text-based turn-by-turn directions, lane guidance, and estimated arrival time must be displayed on the relevant components of the Navigation template. Additional information relevant to the drive (e.g., speed limit, road obstructions) can be drawn on the right side of the map.
New text:
The app draws only map content on the surface of the navigation templates. Text-based turn-by-turn directions, lane guidance, and estimated arrival time must be displayed on the relevant components of the Navigation template. Additional information relevant to the drive (e.g., speed limit, road obstructions) can be drawn on the safe area of the map.
The app must provide meaningful functionality in its category relevant to driving.
New text:
The app must provide meaningful functionality relevant to driving.
Removed criteria:
If a parking app is displaying a list of locations next to a map (e.g., the Place List Map template), then the locations in the list can only be parking spots.
Similarly, for a charging app, the locations must be charging stations.
While driving, the video app must not be launchable and the video app's screen must not be visible. The video app's audio must stop when the user starts driving.
While the app is interacting with the car screen and the car is not parked, the app does not activate the phone screen to present any form of visual information such as notifications, toasts, video, images, advertising, or similar (Learn How for navigation, parking, and charging). Similarly, while the app is running Android Auto UI on the phone screen, the app does not present any visual information on the phone screen that is unrelated to Android Auto.
If the user must go to the phone screen (e.g., to act on a permission request), then the app must display a message instructing the user to only look at their phone screen when it’s safe to do so.
New text:
Android Auto only: If the user must go to the phone screen (for example, to act on a permission request), then the app must display a message instructing the user to only look at their phone screen when it’s safe to do so. (Learn How for media, Learn How for navigation, parking, and charging)
The markets with the fastest growing internet and smartphone penetration can have some challenging issues, such as:
Slow, intermittent, or expensive connectivity.
Devices with screens, memory, and processors that may be less capable than devices in other markets.
Limited opportunities to recharge batteries during the day.
To help your app succeed and deliver the best possible experience in developing markets, we've put together some advice on how to address these issues.
The practices described in this section are relevant to all apps, not only apps published in developing markets. Apps that use memory, power, and network bandwidth efficiently will perform better in any market and produce a better experience for all users.
Build apps to delight billions
We've divided our advice into five broad categories: connectivity, device capability, data cost, battery consumption, and content. The categories are presented in no particular order, and you should take them as guidelines, not absolutes. You should always research the particulars of any market or country you are targeting.
Learn how to provide a better experience for users connected to slower networks. Focus on optimizing images, optimizing networking, and fine-tuning data transfer.
Learn how to support devices with capabilities that may be different from those you usually develop for. Take into account different screen sizes, backward compatibility, and efficient memory use.
Learn how your app can help preserve battery life. Follow the best practices for power management and benchmarking to ensure sure that your app isn't draining the battery unnecessarily.
Android devices come in a variety of form factors—phones, tablets, Chromebooks, foldable devices—which have a wide range of screen sizes. Android supports multiple display modes, including multi-window, multi-display, multi-instance, and picture-in-picture. Foldable devices can be in various folded states, or postures, such as tabletop posture or book posture.
To ensure your app provides a great user experience regardless of device form factor, screen size, display mode, or posture, complete the large screen compatibility checklists and tests below.
The checklists and tests define a comprehensive set of quality requirements for most types of Android apps. Your app probably won't need to meet all of the requirements. Implement the ones that make sense for your app's use cases.
As you enhance your app with large screen capabilities, help users better understand your app's large screen experience by updating your app listing on Google Play. Upload screenshots that show off the app on large screens. Call attention to large screen features in your app description. For more information and best practices, see Google Play Help.
For examples of optimized and differentiated large screen layouts, see the large screen gallery.
Large screen compatibility checklists
The compatibility checklists define criteria to help you assess the level of support your app provides for large screens.
Levels of support include the following:
Tier 3 (Basic) — Large screen ready: Users can complete critical flows but with a less than optimal user experience. Your app runs full screen (or full window in multi-window mode), but app layout might not be ideal. The app is not letterboxed; it does not run in compatibility mode. The app provides basic support for external input devices, including keyboard, mouse, and trackpad.
Tier 2 (Better) — Large screen optimized: Your app implements layout optimizations for all screen sizes and device configurations along with enhanced support for external input devices.
Tier 1 (Best) — Large screen differentiated: Your app provides a user experience designed for tablets, foldables, and Chrome OS. Where applicable, the app supports multitasking, foldable postures, drag and drop, and stylus input.
Complete the Tier 2 requirements to enable your app to provide an excellent user experience on all Android devices. To make your app outstanding on large screens, complete Tier 1.
Tier 3 — Large screen ready
Large screen ready apps must first fulfill the core app quality requirements—in particular, the UI and Graphics requirements.
Apps must also meet the following large screen requirements:
App fills the available display area—the entire screen or, in multi-window mode, the app window. App is not letterboxed; it does not run in compatibility mode.
App handles configuration changes and retains or restores its state as the device goes through configuration changes such as device rotation, folding and unfolding, and window resizing; for example:
Scroll position of scrollable fields is maintained
Text typed into text fields is retained and the keyboard state is restored
Media playback resumes where it left off when the configuration change was initiated
App handles combinations of configuration changes, such as window resizing followed by device rotation, or rotation followed by device folding or unfolding.
App fully supports multi-resume mode. App updates its UI (continues playing media, incorporates new messages, updates download progress, etc.) when the app is not the top focused app. In addition, the app handles the loss of exclusive resources such as cameras and microphones in multi-window scenarios. See Multi-window lifecycle in Multi-window support.
App provides camera preview in landscape and portrait orientations, folded and unfolded device states, and multi-window mode. Preview is properly proportioned and in the correct orientation.
App supports media projection in landscape and portrait orientations, folded and unfolded device states, and multi-window mode. Projection is properly proportioned and in the correct orientation.
App supports text input using external keyboard and switches between physical and virtual keyboards when an external keyboard is connected or disconnected without relaunching the app.
App provides basic support for stylus-equipped Chromebooks, tablets, and foldables. The stylus can be used to select and manipulate UI elements, including scrolling through lists, pickers, and other scrollable content. See Stylus in Input compatibility on large screens.
Note: Basic stylus input is the same as touch input, which is fully supported by Android. All apps support basic stylus input with no special development required.
Tier 2 — Large screen optimized
Optimized apps fully support all screen types and device states, including state transitions.
Modals, options menus, and other secondary elements are properly formatted on all screen types and device states, for example:
Bottom sheets are not full width on large screens. (Apply a maximum width to avoid stretching.) See Behavior in Sheets: bottom.
Buttons are not full width on large screens. See Behavior in Buttons.
Text fields and boxes do not stretch to full width on large screens. See Behavior in Text fields.
Small edit menus or modals do not cover the entire screen and maintain context for the user as much as possible. See Menus.
Options menus appear next to the item the user selected. See the "Contextual menu" topic in Menus.
Navigation rails replace navigation bars for better ergonomics. Rails can also complement other navigation components, such as navigation bars. See Navigation rail.
Navigation drawers are updated to the latest material component. See Navigation drawer.
Dialog boxes are updated to the latest material component. See Dialogs.
Images are displayed at a proper resolution and are not stretched or cropped.
A focused state is created for custom drawables that are interactive. A custom drawable is any visual UI element not provided by the Android framework. If users can interact with a custom drawable, the drawable must be focusable when the device is not in Touch Mode, and a visual indication of the focused state must be apparent.
App supports mouse and trackpad for zoom and right-click (secondary mouse button or secondary tap) capabilities. Options menus are accessible by typical mouse and trackpad right-click behavior.
Actionable UI elements have hover states (where appropriate) to indicate to mouse and trackpad users that the elements are interactive.
Tier 1 — Large screen differentiated
Large screen differentiated apps use the large screen form factor to its full potential. Differentiated apps offer a premium user experience that's productive and enjoyable.
App supports various multitasking scenarios; for example:
Picture-in-picture mode: App is able to enter and exit picture-in-picture mode in portrait and landscape orientations, with the device folded and unfolded, and in multi-window mode. See Picture-in-picture (PiP) support.
Multi-window mode: App can open another application in a separate window from a deep link; for example, a contact management app opens a link to an email message which is displayed in an email app in a new window. See FLAG_ACTIVITY_LAUNCH_ADJACENT.
Attachments: Messaging apps can open attachments (such as videos) in a separate window.
App is able to launch multiple instances of itself in separate windows. Use cases include document editing, web browsing, file management apps, and product comparisons in shopping apps. See Multi-instance in Multi-window support.
App provides a comprehensive set of keyboard shortcuts while supporting conventional shortcuts such as Ctrl-C for copy and Ctrl-Z for undo. App maintains keyboard shortcut parity with equivalent web or desktop versions of the app whenever possible.
Keyboard and mouse or trackpad combinations, such as Ctrl+click or Ctrl+tap and Shift+click or Shift+tap, provide enhanced capabilities, including the selection of ranges of adjacent items or multiple separated items.
Where applicable, UI elements display additional content such as fly‑out menus or tooltips on mouse or trackpad hover. App maintains hover state parity with equivalent web or desktop versions of the app whenever possible.
UI panels in multi-panel layouts are reconfigurable using a mouse or trackpad. Reconfigurable panels enable users to adjust the app layout for increased productivity, for example, by changing the size of the detail panel of a list-detail layout or by rearranging panels on screen. Note: This does not apply to navigation bars, rails, or drawers.
App provides stylus support for dragging and dropping content between views within the app and, in multi-window mode, to and from other apps. See Drag and drop.
The following tests help you discover quality issues in your app. You can combine the tests or integrate groups of tests together in your own test plans.
For layout and UX purposes, test on at least the following device types:
Foldable (841x701 dp)
8-inch tablet (1024x640 dp)
10.5-inch tablet (1280x800 dp)
13-inch Chromebook (1600x900 dp)
Use the following Android emulators to test large screen device compatibility:
Verify that the app is not letterboxed and is not running in compatibility mode in portrait and landscape orientations, in multi-window mode, or when a large screen foldable device is unfolded in portrait and landscape orientations.
Note: Test on a large screen device (sw >= 600dp) running Android 12 (API level 31) or higher to ensure the device supports the following:
All device orientations regardless of orientation restrictions set with the android:screenOrientation app manifest element
From each app screen that has scrollable content, continuous playback content, or text entry fields, do the following:
Scrollable content: Scroll the content
Playback content: Begin playback
Text entry fields: Enter text in multiple fields
Rotate the device between landscape and portrait orientations, fold and unfold the device (if applicable), span and unspan your app across two screens (if you have a dual-screen device) and resize the app window in multi-window mode. Verify the following:
Scrollable content: The scroll position remains the same
Playback content: Playback resumes where it left off when the configuration change was initiated
Text entry fields: Previously entered text is retained in input fields
From each app screen, perform combinations of rotating the device between landscape and portrait orientations, folding and unfolding the device (if applicable), and resizing the app window in multi-window mode.
Open the app in multi-window mode. Check whether the app is fully functional in all window sizes, device orientations, and foldable device states. Resize the app window in each orientation. For foldable devices, fold and unfold the device in each orientation.
Unity apps
Open an app other than your Unity app. Go to the Recents screen. Select the app icon and put the app in split-screen mode. Open your Unity app, which should launch in split-screen mode beside or below the first app. Go to the Home screen to hide the pair of apps. Go to the Recents screen. Select the split-screen app pair that includes your Unity app. Verify that the Unity app resumes its activity and the app's layout in the split-screen window is correct with all UI elements accessible.
Open the app and initiate a process, such as playing a video, that continuously updates the app. Open another app and make the new app the top focused app. Verify that the non-focused app continues to update its content (for example, a video continues to play).
In the app, open the camera or use the microphone. Open another app, and make the new app the top focused app. Verify that the non-focused app has relinquished the camera or mic. Make the original app the top focused app. Verify that the app has regained access to the camera or mic.
Open the app full screen and in multi-window mode. Start the camera from within the app. Rotate the device between landscape and portrait orientations. For foldable devices, fold and unfold the device in each orientation. In multi-window mode, resize the app window. Verify that the camera preview is in the proper orientation and proportions in all device states and window sizes.
Open the app full screen and in multi-window mode. Start a media projection. Rotate the device between landscape and portrait orientations. For foldable devices, fold and unfold the device in each orientation. In multi-window mode, resize the app window. Verify that the media projection is in the proper orientation and proportions in all device states and window sizes.
For each app screen that has text entry fields, connect an external keyboard to the device and enter text with the external keyboard and the virtual keyboard. Disconnect the external keyboard and enter text with the virtual keyboard.
Run the app on devices that have a wide variety of screen sizes, including phones, foldable phones, small and large tablets, and Chrome OS devices. Run the app in multi-window mode on the devices.
Verify that the app layout responds and adapts to different screen and window sizes. Check whether the app expands and contracts navigation rails, scales the number of columns in grid layouts, flows text into columns, and so forth. Observe whether UI elements are formatted for both aesthetics and function.
For apps using activity embedding, test whether activities are displayed side by side on large screens, stacked on small screens.
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.
On each app screen that contains an interactive custom drawable, verify that the drawable can be focused using an external keyboard, D‑pad, or other device that enables views to be focused. Verify that a visual indication of the focused state is apparent. For related information, see Touch Mode.
Enter and exit picture-in-picture mode in portrait and landscape orientations, with the device folded and unfolded, and in multi-window mode. In multi-window mode, change the window size while picture-in-picture mode is active.
Launch multiple instances of the app in separate windows in portrait and landscape orientations, with the device folded and unfolded, and in multi-window mode.
View the app in all foldable postures, including tabletop mode, book mode, and dual display (for example, Microsoft Surface Duo). Verify that UI elements transition to the optimal location (for example, media controllers move to the horizontal screen area in tabletop mode).
Activate the camera from within the app. Verify that the camera preview is correct when the device is folded and unfolded and rotated to portrait and landscape orientations. With the device unfolded, verify that the preview is correct on front and back screens.
Drag and drop images and text to drop targets within the app. In multi-window mode, drag and drop images and text between the app and another app (to and from both apps). Verify the functionality in portrait and landscape orientations and when the device is in a folded or unfolded state.
Using an external keyboard, mouse, and trackpad, select items in the app's UI. Select multiple separated items and ranges of adjacent items using keyboard/mouse/trackpad actions such as Ctrl+click, Ctrl+tap, Shift+click, and Shift+tap.
Using a mouse and trackpad, hover the pointer over UI elements that contain cascading or pop-up content. Verify that the additional content is revealed.
Using a stylus, drag and drop content to drop targets within the app. In multi-window mode, drag and drop content between the app and another app (to and from both apps).
Draw with varying amounts of stylus pressure. Check whether the width of the strokes changes as the pressure changes. More pressure should produce thicker strokes.
Tilt the stylus as you draw; shading strokes should be produced. The more the stylus is tilted, the wider and lighter the shading strokes should be.
As you're drawing, let your fingers and palm touch the screen. The finger and palm touches should not produce marks.
Whether you're building for Android handsets, Wear OS by Google, Android TV, or Android for Cars, this section provides the guides and API reference you need.
This set of libraries provides APIs for essential app architecture tasks like lifecycle management and data persistence, so you can write modular apps with less boilerplate code.
You can install and run your app on the Android Emulator faster than with a physical device. It simulates various device configurations and hardware sensors, and it uses a snapshot to quickly resume exactly where you left off.
Android Studio uses Gradle, an advanced build toolkit, to automate the build process, while allowing you to define flexible, custom build configurations.
Android Studio includes a layout editor that allows you to build and preview your app UI by dragging elements into a visual design editor instead of writing layout XML by hand.
Poor app performance can ruin the user experience and destroy your app's reputation. If it ever responds slowly, shows choppy animations, freezes, crashes, or consumes a lot of power, your users will notice. To avoid these performance problems, use the Android Profiler to measure your app's memory, CPU, and network usage.
Codelabs are short, self-paced tutorials that step you through the process of building a particular type of app or adding a new feature to an existing app.
Google partnered with Udacity to teach Android development with online videos. Several free courses are available, or you can enroll in the Nanodegree program.
These online trainings provide a guided path through the process of learning how to build Android apps. Courses are available for new and advanced developers.
Wear OS is a wearable platform, helping people live more present, healthy, and productive lives. Wear OS makes smartwatches into glanceable standalone devices so users can stay connected online and complete tasks quickly, while leaving their phones in their pockets. Designing experiences for wearables is different from designing for phones or tablets. For more information, see Principles of Wear OS development.
These checklists define minimum quality criteria and associated tests to help you assess the quality of your app. The minimum quality criteria are assessed using the latest version of Wear OS. Some of these criteria are easy to miss, and the tests help you remember to include them in your test plans.
Each test has a unique ID which you might find helpful to use when you communicate with your team.
Basic compatibility
Your mobile app should fulfill the core app quality requirements. In particular, you should pay special attention to the following two notification related requirement for your mobile apps:
Area
ID
Description
Notification
VX-S1
Notifications follow Material Design guidelines. In particular:
Notifications are not used for cross-promotion or advertising 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.
Notifications are persistent only if related to ongoing events, such as music playback or a phone call. For more information, see the Functionality section.
VX-S2
For messaging apps, social apps and conversations:
Only 1 and 2 are supported on Wear OS without a native Wear OS app.
When setting up a test environment, we recommend that at minimum, you pair your phone / emulator with the Wear OS Round 1.84” emulator.
Better: Full support for Wear OS
Beyond supporting notifications on connected mobile devices, Wear OS also supports native applications. As a first step, we recommend that developers read the Principles of Wear OS development guide. This contains the best practices for creating a Wear OS app.
you should test their Wear OS app against the following emulators:
Wear OS Square 1.65”
Wear OS Round 1.84”
Important: To ensure a great user experience, apps for wearables must meet specific requirements for usability. Only apps that meet the following quality criteria qualify as Wear OS apps on Google Play. Qualifying as a Wear OS app makes it easier for those using wearables to discover your app on Google Play.
Area
ID
Description
Layout
WO-L1
The app's user interface is formatted appropriately for all Wear OS display types:
Square
Round
The app's content fits within the physical display area, and no text or controls are cut off by the screen edges.
The app's text is large and glanceable with a suggested minimum font size of 12sp.
Functionality
WO-F1
App includes a watch APK that runs directly on the Wear OS device and is discoverable in the Wear OS on-watch Play Store. For more information, see Package and distribute Wear OS apps.
WO-F2
The app must mention Wear OS in its Google Play Store listing and contain at least one screenshot that depicts the Wear OS app experience. Provide screenshots showing only your app interface. Don’t place your screenshots within device frames, or include additional text, graphics, or backgrounds that are not part of the interface of your app. Upload screenshots with a 1:1 aspect ratio. For more information, see Add preview assets to showcase your app.
WO-F3
Wear OS functionality works as expected or as described in the app's Google Play Store listing.
WO-F4
If your app is a single Wear OS watch face, the App Icon must be an accurate representation of the watch face. Apps that include more than one watch face are exempt from this requirement. However, apps are more discoverable on the Store if they only have a single watch face. Do not include text or graphics that are not part of the watch face experience. For more information on creating app icons, see Google Play icon design specifications.
Best: A differentiated experience
At this level, the Wear OS app should have been tested and paired with both Android and iOS mobile devices.
Area
ID
Description
Functionality
WO-F5
If the app is identified as standalone, it must be functional without requiring a phone for authentication or operation. In addition to supporting independent login via app on the watch, standalone apps may support additional authentication methods, such as automatic login sharing when a mobile phone is nearby. For more information, see Authentication on wearables.
Frequently asked questions
After I submit my app for Wear OS review, how do I find out if my app doesn't meet all of the requirements for Wear OS?
If your app does not meet the usability requirements described on this page, the Play Store team contacts you using the email address specified in the Google Play Console account associated with the app.
Caution: Make sure your app meets the functionality requirements, otherwise your app isn't considered a Wear OS app and won't be reviewed for Wear OS.
If my app does not meet the Wear OS requirements, will my new or updated app still appear on Google Play for other devices and still be installable on wearables?
No, your app will not show up in the Wear OS version of the Google Play Store. However, your app may still appear in the Play Store for other devices (phones or tablets) and still may be installed on a wearable.
For information about how to publish your Wear OS apps in Google Play, see Distributing to Wear OS.
Device capability for billions | Android Developers
Reaching new users means supporting an increasing variety of Android platform versions and device specifications. To improve the user experience, optimize for common RAM configurations, and screen sizes and resolutions.
Support multiple screen sizes
Your app can provide a better user experience for billions of users if it supports screens of various sizes and resolutions. This section describes a few ways you can do this.
Use density-independent pixels (dp)
Defining layout dimensions with pixels doesn't work well because different screens have different pixel densities, so the same number of pixels may correspond to different physical sizes on different devices.
To overcome this Android supports the density-independent pixel (dp), which corresponds to the physical size of a pixel at 160 dots per inch (mdpi density).
Defining layouts with dp ensures that the physical size of your user interface is consistent regardless of device. Visit the Android guide on Supporting Multiple Screens for best practices on using density-independent pixels.
Test text and graphics on ldpi and mdpi screen densities
Test to ensure that your text and graphics work well on low- and medium-density (ldpi and mdpi) screens because these are common densities, especially in lower-cost devices. Look out for text that may be unclear on lower-density screens, where fine details aren't visible.
Devices with lower-density screens tend to have lower hardware specifications. To ensure that your app performs well on these devices, consider reducing or eliminating heavy graphics processing loads, such as animations and transitions.
Validate that your layouts scale down by testing on smaller screens. As screen sizes shrink, be very selective about visible UI elements, because there is limited space for them.
The Material Design guidelines describe metrics and keylines to ensure that your layouts can scale across screen densities.
Not all of your users may be using devices powered by the latest, greatest version of the Android platform. Here are some ways you can improve backward compatibility, helping make your app available to as many people as possible.
Set your targetSdkVersion and minSdkVersion appropriately
Apps should build and target the most recent version of Android to ensure they offer the most current behavior across a broad range of devices; this still provides backward compatibility to older versions. Here are the best practices for targeting API levels appropriately:
targetSdkVersion should be the latest version of Android. Targeting the most recent version ensures that your app inherits newer runtime behaviors when running newer versions of Android. Be sure to test your app on newer Android versions when updating the targetSdkVersion as it can affect app behavior.
minSdkVersion Sets the minimum supported Android version. Setting minSdkVersion also results in the Android build tools reporting incorrect use of new APIs that might not be available in older versions of the platform. By doing so, you are protected from inadvertently breaking backward compatibility.
Consult the Android dashboards, the Google Play Developer Console for your app, and industry research in your target markets to gauge which versions of Android to target, based on your target users.
Use the Android Support libraries
Ensure your app provides a consistent experience across OS versions by using the Android Support Library. This library provides backward-compatible versions of Android framework APIs as well as features that are only available through the library APIs such as AppCompatActivity and the Material Design Support Library.
Multidex support library: provides support for large apps that have more than 65K methods. This can happen if your app is using many libraries.
For more information about the available support libraries, see the Support Libraries Features section of the Android Developer site.
Use Google Play services
Google Play services brings the best of Google APIs independent of Android platform version. Consider using features from Google Play services to offer the most streamlined Google experience on Android devices.
Google Play services also include useful APIs such as GcmNetworkManager, which provides much of Android 5.0's JobScheduler API for older versions of Android.
Updates to Google Play services are distributed automatically by the Google Play Store, and new versions of the client library are delivered through the Android SDK Manager.
Use memory efficiently
Memory is an unsung hero of the user experience. Good memory management can make your app more stable and more performant; in some cases, its effective use may be the only thing making your app usable at all. Here are some ways you can help your app use memory wisely.
Reduce memory footprint on low-cost devices
Adjust your memory footprint dynamically to ensure compatibility across devices with different RAM configurations.
Methods such as isLowRamDevice() and getMemoryClass() help determine memory constraints at runtime. Based on this information, you can scale down your memory use. As an example, you can use lower resolution images on low memory devices.
For more information about managing your app's memory, see the Android training on Managing Your App's Memory.
Avoid long-running processes
Long-running processes stay resident in memory and can slow down the device. In most situations, your app should wake up for a given event, process data, and shut down. You should use Firebase Cloud Messaging (FCM) and GcmNetworkManager to avoid long running background services and reduce memory pressure on the user's device.
Benchmark memory use
Android Studio provides memory benchmarking and profiling tools, enabling you to measure memory use at run time. Benchmarking your app's memory footprint enables you to monitor memory use over multiple versions of the app. This can help catch unintentional memory footprint growth. Use the Memory Profiler tool to do the following:
Find out whether undesirable garbage collection (GC) event patterns might be causing performance problems.
Identify object types that get or stay allocated unexpectedly or unnecessarily.
Android (Go edition) is an optimized experience for entry-level devices with ≤1GB RAM, starting with Android Oreo (Go edition). To ensure your app runs great on Android (Go edition) devices, you should should take into account the following guidelines:
targetSdkVersion should be the latest version of Android. Android (Go edition) devices only run Android Oreo (API 27 or higher).
The app should run smoothly on devices with ≤1GB RAM. Keep in mind the memory optimizations listed in Use memory efficiently above and use Android vitals to identify and fix bad behaviors like slow rendering and frozen frames.
The on-device app size should be smaller than 40MB.
The Proportional Set Size (PSS) of the app's RAM usage should not exceed 90MB. For games, the PSS of the game's RAM usage should not exceed 150MB. For more information about PSS, see the Investigating Your RAM Usage guide.
The startup time of the app should be minimal and under 5 seconds.
SYSTEM_ALERT_WINDOW (which allows apps to draw a window on top of other apps) might be disabled on Android Go devices that have low RAM. Before drawing over other apps, check whether your app has this authorization by calling Settings.canDrawOverlays(). If your app cannot get the permission, gracefully degrade your app so that the user can continue using your app, possibly by disabling the feature that requires the SYSTEM_ALERT_WINDOW permission.
We recommend that most developers optimize their existing app, which will be available on all Android (Go edition) devices, because making your app run faster and lighter will benefit your whole audience. You can use the Multiple APK feature on the Play Console to distribute a specific APK for Android (Go edition) devices but you should only do so without compromising the experience (e.g. you should avoid removing features). The APK targeting Android (Go edition) devices needs to declare <uses-feature android:name="android.hardware.ram.low" android:required="true">, target at least API Level 26, and have a higher version code than the non-Go edition APK.
Related
Additional resources
To learn more about supporting a variety of devices, view the following resource:
A useful way to evaluate app excellence is to walk through the workflows in your app and evaluate the smoothness and safety of the app experience.
This checklist defines a set of core quality criteria and associated tests to help you assess the quality of your app. Some of these criteria might be easy to miss, and the tests help you remember to include them in your test plans.
The checklist highlights the minimum quality that all apps should meet. Your testing will likely go well beyond what's described here.
Each item in the quality checklist has a unique ID which you might find helpful to use when you communicate with your team. You can also view the previous version of these guidelines.
Visual experience
Your app should provide standard Android visual design and interaction patterns where appropriate, for a consistent and intuitive user experience.
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.
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.
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.
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 are persistent only if related to ongoing events, such as music playback or a phone call. For more information, see the Functionality section.
The app avoids running unnecessarily long services in the background. To ensure the smooth running of the user’s device, the system applies various restrictions on background services. These are not considered good uses of background services:
Maintaining a network connection for notifications
The app loads quickly or provides onscreen feedback to the user (a progress indicator or similar cue) if the app takes longer than two seconds to load.
Apps should render frames every 16ms to achieve 60 frames per second. Developers can use the Profile HWUI rendering option in testing. If there are issues, tools are available to help diagnose slow rendering.
With StrictMode enabled (see StrictMode Testing, below), no red flashes (performance warnings from StrictMode) are visible when testing the app. Any red flashes indicate bad behaviors regarding storage, network access, or memory leaks.
For Google SDKs, consider using 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.
The developer is accountable for the entire app’s codebase, inclusive of any third-party SDKs used.
The app properly supports the power management features that were introduced in Android 6.0 (Doze and App Standby). In the case where core functionality is disrupted by power management, only qualified apps may request an exemption. See Support for other use cases in Doze and App Standby.
During development, developers can test app standby and doze behavior using these ADB commands.
The app requests only the absolute minimum number of permissions that it needs to support its use case at hand. For some permissions such as location, use coarse location in place of fine location if possible.
SC-P2
The app requests permission to access sensitive data (such as SMS, Call Log, or Location) or services that cost money (such as Dialer or SMS) only when 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.
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.
When setting up your PendingIntents, explicitly set the immutable flag, where applicable.
The app strictly adheres to the terms of the Google Play Developer Content Policy and does not offer inappropriate content, does not use the intellectual property or brand of others, and so on.
The app’s feature graphic follows the guidelines outlined in this support article. Make sure that:
The app listing includes a high-quality feature graphic.
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.
The feature graphic does not resemble an advertisement.
Common user-reported bugs in the Reviews tab of the Google Play page are addressed if they 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.
Setting up a test environment
For the purpose of setting up a test environment for this checklist, we recommend the following:
Focused on emulator testing - Android Emulator is a great way to test your app under different Android versions and screen resolutions. You should set up emulated devices (AVDs) to represent the most common form factors and hardware/software combinations for your target user base. In addition to testing for phones, we also recommend you test other 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).
For 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 currently available to consumers. It's not necessary to test on every device that's on the market — rather, you should 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 as Firebase Test Lab, to test your app on a wider 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 (currently Android 11). This ensures that the latest behavior changes do not negatively impact your user’s experience.
For more comprehensive guidance on testing including unit testing, integration testing and UI testing, check out the Android testing fundamentals.
Test procedures
These test procedures help you discover various types of quality issues in your app. You can combine the tests or integrate groups of tests together in your own test plans. See the sections above for references that associate criteria with these test procedures.
Type
Test
Description
Core Suite
CR-0
Navigate to all parts of the app — all screens, dialogs, settings, and all user flows.
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
CR-1
From each app screen, press the device's Home key or swipe up in gesture navigation, then re-launch the app from the All Apps screen.
CR-2
From each app screen, switch to another running app, and then return to the app under test using the Recents app switcher.
CR-3
From each app screen (and dialogs), press the Back button or use the back swipe gesture.
CR-5
From each app screen, rotate the device between landscape and portrait orientation and folding / unfolding at least three times.
CR-6
Switch to another app to send the test app into the background. Go to Settings and check whether the test app has any services running while in the background. In Android 4.0 and higher, go to the Apps screen and find the app in the "Running" tab.
CR-7
Press the power button to put the device to sleep, then press the power button again to wake the screen.
CR-8
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.
CR-9
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.
CR-10
Review Support for other use cases in Doze and App Standby.
Install on SD Card
SD-1
Repeat Core Suite with the app installed to a device’s SD card (if the app supports this installation method).
To move the app to SD card, you can use Settings > App Info > Move to SD Card.
Performance and Stability
SP-1
Review the Android manifest file and build configuration to ensure that the application is built against the latest available SDK (targetSdk and compileSdk).
SP-2
Review the build.gradle file for any outdated dependencies.
Pay close attention to garbage collection and its impact on the user experience.
Battery
BA-1
Repeat Core Suite across Doze and App Standby cycles.
Pay close attention to alarms, timers, notifications, syncs, and so on. See Testing with Doze and App Standby for requirements and guidelines.
Security
SC-1
Review all data stored in external storage.
SC-2
Review how the data that’s loaded from external storage is handled and processed.
SC-3
Review all content providers defined in the Android manifest file. Make sure each provider has an appropriate protectionLevel.
SC-4
Review all permissions that your app requires, in the manifest file, at runtime, and in the app settings screen (Settings > App Info) on the device.
SC-5
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.
Run the application and exercise all core functionality, while observing the device log. No private user information should be logged.
Google Play
GP-1
Sign into the Google Play Developer Console to review your developer profile, app description, screenshots, feature graphic, content rating and user feedback.
GP-2
Download your feature graphic and screenshots, and scale them down to match the display sizes on the devices and form factors that you are targeting.
GP-3
Review all graphical assets, media, text, code libraries, and other content that’s packaged in the app or expansion file download.
Testing with StrictMode
For performance testing, we recommend enabling StrictMode in your app and using it to catch operations that could affect performance, network accesses, file reads/writes, and so on. Look for potentially problematic operations both on the main thread and on other threads.
Reduced data cost for billions | Android Developers
Data plans in some countries can cost upwards of 10% of a typical user's monthly income. This means that minimizing your app's download size and letting the user control how your app uses data can have a large, tangible benefit to many users. Minimizing download size also helps conserve space in internal storage, which is a scarce resource in some devices.
Here you can find some strategies to help optimize the amount of data your app uses, both over the network and in internal storage.
Reduce app size
Reducing app size is one of the fundamental ways you can help your user consume less data, in terms of both network data and internal storage. This section describes several approaches to reducing app size.
Reduce APK graphical asset size
Graphical assets are often the largest contributor to the size of the APK. Optimizing these can result in smaller downloads and thus faster installation times for users.
For graphical assets such as icons, use the Scalable Vector Graphics (SVG) format. SVG images are tiny in size compared to bitmap graphics and can be rendered at runtime to any resolution. The Android Support Library provides a backward-compatible implementation for vector resources to Android 2.1 (API level 7). Get started with vectors with this Medium post.
For non-vector images, such as photos, use WebP to reduce image load times and save network bandwidth. WebP is proven to result in smaller file sizes than its PNG and JPG counterparts, with at least the same image quality. Even at lossy settings, WebP can produce a nearly identical image to the original. Android has included lossy WebP support since Android 4.0 (API level 14: Ice Cream Sandwich) and support for lossless, transparent WebP since Android 4.2 (API level 17: Jelly Bean).
If you have many large images across multiple densities, consider using Multiple APK support to split your APK by density. This results in builds targeted for specific densities, meaning users with low-density devices won’t have to incur the penalty of downloading unused high-density assets.
Every library in your Android project is adding potentially unused code to the APK. Be particularly careful about using external libraries because not all libraries are designed for use in mobile apps. Ensure that the libraries your app is using are optimized for mobile use.
Consider optimizing your compiled code using a tool such as ProGuard. ProGuard identifies code that isn’t being used and removes it from your APK. Also enable resource shrinking at build time by setting minifyEnabled=true, shrinkResources=true in build.gradle—this automatically removes unused resources from your APK.
When using Google Play services, you should selectively include only the necessary APIs into your APK.
Low-cost devices often come with little on-device storage. Users can extend this with SD cards; however, apps need to explicitly declare that they support being installed to external storage before users can move them.
Allow your app to be installed to external storage using the android:installLocation flag in your AndroidManifest.xml. For more information on enabling your app to be moved to external storage, see the Android guide on App Install Location.
Reduce post-install app disk use
Keeping your app’s disk use low means that users are less likely to uninstall your app when the device is low on free space. It’s important to apply bounds around your caches—this prevents your app’s disk use from growing indefinitely. Be sure you put your cached data in getCacheDir()—the system can delete files placed here as needed, so they won’t show up as storage committed to the app.
Offer configurable network use
The Android platform includes a number of ways you can give the user control over your app's network use, optimizing it for their own needs. For example, on first use, your app can walk the user through a variety of network-related settings. You can also provide a network preferences screen from outside the app.
Provide onboarding experiences for users' network choices
Apps that allow users to reduce data use are well received, even if they have heavy data requirements. If your app uses a considerable amount of bandwidth (for example, video streaming apps), you can provide an onboarding experience for users to configure network use. For example, you could allow the user to force lower-bitrate video streams on cellular networks.
Additional settings for users to control data syncing, prefetching, and network use behavior (for example, prefetch all starred news categories on Wi-Fi only), also help users tailor your app’s behavior to their needs.
For more information on managing network use, see the Android training on Managing Network Usage.
Provide a network preferences screen
You can navigate to the app’s network settings from outside the app by means of a network preferences screen. You can invoke this screen from either the system settings screen or the system data usage screen.
To provide a network preferences screen that users can access from within your app as well as from the system settings, in your app include an activity that supports the ACTION_MANAGE_NETWORK_USAGE action.
