What the rejection typically looks like
Issue found: Violation of Broken Functionality policy
Your app doesn't comply with the Broken Functionality policy. We don't allow apps that crash, force close, freeze, or otherwise function abnormally. During review, the app crashed or stopped responding on our test device, or key features did not load.
Action required: Fix the issue, upload a compliant version with a new version code and deactivate the non-compliant app bundle. If any part of your app requires sign-in, provide valid sign-in details in Play Console before you resubmit.
Paraphrased example – the exact wording in your message may differ.
What the Broken Functionality policy actually says
Broken Functionality is a clause of Google Play's Functionality, Content, and User Experience policy, in the "Spam, Functionality, and User Experience" area of the Policy Center. Older emails and forum posts refer to it as part of the "Spam and Minimum Functionality" policy.
The policy opens with the expectation that "apps should provide a stable, responsive, and engaging user experience" (Google Play Policy Center). The Broken Functionality clause then says Google doesn't allow apps that "crash, force close, freeze, or otherwise function abnormally" and names three common violations:
- Apps that don't install on the reviewer's device
- Apps that install, but don't load – a crash on launch, an endless splash screen, a blank first screen
- Apps that load, but are not responsive – frozen screens, ANR dialogs, buttons that do nothing
The sister clause, Limited Functionality and Content, covers apps that work but offer too little, such as text-only, PDF or single-wallpaper apps. If that's your problem, read our WebView and spam policy guide.
According to Google's help center, a rejection doesn't affect your developer account's standing, and a rejected update leaves the previous version live. A new app simply stays unpublished until a fixed version passes.
Common reasons apps fail with broken functionality
The reviewer installs your production artifact on a real device and tries the main features. These patterns are behind most rejections:
| Trigger | Why it only shows up in review |
|---|---|
| Release build crashes, debug works | R8/ProGuard strips classes used through reflection (Gson or Moshi models, some SDKs). R8 full mode is the default since Android Gradle Plugin 8.0, so an upgrade can break a build that used to work. |
| Target SDK behavior changes | A higher targetSdkVersion enables new rules: PendingIntent mutability flags (Android 12), receivers without RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED and foreground services without a type (Android 14), enforced edge-to-edge that hides buttons behind system bars (Android 15), and on Android 16 the edge-to-edge opt-out goes away while orientation and resizability locks are ignored on large screens. |
| Backend unreachable | The release build points to staging, your API geo-blocks other countries, a TLS certificate expired, or plain http:// calls are blocked because cleartext traffic is off by default. |
| Signing key mismatch | Play App Signing re-signs your bundle. If only your upload key's SHA-1 is registered, Google Sign-In fails (with the legacy Google Sign-In SDK often as status code 10, DEVELOPER_ERROR) and key-restricted Maps or Firebase APIs return errors. |
| Login wall | No demo account, an expired password, one-time codes sent to your phone, or an account that needs admin approval. |
| Purchases not set up | Inactive products or none available in the reviewer's country, so the paywall says the item "could not be found". |
| Dead ends | Empty lists with no explanation, "coming soon" tabs, buttons without a handler, a WebView browser error page. |
| Denied permissions | The reviewer taps "Don't allow" for camera or location and the app crashes instead of degrading gracefully. |
| Untested devices | Tablets, foldables and Chromebooks: rotation and resizing recreate activities and lose state, or code assumes a camera you declared as not required. |
Rejected or stuck? Talk to an App Specialist – for free.
Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.
When the reviewer can't get in: sign-in details
A reviewer stuck on your login screen sees an app that doesn't work. If your entire app or parts of it are restricted by login credentials, memberships, location or other authentication, you must provide access in Play Console: open Policy and programs > App content, select Start under Sign-in details and click + Add new instructions. Older Play Console versions and many tutorials call this declaration App access. You can add up to five sets of instructions.
As of October 2026, Google's requirements for sign-in details say credentials must be:
- Accessible at all times, reusable and valid regardless of location – if passwords depend on the user's region, provide one login that works everywhere.
- Free of 2-step verification and one-time passwords – provide a login that bypasses them and explain any special mechanism in Any other instructions.
- Kept valid – if the credentials expire or fail, Google may not be able to review the app and may reject it.
- In English.
- Usable without scanning – for QR code or barcode logins, provide a static URL.
- Complete for social sign-in – include all account information and step-by-step instructions.
- Enough to get past the paywall – add access details so the reviewer can reach paid content.
Create a dedicated review account that cleanup jobs, password rotation and fraud rules never touch, and fill it with realistic data. For hardware-dependent apps, explain the setup in "Any other instructions", link a short screen recording and, ideally, add a demo mode that simulates the device.
How to fix a Broken Functionality rejection step by step
- Read the issue details on the app's Policy status page and in Google's email. Note the version code and any attached screenshot: your login screen points to access, a crash dialog points to code.
- Reproduce with the exact artifact. Install the rejected bundle from an internal testing track: that build is signed with your app signing key, like the one the reviewer gets. Internal app sharing re-signs uploads with a separate internal app sharing key, so signing-related failures may not show up there. For quick local checks, use
bundletool build-apks --bundle=app-release.aab --output=app.apksandbundletool install-apks --apks=app.apks. Use a clean install and a fresh account. - Collect stack traces from Test and release > Testing > Pre-launch report and, if you have users, Monitor and improve > Android vitals > Crashes and ANRs. Upload your R8
mapping.txtand native debug symbols so traces are readable. Locally, useadb logcat -b crash. - Fix the root cause. Add keep rules for reflected classes, handle the new target SDK rules, move disk and network work off the main thread (StrictMode finds it) and replace silent failures with error states and retry buttons.
- Check the infrastructure: production URL in the release variant, TLS certificates, geo-blocking and firewall rules, active in-app products, and the app signing key SHA-1 from the Play app signing page (under Protected with Play in the current Play Console) registered in Firebase and Google Cloud.
- Test a small device matrix: your
minSdk, the current Android version, a low-RAM phone, a tablet or foldable, and permission-denied flows. - Update sign-in details and test the demo login on a clean device.
- Upload a new release with a higher
versionCodeand deactivate the non-compliant bundle on every track where it is active. Google warns that otherwise your resubmission fails and live versions may be removed. - Send for review from Publishing overview under "Changes not yet sent for review".
Android vitals thresholds and the pre-launch report
Android vitals measures technical quality among real users, checked daily as a 28-day average, and can affect your visibility on Google Play. It is separate from policy review: exceeding a threshold is not itself a Broken Functionality rejection, but high crash or ANR rates confirm the problem is real.
As of October 2026, Google lists these bad behavior thresholds:
| Vital | Overall | Per phone model | Per watch model |
|---|---|---|---|
| User-perceived crash rate | 1.09% | 8% | 4% |
| User-perceived ANR rate | 0.47% | 8% | 5% |
| Excessive partial wake locks | 5% | – | – |
The crash and ANR rates are the share of daily active users who had at least one user-perceived crash or ANR. Google says that above a threshold, Play may reduce your app's visibility and may show users a warning on your store listing. Google has also published thresholds for memory usage, bitmap memory usage and code optimization, and says apps exceeding them may see store visibility impact starting from February 2027.
Use the pre-launch report before the reviewer does
Uploading an app bundle or APK triggers a pre-launch report automatically, depending on device lab capacity. Powered by Firebase Test Lab, it installs the app on a range of devices and crawls it for several minutes, then reports stability (crashes, ANRs), performance, accessibility and Android compatibility issues, plus screenshots.
- Under Test and release > Testing > Pre-launch report > Settings, add test credentials. Auto-fill only works with standard Android widgets, not with WebView or OpenGL login screens; apps that use Sign in with Google need none.
- Add up to three deep links, and a Robo script for flows the crawler can't handle.
Treat every crash in the report as a blocker.
Flutter, React Native and WebView pitfalls
Cross-platform apps fail for the same reason native ones do: release mode differs from debug mode.
Flutter
android.permission.INTERNETis declared in Flutter's debug and profile manifests, but not necessarily inandroid/app/src/main/AndroidManifest.xml. Without it, the release build shows empty screens.- Test the output of
flutter build appbundle --release, notflutter run, and report errors fromFlutterError.onErrorandPlatformDispatcher.instance.onError.
React Native and Expo
- Environment variables (
react-native-config, EAS environment variables) missing in the CI release build leave the app with an undefined API URL. - In a release bundle, a JavaScript error that showed a red box in development can crash the app or leave a blank screen. Add an error boundary with a usable fallback screen and test the release build on a device.
WebView and hybrid apps
- File inputs do nothing unless you implement
WebChromeClient.onShowFileChooser– a dead button to a reviewer. - Handle
target="_blank"links, geolocation prompts and downloads explicitly, and show a native error screen instead of anet::ERR_page.
Responding: resubmit or appeal?
Google Play has no back-and-forth message thread with the reviewer like App Store Connect, so pick one of two paths.
Fix and resubmit if you find anything plausible: a crash in the pre-launch report, an expired demo password, a server outage around the review date. That covers most cases. Google's Policy status help page says not to republish a rejected app until the violation is fixed, so sending the same build again rarely helps.
Appeal only if you're sure the app works and the reviewer hit something outside your control, such as a misunderstanding about required hardware. Use the appeal option linked in the rejection email or on the Policy status page.
- You can submit one appeal per enforcement action, so make it complete.
- Google says it responds to appeals only in Chinese, English, Japanese and Korean.
- Include the version code tested, devices and Android versions, a screen recording, a clean pre-launch report and exact sign-in steps.
How to prevent broken functionality rejections
Most of these rejections are caught by checks you can automate once in your pipeline.
- Test the release variant in CI. Run smoke tests (Espresso or Maestro) on the minified, signed build.
- Run a device matrix on Firebase Test Lab:
minSdk, latest Android, a tablet, a low-memory device. If you ship native code (directly or through SDKs), add the 16 KB page size emulator image: Google Play requires 16 KB page size support for apps targeting Android 15 or higher, so check that page for the current enforcement dates. - Ship to internal testing first and promote only builds with a clean pre-launch report. Newer personal developer accounts must run a closed test before production access anyway; see the 12 testers for 14 days guide.
- Monitor the review account with a scheduled login check so expired passwords never reach a reviewer.
- Plan target SDK upgrades well before the target API level deadline forces a rushed update.
AI-assisted checks help with the tedious parts: grouping obfuscated stack traces, spotting blank screens in pre-launch screenshots and checking review notes for gaps. A human still decides the fix. appsubmitter.io combines both in your CI/CD and submission workflow – start with a free consultation call or book the Android service.
Template: how to reply to the Google Play review team
Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.
Subject: Appeal – [App name] ([package name]), version code [version code] Hello Google Play team, Thank you for reviewing [App name]. On [date], version code [version code] was rejected under the Broken Functionality policy. We have investigated carefully and believe the app works as intended, so we kindly ask for a second review. What we checked: - We installed version code [version code] from our internal testing track on [device models] running Android [versions] and could not reproduce a crash, freeze or blank screen. - The pre-launch report for this version code shows [no crashes or ANRs / short summary]. - [Possible cause outside the app, e.g. "Our API had scheduled maintenance on [date] between [time] and [time] UTC."] How to access the app: - The sign-in details in Play Console are current (username: [demo username]). The account needs no one-time password and works from any location. - Main features to test: [feature 1], [feature 2]. - [If hardware is required: Settings > Demo mode simulates the device.] Evidence: screen recording of the full flow on version code [version code]: [link]. If the problem occurred on a specific screen or device, we would be grateful for the details so we can fix it right away. Kind regards, [Your name], [Company] – [contact email]
Checklist before you resubmit
- The exact bundle you submit was installed from an internal testing track (Play-signed, unlike internal app sharing) on a clean device.
- The R8-minified release build launches, signs in and completes every main feature without crashing or freezing.
- The pre-launch report for the new version code shows no crashes, ANRs or blank screens.
- Sign-in details are current, reusable, in English, location-independent and need no one-time password.
- The demo account contains realistic data, so no main screen is empty.
- The release variant uses the production backend with a valid TLS certificate and no geo-blocking.
- The app signing key SHA-1 is registered in Firebase and Google Cloud, and Google Sign-In works in the Play-delivered build.
- In-app products are active and the paywall can be passed with the access details provided.
- Denying each runtime permission shows a helpful message instead of a crash.
- The versionCode is higher than the rejected one and the non-compliant bundle is deactivated on every track.
Frequently asked questions
Why does Google say my app crashes when it works on my phone?
Where do I enter demo login details for the Google Play review?
Do Android vitals crash and ANR thresholds cause a rejection?
Does a Broken Functionality rejection hurt my developer account?
My app needs special hardware. How can the reviewer test it?
Should I appeal or fix and resubmit?
Official source: Google Play Developer Policy – Functionality, Content, and User Experience (Broken Functionality). Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.