Google Play Broken Functionality Rejection: What to Check First

A Broken Functionality notice means the release Google reviewed did not work: it crashed, force closed, froze, would not load, or loaded and did not respond. It is a decision about one release, not a strike against your account, and the last version you successfully published usually stays live while you fix it. The notice is short, so the work is finding what the reviewer found. Three checks narrow down almost every case: test the build Google Play actually distributes, confirm a reviewer can get past your login, then read the pre-launch report and Android vitals before you resubmit. This guide covers what the policy sentence really prohibits, what Play Console does and does not tell you about the failure, each of the three checks in order, and the resubmission step most developers get wrong.

What does a Broken Functionality rejection actually mean?

Broken Functionality is the second section of Google's Functionality, Content, and User Experience policy. The rule itself is one sentence, and it is worth reading exactly as Google wrote it: "We don't allow apps that crash, force close, freeze, or otherwise function abnormally." (source) Under it, Google lists three named examples of common violations. Most notices name one of those three as the issue, so identify which one before you change any code. When a notice does not name one, the three checks below are how you narrow it down.

Example Google names	What the reviewer likely hit	Where you find it
Apps that don't install	The download fails on the reviewer's device: a native library the device cannot load, a missing feature split, a target API level Play now refuses	Release errors in Play Console, then your build configuration
Apps that install, but don't load	The first screen hangs: a splash screen waiting on an API call, an auth token, a remote config fetch or a server that is down or unreachable	Pre-launch report, then a clean install with the network off
Apps that load, but are not responsive	Screens render but taps do nothing: a button wired to a broken flow, an empty list with no explanation, an interface that picked the wrong layout for the device	Manual pass on a real device, every visible control, every empty state

The second section of the same policy, Limited Functionality and Content, is a different problem with the opposite fix: it covers apps that work exactly as built but offer too little purpose, such as static text or PDF apps, single wallpaper apps, or apps designed to do nothing. If your notice cites that section instead, bug fixes will not answer it. Older help links and forum threads still call it Minimum Functionality; the current section name is Limited Functionality and Content. Both sit on the same policy page, so read which section your notice names first.

Equally important is what a rejection is not. Google's Play Console help states plainly that rejections "Don't impact the standing of your Google Play Developer account" (source), and that when an update is rejected "the last version that you successfully published is still available on Google Play" (source). A rejection is a release-level decision. Suspension is the account-level decision, and only suspension counts as a strike.

Decision	Effect on your app	Effect on account standing	What you do next
Rejected	Last successfully published version stays available	No impact	Fix and resubmit this release
Removed	Unavailable until a compliant update is submitted	No immediate impact, though multiple removals may result in suspension	Fix and submit a compliant update
Suspended	Not available on Google Play	Counts as a strike	Fix, then decide between appeal and a new compliant release
Warning	Removed after the number of days in the warning email	No impact	Fix before the stated date
Production access refused	Not a policy notice about your code at all: Google decides your closed test needs more testing	No impact	Different process, different fix, covered in our analysis of production access rejections

Where a submission can be stopped, and how often each stage fires, is mapped in our breakdown of the Google Play rejection rate, using Google's published transparency counts.

Where does Google show what was broken?

Start with the enforcement email, then open Policy status in Play Console (Policy status in the left menu of the affected app). Google's help page says Policy status "shows any active enforcement against your app, such as rejection, removal, or suspension" and that "It also provides any additional information that's available, so that you can address the issues that violated Google Play policies" (source). Notice the wording: any additional information that is available, not a guaranteed diagnosis.

Google does not document a promise of a stack trace, a device list, or a screenshot with this decision. Developers documenting their own notices do report receiving them. One developer rejected for "Unresponsive UI elements, such as buttons or icons" describes four attached screenshots that never named the control in question, and a notice pasted in the Play Console Help Community reads "In-app experience: Please see attached screenshot". Those are reports of what those developers received, not a Google guarantee about what you will receive. Treat a screenshot as a bonus, never as the thing you are waiting for, and if none arrives or none pinpoints the screen, the three checks below do not depend on it.

Two things Google states outright: until the violation is fixed, "don't republish a rejected or removed app", and a rejected update leaves your previously published version live, so your existing users keep working while you fix the new release.

Check 1: Test the build Google Play actually distributes

Start with the binary itself, because the app on your phone and the app the reviewer installed are not the same artifact. Yours is a debug or locally signed build installed over your existing data, signed with your upload or debug key. Theirs is a release build from your app bundle, signed by Google with your app signing key, installed on a device that has never seen your app, with no account, no cached session and no permissions granted.

Play App Signing creates a specific trap for sign-in and API calls. Google documents it directly: "Because Google signs the final APK, you must register the Google-held app signing key fingerprint with your API providers, not just your local upload key" (source). If your OAuth client, Maps key or third-party SDK only accepts the fingerprint from your machine, sign-in silently fails in exactly the build the reviewer installs: the app loads, the login screen appears, and nothing happens after that. The fix is in Play Console under Protected with Play, Play Store distribution, Go to Play app signing, where the App signing key section lists the SHA-1 and SHA-256 fingerprints to paste into your API provider's console. The same page notes you should update your assetlinks.json file with those fingerprints if you use Android App Links.

Once the fingerprints are right, get the real build onto a device. Google's own guidance for this is short: "Use Internal App Sharing to test exactly what Google Play will deliver to users", or download device-specific APKs from the app bundle explorer and install them locally (source). Then test it as a reviewer would: fresh install, new or wiped account, permissions denied first, no cached session, network toggled off on the way in.

The patterns we can speak to come from our own records. Based on our analysis of more than 1,500 closed-testing campaigns run on real Samsung, Pixel, Xiaomi and OnePlus devices, on Android 11 through 15 in over 80 countries, the failures that surface in the first minutes on a clean install are first-run failures rather than deep feature bugs: a splash screen waiting for a call that never returns, an empty state with no message, a login that only works with data already on the device, a control that does nothing on a screen the tester has never opened. We do not sit in Google's review sessions, so this is our testing record, not data about Google's decisions. The practical conclusion is the same either way: run the first five minutes on a clean install before you test anything deeper.

Two install failures deserve their own mention because they stop the app before a single screen renders. Native libraries built only for 4 KB memory pages fail to load on a device that uses 16 KB pages, and Google requires apps targeting Android 15 (API level 35) and higher to support 16 KB memory page sizes on 64-bit devices, as covered in our guide to finding the failing .so file. Separately, Play requires a target API level of 36 or higher for submission, so a stale target SDK produces a submission or availability error before review even starts: see how to fix the target API level error.

Check 2: Make sure a reviewer can get past your login

Google makes this an obligation, not a favour: "If your entire app or parts of your app are restricted based on login credentials, sign in details, memberships, location, or other forms of authentication, you must provide all required details to enable access to your app" (source). A reviewer who cannot get past your login will record whatever they can see: a stuck screen, an error page, a control that does nothing. That becomes a Broken Functionality finding.

Where it goes: Play Console, then Policy and programs, then App content, then Sign-in details. Select Start, or Manage if you added instructions before, then Add new instructions and enter the access details. Google's page flags the field that matters most: "Use the 'Any other instructions' field to let us know if there's anything special about your login mechanisms, such as using a one-time password, multi-factor authentication, or logins with more than two fields." You can add up to five sets of instructions (source).

What counts as access that actually works during a review:

• A reusable account, not a single-use invite or a trial that expires mid-review.
• A path that survives one-time codes and two-step verification, because the reviewer cannot receive the code sent to your phone. Support Sign-in with Google, or give an account whose second factor you can control.
• Access that works from any location if you restrict by region, and access to the gated features the reviewer needs to see without being charged.
• Instructions kept current in English, updated whenever your login flow changes.

Send the change when you are done. After saving Sign-in details, the update sits in the Publishing overview page under Changes ready to send for review until you select Send for review. An instruction set you never sent is one the reviewer never sees (source).

Check 3: Read the pre-launch report and Android vitals before resubmitting

The pre-launch report is Google's own automated look at your bundle, and it is the closest thing to a preview of the reviewer's session. Google's help page explains the mechanism: after you upload an app bundle or save a release to the production track, Google installs it on devices in its test lab, then "automatically launch and crawl your app for several minutes. The crawler performs basic actions such as typing, tapping, and swiping" (source). It tests stability, Android compatibility, performance and accessibility, and the Details tab gives you stack traces and screenshots from real devices. Provide test-account credentials on the pre-launch report settings page so the crawler can get behind your login.

One documented limitation matters more than the rest. If your app is not in an open test and has no active bundle published to production, Google states that "your app will fail the licensing check. You'll still receive pre-launch report results, but your app will be in an unlicensed state" (source). In other words, an app that has never been published and sits in no open test runs the report unlicensed, so licensed features can fail inside the report even when they work everywhere else. Read the stability results with that caveat in mind and fix what it does surface. Our longer walkthrough covers how to read the pre-launch report properly.

Then check Android vitals, which tells you what your existing users hit rather than what one reviewer hit. Google defines bad behaviour thresholds and states that "If your app exceeds these thresholds, it's likely to be less discoverable on Google Play. In some cases, a warning could be shown on your app's store listing to set user expectations" (source). The stability thresholds published on that page:

Metric	Overall bad behaviour	Per single device model
User-perceived crash rate	At least 1.09% of daily users, across all device models	At least 8%
User-perceived ANR rate	At least 0.47% of daily active users, across all device models	At least 8%

Google also defines what hitting the threshold means, and it is worth quoting because it is not a penalty: a metric at or above the threshold puts the app "in the bottom 25% of the top 1,000 apps on Google Play (by number of installs)". Google documents that outcome as a discoverability and store-listing matter, which is separate from the release review that produced this notice. A crash cluster concentrated on a device model you never tested is still worth fixing before you resubmit, because your reviewer's device is one you have not seen. Our Android vitals guide explains which numbers are core vitals and what to fix first.

Fix every track, then resubmit correctly

Google's resubmission instructions contain one step that silently fails if you skip it. The sequence from Play Console help (source):

1. Read the policy named in the enforcement message, and check the Notifications section of Play Console as well as your email.
2. Check your app against the other policies too. Google warns that "Additional enforcement could occur if there are further policy violations."
3. Make the change and "update all release types in addition to your production release (for example, the open, closed, and internal test track releases)."
4. Upload the compliant bundle to every affected track and deactivate the non-compliant bundles. This is the step that breaks resubmissions: "If you fail to deactivate the non-compliant app bundle(s), your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play."
5. Open Manage track, create a new release, keep the non-compliant version under the Not included section, save, review the release, and roll it out to 100%. Repeat on each track where the old bundle is still live.

Google adds its own warning about republishing: "Until a policy violation has been fixed, don't republish a rejected or removed app." Resubmitting the same broken bundle with a new release name changes nothing about the app itself.

For a rejection, the sequence above is the documented route: you fix the app and send it back yourself. Google documents an appeal for the heavier decisions, where it says "You may submit one appeal per app removal, suspension, or other enforcement action", and it is one attempt, not a conversation. Google also notes it can only respond to appeals in Chinese, English, Japanese and Korean. Spend an appeal when your own testing shows the build works and the notice describes something you cannot reproduce; otherwise fix, resubmit and let the review do its job. For the mechanics, see how to appeal a Play decision, and for how account-level enforcement differs, why apps get suspended, reason by reason. If your real question is timing, our review timing analysis covers how long the second look usually takes.

How to stop the next Broken Functionality rejection

None of the checks above are exotic. They are the same pass to run before every release, in the order that catches the most failures per minute:

• Install the release build from your app bundle on a device you have wiped, or through Internal App Sharing, once per release. Not the debug build.
• Confirm your app signing key fingerprints are registered with every API provider you depend on, right after you enable Play App Signing and after any key change.
• Walk every visible control and every empty state on a clean install. A list with no items needs a sentence and a next action, not a blank rectangle.
• Cold-start with the network off. If the splash screen hangs instead of explaining itself, you have reproduced the reviewer's finding on your own desk.
• Keep Sign-in details current, and press Send for review after you change them.
• Read the pre-launch report for every new bundle, and watch your crash and ANR rates against the thresholds above.

The cheapest place to run this pass is before submission, with real testers on real devices rather than your own phone. That is what our closed testing service does: matched testers on physical devices, with the failure reports you need to fix the release rather than guess at it.

Frequently Asked Questions

Is a Broken Functionality rejection a strike on my developer account?

No. Google states that rejections "Don't impact the standing of your Google Play Developer account", while suspensions "Count as strikes against the good standing of your Google Play Developer account". A rejection is a decision about one release, your last published version usually stays live, and repeated rejections or removals are what can eventually escalate to a suspension.

Is Broken Functionality the same as Minimum Functionality?

No. They are two sections of the same policy with opposite fixes. Broken Functionality means the release did not work as submitted: it crashed, froze, would not install, or would not respond. Limited Functionality and Content, the name older help links still call Minimum Functionality, means the app works but offers too little purpose or content. Fixing bugs will not answer a Limited Functionality notice, and adding content will not answer a Broken Functionality one.

Does Google tell me which screen or button broke?

Not as a rule. Google's own wording is only that Policy status provides "any additional information that's available". What developers report receiving varies: one described an issue line such as "Unresponsive UI elements, such as buttons or icons" with four attached screenshots, none of which named the control involved. Build your diagnosis on the three checks here rather than waiting for a precise pointer that may never arrive.

My app works fine on my phone but failed review. Why?

Because the reviewer installed a different binary in a different state. Your build is signed with your upload or debug key over existing data; theirs is a release bundle signed by Google, on a clean device, with no account and no cached session. The two most common culprits are API providers still holding only your upload key fingerprint, so sign-in fails in the store build, and first-run screens that only work when local data already exists.

Where do I add demo credentials for Google Play review?

Play Console, then Policy and programs, then App content, then Sign-in details. Select Start or Manage, add the instructions, and use the "Any other instructions" field for one-time passwords, multi-factor authentication or logins with more than two fields. You can add up to five sets of instructions, and you must send the change from the Publishing overview page for a reviewer to see it.

Do I need to contact Play Console support before resubmitting?

No. The resubmission sequence is done entirely in Play Console by you: fix the app, upload the compliant bundle to every track, deactivate the non-compliant ones, and roll out. Google's Sign-in details guidance puts it plainly, saying you can complete those steps "without contacting or waiting for a reply from the policy support team". Open a support case when the notice describes something you cannot reproduce after all three checks above.

Can I appeal a Broken Functionality rejection?

Google documents one appeal "per app removal, suspension, or other enforcement action". For an ordinary rejection, the route is the resubmission sequence above, which you complete yourself without waiting for a reply. Reserve the appeal for a case where your own testing shows the build works and the notice describes something you cannot reproduce, and remember appeals are answered only in Chinese, English, Japanese and Korean.

Sources

All Google documentation below was read on 27 October 2026.

• Functionality, Content, and User Experience policy (Broken Functionality rule, named examples, Limited Functionality and Content)
• Check your app's policy status (what Policy status shows, rejection versus removal versus suspension)
• My app has been removed from Google Play (enforcement consequences, resubmission steps, appeals)
• Prepare your app for review (Sign-in details, sending changes for review)
• Use Play App Signing (upload key versus app signing key, API provider fingerprints, Internal App Sharing)
• Use a pre-launch report to identify issues (what the crawler does, licensing-check caveat)
• Monitor your app's technical quality with Android vitals (bad behaviour thresholds and their meaning)
• Notice contents described above come from developer reports, not from Google's documentation: a developer's write-up of a Capacitor rejection and a notice pasted in a Play Console Help Community thread. They illustrate what those developers received, not what Google guarantees you will receive.