How to Create Android App Screenshots for Google Play

Direct answer: Create screenshots from the current version of your Android app on the form factors you distribute, export them as JPEG or 24-bit PNG without alpha, verify Google Play’s size and aspect-ratio rules, then upload them in Play Console under Main store listing → Graphics. Use the device-specific sections for phones, tablets, Wear OS, TV, Automotive, or XR. Keep the first images focused on the real app UI and make every screenshot accurately reflect the version users can install.

Google’s official requirements are documented in Add preview assets to showcase your app. Also review its guidance on accurate store listings and listing and localization best practices before publishing.

1. Plan the screenshot set

Choose the device sections you actually support

Plan a separate set for each distributed form factor:

Form factor	What to prepare
Phone	Core flows in the orientation your app uses most.
Tablet or Chromebook	Large-screen layouts; Google calls for at least four large-screen screenshots between 1,080 and 7,680 px.
Wear OS	At least one current-version, 1:1 screenshot of only the app or watch-face interface, at least 384 × 384 px, with no device frame, transparency, masking, extra text, or background.
Android TV	At least one TV screenshot plus the required Android TV banner.
Android Automotive OS	Category-specific images; the guidance calls for two portrait images at 800 × 1280 and two landscape images at 1024 × 768 when Automotive screenshots are provided. Use generic system UI rather than a vehicle or OEM UI.
Android XR	Four to eight PNG or JPEG images, up to 8 MB each, in an 8:5 ratio. Recommended resolution is 3840 × 2400; minimum is 1920 × 1200.

Baseline publishing rules versus recommendation guidance

Keep these two goals separate:

General baseline: at least two screenshots across different device types; JPEG or 24-bit PNG without alpha; each image at least 320 px, at most 3840 px, with the longest dimension no more than twice the shortest.
Recommendation eligibility guidance for apps: at least four screenshots at 1080 px or higher, in 16:9 landscape (minimum 1920 × 1080) or 9:16 portrait (minimum 1080 × 1920).
Recommendation eligibility guidance for games: at least three landscape 16:9 images at 1920 × 1080 or larger, or three portrait 9:16 images at 1080 × 1920 or larger.

The high-resolution sets are recommended guidance for recommendation surfaces; they are not a replacement for checking the baseline and device-specific requirements.

2. Capture the real app

Build the exact app version you intend to publish.
Run it on each relevant emulator or physical device form factor.
Put the app into a clean, representative state: remove debug data, test accounts, accidental dialogs, and stale notifications.
Capture screens that explain the core feature first. Use the first three images to make the UI and main value immediately understandable.
Capture distinct features or outcomes instead of several nearly identical screens.

Google says store-listing images should accurately reflect app functionality. A mismatch can lead to rejection. Do not show a feature, workflow, or content that users cannot find in the downloadable app.

Capture checklist

Use the correct orientation for the listing section.
Keep text and controls legible at the displayed size.
Remove excess notification-bar content. Avoid showing service-provider notifications; Google advises keeping battery, Wi‑Fi, and mobile-service indicators full.
Do not use blurry, stretched, pixelated, sideways, distorted, or heavily compressed images.
Do not include a person interacting with a device unless off-device use is central to the app.
Check that no private data, internal URLs, test credentials, or development labels are visible.

3. Compose a useful sequence

A practical order is:

Recognizable entry point: the screen that tells a new user what the app is.
Primary action: the main task completed in the app.
Distinctive capability: a feature that separates the app from alternatives.
Result or outcome: what the user gets after using it.
Supporting workflow: settings, collaboration, offline mode, or another important capability.

Overlay text can clarify a screen, but keep it small. Google says taglines should not occupy more than 20% of the image. Avoid rankings, awards, testimonials, pricing, discounts, “Download now” calls to action, and time-sensitive claims. If an overlay contains language-specific text, create localized screenshot variants rather than relying on one language everywhere.

4. Export and validate files

Before uploading, inspect every file against this checklist:

Check	Requirement or action
Format	JPEG or 24-bit PNG without alpha for the general listing.
Dimensions	At least 320 px and at most 3840 px; longest dimension no more than twice the shortest.
Orientation	Matches the device-specific section and the app’s real experience.
Quality	No blur, stretching, pixelation, skew, or destructive compression.
Content	Current UI, truthful features, clean status bar, and no private or test data.
Alt text	Write unique, context-specific descriptions of 140 characters or fewer.
File size	For XR, keep each PNG or JPEG at or below 8 MB.

5. Upload in Play Console

Open your app in Google Play Console.
Go to Main store listing.
Open the Graphics section.
Select the relevant device-specific subsection.
Upload the matching screenshots in the order you want users to see them.
Add concise alt text and localized variants where needed.
Preview the listing at phone and large-screen sizes, then submit the store-listing changes.

Assets added to the Main store listing can appear across test tracks and on Play surfaces beyond the app detail page, so keep them current whenever the user-facing experience changes.

6. Screenshot automation for supporting web pages

Native Android UI screenshots must come from the app running on an emulator or device. If you also need screenshots of your app’s documentation, landing page, changelog, or other web content, automate those separately with a browser capture API.

Or skip the browser setup

ScreenshotNeo captures web pages through one GET request. It does not replace native-device capture for Android UI, but it can produce clean screenshots of the web pages that support your Play listing and release workflow. Before capture, it accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the result with X-Page-Verdict and X-Billed headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo API documentation for all options.

cURL

curl -G 'https://api.screenshotneo.com/v1/shot' -d access_key=YOUR_API_KEY --data-urlencode url=https://your-app-site.example -o shot.webp

Python

import requests

r = requests.get(
    'https://api.screenshotneo.com/v1/shot',
    params={'access_key': 'YOUR_API_KEY', 'url': 'https://your-app-site.example'},
    timeout=90,
)
r.raise_for_status()
open('shot.webp', 'wb').write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://your-app-site.example'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const data = Buffer.from(await res.arrayBuffer());
require('fs').writeFileSync('shot.webp', data);

ScreenshotNeo supports full-page capture, CSS-element capture, device presets or custom viewports, retina scale, dark mode, custom CSS and JavaScript, clicks, selector or network-idle waits, request blocking, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, caching, signed links, asynchronous jobs, bulk capture, usage reporting, PDFs, and HTML/CSS-to-image. Its parameter names also match those used by other screenshot APIs, which simplifies migration.

Create a free ScreenshotNeo account: 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is included on every plan.

7. Troubleshooting

Problem	Likely cause	Fix
Play rejects the file dimensions	The image is below 320 px, above 3840 px, or its longest side exceeds twice the shortest.	Resize and export again, then verify both dimensions and aspect ratio.
Images look blurry or stretched	Upscaling, compression, or a mismatched aspect ratio.	Capture at the target resolution and export directly to JPEG or 24-bit PNG.
Text is unreadable in the listing	Small device text or an oversized promotional overlay.	Capture a clearer state, shorten overlays, and keep taglines under 20% of the image.
Screenshot does not match the published app	It was captured from an older build, a mock screen, or a feature flag unavailable to users.	Capture from the release candidate and verify every shown flow.
Wear OS upload fails	Wrong ratio, transparency, device frame, or insufficient resolution.	Use a 1:1 image at least 384 × 384 px showing only the watch interface.
TV listing is incomplete	The TV screenshot or Android TV banner is missing.	Add both before publishing the TV-enabled listing.
Automotive screenshots are rejected	Wrong dimensions or vehicle-specific UI.	Use the required portrait and landscape sizes and generic system UI.
Localized listing looks inconsistent	One screenshot contains text in the wrong language.	Provide translated screenshot assets for each language with text overlays.
ScreenshotNeo response is not an image	The page failed, timed out, triggered a bot check, or returned a blank page.	Inspect `X-Page-Verdict` and `X-Billed`, then adjust waits, headers, cookies, user agent, or blocking options.

8. Performance, reliability, and cost notes

Capture only the states you need; a focused set is easier to review and localize.
Use the same release candidate and deterministic test data for every device set.
Keep source captures and exported files versioned so you can reproduce a listing after a UI change.
For web captures, wait for a selector or network idle when content loads asynchronously. Use caching with a chosen TTL for unchanged pages.
ScreenshotNeo bills only clean shots. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed.
ScreenshotNeo pricing is Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free.

FAQ

How many screenshots should a phone listing have?

Google’s baseline is at least two screenshots across different device types. For recommendation eligibility, apps are guided toward at least four high-resolution images; choose the number that explains your app without repeating screens.

Can I use marketing graphics instead of app screens?

Use the real UI prominently, especially in the first three images. Small explanatory taglines are allowed, but avoid claims, pricing, testimonials, awards, and download calls to action.

Do I need a physical Android phone?

No. An emulator or another capture workflow can be suitable. A physical device is useful when you need to inspect hardware-specific rendering.

Do screenshots apply to every test track?

Assets in the Main store listing can appear across test tracks and on Play surfaces beyond the app detail page.

Can ScreenshotNeo capture my native Android app?

No. ScreenshotNeo captures web pages. Use an emulator or device for native app UI, and use ScreenshotNeo for related web pages, documentation, or release assets.