Google Play Rejected for Broken Functionality: How to Fix

A Google Play rejection that names broken functionality means the release the reviewer installed did not work: it crashed, force closed, froze, would not install, would not load, or loaded without responding. Google's policy is one sentence long: "We don't allow apps that crash, force close, freeze, or otherwise function abnormally." The rejection attaches to that release, not to your developer account, and Google states that rejections do not impact the standing of your developer account. The way out is fixed work in a fixed order: identify the reviewed release, rule out reviewer access, read the pre-launch report and Android vitals, reproduce the failure on a device you do not develop on, then send a corrected release for review.

This page walks those five checks in the order a stuck developer needs them, separates this notice from limited functionality, sign-in details, and "more testing required", and answers the question Google does not answer anywhere in its documentation: what a rejection does to the 14-day closed-testing window you are in the middle of.

What Google's Broken Functionality policy covers

Broken Functionality sits in Google's Developer Program Policy under Spam, Functionality, and User Experience. The rule is one sentence, and Google attaches three examples to it: apps that don't install, apps that install but don't load, and apps that load but are not responsive.

The policy summary page frames the wider expectation: "Apps should provide a stable, responsive, and engaging user experience." Apps that crash, that "do not have the basic degree of adequate utility as mobile apps", that lack engaging content, or that show other behavior inconsistent with a functional and engaging user experience are not allowed on Google Play.

Google's publishing tips say the same thing in operational terms: "Per our Broken Functionality policy, we will reject apps that do not function as expected", and they point at the tool you should already be reading: "You can view crashes and application not responding (ANR) errors in Play Console to check for app stability." The same page explains why one rejection deserves same-week attention: "By catching issues early, we can help prevent your app from getting rejected multiple times, since multiple rejections may lead to your app getting suspended."

Worth being precise about scope, because the phrase is wider than a crash log. "Function abnormally" covers a freeze, an app that never finishes loading, a screen that sits unresponsive after a tap, and a package that will not install on the reviewer's device. It does not cover how much the app does, which is a separate finding under Limited Functionality and Content, and it does not cover what your listing promises, which is a metadata matter. In practice that means a rejection citing this policy is answered with a working build, not with new features or rewritten store text, and the checks below are all stability checks rather than content checks.

Which notice did you actually get?

Four different outcomes get described as "my app was rejected". They are decided by different parts of Play Console, fixed by different work, and only one of them is a judgment about whether your app runs.

The boundary that matters most: a broken functionality notice is about how the build behaved, while sign-in details is about whether a reviewer could enter it at all. The two produce the same screen in Play Console and lead to opposite first moves, which is why check 2 below comes before any code change.

If your notice names a different policy entirely, the full catalogue with the fix for each one is in Google Play app rejected: every rejection reason and its fix. This page stays on the stability rejection, because it is the one where the debugging order decides whether you get a second rejection or a published app.

Where Google shows what the reviewer saw

The decision arrives in three places, and Play Console gives you no reply box: the only two responses available are the ones the notice itself names, fix the issue and resubmit, or submit an appeal. What you receive is a policy name and a release. No screenshot is promised in Google's documentation, and no stack trace rides along with the notice.

The email to your account owner and the Play Console Notifications bell carry the same text and name the policy. The third source is your update status, which Google defines on the Publish your app page: Update rejected means "One or more of the changes in your update are not compliant with the Google Play policy or the Developer Distribution Agreement. You can fix the issue and resubmit, or you can submit an appeal." App rejected is the same decision with one difference: it applies only to apps in Draft that you are attempting to publish for the first time.

Write four things down before you touch code: the policy section named, the version code and track that were reviewed, the date, and any evidence attached. That short record decides whether your next move is a fix or an appeal.

The five checks to run, in the order a stuck developer needs them

These are ordered from cheapest to rule out, not by how often each cause occurs. Google publishes no data ranking the causes of broken functionality rejections, and neither do we, so the ordering is about getting to the real fault fastest.

1. Confirm the reviewed release and install the build Play distributes

Install the app from the track that was reviewed, on a clean device, signed in with a Google account that has never run it, then open it the way a reviewer would. A build that runs perfectly from Android Studio can fail from the track, because Play signs the APKs it delivers with your app signing key, not with the key on your machine. Google's Play App Signing documentation is explicit that API providers must be registered with the app signing key fingerprint, which you copy from the App signing key certificate section in Play Console. Anything that checks a certificate fingerprint, such as Google Sign-In, Maps, or an API key restricted by package name and fingerprint, can pass locally and fail in the store build.

Run the path the notice describes with the network the reviewer likely had: mobile data, permissions denied first time, an account with no data in it, and the app cold-started rather than already warm in the background.

2. Rule out reviewer access before you change any code

If any part of your app sits behind a login, membership, location, paywall or one-time code, Google requires the access details. The Prepare your app for review page states it directly: "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."

Google's sign-in detail requirements turn that into a checklist:

• Accessible at all times, reusable, and valid regardless of user location.
• Maintained without any error. If your login normally needs a two-step or one-time code, provide credentials that bypass it, because the reviewer cannot receive a code sent to your phone.
• Provided in English, even if your app's login is not.
• Delivered as a static URL when access is a QR code or barcode rather than text.
• Accompanied by instructions for anything unusual, including social login and a paywall the reviewer must get behind without paying.

To submit them: open Play Console, go to Policy and programs, then App content, choose Sign-in details, add or edit the instructions, save, then go to Publishing overview and select Send for review. Saving alone submits nothing. Google's testing requirements page repeats the same obligation from the other direction, telling you to "provide valid, working login credentials in Play Console so reviewers can fully test your app's features" (app testing requirements).

3. Read the pre-launch report for the reviewed version

Pre-launch reports are generated automatically when you upload a bundle or save a production release, and Google tests for stability, Android compatibility, performance, and accessibility by installing the artifact in its device lab and crawling it. Google's report documentation separates what you are looking at:

• Errors: crashes, ANRs, use of defective libraries, and use of unsupported APIs that have been restricted.
• Warnings: slow startup and load times, sign-in or crawl issues, memory issues, and unsupported APIs that are not yet restricted.
• Minor issues: missing content labels, color contrast, small touch targets.

If your app has a sign-in screen, give the crawler test account credentials on the pre-launch report settings page, otherwise it reports a sign-in problem that is really a test setup gap. Google notes that credentials can only be inserted automatically into apps that use standard Android widgets, not into OpenGL custom controls or a WebView-based authentication flow.

Two limits worth knowing before you over-read the report. Google states that it "can't guarantee that tests will identify all issues", and crashes found in the lab come from test devices, so they "don't affect your crash statistics". A clean pre-launch report means the crawler got through, not that a reviewer with a different account and network will.

4. Read pre-review checks and Android vitals

Pre-review checks run automatically whenever you change your app and appear on the Publishing overview page under "Changes not yet sent for review". Google's pre-review checks documentation connects them to this exact rejection: "if an issue causes your app to become non-functional, reviewers might reject the app for failing to comply with Google Play policies on app quality, such as the Minimum Functionality policy." Critical issues must be fixed before you can publish; other issues can be deferred with Proceed anyway.

The same page sets the ceiling on that comfort: "Passing all pre-review checks does not guarantee passing the formal app review process, which evaluates compliance more comprehensively than automated pre-review checks."

Then open Android vitals for the reviewed version. Google's Android vitals documentation lists the core vitals as the user-perceived crash rate and the user-perceived ANR rate, with bad behavior thresholds of 1.09% overall for crashes and 0.47% overall for ANRs. Play uses the last 28 days of data, and warnings clear on a 28-day average rather than the moment you ship a fix. One measurement detail explains a lot of panic during a small closed test: Google calculates vitals issues per daily active user, so a handful of crashes across a twelve-tester cohort can read as a very large percentage. The Play Console vitals overview is the source for how that dashboard reports the same data.

5. Reproduce it on hardware and networks you do not control

The reviewer's device is not your device. Test on more than one manufacturer and more than one Android version, on a network you do not administer, with a fresh install and a fresh account. Cover the states a reviewer hits first: first-run with no data, permission denied, no connectivity, an empty list, expired session, and Back pressed on every screen.

This is the work our own platform is built for. OnTesters runs closed-testing campaigns on physical devices, Samsung, Pixel, Xiaomi and OnePlus, across Android 11 to 15, with testers in more than 80 countries, matched in under 24 hours. When a build only fails on one manufacturer's WebView or one Android version, that kind of spread is what finds it, and it is far cheaper to find before a second rejection than after.

Pay particular attention to surfaces that are technically valid and look broken: a button that does nothing, a blank screen with no error message, a feature the store listing promises that is not in this build. A reviewer has no context for an intentional empty state, and cannot ask you what a dead control was supposed to do.

What happens to your 14-day closed-testing clock while you fix it

This is the question that sends most developers to forum threads, so here is the honest split between what Google documents and what we observe.

What Google documents. The requirement for personal accounts created after November 13, 2023 is "a minimum of 12 testers who have been opted in continuously for at least 14 days", and the requirement is measured on your testers, not on your releases (app testing requirements for new personal developer accounts). Google publishes no rule stating that a policy rejection pauses, resets, extends, or protects that count. Nothing in the testing requirements page mentions rejections at all.

What we observe. In our own campaign records, a rejected release does not remove anyone from the opted-in list. The tester list and the release status are separate objects in Play Console, and the things that actually drop your count are testers opting out, uninstalling, switching Google accounts, or being removed from the list, which we cover in detail in what actually resets Google Play's 14-day test. That is our observation from running campaigns, not a Google statement, and we would not want it read as one.

What the rejection really costs you is calendar time. Three documented behaviors add up:

• After a rejection, the next submission must be reviewed before it can be published, and Google notes this applies even to an internal test upload, which otherwise goes live immediately.
• Processing "can take a few hours or up to seven days (or longer in exceptional cases)", according to Google's guidance on controlling when changes are reviewed and published.
• Your changes are not automatically sent for review. The status "Changes not yet sent for review" sits on the Publishing overview page until you press Send for review, so a fixed build that nobody submits changes nothing.

There is also a second-order risk. A broken build sitting in your closed track for a week while review runs is a build your testers are installing. Every tester who uninstalls or opts out during that week ends their own continuous opt-in, and the count is what your application is judged on. The rejection did not reset your window; a slow fix can empty it.

Our recommendation. Treat the fix as a days-not-weeks job. Recruit to 15 or 16 rather than exactly 12 so one or two departures never take you below the floor, check the opted-in list daily while a rejection is open, send the corrected release for review the same day it passes your own testing, and confirm which tracks still carry the non-compliant bundle. This is our recommended approach, not a Google requirement.

Fix and resubmit, or appeal?

Google's enforcement documentation gives you both options in the same sentence as the rejection itself: "You can fix the issue and resubmit, or you can submit an appeal." The practical rule we use is simple. Fix and resubmit when you can reproduce the failure or find a plausible cause. Appeal when you have evidence that the cited finding was mistaken.

Two facts should shape the decision. First, rejections "Don't impact the standing of your Google Play Developer account", and if an update is rejected the previously published version stays available. Second, if a suspension ever arrives, Google states that "Egregious or multiple policy violations can result in suspension, as can repeated app rejections or removals." A second rejection for the same cause is a worse position than the first, which is why the resubmission has to be complete rather than minimal.

If you fix, follow Google's resubmission path rather than re-uploading one bundle: read the policy named in the enforcement message, check your app against the other policies as well, "update all release types in addition to your production release (for example, the open, closed, and internal test track releases)", upload the compliant bundle across all tracks and deactivate the non-compliant ones. Google warns that if you fail to deactivate the non-compliant bundles, "your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play." Then create the release, keep the non-compliant version under Not included, save, review the release, and roll it out. Repeat on every affected track. In each case, until the violation is fixed, do not republish.

If you appeal, know the constraints before you spend your one shot. Google allows "one appeal per app removal, suspension, or other enforcement action", and the specialist reviewing it can only respond in Chinese, English, Japanese, or Korean. Google's appeal form adds that you should receive a response within 72 hours, that additional documentation should be attached in one appeal rather than spread across several, and that a previously denied appeal should not be refiled without new information. An appeal is the right instrument when the record is wrong, not when the record is correct and you are unhappy about it.

If enforcement escalates past rejection to removal or suspension, the process changes completely, including deadlines and what you lose. That path is covered separately in appealing a Google Play account suspension or termination.

What we see across our own 1,500+ closed-testing campaigns

These are observations from OnTesters' own campaign records, not Google data, and we do not publish a pass or approval rate for any part of our work. Three patterns keep repeating in the rejections our developers walk through:

• Release-only authentication failures. The app authenticates fine in development and fails from the track, because the API provider still holds the wrong certificate fingerprint. This is the failure class we reproduce most often on the build Play distributes.
• Access problems that look like crashes. A reviewer who cannot sign in sees a screen that never loads. The build is sound and the sign-in instructions are stale, expired, or protected by a one-time code the reviewer can never receive.
• Half-finished surfaces. Dead buttons, blank states with no message, and store listing promises that are not in this build. None of these are crashes in a technical sense, and all of them read as a broken app to someone who has one attempt and no context.

The diagnostic order above exists because of that pattern: the two cheapest checks, the build you ship and the access you grant, account for most of what we see before anyone opens a profiler.

Some honesty about what those records can and cannot tell you. They cover only campaigns that ran through OnTesters, which skews heavily toward new personal accounts working through the 12-tester requirement, so they say nothing about established accounts, games with custom engines, or apps we never tested. We also only see the rejection our developer reports to us, not the reviewer's internal notes, so the categories above are patterns we recognise in the aftermath rather than a diagnosis Google handed us. Where a claim on this page comes from Google, it is cited to the Play Console Help page that states it; where it comes from our own records, it is labelled that way.

Edge case: WebView and TWA apps

If your app is a web shell or a Trusted Web Activity, the failure is usually in the web layer or in the association between your domain and the app, not in Java or Kotlin code. A common version of this is digital asset links that still list an old fingerprint while Google signs the installed app with the app signing key it holds, which produces a build that behaves incorrectly for a reviewer even though it works from your own domain.

Two quick ways to place the boundary. If the app opens with a visible browser address bar, or if the reviewer can reach a screen you expected to be locked to the app, you are debugging web association rather than Android code. If the app opens full screen but the page behind it spins or errors, load the same URL on mobile data in Chrome with a fresh profile: what fails there is what fails in the app, because the app is rendering the same page. Verify the whole chain in that order before you rebuild anything, then run checks 2 through 5 exactly as written, since reviewer access and network conditions behave the same way inside a web shell.

The diagnosis path for the association case specifically, including the browser bar symptom and what it costs you during closed testing, is covered in TWA app rejected: Google says your testers were not engaged.

Frequently asked questions

Does a broken functionality rejection reset my 14-day closed test?

Google publishes no rule on this either way, so treat any confident claim as unverified. What is documented is that the requirement measures 12 testers opted in continuously for at least 14 days, and a rejection targets a release rather than your tester list. In our records the opted-in list survives a rejection, while opt-outs, uninstalls and account switches do not. The realistic cost is time: your corrected build still has to pass review, and that is days you are spending while the window runs.

How long does a corrected release take to get through after a rejection?

Google says processing can take a few hours up to seven days, or longer in exceptional cases, and notes that certain accounts are reviewed more thoroughly, which can mean up to seven days or longer. After a rejection the next submission must be reviewed before publication even on a track that normally publishes immediately, and the clock only starts when you actually send the changes for review.

Does a rejection count as a strike on my developer account?

No. Google states that rejections do not impact the standing of your Play developer account, and the previously published version of a rejected update stays available. What does escalate is repetition: Google documents that repeated rejections or removals, alongside egregious or multiple violations, can result in suspension.

Should I appeal a broken functionality rejection or just fix it?

Fix it whenever you can reproduce the failure or identify a likely cause, because resubmission is the faster path and the notice itself offers both options. Appeal only when you can show the finding was mistaken, and put all of your evidence into that single submission. Google permits one appeal per enforcement action and asks that denied appeals not be refiled without new information.

What is the difference between "Update rejected" and "App rejected"?

Both carry the same meaning: the changes are not compliant and you can fix and resubmit or appeal. The difference is scope. App rejected applies only to an app in Draft that you are attempting to publish for the first time; Update rejected applies to an update to an app that already exists.

Do I need 12 new testers if a release of my app was rejected?

Not because of the rejection itself. The requirement is continuous opt-in for at least 14 days across a minimum of 12 testers, and what breaks it is testers leaving the test, not releases being rejected. If your count held, your window is still yours. If the broken build drove testers to uninstall or opt out, the count is what suffers, which is exactly the argument for keeping more than 12 recruited, as explained in what counts as a Google Play closed tester.

Sources

• Developer Program Policy - Play Console Help - Broken Functionality rule and its three examples.
• Functionality, Content, and User Experience - Play Console Help - policy summary quoted at the top of this page.
• Helpful tips to get your app published on Google Play - broken functionality rejection guidance, crash and ANR checks, and the escalation to suspension.
• My app has been removed from Google Play - rejections versus removals and suspensions, the six-step resubmission path, and the one appeal per enforcement action rule.
• Publish your app - Play Console Help - publishing status, Update rejected, App rejected, and Changes not yet sent for review.
• Control when app changes are reviewed and published - review requirement after a rejection and processing times.
• App testing requirements for new personal developer accounts - the 12 tester, 14 continuous day requirement and reviewer credentials.
• Prepare your app for review - Sign-in details on the App content page.
• Requirements for providing sign in details for review - reusable, location-independent, English-language credentials.
• Use a pre-launch report to identify issues and Understand your pre-launch report - report scope, error and warning categories, and test device statistics.
• Detect app issues early with pre-review checks - automated checks and their link to Minimum Functionality rejections.
• Android vitals and Monitor your app's technical quality with Android vitals - core vitals, bad behavior thresholds, and the 28-day window.
• Use Play App Signing - upload key versus app signing key and where to copy the fingerprints.
• First-hand observations in this article come from OnTesters' own records across more than 1,500 closed-testing campaigns on physical devices, Android 11 to 15, across more than 80 countries. They are our platform records, not Google statistics, and no success rate is implied by them.