Mobile-Android

Android app quality for cars | Android Developers

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:

Android Automotive OS

Android Auto

Important: Apps must meet the criteria listed in this page to qualify as an
Android Auto or Android Automotive OS app on Google Play. Apps don't work with
Android Auto unless they are installed from the Play Store or the ONE store.

Testing your app

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:

Access on Android Automotive OS: Use the Android Emulator to validate each checklist
item. For more information, see Test your app for Android-powered vehicles.
Access on an Android Auto compatible car display: Use the Android Auto Desktop Head Unit (DHU) to validate each checklist item.
For more information, see Test your app for Android Auto compatible car displays.
Access on a phone screen: Use a phone to validate each checklist item. For more information, see
Test your app for phone screens.

Core app quality

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.

Important: If your app requires user authentication in order to access the app's
full functionality, make sure to submit login details for a test account in
the Play Developer Console. See the
App Access section
for instructions.

Car app guidelines

December 2022 Update : The Internet of Things category has been added,
and the guidelines have been updated to reflect this
change.

App Categories

Select your app's categories to filter the guidelines below.

Supported categories	Android Auto	Android Automotive OS
Media	✔	✔
Messaging	✔
Navigation	✔	✔
Point of Interest	✔	✔
Internet of Things	✔	✔
Video		✔

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.
Expected Performance	`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)
Driver Distraction	`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)
Messaging Functionality	`MF-1`	The app receives incoming messages. (Learn How)
	`MF-2`	Messages are properly grouped and displayed in the correct order. (Learn How)
	`MF-3`	The user can reply to a message. (Learn How)
	`MF-4`	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.

Note: For information about how to publish your app in Google Play, see Distribute Android apps for cars.

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.

Change notes

December 2022

Internet of Things Functionality
- Categories affected: Internet of Things
- New criteria:
  
  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"

Screen Animation
- Categories affected: Media, Messaging, Navigation, Point of Interest
- Previous text:
  
  The app does not display animated elements on the screen such as
  animated graphics, video, or progress bars.
- New text:
  
  The app does not display animated elements on the screen such as
  animated graphics or video.

Image Usage
- 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.

Permitted Categories
- Categories affected: Media, Messaging, Navigation, Point of Interest, Video
- Previous text:
  
  The app does not include games or other features outside the app types
  intended for cars.
  (Learn More)
- New text:
  
  The app does not include features outside the app types intended for cars.
  (Learn More)

Visual Information on Phone
- 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)

Navigation Functionality
- Categories affected: Navigation
- Previous 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 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.

Point of Interest Functionality
- Categories affected: Point of Interest
- Previous text:
  
  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.

April 2022

Display Orientation
- Categories affected: Video
- New criteria:
  
  UIs drawn by the app support both landscape and portrait screens.

Driver Distraction
- Categories affected: Video
- New criteria:
  
  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.

Settings Flow
- Categories affected: Video
- New criteria:
  
  App must proceed to the home page after (attempted) sign-in.

Automotive Functionality
- Categories affected: Video
- New criteria:
  
  App does not contain driver optimized activities.

CPU Architectures
- Categories affected: Video
- New criteria:
  
  App supports both x86_64 and ARM CPUs.

App Navigablity
- Categories affected: Video
- New criteria:
  
  App allows users to navigate through the app without encountering
  any dead ends.

November 2021

Visual Information on Phone
- Categories affected: Media, Navigation, Parking & Charging
- Previous text:
  
  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)

Payments
- Categories affected: Navigation, Parking & Charging
- Previous text:
  
  The app must have simple flows if purchases are enabled.
- New text:
  
  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)

Build for billions | Android Developers

Build for billions

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.

Connectivity

Learn how to provide a better experience for users connected to slower networks.
Focus on optimizing images, optimizing networking, and fine-tuning data transfer.

Device capability

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.

Data cost

Learn how to help users minimize their network traffic costs by
reducing app size and offering configurable network settings.

Battery consumption

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.

User interface and content

Learn how to present content for the best possible user experience. Areas to focus
on include UI responsiveness, UI best practices, and localization.

Read article

Large screen app quality | Android Developers

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:

Category	ID	Test	Description
Configuration and continuity	LS-C1	T3-1, T3-2	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
Configuration and continuity	LS-C2	T3-3	App handles combinations of configuration changes, such as window resizing followed by device rotation, or rotation followed by device folding or unfolding.
Multi-window and multi-resume	LS-M1	T3-4	App is fully functional in multi-window mode. See Multi-window support. Note: Unity apps should be on Unity Long Term Support (LTS) version 2019 or later. See Multi-window mode verification.
Multi-window and multi-resume	LS-M2	T3-5, T3-6	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.
Camera preview and media projection	LS-CM1	T3-7	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.
Camera preview and media projection	LS-CM2	T3-8	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.
Keyboard, mouse, and trackpad	LS-I1	T3-9	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.
Keyboard, mouse, and trackpad	LS-I2	T3-10	App supports basic mouse or trackpad interactions: Click: Any clickable element, including buttons, dropdown menus, text entry fields, and navigation icons Select: Any selectable element, including radio buttons, checkboxes, and text (by swiping or double clicking) Scroll: Vertically and horizontally in scrollable elements such as lists and pickers
Stylus	LS-S1	T3-11	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.

Category	ID	Test	Description
UX	LS-U1	T2-1	App has responsive and adaptive layouts designed for large screens. All layouts are responsive (see Migrate your UI to responsive layouts). Implementation of adaptive layouts is determined by window size classes. The app UI can include the following: Leading edge navigation rails that expand on larger window sizes into full navigation panels Grid layouts that scale the number of columns to accommodate window size changes Columns of text on large screens Trailing edge panels that are open by default on laptop and desktop screen sizes; closed, on smaller screens Two-pane layouts, where appropriate, are recommended to take advantage of the large screen space. See SlidingPaneLayout for list detail UIs. Activity embedding enables activity-based apps to easily create multi-pane layouts by displaying activities side by side.
	LS-U2	T2-1	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.
	LS-U3	T2-2	Touch targets are least 48dp. See the Material Design Layout and typography guidelines.
	LS-U4	T2-3	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.
Keyboard, mouse, and trackpad	LS-I3	T2-4	The main task flows in the app support keyboard navigation, including Tab and arrow key navigation. See Build more accessible apps.
	LS-I4	T2-5	App supports keyboard shortcuts for commonly used actions such as select, cut, copy, paste, undo, and redo. See Input compatibility.
	LS-I5	T2-6	Keyboard can be used to control media playback; for example, the space bar plays and pauses media.
	LS-I6	T2-7	Keyboard Enter key performs a send function in communication apps.
	LS-I7	T2-8	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.
	LS-I8	T2-9	App content can be zoomed using the mouse scroll wheel (in conjunction with a keyboard key press) and trackpad pinch gestures.
	LS-I9	T2-10	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.

Note: Because Tier 1 apps are highly differentiated, some of the listed capabilities are applicable only to specific types of apps. Choose the functionality that's appropriate for your application.

Category	ID	Test	Description
Multitasking and multi-instance	LS-M3	T1-1, T1-2, T1-3	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.
Multitasking and multi-instance	LS-M4	T1-4	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.
Foldable postures and states	LS-F1	T1-5	App supports all foldable postures and related use cases: Tabletop mode — Video calling and video or audio playback. Book mode — Reading lengthy text content. Dual display — Front and back screen preview for camera apps. Support for dual-screen devices. See Learn about foldables.
Foldable postures and states	LS-F2	T1-6	Camera apps adjust their preview for folded and unfolded states and support front and back screen preview.
Drag and drop	LS-D1	T1-7	App supports drag and drop between views within the app and, in multi-window mode, to and from other apps. See Drag and drop. See also LS-S3.
Keyboard, mouse, and trackpad	LS-I10	T1-8	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.
	LS-I11	T1-9	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.
	LS-I12	T1-10	App displays a scrollbar while content is being scrolled using a mouse or trackpad.
	LS-I13	T1-11	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.
	LS-I14	T1-12	Desktop-style menus and context menus are used where appropriate.
	LS-I15	T1-13	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.
	LS-I16	T1-14	Triple clicking or tapping using a mouse or trackpad selects entire lines or paragraphs of text.
Stylus	LS-S2	T1-15	App supports drawing and writing with a stylus. Drawings and writing can be erased with the stylus.
	LS-S3	T1-16	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.
	LS-S4	T1-17	App provides enhanced stylus support, including: Pressure sensitivity for drawing strokes of varying width Tilt detection for creating shading strokes Palm and finger rejection to prevent stray marks
Custom cursors	LS-P1	T1-18	App displays customized cursors to indicate how and when users can interact with UI elements and content, for example: System cursors provided by the Android framework I-beam for text Resize handles at resizable layer edges Processing spinners Specialty cursors that you provide Crosshairs when hovering over targets in games A magnifying glass when hovering over zoomable content Tools in drawing or illustration apps See PointerIcon and Mouse pointer icons.

Large screen compatibility tests

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:

Foldable phone — 7.6” Fold-in with outer display

Tablet — Pixel C 9.94"

Dual-display foldable — Microsoft Surface Duo

Tier 3 — Large screen ready

Category	ID	Feature	Description
Configuration and continuity	T3-1	LS-C1	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 Multi-window mode, even for apps that have specified `android:resizeableActivity="false"` in the app manifest
	T3-2	LS-C1	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
	T3-3	LS-C2	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.
Multi-window and multi-resume	T3-4	LS-M1	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.
	T3-5	LS-M2	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).
	T3-6	LS-M2	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.
Camera preview and media projection	T3-7	LS-CM1	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.
Camera preview and media projection	T3-8	LS-CM2	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.
Keyboard, mouse, and trackpad	T3-9	LS-I1	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.
Keyboard, mouse, and trackpad	T3-10	LS-I2	For each app screen, connect a mouse and trackpad to the device. Perform basic mouse and trackpad interactions: Click all clickable elements such as buttons, dropdown menus, and text entry fields. Select radio buttons and checkboxes. Select text by swiping and double clicking. Scroll vertically and horizontally (if applicable) through lists, pickers, etc.
Stylus	T3-11	LS-S1	Using a stylus, navigate through the app, select UI elements, scroll through lists and pickers, and generally interact with the app.

Tier 2 — Large screen optimized

Category	ID	Feature	Description
UX	T2-1	LS-U1, LS-U2	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.
	T2-2	LS-U3	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.
	T2-3	LS-U4	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.
Keyboard, mouse, and trackpad	T2-4	LS-I3	Navigate through the app's focusable components using the Tab and arrow keys of an external keyboard.
	T2-5	LS-I4	Use keyboard shortcuts on an external keyboard to perform select, cut, copy, paste, undo, and redo actions.
	T2-6	LS-I5	Use an external keyboard to start, stop, pause, rewind, and fast forward media playback.
	T2-7	LS-I6	Use the Enter key of an external keyboard to send or submit data.
	T2-8	LS-I7	Use the secondary mouse button or trackpad secondary tap capability to access the options menu of interactive elements.
	T2-9	LS-I8	Use the mouse scroll wheel (in conjunction with the Control, or Ctrl, key) and trackpad pinch gestures to zoom content in and out.
	T2-10	LS-I9	Hover the mouse or trackpad cursor over actionable UI elements to activate the element's hover state.

Tier 1 — Large screen differentiated

Category	ID	Feature	Description
Multitasking and multi-instance	T1-1	LS-M3	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.
	T1-2	LS-M3	In multi-window mode, open another app from within the app and display both apps side by side.
	T1-3	LS-M3	Open and close attachments and notifications in portrait and landscape orientations, with the device folded and unfolded, and in multi-window mode.
	T1-4	LS-M4	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.
Foldable postures and states	T1-5	LS-F1	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).
Foldable postures and states	T1-6	LS-F2	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	T1-7	LS-D1	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.
Keyboard, mouse, and trackpad	T1-8	LS-I10	Change the app's keyboard shortcuts. Test the revised shortcuts using an external keyboard.
	T1-9	LS-I11	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.
	T1-10	LS-I12	Scroll app content using a mouse and trackpad. Verify that a scrollbar appears while the content is scrolling.
	T1-11	LS-I13	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.
	T1-12	LS-I14	On laptop and desktop displays, verify that desktop-style menus and context menus are used.
	T1-13	LS-I15	On each app screen, resize and rearrange UI panels using a mouse and trackpad.
	T1-14	LS-I16	Using a mouse and trackpad, triple click or tap to select items in the app; for example, to select full lines of text.
Stylus	T1-15	LS-S2	Draw and write within the app using a stylus. Erase drawings and writing using the stylus.
	T1-16	LS-S3	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).
	T1-17	LS-S4	Interact with the app using a stylus as follows: 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.
Custom cursors	T1-18	LS-P1	Interact with the app using a mouse and trackpad. Verify that custom cursors appear where appropriate, for example: I-beam for text entry fields Resize handles at resizable layer edges Spinners when app is performing long-running tasks

Read article

Documentation | Android Developers

Documentation for app developers

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.

Get started

Build your first app

Sample code

API reference

Design guidelines

Codelab tutorials

Training courses

Android devices

Wear OS

Android TV

Android for Cars

Chrome OS Devices

Best practices

Dependency Injection

Testing

Performance

Accessibility

Security

Enterprise

Emerging markets

Core developer topics

App architecture

Android app bundles

Activities

Intents and intent filters

Navigation

Animations & transitions

Graphics

Audio & video

Background tasks

App data & files

User data & identity

User location

Touch & input

Camera2

CameraX

Sensors

Connectivity

Renderscript

Web-based content

See all developer guides

Design guides

Material design

Core app quality

Tablet app quality

Wear app quality

TV app quality

Car app quality

Data binding library

The Data Binding Library enables you to write declarative layouts.

Libraries

Android Test

Android Test helps you build and run test code for your app.

Libraries

Play Billing Library

The Google Play Billing Library provides a simple interface for sending billing requests and managing billing transactions with Google Play.

Developer Tools

Guide

Android Emulator

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.

Guide

Configure your build

Android Studio uses Gradle, an advanced build toolkit, to automate the build process, while allowing you to define flexible, custom build configurations.

Guide

Build your UI layout

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.

Guide

Profile your app performance

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.

Profile your app

More education

Check out these other resources for beginner and experienced Android developers.

Android codelabs

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.

Online video courses

Google partnered with Udacity to teach Android development with online videos. Several free courses are available, or you can enroll in the Nanodegree program.

Training courses

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.

Latest videos

Wear OS app quality | Android 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.

Caution: Test your app and make sure it works on a watch running Wear OS 2.0 and on a watch
running Wear OS 3.0 or greater.

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

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. Selecting the correct notification priority. Multiple notifications are stacked into a single notification group, where 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.
VX-S2	For messaging apps, social apps and conversations: Use the `MessagingStyle` notifications for conversations. Support the direct reply action. Support conversation shortcuts, and implement best practices for getting the best direct share ranking. Support bubbles. Only 1 and 2 are supported on Wear OS without a native Wear OS app.

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.

Selecting

the correct notification priority.

Multiple notifications are stacked into a single
notification group, where 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.

VX-S2

For messaging apps, social apps and conversations:

Use the
MessagingStyle
notifications for conversations.

Support the
direct reply action.

Support
conversation shortcuts, and implement best
practices for getting the
best direct share ranking.

Support bubbles.

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. For more information see Handle different watch face shapes.
Layout	WO-L2	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.

Large screen app quality

TV app quality

Read article

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.

For more information about supporting different densities,
see the Android training on
Supporting Different Densities.

Test layouts on small and medium screen sizes

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.

For more information about supporting different screen sizes,
see the Android training on
Supporting Different Screen Sizes.

Provide backward compatibility

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.

Some of the highlights include:
- v4 and v7 support library: Many framework APIs for older versions of
  Android such as ViewPager ,
  ActionBar ,
  RecyclerView , and
  Palette .
- Material Design
  support library: APIs to support adding Material Design components
  and patterns to your apps.
- 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.

Identify where in your code the problem might be.

For more information about benchmarking memory use, see

View the Heap and Allocations with Memory Profiler.

Optimize for devices running Android (Go edition)

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.

Picture in picture (PIP) might be disabled
on devices. Before your app uses PIP, check to be sure it is available by
calling hasSystemFeature(PackageManager.FEATURE_PICTURE_IN_PICTURE) .

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.

Note: If you are designing a completely different app,
with a new experience and a different set of features,
you might decide to launch an Android (Go edition) specific app,
with a unique application package.
This would also have a unique Play Store listing,
with its own ratings and install count,
and this may be confusing for users on the Play Store.
For the majority of developers,
we recommend using Multiple APK to target Android (Go edition) devices,
instead of creating two distinct and separate apps.

Additional resources

To learn more about supporting a variety of devices, view the following
resource:

Blog posts

To
Make Apps Accessible, Make Them Compatible with Different Devices

Read article

Welcome to Knowledge Base!

KB at your finger tips

Mobile-Android

Android app quality for cars | Android Developers

Testing your app

Core app quality

Car app guidelines

App Categories

Visual design and user interaction

Functionality

Frequently asked questions

Change notes

December 2022

May 2022

April 2022

November 2021

Build for billions | Android Developers

network_check Connectivity

devices_other Device capability

perm_data_setting Data cost

battery_alert Battery consumption

view_quilt User interface and content

Large screen app quality | Android Developers

Large screen compatibility checklists

Tier 3 — Large screen ready

Tier 2 — Large screen optimized

Tier 1 — Large screen differentiated

Large screen compatibility tests

Tier 3 — Large screen ready

Tier 2 — Large screen optimized

Tier 1 — Large screen differentiated

Documentation | Android Developers

Documentation for app developers

Get started

Android devices

Best practices

Core developer topics

Design guides

More documentation

Android Architecture components

Support library

Data binding library

Android Test

Play Billing Library

Android Emulator

Configure your build

Build your UI layout

Profile your app performance

Android codelabs

Online video courses

Training courses

Wear OS app quality | Android Developers

Basic compatibility

Better: Full support for Wear OS

Best: A differentiated experience

Frequently asked questions

Device capability for billions | Android Developers

Support multiple screen sizes

Use density-independent pixels (dp)

Test text and graphics on ldpi and mdpi screen densities

Test layouts on small and medium screen sizes

Provide backward compatibility

Set your targetSdkVersion and minSdkVersion appropriately

Use the Android Support libraries

Use Google Play services

Use memory efficiently

Reduce memory footprint on low-cost devices

Avoid long-running processes

Benchmark memory use

Optimize for devices running Android (Go edition)

Related

Additional resources

Blog posts

Connectivity

Device capability

Data cost

Battery consumption

User interface and content

Set your `targetSdkVersion` and `minSdkVersion`
appropriately