Fix ‘Device Isn’t Compatible’ in Google Play Closed Testing

What ‘your device isn't compatible with this version' actually means

Short answer: the message is not coming from your test track. Play compares your uploaded bundle's manifest and your Console device rules against the tester's exact device, and when something does not match it hides the install. Four things cause it: a minimum Android version above the tester's phone, a required hardware feature the phone does not report, no native binary for the phone's CPU, or a device excluded in Play Console. Google's filter documentation is explicit that an incompatible app is hidden even from a direct link: “Otherwise, Google Play hides your application from search results and category browsing, even if a user specifically requests the app by clicking a deep link that points directly to the app's ID within Google Play.” Your opt-in link is exactly that kind of deep link, which is why a filtered tester gets a listing with no Install button instead of an error.

Device targeting is decided in two places, and knowing which one you are fighting is most of the work. Play Console's help page states it plainly: “The set of device models on which users can discover and install your app on Google Play is known as your targeted devices. Your targeted devices are determined by two things: your manifest declarations and your console exclusion rules.” A manifest problem needs a new bundle. An exclusion problem needs one toggle. Guessing which one you have is what turns a two-minute fix into a two-week delay.

Work the causes in this order. Every step below is cheaper than the one after it, and the first two usually end the investigation.

1. Get the tester's exact model code and Android version from the phone (Settings > About phone).
2. Find that model in Play Console under Monitor and improve > Reach and devices > Device catalog, and read its status plus its per-track status.
3. If the status is Unsupported, open the device details and read which manifest declaration caused it.
4. If the status is Manually excluded or Excluded by rule, fix the exclusion instead of the code.
5. If the device is Supported and still fails, stop looking at compatibility: check the Play account, the track state, and Play Store cache.
6. Only after a real manifest cause is identified, change the bundle: required=false for optional features, a lower minimum SDK if the code allows it, or every CPU architecture you ship.

Check the tester's device before you change anything

One data point resolves most of these cases: the tester's model code. On the phone it sits under Settings > About phone > Model number, sometimes as a marketing name plus a code such as SM-A136U1. Search that code in the Device catalog and open the device details. Two fields matter — the device's overall status, and the per-track status. Google notes that device support is shown per track “because it is declared in your manifest”, so a bundle that requires more in closed testing than in production can leave the same phone supported on one track and unsupported on another.

The status vocabulary is precise, and it maps to the four causes:

• Supported — nothing in the manifest or in Console blocks this device. Compatibility is not your problem.
• Unsupported — the device is missing a feature or property the bundle requires, such as an SDK level, a sensor, or a screen size. This is a manifest problem and it needs a new release.
• Manually excluded — this model was excluded in Console, by you or by a teammate.
• Excluded by rule — a RAM, SoC, or Android Go exclusion rule matches the device. Some models show as partially excluded when only some variants match.

Android Developers documents the detail that saves the most time here: in the Device catalog, “Excluded device entries specify the manifest declarations that caused the exclusion.” You do not have to guess which permission or feature did it — open the device and read the reason. You can also export the list from View and download supported devices; the CSV includes each device's ABIs, Android SDK versions, and OpenGL ES version, which is enough to check a specific phone against what your bundle declares.

Cause 1: the minimum Android version is higher than the tester's phone

A bundle declares a minimum API level, and Play will not offer it to a device below that level. Google's own example is blunt: with minSdkVersion="3", a user on an API level 2 device gets no listing at all. In the Device catalog this appears as Unsupported, with the SDK level named as the reason.

Two things trip people up. First, the value that counts is the merged manifest of the artifact you actually uploaded — not the number in your app's Gradle file before merging, and not the default your cross-platform toolchain advertises in its docs. Dump the artifact instead of trusting the source tree: aapt2 dump badging app.apk. Android Developers says that output “lists all declared permissions and all explicitly and implicitly required features, which determines the filtering rules applied by Google Play.”

Second, target SDK level is not a device compatibility filter. A phone on Android 12 can install an app targeting API 36 as long as it clears the minimum. Target API level is a Play distribution requirement checked at upload and review, not a per-device gate, and confusing the two sends developers to rewrite a manifest that was never the problem.

Fix it one of two ways. Lower the minimum only if the code paths really support it — a lower floor with API calls guarded by version checks is fine; a lower floor that crashes on launch is worse than a filtered tester. Otherwise keep the minimum and give that tester a device at or above it, and write the requirement into your tester instructions so nobody wastes a week on it.

Cause 2: a required feature the tester's device does not have

<uses-feature> is where most silent filtering happens, because the default is the opposite of what people assume. Google documents that “the default value for android:required is ‘true’”, and that “if any required feature isn't supported by the device, Google Play filters the application so that it isn't visible to the user or available for download.” A feature declared without the attribute filters every device that lacks it.

Permissions do the same thing on their own. Play does not filter on <uses-permission> directly, but it reads permissions to infer hardware requirements: “if an application requests the CAMERA permission but does not declare a <uses-feature> element for android.hardware.camera, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.” A permission added for one screen can therefore narrow distribution across the whole app.

The permission-to-feature pairs that hit closed tests most often:

• BLUETOOTH or BLUETOOTH_ADMIN → android.hardware.bluetooth. Wi-Fi-only tablets, some Android TV boxes, and older Chromebooks report no Bluetooth feature, so they are filtered.
• RECORD_AUDIO → android.hardware.microphone. TV boxes and low-cost tablets commonly have no microphone.
• CALL_PHONE, READ_SMS, or any SMS permission → android.hardware.telephony. Wi-Fi-only tablets are filtered.
• ACCESS_WIFI_STATE → android.hardware.wifi. Ethernet-only TV and desktop-mode devices are filtered.
• CAMERA → android.hardware.camera and android.hardware.camera.autofocus. A device with a fixed-focus camera still gets filtered by the autofocus requirement.

The full mapping is in Google's <uses-feature> reference under implied features. Fix by declaring the feature with android:required="false" and handling its absence at runtime. Google's own example for the camera permission is two declarations, one for android.hardware.camera and one for android.hardware.camera.autofocus, both with required="false", because both are implied by the same permission. Confirm what the tester's device actually reports with adb shell pm list features before you ship the fix.

One caveat for older projects: location permissions stopped implying GPS and network location as required features once the target API level passed 20, so a location permission alone normally will not filter a device today. Bluetooth, camera, microphone, and telephony still do.

Cause 3: the bundle has no native binary for the tester's CPU

If your app carries native code — React Native or Hermes builds with native modules, Flutter with native plugins, Unity, or any NDK library — Play delivers only the split that matches the device's CPU. Google: “An application that includes native libraries that target a specific CPU architecture (ARM EABI v7 or x86, for example) are visible only on devices that support that architecture.”

In practice an arm64-v8a-only bundle is invisible to x86 and x86_64 devices, which covers most Android emulators, many Chromebooks, and a scattering of older or unusual phones. This is the usual explanation for a build that installs perfectly on the developer's own phone and fails on a tester's emulator.

Fix by shipping every ABI you intend to support, or by removing the native dependency that forced a single one. Then test on an ARM phone rather than only an emulator. Emulator-only testing hides this failure completely, and it also produces the thin session record Google reviews later; the Flutter and React Native closed-testing notes cover the artifact side of that in more detail.

Cause 4: the device is excluded in your Play Console

Console exclusions sit above the manifest: “exclusions override supported devices declared in your app's manifest.” They are managed per app, so an exclusion added to protect users from a production crash applies to your closed test as well. The usual sources are a RAM or SoC rule added to keep a heavy app off low-spec hardware, an Android Go exclusion, or a manual exclusion a teammate added while chasing a device-specific bug.

Fix: open the Device catalog, switch to the Excluded devices tab, search the model, open its details, and remove the exclusion. For rules, use Manage exclusion rules and delete or narrow the RAM or SoC rule. An exclusion change applies to the app immediately — you do not need to upload a new bundle — which makes this the cheapest fix on the list when it is the cause.

If you cannot remove the exclusion quickly and the 14-day clock is running, do not let the tester idle. Move them to internal testing to verify the build, and keep the closed test on devices that can install. Internal testing does not satisfy the closed-test requirement, and internal testers are exempt from exclusions, so the closed test still needs its twelve opted-in testers regardless.

When it is not a compatibility problem at all

If the catalog says Supported, the message is coming from somewhere else. The lookalikes, and how to tell them apart:

• The tester's country is not in your distribution list. Symptom: the listing is missing entirely rather than showing without an Install button.
• The wrong Google account is signed in on the phone. Symptom: the opt-in page appears but the test never activates, or the tester sees a different build than the one on the track.
• The release is still in review, or the track is paused. Symptom: the opt-in link resolves but Play serves an older build or nothing. Check the track state in Console before blaming the manifest.
• Play Store data is stale. Symptom: the message survives a correct fix. Force stop the Play Store app, clear its storage, and retry before concluding the fix failed.
• The tester is enrolled in two tracks at once. Symptom: inconsistent builds across attempts. Remove them from the track you are not measuring.

None of these need a new bundle, and each one costs less to check than a release upload. That is why the device lookup comes first.

What an incompatible device costs you in the 12-tester count

A tester who cannot install still occupies a slot. They may show as opted in while producing no sessions, and that is precisely the pattern Google names when it sends an app back for more testing: “reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period.” The number on the Dashboard can look satisfied while the record Google reviews is thin.

Based on our analysis of 1,500+ closed-testing campaigns, install blocks from device filtering cluster in two places: bundles whose merged manifest requires a hardware feature nobody on the team remembers adding, and device-catalog exclusions added months earlier to fix a production crash. That is a qualitative pattern from our own campaign records, not a Google statistic, and we do not derive a pass rate from it. The consequence inside a single campaign is concrete: every tester who cannot install has to be replaced, and a replacement tester's own 14 days only start when they opt in.

If the count looks wrong rather than the install, start with 0 testers currently opted in. If the count is right and the button is still missing, read Apply for Production Button Not Showing. And once your testers can install, make sure they actually use the app — do testers need to open the app every day covers what Google means by engagement.

FAQ

Can I make Play ignore my manifest requirements for testers? No. Filtering is applied per device against the artifact you uploaded, so the only levers are the merged manifest and Console exclusions. Internal testing is the one exception, because device exclusion rules do not apply to internal testers.

Does a filtered tester count toward the 12? They can appear as opted in without installing or producing sessions. Because Google reviews tester engagement when it assesses the application, treat them as missing and replace them rather than counting them.

Does the message mean my app is broken on that phone? No. It means Play decided the device does not match the bundle. It is a distribution decision made before install, not a crash report or a review outcome.

Why does the build install from internal testing but not from closed testing? Either the device is excluded in Console, which does not apply to internal testers, or the two tracks carry different bundles with different requirements. Compare the per-track status for that device before changing anything.

Does fixing this need a new review? A new bundle goes through the normal release review for its track. An exclusion change in Console does not involve a new artifact and takes effect for the app without a re-upload.