Quick answer
Before your first Google Play submission, prepare accurate listing text, a support contact, an app icon, a feature graphic, and screenshots that match the current app. The icon and feature graphic are mandatory, and Google also requires screenshots. Check the exported files before opening Play Console, then compare every claim and image with the build you are submitting.
Start with the publish blockers
Don't begin with decoration. Begin with the assets that can stop the listing from being ready.
I checked Google's official preview asset requirements before copying any specification into this checklist. Google separates mandatory requirements from highly recommended guidance, and that distinction matters. A required item can block publication or create a policy problem. A recommendation can affect presentation or promotional eligibility without blocking the basic listing.
Your first folder should contain the final app icon, the final feature graphic, and screenshots taken from the build you intend to submit. Keep editable design files elsewhere. Play Console needs exported files, not your canvas, layers, or a link that somebody still has to open.
Then prepare the text and contact information. You'll need the app name, short description, full description, and support email. None of those should be placeholder copy. It isn't enough that the words sound polished. They must describe what the submitted app actually does.
This is a listing check, not a release check. Your bundle, testing, declarations, and policy forms still need their own review. Mixing every launch task into one giant list makes it easier to miss the small image error sitting right in front of you.
I checked Google's official preview asset requirements before copying any specification into this checklist. Google separates mandatory requirements from highly recommended guidance, and that distinction matters. A required item can block publication or create a policy problem. A recommendation can affect presentation or promotional eligibility without blocking the basic listing.
Your first folder should contain the final app icon, the final feature graphic, and screenshots taken from the build you intend to submit. Keep editable design files elsewhere. Play Console needs exported files, not your canvas, layers, or a link that somebody still has to open.
Then prepare the text and contact information. You'll need the app name, short description, full description, and support email. None of those should be placeholder copy. It isn't enough that the words sound polished. They must describe what the submitted app actually does.
This is a listing check, not a release check. Your bundle, testing, declarations, and policy forms still need their own review. Mixing every launch task into one giant list makes it easier to miss the small image error sitting right in front of you.
Lock the listing text before the artwork
Words drive the art. If the core promise changes after the screenshots are designed, every caption and visual order may need another pass.
I read Google's official app setup help page too. It gives the current field limits as 30 characters for the app name, 80 characters for the short description, and 4000 characters for the full description. Those limits are firm. Write inside them from the start rather than cutting copy in the upload form.
The app name should be the name users will see. Don't pack it with unrelated search phrases. Google's page warns that repetitive or irrelevant keyword use can create an unpleasant experience and may lead to suspension. A clear name is safer than a stuffed one.
Your short description has a different job. It should state the app's core purpose in plain language, since Google says it is the first text people see on the Play Store detail page. It can be expanded into the full description, so it doesn't need to carry every feature. Keep it focused.
The full description can explain the product in more depth, but accuracy still wins. Don't promise a feature that exists only on a roadmap. Don't describe a paid capability as included when it isn't. And don't leave launch language in place after the launch has passed.
Read the text beside the screenshots. Repeated claims waste space. If the short description and first screenshot say exactly the same thing, one of them isn't helping. Give each asset a role, while keeping the underlying promise consistent.
I read Google's official app setup help page too. It gives the current field limits as 30 characters for the app name, 80 characters for the short description, and 4000 characters for the full description. Those limits are firm. Write inside them from the start rather than cutting copy in the upload form.
The app name should be the name users will see. Don't pack it with unrelated search phrases. Google's page warns that repetitive or irrelevant keyword use can create an unpleasant experience and may lead to suspension. A clear name is safer than a stuffed one.
Your short description has a different job. It should state the app's core purpose in plain language, since Google says it is the first text people see on the Play Store detail page. It can be expanded into the full description, so it doesn't need to carry every feature. Keep it focused.
The full description can explain the product in more depth, but accuracy still wins. Don't promise a feature that exists only on a roadmap. Don't describe a paid capability as included when it isn't. And don't leave launch language in place after the launch has passed.
Read the text beside the screenshots. Repeated claims waste space. If the short description and first screenshot say exactly the same thing, one of them isn't helping. Give each asset a role, while keeping the underlying promise consistent.
Prepare the icon as its own file
The store icon isn't the launcher file copied without inspection. Google describes it as a higher resolution version that follows Play icon specifications.
For the listing, Google requires a 32 bit PNG with alpha, sized at 512 by 512 pixels, with a maximum file size of 1024 KB. The same official preview asset page also says the icon must not contain badges or text that suggests ranking, price, Google Play categories, or anything else that misleads people.
Check the exported PNG itself. Open its properties and confirm the dimensions. Then view it against more than one background, since transparency can reveal an edge or stray pixel that wasn't visible on the design canvas. It shouldn't look like a screenshot squeezed into a square.
Keep tiny copy out. Even if it technically fits, the icon appears in places where detail becomes difficult to read. A simple focal shape has a better chance of remaining recognizable, but treat that as design advice rather than a Google acceptance rule. The technical file can pass while the design still feels crowded.
Don't add a Play badge. Don't add a price. Don't add a ranking claim. Those aren't harmless flourishes, because Google's requirements specifically call out misleading ranking and price signals.
Name the exported file clearly for your own handoff. The filename doesn't sell the app, but a clear name helps your team upload the approved icon instead of an old draft with nearly identical artwork.
For the listing, Google requires a 32 bit PNG with alpha, sized at 512 by 512 pixels, with a maximum file size of 1024 KB. The same official preview asset page also says the icon must not contain badges or text that suggests ranking, price, Google Play categories, or anything else that misleads people.
Check the exported PNG itself. Open its properties and confirm the dimensions. Then view it against more than one background, since transparency can reveal an edge or stray pixel that wasn't visible on the design canvas. It shouldn't look like a screenshot squeezed into a square.
Keep tiny copy out. Even if it technically fits, the icon appears in places where detail becomes difficult to read. A simple focal shape has a better chance of remaining recognizable, but treat that as design advice rather than a Google acceptance rule. The technical file can pass while the design still feels crowded.
Don't add a Play badge. Don't add a price. Don't add a ranking claim. Those aren't harmless flourishes, because Google's requirements specifically call out misleading ranking and price signals.
Name the exported file clearly for your own handoff. The filename doesn't sell the app, but a clear name helps your team upload the approved icon instead of an old draft with nearly identical artwork.
Build the required feature graphic
This one gets missed. Google says you must provide a feature graphic to publish the store listing.
The required canvas is 1024 by 500 pixels. Google accepts JPEG or 24 bit PNG with no alpha. That's a different PNG rule from the app icon, so don't assume one export preset fits both assets. The icon permits alpha. The feature graphic doesn't.
Keep the focal idea near the center. Google explains that feature graphics can appear as a preview video cover and in larger collections, where crops or interface overlays may change what remains visible. Essential copy near an edge can disappear even when the original file looks balanced.
Use broad background elements near the outside. Put the subject where it can survive a crop. If a play control would cover the only important detail, move that detail rather than hoping the graphic always appears without an overlay.
Avoid price language, ranking claims, testimonials, awards, store badges, and time sensitive promotions. Google's guidance calls out those categories. A sale message also creates maintenance work because it becomes false as soon as the offer ends.
The feature graphic guide goes deeper into the canvas and crop problem. For this checklist, the gate is simpler. Confirm the exact dimensions, approved format, opaque export, central focal point, and accurate message before the asset enters the upload folder.
The required canvas is 1024 by 500 pixels. Google accepts JPEG or 24 bit PNG with no alpha. That's a different PNG rule from the app icon, so don't assume one export preset fits both assets. The icon permits alpha. The feature graphic doesn't.
Keep the focal idea near the center. Google explains that feature graphics can appear as a preview video cover and in larger collections, where crops or interface overlays may change what remains visible. Essential copy near an edge can disappear even when the original file looks balanced.
Use broad background elements near the outside. Put the subject where it can survive a crop. If a play control would cover the only important detail, move that detail rather than hoping the graphic always appears without an overlay.
Avoid price language, ranking claims, testimonials, awards, store badges, and time sensitive promotions. Google's guidance calls out those categories. A sale message also creates maintenance work because it becomes false as soon as the offer ends.
The feature graphic guide goes deeper into the canvas and crop problem. For this checklist, the gate is simpler. Confirm the exact dimensions, approved format, opaque export, central focal point, and accurate message before the asset enters the upload folder.
Choose screenshots that prove the app
Google requires a minimum of two screenshots across device types to publish the listing. Each screenshot must be JPEG or 24 bit PNG with no alpha. The minimum dimension is 320 pixels, the maximum is 3840 pixels, and the longest dimension can't be more than twice the shortest.
Those are acceptance rules from the official preview asset page. They aren't a reason to upload the smallest file that passes. Your images still need to show the interface clearly on the devices you support.
Use current app screens. Google recommends captured footage of the app or game itself, focused on core features and content, so people can anticipate the experience. A concept screen that never appears in the app creates the wrong expectation. A stale screen does the same thing more quietly.
Clean the status area. Google's guidance says not to show service providers or notifications, and it recommends full battery, WiFi, and cell service symbols. The clean capture guide covers that preparation without mixing it into the design stage.
Device categories need honest assets. A phone screenshot stretched into a tablet canvas doesn't demonstrate a tablet experience. If you support another form factor, capture the app on that form factor and review its specific section in Play Console. Don't infer one device rule from another.
Finally, compare every screenshot with the submitted build. Buttons, labels, navigation, and available features should line up. If somebody installs the app and can't find the screen you advertised, the listing has failed even if every pixel passed validation.
Those are acceptance rules from the official preview asset page. They aren't a reason to upload the smallest file that passes. Your images still need to show the interface clearly on the devices you support.
Use current app screens. Google recommends captured footage of the app or game itself, focused on core features and content, so people can anticipate the experience. A concept screen that never appears in the app creates the wrong expectation. A stale screen does the same thing more quietly.
Clean the status area. Google's guidance says not to show service providers or notifications, and it recommends full battery, WiFi, and cell service symbols. The clean capture guide covers that preparation without mixing it into the design stage.
Device categories need honest assets. A phone screenshot stretched into a tablet canvas doesn't demonstrate a tablet experience. If you support another form factor, capture the app on that form factor and review its specific section in Play Console. Don't infer one device rule from another.
Finally, compare every screenshot with the submitted build. Buttons, labels, navigation, and available features should line up. If somebody installs the app and can't find the screen you advertised, the listing has failed even if every pixel passed validation.
Treat the preview video as optional
A preview video isn't required for a basic listing. Don't let an unfinished video delay a complete set of mandatory assets.
Google allows one regular preview video by adding a YouTube URL to the listing. The URL must point to a video, not a channel or playlist, and Google says not to add extra parameters such as timecodes. The video must be public or unlisted, not private, and it can't be age restricted. Ads also need to be disabled for the video to appear on Google Play.
That's enough configuration to justify a separate check. Open the URL in a signed out browser. Confirm the right upload loads, the thumbnail is intentional, and the video represents the current app. If it relies on an internal account or a private permission, shoppers won't see the experience you expected.
The feature graphic may act as the cover, with a play control over it. Review those assets together. A good video with a confusing cover still creates a weak first frame.
Skip the video if it isn't ready. You can publish a listing without one, while a rushed video can show old interface, stale claims, or material you don't have permission to use. Optional doesn't mean unimportant. It means the listing shouldn't depend on it to explain the core product.
Screenshots need to stand alone. If the only clear demonstration lives in the video, people who don't play it are left guessing.
Google allows one regular preview video by adding a YouTube URL to the listing. The URL must point to a video, not a channel or playlist, and Google says not to add extra parameters such as timecodes. The video must be public or unlisted, not private, and it can't be age restricted. Ads also need to be disabled for the video to appear on Google Play.
That's enough configuration to justify a separate check. Open the URL in a signed out browser. Confirm the right upload loads, the thumbnail is intentional, and the video represents the current app. If it relies on an internal account or a private permission, shoppers won't see the experience you expected.
The feature graphic may act as the cover, with a play control over it. Review those assets together. A good video with a confusing cover still creates a weak first frame.
Skip the video if it isn't ready. You can publish a listing without one, while a rushed video can show old interface, stale claims, or material you don't have permission to use. Optional doesn't mean unimportant. It means the listing shouldn't depend on it to explain the core product.
Screenshots need to stand alone. If the only clear demonstration lives in the video, people who don't play it are left guessing.
Check ownership, privacy, and support
Asset review isn't only about dimensions. It is also a rights and privacy check.
Confirm that you can use every logo, illustration, font, photograph, and character in the listing. A file downloaded from the web isn't automatically licensed for store marketing. If the proof is unclear, replace the asset before submission.
Use fictional account data in screenshots. Real names, email addresses, messages, locations, payment details, and profile photos don't belong in a public store image unless you have a valid reason and permission, and a launch checklist isn't the place to debate that risk. Use controlled sample content.
Check your support contact. Google's app setup page says a contact email address is required and explains that the information is shown on the listing. Send a test message to it. Make sure the inbox is monitored and the address matches the support identity users will recognize.
Review claims again. If a screenshot says the app works offline, verify that the pictured action really does. If the description calls a feature included, make sure a payment screen doesn't appear first. Accuracy isn't a tone choice. It is part of the store relationship.
Keep approvals visible inside your team. The person uploading shouldn't have to guess which icon, graphic, or screenshot set received legal and product review. A simple approved folder prevents the wrong draft from becoming public.
Confirm that you can use every logo, illustration, font, photograph, and character in the listing. A file downloaded from the web isn't automatically licensed for store marketing. If the proof is unclear, replace the asset before submission.
Use fictional account data in screenshots. Real names, email addresses, messages, locations, payment details, and profile photos don't belong in a public store image unless you have a valid reason and permission, and a launch checklist isn't the place to debate that risk. Use controlled sample content.
Check your support contact. Google's app setup page says a contact email address is required and explains that the information is shown on the listing. Send a test message to it. Make sure the inbox is monitored and the address matches the support identity users will recognize.
Review claims again. If a screenshot says the app works offline, verify that the pictured action really does. If the description calls a feature included, make sure a payment screen doesn't appear first. Accuracy isn't a tone choice. It is part of the store relationship.
Keep approvals visible inside your team. The person uploading shouldn't have to guess which icon, graphic, or screenshot set received legal and product review. A simple approved folder prevents the wrong draft from becoming public.
Make the upload folder boring
Boring is good here. The final folder should contain only files that can be uploaded.
Separate source designs from exports. Remove abandoned variants, temporary crops, and files called final that aren't final. Use names that identify the asset and device category without relying on memory. Then open every export once.
Check the icon dimensions and file size. Check the feature graphic dimensions, format, and alpha setting. Check screenshot dimensions, orientation, and current interface. Open every external video link. Read the listing text in a plain document so formatting doesn't hide a typo.
Then compare the folder against Play Console section by section. Don't upload while assets are still arriving in chat messages. Don't resize inside a random image viewer at the last moment. And don't assume that a green upload state proves the marketing claim is accurate.
If you need to compose screenshots, the Play Store size guide lists the current Android image rules. PlayMockUp publishes this post and operates the linked tool, so this is a self recommendation rather than an independent review. The tool can be useful for framing and exporting, but the checklist still belongs to you.
One final practical move helps. Ask somebody who didn't make the assets to compare the folder with the app. They don't need to judge the design. They only need to spot a missing file, stale screen, unreadable label, or claim that the build doesn't support.
Separate source designs from exports. Remove abandoned variants, temporary crops, and files called final that aren't final. Use names that identify the asset and device category without relying on memory. Then open every export once.
Check the icon dimensions and file size. Check the feature graphic dimensions, format, and alpha setting. Check screenshot dimensions, orientation, and current interface. Open every external video link. Read the listing text in a plain document so formatting doesn't hide a typo.
Then compare the folder against Play Console section by section. Don't upload while assets are still arriving in chat messages. Don't resize inside a random image viewer at the last moment. And don't assume that a green upload state proves the marketing claim is accurate.
If you need to compose screenshots, the Play Store size guide lists the current Android image rules. PlayMockUp publishes this post and operates the linked tool, so this is a self recommendation rather than an independent review. The tool can be useful for framing and exporting, but the checklist still belongs to you.
One final practical move helps. Ask somebody who didn't make the assets to compare the folder with the app. They don't need to judge the design. They only need to spot a missing file, stale screen, unreadable label, or claim that the build doesn't support.
Frequently asked questions
What assets are required for a first Google Play listing?
Google requires listing text, a support email, an app icon, a feature graphic, and screenshots. A preview video is optional. Your policy forms, declarations, and release bundle are separate submission work.
How many screenshots does Google Play require?
Google requires a minimum of two screenshots across device types for publication. The official preview asset page provides separate guidance for additional device categories and promotional eligibility.
Is a Google Play feature graphic optional?
No. Google states that the feature graphic is required to publish the store listing. It must be 1024 by 500 pixels and supplied as JPEG or 24 bit PNG with no alpha.
Can I add a preview video later?
Yes. The regular preview video is optional, so it shouldn't block a complete first listing. When you add one, use a public or unlisted YouTube video that meets Google's current requirements.
Where can I prepare store sized screenshot mockups?
You can use [the PlayMockUp studio](/create) to frame and export screenshots. PlayMockUp publishes this guide and operates that tool, so treat the link as a disclosed self recommendation.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.