Skip to content

"Your device isn't compatible with this version" in a closed test

Updated

Your tester opted in, opened the app in the Play Store, and instead of an install button got "Your device isn't compatible with this version". The account and the link are fine. Google Play is deciding, from your build and your Play Console settings, that this particular phone shouldn't get the app.

The good news: unlike most closed testing problems, this one leaves a clear trace in Play Console. You can usually find the exact reason in two minutes.

On the Play website, the same situation shows the tester's device grayed out. Google explains that this "usually occurs because the app isn't available in your location or designed for your device's screen size or version of Android" (Google Play Help).

One tester or everyone?

PatternMost likelyCheck first
One tester, older or unusual phoneMinimum Android version, a hardware feature, CPU architectureStep 1, then causes 1 to 3
Everyone, right after a new buildSomething you added to the manifest or a new native libraryCauses 1 to 3 on the new build
Works in internal testing, fails in closedDevice exclusion rulesCause 4
Phone with a custom ROMDevice integrityCause 6

Step 1: look the device up in the Device catalog

Ask the tester for their exact phone model and Android version (Settings > About phone). Then open Monitor and improve > Reach and devices > Device catalog in Play Console and search for the model (Play Console Help).

The status tells you which way to look:

  • Unsupported: your manifest requires a feature or property the device doesn't have, such as an SDK level, a screen size or a sensor.
  • Partially supported: some variants of that model work and others don't, often because of the Android version or RAM.
  • Excluded by rule, Partially excluded by rule, Manually excluded: you, or someone on your team, excluded it in Play Console.

Check the status for the closed testing track. Google shows support per track, because each track can carry a different build. "If the beta version of your app requires more features than the production version, you may notice that a device is supported in production but not in beta."

Causes and fixes, in the order to try them

1. Your minimum Android version is too high

If minSdk is above the tester's Android version, Google Play won't show the app on that phone (Android Developers).

Fix: lower minSdk if your code allows it, or accept that this tester can't be in your 12 and recruit someone on a newer Android version. Don't confuse minSdk with targetSdk: new apps must target API 36, which says nothing about the oldest Android version you support. See target API 36.

2. A hardware feature is marked as required

Each <uses-feature> you declare filters out devices without that hardware. Google's example: an app that declares the light sensor won't be shown on a device without one. Permissions count too: Google Play reads some <uses-permission> elements as implied feature requirements (Android Developers). Asking for the camera permission can make a camera a requirement, even if your app only uses it in one optional screen.

Fix: for every feature your app can live without, declare it explicitly with android:required="false", and check for it at runtime. Then upload a new build with a higher version code.

xml
<uses-feature android:name="android.hardware.camera" android:required="false" />

Libraries and plugins can add permissions to your merged manifest without you noticing. Look at the merged manifest of the release build, not just the file you edit.

3. Your native libraries don't cover the tester's CPU

Google says apps whose native libraries "target a specific CPU architecture (ARM EABI v7 or x86, for example) are visible only on devices that support that architecture" (Android Developers). This bites apps built with engines or frameworks where a build setting drops one architecture to save size.

Fix: check which ABIs your build includes (your build settings, or the folders under lib/ inside the bundle) and include the ones your testers' phones use.

4. You excluded the device in Play Console

Excluded devices "won't be able to see or install your app on Google Play" (Play Console Help). Exclusions can be per model, or by rule on RAM or System on Chip. They apply to the whole app and override your manifest.

Here's the tell: Google says "device exclusion rules don't apply to internal testers" (Play Console Help). If the app works in internal testing on the same phone, check exclusions first.

Fix: in the Device catalog, open Manage exclusion rules and the Excluded tab. Remove the rule or the manual exclusion if it wasn't intended.

5. Screen size or form factor

Screen-size declarations and graphics requirements (such as texture compression formats) also filter devices (Android Developers). A tester on a tablet, a Chromebook or a TV device may be filtered while phones work. If your app is phone only, that's expected: recruit testers on phones.

6. Device integrity checks

Google lets you restrict distribution to devices that pass integrity checks, from Test and release > App integrity. Google notes that some devices report a certified model name but don't pass Play Integrity checks (Play Console Help). If you turned the restriction on, testers on such devices can't get the app. Keep it on if your app needs it, and recruit testers on stock devices.

7. You fixed it, but the tester still sees the old message

Any fix means a new release, and a new release takes time to reach testers. On the tester's side, the Play Store app can show stale information. Google's Play Help suggests clearing the Play Store cache as the first fix for download problems (Google Play Help).

Does a fix restart the 14 days?

Google's help doesn't mention testers having to opt in again after a new build. It actually recommends updating your app in closed testing while you fix what testers report (Play Console Help). The 14 days only count testers who stay opted in, so a tester who can't install may leave. Replace them early.

A device problem found during the closed test is exactly what the test is for. Write it down: Google's production access form asks what you changed based on the test. See Item not found if the store shows no app at all, and the setup guide to check your track from scratch.

When to contact Google

If the Device catalog shows the tester's model as Supported on your closed testing track, there's no exclusion, and the message persists for days after a cache clear, contact Google through the Contact us link in Play Console Help. Include the device model, Android version, package name and track. For the big picture, see the Google Play closed testing guide.

Frequently asked questions

What does Your device isn't compatible with this version mean in a closed test?

Google Play filtered that phone out. The usual reasons are your manifest (minimum Android version, required hardware features, CPU architecture) or exclusion rules you set in Play Console.

How do I find out why a specific device is incompatible?

Open Device catalog in Play Console, search the tester's device model and check its status for your closed testing track. Unsupported means your manifest requires something the device doesn't have.

Why does the same phone work in my internal test?

Google says device exclusion rules don't apply to internal testers. If a phone works in internal testing and not in closed testing, check your exclusion rules first.

Can I ship a fixed build during the 14 days?

Yes. Google encourages updating your app in closed testing while you fix issues. Use a higher version code so testers receive the new build.

Sources

  1. support.google.com/googleplay/android-developer/answer/7353455
  2. developer.android.com/google/play/filters
  3. support.google.com/googleplay/android-developer/answer/9845334
  4. support.google.com/googleplay/android-developer/answer/14151465
  5. support.google.com/googleplay/answer/2851648
  6. support.google.com/googleplay/answer/14121800