Android App Rejection Reasons, Including Android TV

You spent weeks building your Android app. You went through the 50+ fields in the Play Console setup. You hit "Submit for Review." And then you got the email every developer dreads: your app has been rejected. The rejection notice is vague, the appeal process is slow, and you're not sure what you did wrong. Here are the five most common reasons this happens, the separate quality review that rejects Android TV apps, and how to fix each one so your next submission goes through cleanly.

Why do Android apps get rejected from Google Play?

Google Play rejects Android apps most often for five reasons: a missing or inaccurate content rating, a Data safety form that does not match the app, a missing or non-compliant privacy policy, target audience and Families policy problems, and metadata policy violations. Android TV apps also face a separate quality review covering the launcher, hardware declarations, D-pad navigation and screenshots.

Can a missing or incorrect content rating get your Android app rejected?

Yes. Google Play does not allow apps without a content rating, and unrated apps are removed from the store. Misrepresenting your app's content in the IARC questionnaire can lead to removal or suspension. The fix is to answer every question accurately and submit a new questionnaire whenever a change to your content or features affects your answers.

Google requires every app to complete the content rating questionnaire, and the ratings themselves come from the International Age Rating Coalition (IARC). The rating determines the age label shown on your listing. The common mistakes are skipping the questionnaire, shading answers to get a lower rating, and forgetting to redo it after a feature change. Google's content ratings policy says that if you change your app's content or features in a way that affects your questionnaire answers, you must submit a new questionnaire in Play Console.

The fix: Answer every question based on what the app actually contains, including violence of any kind, user interaction features and in-app purchases where the questionnaire asks about them. If you've added features since your last rating, redo the questionnaire. An accurate rating that is "higher than you'd like" costs you nothing; Google's policy says misrepresentation may result in removal or suspension. Our walkthrough of the IARC content rating questionnaire goes through it question by question.

Why do Data Safety section inconsistencies get apps rejected?

Data safety inconsistencies get apps rejected because the form must describe everything your app collects and shares, including data handled by third-party SDKs. Google says that when it becomes aware of a discrepancy between your app's behavior and your declaration, it may take enforcement action. The fix is to audit every permission and SDK, then declare what they collect.

The Data safety section is one of the most misunderstood requirements. The classic mismatch is an app that requests location permission while its Data safety form says it collects no location data. Google's Play Console Help is explicit that developers are responsible for data "collected and handled through any third-party libraries or SDKs used in their apps," and that this collection must be reflected in the form.

The fix: Audit every permission in your app's manifest and every third-party SDK you include. Firebase, AdMob, analytics libraries: they all collect data. Your Data safety section needs to reflect everything, including what your dependencies do. If you're not sure what data an SDK collects, check its documentation or privacy policy.

Does every Google Play app need a privacy policy?

Yes. Google's User Data policy says all apps must post a privacy policy link in the designated field in Play Console and a privacy policy link or text inside the app. Play Console Help adds that even apps that collect no user data must provide one. The policy must live on an active, publicly accessible, non-geofenced URL, not a PDF.

The policy must also actually describe your app's data practices. Google lists what it has to cover: how the app accesses, collects, uses and shares user data; the types of personal and sensitive data involved; secure handling; your data retention and deletion policy; developer information with a privacy point of contact; and clear labeling as a privacy policy. The entity named in your store listing must also appear in the policy. A surprising number of rejections happen because the privacy policy link is broken, points to a placeholder page, or is missing entirely.

The fix: Write a privacy policy that specifically describes what data your app collects, why, and how it's used. Host it at a stable URL that won't go down. Make sure it names your app and the developer, and covers the specific data types declared in your Data safety section. A policy generated by a reputable tool can work, but it has to be accurate and specific to your app.

How do target audience settings get an app rejected?

If one of your declared target audiences is children, Google Play's Families policies apply. Those policies restrict ads to Families Self-Certified Ads SDKs, prohibit interest-based ads to children, and require COPPA compliance for your app and every SDK it calls. Developers often trigger them by selecting child age groups for an app that is really built for adults.

Google also warns that imagery and terminology that could be read as targeting children "may impact Google Play's assessment of your declared target audience," so an adult app with cartoon art and child-friendly copy can still get pulled into the Families review.

The fix: Be accurate about your target audience. If your app isn't designed for children, don't include child age groups. If it is designed for children, use only Families Self-Certified Ads SDKs to show ads to them, turn off interest-based advertising for those users, confirm every SDK you call is COPPA compliant, and make sure the app does not link to websites whose content violates Google Play's policies.

What metadata policy violations get an app rejected from Google Play?

Google Play rejects apps whose title, icon, developer name, description or screenshots break the Metadata policy. Common violations are ALL CAPS that isn't part of your brand, emojis in the title, repetitive or unrelated keywords, ranking claims like "#1", promotional text such as "free for limited time only", and screenshots that misrepresent the app.

Your app title, description, and graphics must all comply. The policy also rules out unattributed or anonymous user testimonials, Google Play program badges such as "Editor's choice" or "New", misleading symbols in icons (a fake notification dot, for example), and using a celebrity's name or a brand's logo without permission. Google sums up the rule as no "misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata."

The fix: Keep your title professional: capitalize normally, no ALL CAPS, no emojis, no repeated punctuation. Make sure screenshots and videos reflect the app's actual experience. Drop store-performance and price claims from your metadata. Write descriptions that use your keywords in natural sentences a human would want to read, because Google says excessive length, detail, improper formatting or repetition can itself violate the policy.

Why do Android TV apps get rejected from Google Play?

Android TV apps get rejected when they fail Google's TV app quality review. The usual causes are a missing leanback launcher intent or TV banner, a manifest that requires a touchscreen or other hardware TVs don't have, screens you can't navigate with a D-pad, phone or portrait-only layouts, and missing or unrepresentative TV screenshots in the store listing.

This is a separate gate from everything above. A phone app can be live and healthy on Google Play while its Android TV release is "Not approved." When you opt in to Android TV, Play Console Help says your app "will be reviewed against the Android TV quality guidelines," and those guidelines (Google's TV app quality page) set out a minimum "TV Ready" tier with numbered criteria. These are the ones that trip up apps ported from phones, with Google's criterion IDs in brackets so you can match them against a rejection email.

No leanback launcher intent or TV banner

Your manifest must declare an activity with an ACTION_MAIN intent and the CATEGORY_LEANBACK_LAUNCHER category (TV-ML). Google's TV setup guide is blunt about what happens without it: the app is "not visible to users running Google Play on TV devices." The app must also show a 320 x 180 pixel banner plus an app icon of at least 160 x 160 pixels at xhdpi in the TV launcher (TV-LB), and the banner must contain the app's name (TV-BN). You set it with the android:banner attribute on the <application> element.

<application android:banner="@drawable/banner" ...>
  <activity android:name=".TvActivity" ...>
    <intent-filter>
      <action android:name="android.intent.action.MAIN" />
      <category android:name="android.intent.category.LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

If the same app also runs on phones, declare android.software.leanback with android:required="false". Setting it to true makes Google Play offer the app only on Android TV devices.

Touchscreen and other hardware declared as required

The manifest must mark android.hardware.touchscreen, and the other features TVs don't support, as not required (TV-MT). Google's list of unsupported TV hardware covers the touchscreen, touchscreen emulation (faketouch), telephony, camera, NFC, GPS, microphone, sensors and portrait screen orientation. Google warns that declaring any of these as required "prevents your app from being installed on TV devices or appearing in the Android TV home screen launcher."

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
<uses-feature android:name="android.hardware.faketouch" android:required="false" />
<uses-feature android:name="android.hardware.telephony" android:required="false" />
<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.microphone" android:required="false" />

Screens you can't use with a D-pad

Everything in the app must be navigable with a five-way D-pad unless the app genuinely requires a game controller (TV-DP). Back must lead back to the Android TV home screen (TV-DB), and no control can depend on the remote having a Menu button (TV-DM). Ads count too: users must be able to interact with them by D-pad (TV-AP), and full-screen non-video ads must be dismissible immediately with the D-pad or a gamepad (TV-AD). In practice, test every screen with only the arrow keys, select and back on an emulator remote, and check that focus can reach every control and that you can always see which element has focus.

Phone layouts and portrait-only screens

A phone UI stretched onto a television fails several criteria at once. The app must support landscape without vertical letterboxing or pillarboxing (TV-LO), must not cut off text or controls at the screen edges (TV-OV), and must fill the whole screen with a non-transparent background (TV-TR). Web content has to stay inside a WebView; the app must not try to launch a browser (TV-WB). Google also lists portrait screen orientation among the features TVs don't support, so a portrait-locked activity cannot meet TV-LO.

Missing or unrepresentative TV screenshots

Play Console won't let you opt in to Android TV until you have uploaded Android TV screenshots for every store listing. The quality guidelines then require at least one "unaltered, high resolution screenshot that accurately depicts the current version of the TV app experience" (TV-G4), so reusing phone screenshots or mockups does not work. The store listing also needs an Android TV banner graphic, which Play Console Help specifies at 1280 x 720 pixels, separate from the 320 x 180 launcher banner. If the app needs a login, provide test credentials in Play Console's App access section (TV-G5). Our Google Play image asset specs covers the other listing graphics.

Media playback that ignores the remote

Media apps have their own criteria. Pressing the D-pad center button must pause and resume playback, and left and right must rewind and fast-forward (TV-PC). A play/pause key event must toggle playback (TV-PP). If audio keeps playing after the user goes home or switches apps, the app must provide media controls in the system UI, such as a Now Playing card (TV-NP). Video apps must not use those controls; video must pause when the user leaves the app. The app must keep the TV out of Ambient Mode during user-started video playback, and must not block Ambient Mode when nothing is playing (TV-BU, TV-BY).

How do you get an Android TV app approved in Play Console?

Upload TV screenshots for every store listing, then open Test and release, Advanced settings, choose the Form factors tab, add Android TV, and opt in while agreeing to the review policy. Releases then go through a dedicated Android TV track. Google reviews the app against the TV quality guidelines and emails you if it falls short.

Google's TV distribution guide lists three review states: Pending while review is underway, Approved once the app is discoverable to Android TV users, and Not approved. If the app is not approved, the notification email sent to your developer account address summarizes the areas you need to address. Fix those, upload a new version, and it goes back into review. The same guide also asks you to mention "Android TV" in your app's description.

Because the TV review runs against a published checklist, the fastest path is to self-audit before you opt in: go through every Tier 3 "TV Ready" criterion on Google's TV app quality page, test on an Android TV emulator with only the remote, and capture fresh screenshots from that build. Expect the usual review wait on top; our guide to how long Google Play app review takes covers the timing.

How to prevent rejections before they happen

The best fix for a rejection is never getting one. IOn Emit's 8-step Pre-Flight Wizard walks you through the Play Console declarations, including content ratings, data safety, privacy policy, target audience and declarations, in plain English. The AAB analyzer maps your app's permissions to data safety categories so you cannot accidentally miss one, and pre-publish validation runs before you submit.

The Pre-Flight Wizard and pre-publish validation are in IOn Emit's free tier. They cover the store listing and policy forms; the Android TV criteria above are about your app's manifest, layouts and input handling, so work through Google's TV checklist in your own build before you opt in.

This post is part of our app publishing guides for indie Android developers.

Why Your Android App Got Rejected (Android TV Included, and How to Fix Each One)