Quick Answer
A Broken Functionality rejection means Google's reviewer found that the release you submitted crashed, force closed, froze or otherwise functioned abnormally; Google's own examples are apps that don't install, install but don't load, or load but are not responsive. It is a policy decision about a release, not a production access refusal, and Google says a rejection by itself does not affect your developer account's standing. Reproduce the problem on the build Play distributes, confirm reviewers can sign in through Sign-in details (formerly App access), fix every affected track, then send the corrected release for review. Appeal only when you can show the finding was mistaken.
Current as of October 16, 2026. Every rule on this page was checked against Google Play's policy pages and Play Console Help on that date, and each one is linked where it is used. The developer reports quoted below are evidence of what developers saw in 2026, not Google's diagnosis of their apps, and no ranking of causes is given because no public dataset supports one.
This post covers release rejections under the Broken Functionality policy. If Google declined production access after your closed test, or told you more testing is required, that is a different decision with a different fix: read what to do when Google Play says more testing is required and why closed testing applications get rejected instead.
What This Post Covers
What does Broken Functionality mean on Google Play?
It is one of two sections of Google's Functionality, Content, and User Experience policy. The other section, Limited Functionality and Content, is about apps with too little purpose. Broken Functionality is about an app that does not work as submitted.
We don’t allow apps that crash, force close, freeze, or otherwise function abnormally.
Google lists three examples of common violations under that sentence: apps that don't install, apps that install but don't load, and apps that load but are not responsive. Read those as three places to look. A reviewer who cannot install the build, who sees a blank or endless loading screen, or who taps a control and nothing happens can all produce the same notice.
You may still meet the name Minimum Functionality in older Help links and forum threads. The current policy section is called Limited Functionality and Content, and it covers static text or PDF apps, apps with very little content, and apps designed to do nothing. A notice can cite either section, and the fixes differ, so read which one your notice names before you change anything.
Four decisions that get confused with each other
| Decision | What it is about | Where to start |
|---|---|---|
| Broken Functionality | What it is aboutThe submitted release crashed, froze, did not load or did not respond for the reviewer. | Where to startReproduce it on the build Play distributes, fix it on every affected track, resubmit. |
| Limited Functionality and Content | What it is aboutThe app runs but offers too little app-specific purpose or content. | Where to startAdd real functionality. A bug fix alone will not answer this one. |
| Sign-in details missing or not working | What it is aboutReviewers could not get past a login, membership, paywall, one-time code or region check. | Where to startUpdate Sign-in details in App content, then send the change for review. |
| Production access not granted | What it is aboutAfter the closed test, Google decided the app needs more testing or is not ready for production. | Where to startA separate process with no code-level notice. See more testing required. |
Where does Google show what was broken?
Start with the enforcement email and the Policy status page in Play Console. Together they name the policy and the affected release, and Google says Policy status also shows any additional information that is available. Screenshots, device details and stack traces are not promised, so do not wait for them.
Open Play Console, select the app and open its Policy status page. Write down four things before you touch the code: the policy section named, the version code and track that were reviewed, the date, and any evidence attached. Check the email and your Play Console notifications as well, because they are where Google states which policy the release violated.
What 2026 notices actually look like
There is no single Broken Functionality email that everyone receives, and any page that prints one as the exact template is guessing. Developers who posted their notices publicly in 2026 describe very different levels of detail:
- A notice label reading "Broken Functionality: Unresponsive UI elements", posted on September 2, 2026 by a developer whose app showed an offline retry screen during its first data sync (Play Console Help Community).
- A reviewer example reading "For example, your app does not open or load.", quoted in June 2026 by a game developer whose title screen did load. The author later reported that the game was published after changing how the Android Back button exited it.
- A notice one developer described in August 2026 as just two words, "Broken functionality", with nothing else.
These are excerpts reproduced by developers, not authenticated Google emails, and each one is a single case. They show the range of detail you might get, not what your notice will say or why your app failed.
If your notice is vague
Treat the cited policy as a symptom to reproduce, not as a diagnosis. The five checks in the next section are ordered so that each one rules out a different place the failure can hide.
What should you check first after a Broken Functionality rejection?
Run five checks against the exact release Google reviewed. They are ordered from the cheapest to rule out to the hardest, not by how often each cause occurs, because no public data shows how often each one happens.
Five checks, in order
Install the build Play distributes, not your debug build
Install from your test track on a clean device signed in with a Google account that has never run the app, then open it the way a reviewer would. Google Play signs the builds it distributes with your app signing key (Use Play App Signing), so any service that checks a certificate fingerprint, such as Google Sign-In, Maps or an API key restricted by package name and SHA-1, can work in your debug build and fail in the store build. One developer in 2025 traced a release-only failure to an internet permission missing from the production manifest.
Confirm the reviewer can get in
If any part of the app sits behind a login, membership, location or other gate, Google requires you to provide the access details. Check that Sign-in details (formerly App access) holds credentials that work today, from any country, without a one-time code. The next section walks through it.
Test the backend from outside your own network
Login screens and data screens fail when the server cannot be reached from the reviewer's network. Developers in 2026 traced failures to an accidental firewall rule that blocked a login code request, and reported a certificate trust error shown on a sign-in screen. Test over mobile data and another network, and from another country if your server filters traffic by region.
Tap every visible control and open every empty screen
Every button and link should respond with appropriate content. Google's own Broken Functionality checklist in the Play Console Help Community says: "Make sure that your app does not have any empty or blank pages that lack appropriate disclaimers or error messages." Remove unfinished features instead of shipping a button that does nothing, and check that every feature your store listing promises actually works in the build. Give a legitimately empty list, such as no saved items yet, a sentence that explains it and a next action. If your navigation is unusual, such as tapping anywhere to continue, add a visible cue a first-time user cannot miss.
Check launch, Back and the reports Play already holds
Open the app cold, rotate it, send it to the background and bring it back, and press Back on every screen. Then read the pre-launch report and Android vitals for the reviewed version. A crash recorded there is the strongest evidence you will get, and a clean report has limits that the section after next explains.
How do you give Google's reviewers sign-in details?
In Play Console, go to Policy and programs, then App content, then Sign-in details. The section used to be called App access, so older posts and some translated Help pages still use that name.
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.
Add or update the instructions
- Open Play Console and go to the App content page (Policy and programs > App content).
- Under Sign-in details, select Start, or Manage if you added instructions before.
- Select + Add new instructions and enter the access details. Use the Any other instructions field for anything unusual, such as a one-time password, multi-factor authentication or a login with more than two fields.
- Save your changes. You can add up to five sets of instructions.
- Go to Publishing overview, find the change under Changes ready to send for review, and select Send for review. Saving alone does not submit anything.
What counts as working access
Google's Play Console Requirements ask you to "Provide an active demo account, login information, and all other resources needed for Google Play to review your app". Google's requirements for sign-in details spell out what that means:
- An account that is active and reusable, not a single-use invite or a trial that expires during review.
- Credentials that get past one-time codes and two-step verification, because the reviewer cannot receive the code you send to a phone or inbox.
- Access that works from any location if the app restricts by region, and full access to paid or gated features the reviewer needs to see, without being charged.
- Details written in English and kept current. If you rotate the password or delete the test account, update Sign-in details the same day.
- If sign-in needs something that is not text, such as a QR code or barcode, generate a static URL for it and add it to Sign-in details. If the app asks users to set their own PIN or uses a social login, explain in the instructions how a reviewer gets through.
Missing access is not the same as a broken login
If the notice cites Sign-in details, no code change helps until the access details are corrected and sent for review. If the credentials were fine and the login itself failed, that is a Broken Functionality problem, and the backend check above is where to look.
What if the app works on your phone and Google sent no screenshot?
Then your phone is not the environment that failed. Reproduce on the store build, on a clean device and another network, and read the two reports Play Console already holds for that release before you decide anything.
The pre-launch report
Find it under Test and release > Testing > Pre-launch report. Google generates it automatically when you upload an app bundle or APK, subject to capacity, by running the app on test devices. Check which screens the crawl actually reached: if it stopped at your login screen, it never saw the rest of the app. Google adds a limit worth knowing: "Credentials can only be automatically inserted into Android apps that use standard Android widgets." (Use a pre-launch report to identify issues). A clean report is evidence, not a pass. Google says the same of its pre-review checks: "Passing all pre-review checks does not guarantee passing the formal app review process".
Android vitals
Find it under Monitor and improve > Android vitals > Crashes and ANRs. Google collects this data only from users who opted in to share usage and diagnostics data (Monitor technical quality with Android vitals), so a new app in a small test may show nothing at all. An empty vitals page does not prove the app never crashed.
Real people on real devices
A closed test exists to find this kind of problem before a public release. Testers on different phones, Android versions and networks reach the screens a reviewer reaches, and their feedback tells you where things break. That helps you find and fix defects; it does not change how Google reviews the app. If you need the basics of the track itself, see how Google Play closed testing works.
Should you fix and resubmit, or appeal?
Fix and resubmit when you can reproduce a failure or find a plausible cause. Appeal when you have evidence that the cited finding is mistaken. Never resubmit the same build unchanged: Google tells developers not to republish a rejected app until the violation is fixed.
Fix, clarify or appeal?
Answer three questions about your notice and your own testing. Nothing you choose leaves this page.
Answer the questions to see a recommendation. If you cannot reproduce a failure, the third question decides it.
Fix it, then resubmit on every track
Fix and resubmitYou have a reproducible failure, which is the best position to be in. Fix it, test the fix on the store build, then follow the resubmission steps below so no noncompliant bundle stays active on any track.
Test the store build before you decide
Test firstA debug build is not what the reviewer ran. Install from your test track on a clean device with a fresh account, over a network you do not control, and run the five checks. Decide only after that.
Correct Sign-in details, then send for review
Access fixUpdate the instructions with reusable credentials that bypass one-time codes, save, then send the change for review from Publishing overview. Google says you can do this without contacting or waiting for the policy support team.
Add purpose, not just fixes
ReworkLimited Functionality and Content is about how much the app does. Add real app-specific features or content before you resubmit; a stability fix does not answer this finding.
Make the design obvious, then decide
ClarifyIf an offline screen, an empty state or an unusual gesture is deliberate, a reviewer may still read it as broken. Add a visible cue, an explanation and a next action. You can appeal with evidence, but a clearer screen also removes the doubt for the next reviewer.
Appeal with evidence
AppealYou tested the store build on a clean device and another network and found nothing wrong. Appeal once, with the version code, the device and Android version, the exact steps, and a screen recording of the flow the notice names.
Resubmitting a fixed release
Google's resubmission steps are more than uploading a new version code:
- Read the policy named in the email and your notifications, and check the app against the other policies too; Google warns that further violations can lead to further enforcement.
- Update every release type that carries the affected version, not only production: open, closed and internal test tracks included.
- Upload the corrected app bundle and deactivate the noncompliant ones. Google warns that if you do not deactivate them, the resubmission fails and live versions may be removed.
- In each affected track, select Manage track and Create new release, add the corrected bundle (or discard a draft that holds the violating one), and make sure the noncompliant version is listed under Not included.
- Save, select Review release, and roll it out.
After that, the change waits for processing. Google says: "Processing can take a few hours or up to seven days (or longer in exceptional cases)" (Control when app changes are reviewed and published).
Fixed, but the warning is still there
If a corrected version is live and Policy status still shows the issue, compare the version codes and tracks the warning names with what is now active: a noncompliant bundle left on a test track is the first thing to rule out. A newer version does not automatically clear every enforcement entry. If everything matches, contact Play Console support with the version codes, the affected tracks and any earlier case reference.
Appealing the decision
Google reinstates apps when it made an error and finds the app does not violate its policies. To appeal, follow the instructions in the enforcement email or use Google's appeal form. You can submit one appeal per enforcement action (Managing policy violations and appeals), and Google answers appeals in Chinese, English, Japanese and Korean. Google publishes no response time for appeals, and developer reports mix appeal replies with later release reviews, so plan without a date.
Write the appeal as evidence, not as frustration: the version code that was reviewed, the device and Android version you tested on, the exact steps, a screen recording of the flow the notice names, and what you changed, if anything.
Does a Broken Functionality rejection hurt your account or your closed test?
A rejection by itself does not affect your developer account's standing. Repeated rejections can lead to suspension, and suspensions count as strikes, so fix before you resubmit. What a rejection does to a running closed test is not documented.
Google's Enforcement Process page sets out the difference:
- "Rejections don’t impact the standing of your Google Play Developer account."
- "If an update to an existing app was rejected, the app version published prior to the update will remain available on Google Play."
- "Suspension can occur as the result of egregious or multiple policy violations, as well as repeated app rejections or removals."
Google publishes no number of rejections that is safe. Resubmitting the same failure is exactly the pattern the third line describes.
And the 14-day closed test?
Google's testing requirement asks personal accounts created after November 13, 2023 for at least 12 testers opted in continuously for at least 14 days before applying for production access. It does not say whether a policy rejection of a closed track release resets, pauses or keeps that period, and forum claims either way are guesses. What you can check: whether your testers still have an approved release on the track, and what the Dashboard shows about production access. Keep testers opted in while you fix, and ask Play Console support about your case if the Dashboard changes. The rule itself is explained in what 14 consecutive days means.
Will Google reject a WebView or TWA app as broken?
Not for the technology. Google documents both Trusted Web Activities and WebView for Android apps, and no policy bans the architecture. The questions are whether the app works, whether it has enough purpose, and whether you have the right to wrap the website.
We don’t allow apps whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator.
For a web-based app the Broken Functionality checks are the same as for any other app: the site must load inside the app from a clean install, offline and error states must explain themselves, and every link must lead somewhere. If the app is mostly a thin view of a website, the Limited Functionality and Content section is the bigger risk. Switching from a TWA to a WebView, or the reverse, has not been shown to fix a rejection by itself.
How does PrimeTestLab help before the next review?
We cannot fix your code or change Google's decision. What we supply is the testing side: real people on real devices who use your app through your closed test, so problems like the ones above show up in their feedback before a reviewer finds them.
PrimeTestLab supplies 12 or more real testers on real devices spanning Android 7 to 17, opted in for the full 14 days, with testing starting in 4-6 hours. We have run managed tests for 12,100+ apps with testers in 120+ countries.
DIY testing or managed testing
| Task | Doing it yourself | With PrimeTestLab |
|---|---|---|
| Finding testers | Doing it yourselfFriends, groups and forums, usually on similar phones | With PrimeTestLabReal testers on real devices, assigned to your app |
| Device and Android version spread | Doing it yourselfWhatever your volunteers own | With PrimeTestLabDevices spanning Android 7 to 17 |
| Daily use and feedback | Doing it yourselfDepends on goodwill | With PrimeTestLabTesters use the app and report what breaks |
| Keeping 12 opted in for 14 days | Doing it yourselfYou chase dropouts yourself | With PrimeTestLabDropouts are replaced so the count holds |
| Fixing the code and the notice | Doing it yourselfYou | With PrimeTestLabStill you; we report what testers found |
| Google's decision | Doing it yourselfGoogle | With PrimeTestLabStill Google; nobody can promise approval |
If Google has not granted production access after your full PrimeTestLab test, you choose a free retest or a full refund; see the refund and free-retest policy. That covers the testing requirement, not a policy rejection of your code. Plans start at $19.99 plus a 5% service fee at checkout (minimum $1.50), and Google's one-time $25 registration fee is separate. Compare plans on the pricing page.
Frequently asked questions
What is the Broken Functionality policy on Google Play?
It is a section of Google Play's Functionality, Content, and User Experience policy. Google does not allow apps that crash, force close, freeze, or otherwise function abnormally, and lists apps that don't install, apps that install but don't load, and apps that load but are not responsive as common violations.
Is Broken Functionality the same as Minimum Functionality?
No. Minimum Functionality is the older name for what Google now calls Limited Functionality and Content, which covers apps with too little purpose or content. Broken Functionality covers apps that do not work as submitted. Both sit in the same policy, but they need different fixes.
Where do I add demo credentials for Google Play review?
In Play Console, go to Policy and programs, then App content, then Sign-in details (formerly App access). Select Start or Manage, add the instructions and save, then send the change for review from the Publishing overview page. The credentials should be reusable and must not depend on a one-time code sent to your phone.
Does a rejection count as a strike on my developer account?
Google says rejections don't impact the standing of your developer account. Suspensions count as strikes, and Google lists repeated app rejections or removals among the reasons for suspension, so fix the cited problem before you resubmit.
How long does review take after I resubmit a fixed app?
Google says app changes can take a few hours or up to seven days to process, or longer in exceptional cases. That is the review of the corrected release. Google publishes no response time for appeals.
Can I appeal a Broken Functionality rejection?
Yes, if you believe the finding is wrong. Follow the instructions in the enforcement email or use Google's appeal form. You can submit one appeal per enforcement action, so include the reviewed version code, the device and steps you tested, and a recording of the flow the notice names.
Does a Broken Functionality rejection reset my 14-day closed test?
Google does not document that. Its requirement is at least 12 testers opted in continuously for at least 14 days before you apply for production access. Keep testers opted in while you fix the release, watch the Dashboard, and ask Play Console support if your eligibility changes.
Why was my app rejected if it works on my phone?
Your phone covers one build, one account, one set of data and one network. Install the release Play distributes on a clean device with a new account, then test empty content and failed network requests. A store build signed with the app signing key can fail where your debug build works, so test the build the reviewer installed.
My app uses Google Sign-In or a one-time code. What should I give reviewers?
Google requires sign-in details that are reusable, work from any location and bypass one-time passwords or two-step verification. Give reviewers a test account and instructions that reach every restricted feature, including paid ones. Then test the exact details you supplied yourself; explaining how a normal user receives a code is not working access.
Google sent no screenshot or crash log. What now?
Check Policy status and the enforcement email for the affected version and any details Google added. Then reproduce the main journey on the submitted release and record your own video and logs. A clean Android vitals page or pre-launch report does not prove every screen and backend request worked for the reviewer.
Are TWA and WebView apps automatically rejected?
No. Google documents both technologies and no policy bans them. Google does restrict apps that wrap a website without the owner's permission and apps with too little functionality or content. Diagnose the actual failure, such as login, navigation or network errors; switching from one wrapper to the other is not a documented fix.
The bottom line
Bottom Line
A Broken Functionality rejection says the release Google reviewed did not work: it crashed, froze, would not load or did not respond. Read which policy the notice cites, reproduce on the build Play distributes, confirm reviewers can sign in through Sign-in details, test the backend from outside your network, and make every control and empty screen explain itself. Fix every affected track and send the corrected release for review. Appeal only with evidence that the finding was wrong. A rejection alone is not a strike, but repeated unfixed resubmissions can lead to one.
If you want real people on real devices to find the broken screen before the next reviewer does, PrimeTestLab runs the closed test side while you fix the app.
Official Google documentation
What can change on this page
- Play Console labels move. Sign-in details was called App access until recently, and some translated Help pages still use the old name.
- Notice wording is not published as a template and changes between cases; trust your own email and Policy status page over any example here.
- Google does not document what a policy rejection does to a running closed test. If it publishes a rule, this page will follow it.
Sources checked October 16, 2026.