Prepare Google Play screenshots: a device review checklist

Editorial diagram · illustrative, not a store screenshot.

Do not mix up the assets

A screenshot shows the experience of using your app. A feature graphic is a separate promotional image with its own specifications; a preview video is a different format again. Renaming a screenshot as a feature graphic does not make it compliant. Make an asset inventory with separate entries for each role, supported device and language.

Google labels rules as requirements or highly recommended guidance. The former are mandatory. The latter can affect recommendation or promotional eligibility without being the same as the baseline listing requirements. Keep two review columns so that an attractive promotional design does not conceal a missing required asset.

Build your Android reference shortlist with Snaps

Start with the Android app screenshot library, then use the Android screenshot wall to compare how publishers explain features. Keep phone and tablet observations separate. A listing on Snaps is inspiration, not evidence that your own files meet Google Play’s current requirements.

Check the baseline, then the device section

Google’s preview-assets guidance (linked below), under Screenshots → Content guidelines → Requirements, specifies a minimum of two screenshots across device types to publish, JPEG or 24-bit PNG without alpha, and additional dimensional constraints. Its Screenshots introduction permits up to eight per supported device type. These are source rules, not our design recommendations. This checklist does not reproduce the full dimensional matrix: copy applicable dimensions, ratios and counts from the live device section into your upload record.

For phone exports, verify the current dimensional and aspect-ratio rules directly in the screenshot section of the official guidance. Record what is mandatory separately from recommended portrait or landscape treatments. A file accepted by the uploader is not evidence that it meets every policy or is eligible for every promotional placement.

Phone artwork does not fit every surface

Our editorial recommendation is to review tablets and Chromebooks separately and show the real large-screen layout instead of stretching a phone composition. Google’s preview-assets guidance, under Screenshots → Large screens, says to exclude additional text outside the core app experience because it can be cut off on Play homepages on certain screen sizes. Preserve that placement-specific context rather than turning it into a ban on all screenshot text.

Google’s Screenshots → Wear OS section requires interface-only screenshots without device frames or extra text, graphics or backgrounds outside the app interface. Do not generalize this watch-specific rule to phones. Android TV, Android Automotive OS and Android XR have their own sections in the same source. Automotive screenshot obligations depend on category; where supplied, screenshots must depict generic system UI rather than an individual vehicle model or OEM. Read the complete applicable device section before deciding what to export.

Review the story and accessibility

For each screenshot, name the capability a first-time visitor should understand and identify the visible evidence for it. Prefer actual interface or gameplay over a claim that the image does not substantiate. Avoid borrowed awards, ranking badges or promotional language that conflicts with Google’s content guidance.

Review screenshots at listing scale, not just on a large design monitor. Check clipping and legibility in applicable orientations. In Google’s preview-assets guidance, the Screenshots → Highly recommended section advises alt text for each screenshot and keeping it to 140 characters or less. Treat that as accessibility guidance, not a baseline publication count rule. Describe the important visible content rather than repeating keywords. Have a target-language reader review the overlay and interface.

Worked device-review record

Hypothetical own-build worksheet: device phone; build demo-42; language en-US; asset role screenshot; file saved-route-phone.png; visible proof saved route and stop list. Required-rules column: format, pixel bounds, aspect constraint and count must be copied from Google’s current Screenshots requirements before approval. Device exceptions: check the phone section; do not borrow watch rules.

Editorial-review column: headline matches visible UI; no personal data; route labels readable at listing scale. Accessibility recommendation: alt text “Saved route with three stops and a save button.” Status: HOLD pending actual export metadata, source-rule comparison and Play Console preview. No upload or acceptance is implied by this completed planning record.

Build a device-by-device upload checklist

For every supported device type, record the source build, language, export format, accepted size and required asset count from the official page. Upload to the correct device section under Graphics in the Main store listing. Inspect sequence, cropping and the relationship between video and screenshots in the listing preview.

Keep a clear distinction between policy, your observation of other apps, and a design hypothesis. Snaps can help you browse Android screenshot references, but it does not validate Play Console uploads, create assets or prove that a competitor’s treatment complies with current policy.

Sources & further reading

Editorial revision dated 21 October 2026. Apple screenshot specifications and Google Play preview-assets guidance were retrieved directly for this revision; other linked editorial and legal pages were not reverified. This is not a complete specification matrix or a report of an upload test. Requirements can change; confirm the current source before upload.