App Quality: Broken Functionality policy

App Quality: Broken Functionality (Crashes, Won't Install, Unresponsive)

High RiskMedium DifficultyTypical Fix: 1-3 days0 Reports

Also known as:Violation of Broken Functionality policyApps that don't installApps that install, but don't loadApps that load, but are not responsiveThe item that you were attempting to purchase could not be found

Our Take

Google rejects apps that crash, force close, freeze, or otherwise function abnormally under its Broken Functionality policy, which explicitly bars apps that don't install, install but don't load, or load but are not responsive.

This is Play's rough equivalent to Apple's App Completeness guideline, and it's frequently triggered by the automated Pre-launch report (powered by Firebase Test Lab) catching crashes or ANRs on specific device models, or by a reviewer hitting a broken in-app purchase flow, dead link, or unresponsive core feature during manual testing.

A common blind spot is IAP/paywall failures caused by geo-availability misconfiguration — the reviewer's test region can't fetch your product listing, which reads as broken functionality even though the app works fine for real users elsewhere.

Resolution Guide

Pull the Pre-launch report

In Play Console go to Test and release > Testing > Pre-launch report. It runs Firebase Test Lab's Robo test across a range of devices and surfaces crash logs, ANRs, and screenshots at the point of failure — start here before guessing.

Check Android vitals for crash/ANR spikes

Quality > Android vitals shows your User-perceived crash rate and ANR rate. Google's "bad behavior" thresholds are ≥1.09% crash rate (or ≥8% on a single device model) and ≥0.47% ANR rate (or ≥8% on a single device model) — exceeding these can trigger reduced discoverability independent of a manual rejection.

Reproduce on the flagged device/OS combination

Pre-launch reports list the specific device model and Android version where the failure occurred. Test on that exact configuration (physical device or matching emulator image) rather than only your primary dev device.

Verify every advertised feature end-to-end, including IAP

If the rejection cites a purchase flow ("item could not be found"), confirm your in-app products/subscriptions are published and available in every country your store listing targets — a product missing in the reviewer's test region reads as broken functionality.

Check for unhandled exceptions and network-failure states

Wrap network calls and config fetches (especially anything gating your paywall or core screen) in proper error handling so a timeout or empty response doesn't crash or freeze the UI.

Use the pre-review automated check before submitting

On the Publishing overview page, under "Changes not yet sent for review," Google now runs a fast automated check (~15 minutes) that can catch some Broken Functionality issues before you submit for full review.

Test through a closed or internal testing track

Distribute a release candidate via Internal testing or Closed testing and have real testers exercise every core flow (install, first launch, primary feature, IAP if applicable) on varied devices before promoting to production.

Resubmit only after confirming the fix

Re-run the Pre-launch report on the new build and confirm crash-free/ANR-free behavior on the previously flagged device before resubmitting for review.

Example Rejection Email

From:Google Play Developer Support

Subject:Policy violation - App Quality: Broken Functionality (Crash

Google Play Console — Policy status Issue found: Violation of Broken Functionality policy We don't allow apps that crash, force close, freeze, or otherwise function abnormally. During review, we found that your app: - Crashed or became unresponsive during normal use, OR - Failed to complete a core advertised feature Details: "The item that you were attempting to purchase could not be found." This may indicate your in-app product configuration is not available in the region used for review, or a broken payment flow. Action required: - Reproduce and fix the crash, ANR, or broken feature - Verify all in-app purchase products are configured and available in every country where your app is distributed - Test your app end-to-end using the Pre-launch report before resubmitting - Resubmit your app for review once verified Learn more: https://support.google.com/googleplay/android-developer/answer/9898783

Consider Appealing

Appeal only if you have evidence the crash was environment-specific to the reviewer's test conditions (e.g., a region-locked IAP product that works correctly for your actual user base, or a Pre-launch report showing no reproducible crash on the cited device after investigation). Include your Android vitals crash/ANR rate for the affected device, Pre-launch report screenshots showing a clean run, and a changelog of what you fixed. If you can reproduce the crash yourself, don't appeal — fix it and resubmit, since Google's review notices rarely include full stack traces and repeated appeals without a code fix don't change the outcome.

Generate Appeal

Before & After

Before — Rejected

A subscription app's paywall screen calls a remote config endpoint to fetch pricing; when that call times out or the reviewer's test region has no matching product ID, the screen throws an unhandled exception and the app force-closes.

After — Approved

The developer adds a timeout + fallback UI state ("Pricing unavailable, try again") instead of crashing, and confirms all subscription products are published in every country listed in the store listing's distribution settings.

What changed: Handling the failure state gracefully and matching product availability to actual distribution countries eliminates both the crash and the region-specific 'item could not be found' error that Google's reviewers read as Broken Functionality.