Why does the Google Play store say my Android app is incompatible with my own device?
Asked Answered
T

15

102

I am hesitant to ask this question, because it appears as though many people have a similar problem and yet I have found no solution that solves my particular instance.

I have developed an Android app (link to the actual app) and have uploaded it to the Play store. The Play store says

"This app is incompatible with your XT Mobile Network HTC HTC Wildfire S A510b."

Of course that is the phone on which I developed the app, so it ought to be compatible. Some people with other devices say that it reports compatible, others say it reports incompatible, but I can find no trend. (Apparently I don't know very many people with Android devices.)

I have tried the following:

  • moving a large-ish file out of the res/raw directory as suggested by this answer. The only file in there was a ~700 kB text file, but I moved it to assets/ with no apparent change.

  • adding the following two feature assertions:

    <uses-feature android:name="android.hardware.faketouch" />
    <uses-feature android:name="android.hardware.touchscreen" android:required="false" />
    

    thinking that maybe my phone doesn't claim to support the usual android.hardware.touchscreen feature, but again, with no apparent change.

When uploading the APK to the Play store, the only filter that it reports as active is the android.hardware.faketouch feature.

The following is the output of aapt dump badging bin/NZSLDict-release.apk:

package: name='com.hewgill.android.nzsldict' versionCode='3' versionName='1.0.2'
sdkVersion:'4'
targetSdkVersion:'4'
uses-feature:'android.hardware.faketouch'
uses-feature-not-required:'android.hardware.touchscreen'
application-label:'NZSL Dictionary'
application-icon-160:'res/drawable/icon.png'
application: label='NZSL Dictionary' icon='res/drawable/icon.png'
launchable-activity: name='com.hewgill.android.nzsldict.NZSLDictionary'  label='NZSL Dictionary' icon=''
main
other-activities
supports-screens: 'small' 'normal' 'large'
supports-any-density: 'true'
locales: '--_--'
densities: '160'

and for completeness, my manifest file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.hewgill.android.nzsldict"
      android:versionCode="3"
      android:versionName="1.0.2">
    <uses-sdk android:minSdkVersion="4" android:targetSdkVersion="4" />
    <uses-feature android:name="android.hardware.faketouch" />
    <uses-feature android:name="android.hardware.touchscreen" android:required="false" />
    <application android:label="@string/app_name"
        android:icon="@drawable/icon">
        <activity android:name="NZSLDictionary"
                  android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <activity android:name=".WordActivity" />
        <activity android:name=".VideoActivity" />
        <activity android:name=".AboutActivity" />
    </application>
</manifest> 

In the "Device Availability" section of the Play store, I can see that all the HTC devices, including the Wildfire S, are supported except for "G1 (trout)" and "Touch Viva (opal)", whatever those are. Actually I see that both "Wildfire S (marvel)" and "Wildfire S A515c (marvelc)" are listed as supported, but my "Wildfire S A510b" is not specifically mentioned. Can this sort of sub-model identifier matter that much? I have been able to download several other apps from Google Play to my phone with no problems.

The only thing I haven't done at this point is wait 4-6 hours after uploading the latest version (as in this comment) to see whether it still says it's incompatible with my phone. However, the Play store page currently shows 1.0.2 which is the latest I have uploaded.

Tied answered 7/5, 2012 at 2:18 Comment(5)
Something that helped me out a ton with phone related issues was to setup ACRA: code.google.com/p/acra I run it on first start of the application to pull down a phone's full specs, and use the handleSilentException method to report silently. It will at least tell you which hardware the app is working on.Purulent
@GavinMiller: Thanks, but I'm not sure that will help when the Play store refuses to deliver the app at all.Tied
Maybe I misunderstood your comment: "Some people with other devices say that it reports compatible, others say it reports incompatible, but I can find no trend." If many people you don't know can download and install the app, you can collect a larger pool of hardware data to try and form a trend. Thus alleviating the "I don't know very many people with Android devices." issue.Purulent
@GavinMiller: However, that will only tell me which devices Google Play believes it can be installed on, and will give no information about which devices Google Play believes it can't be installed on. Besides, even knowing with certainty which devices were ok and which weren't, wouldn't really help me solve this problem.Tied
check this solution its working for me https://mcmap.net/q/212213/-android-app-is-supported-by-0-devicesIre
T
87

The answer appears to be solely related to application size. I created a simple "hello world" app with nothing special in the manifest file, uploaded it to the Play store, and it was reported as compatible with my device.

I changed nothing in this app except for adding more content into the res/drawable directory. When the .apk size reached about 32 MB, the Play store started reporting that my app was incompatible with my phone.

I will attempt to contact Google developer support and ask for clarification on the reason for this limit.

UPDATE: Here is Google developer support response to this:

Thank you for your note. Currently the maximum file size limit for an app upload to Google Play is approximately 50 MB.

However, some devices may have smaller than 50 MB cache partition making the app unavailable for users to download. For example, some of HTC Wildfire devices are known for having 35-40 MB cache partitions. If Google Play is able to identify such device that doesn't have cache large enough to store the app, it may filter it from appearing for the user.

I ended up solving my problem by converting all the PNG files to JPG, with a small loss of quality. The .apk file is now 28 MB, which is below whatever threshold Google Play is enforcing for my phone.

I also removed all the <uses-feature> stuff, and now have just this:

<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="15" />
Tied answered 9/5, 2012 at 22:5 Comment(9)
Very interesting and valuable information. And so annoying that this is not documented anywhere.Basic
Indeed, I would never have even known about the problem if I didn't happen to have a Wildfire phone.Tied
I have 3 games: 32MB, 35MB and 44MB in size. My own HTC bravo sees the first two games and doesn't see the third on the store. My friend's HTC desire S sees only the first game. So, apparently the size of the games should be under 33MB or so to be visible to most (?) devices. Unfortunately I saw this reply too late and didn't know about the issue for months... I was sure it depends on the processor type of the device, supported OpenGL version, limitations set in manifest or something. Sigh..Kuehnel
I am having a similar problem. My minSdkVersion is 10, but an RCA tablet running 4.2.2 is "not compatible". On another device the install only shows as about 10MB. I do have a uses-feature declared for opengl es2, but I also declared required=false. Is Play maybe not honoring the required attribute?Bromine
It's insane that Google does not list the reason for the incompatibility on the Play store. I always assumed that at least the app developers would have received this information and would have consciously chosen not to support my device. How has the situation remained like this for so long?Hocker
I have a feeling this will come in handy some day! Bookmarking! :DRevanche
@GregHewgill Hello Greg. I have contacted google support about a similar kind of an issue. As my app size was just 5 MB i was looking at different options why Google Play filtered my application on a particular device. It's been 72 hours since i've contacted them and they didn't come back with any sort of explanation. Is there any way i could contact Google Support other than the normal Contact Us?Selffulfillment
@hemanthkumar did you ever get the response from Google support team? I am on the same boat as you were.Feigin
@RohitSingh sorry, I do not remember exactly, this was a while back.Selffulfillment
N
17

I ran into this as well - I did all of my development on a Lenovo IdeaTab A2107A-F and could run development builds on it, and even release signed APKs (installed with adb install) with no issues. Once it was published in Alpha test mode and available on Google Play I received the "incompatible with your device" error message.

It turns out I had placed in my AndroidManifest.xml the following from a tutorial:

<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" />
<uses-permission android:name="android.permission.CAMERA" />

Well, the Lenovo IdeaTab A2107A-F doesn't have an autofocusing camera on it (which I learned from http://www.phonearena.com/phones/Lenovo-IdeaTab-A2107_id7611, under Cons: lacks autofocus camera). Regardless of whether I was using that feature, Google Play said no. Once that was removed I rebuilt my APK, uploaded it to Google Play, and sure enough my IdeaTab was now in the compatible devices list.

So, double-check every <uses-feature> and if you've been doing some copy-paste from the web check again. Odds are you requested some feature you aren't even using.

Nival answered 12/11, 2013 at 1:50 Comment(3)
Thank you ! I was using another <uses-feature> : <uses-feature android:name="android.hardware.camera2" /> And because of that I had ZERO compatible devices. I removed the line and now have 10000.Kalasky
You can set it to still make use of it, but not require it: <uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />Beerbohm
<uses-feature android:name="android.hardware.camera2" /> makes my app incompatible so I was unable to find the app on playstore. Save my lifeSwanskin
G
12

I have experienced this problem too while developing an application for a customer that wanted to have videos offline available from their application. I have written a blogpost about why the app I worked on for months wouldn't show up in the play store for my device (post can be found here). I found the same as @Greg Hewgill found: Cache partition limitations on some devices.

The journey didn't stop for me there. The customer wanted to have these videos in the application and didn't want the quality of the video to be decreased. After some research I figured out that using expansion files was the perfect solution to our problem.

To share my knowledge with the Android community I held a talk at droidconNL 2012 about expansion files. I created a presentation and sample code to illustrate how easy it can be to start using expansion files. For any of you out there wanting to use expansion files to solve this problem feel free to check out the post containing the presentation and the sample code

Gemstone answered 27/11, 2012 at 17:21 Comment(1)
The Google support link mentioned in your post is now outdated, the new link is support.google.com/googleplay/android-developer/answer/…. Hope you update the article with the latest link and btw, nice post.!!Ledeen
B
8

You might want to try and set the supports-screens attribute:

<supports-screens
    android:largeScreens="true"
    android:normalScreens="true"
    android:smallScreens="true"
    android:xlargeScreens="true" >
</supports-screens>

The Wildfire has a small screen, and according to the documentation this attribute should default to "true" in all cases, but there are known issues with the supports-screens settings on different phones, so I would try this anyway.

Also - as David suggests - always compile and target against the most current version of the Android API, unless you have strong reasons not to. Pretty much every SDK prior to 2.2 has some serious issue or weird behavior; the latter SDK's help to resolve or cover up a lot (although not all) of them. You can (and should) use the Lint tool to check that your app remains compatible with API 4 when preparing a release.

Basic answered 8/5, 2012 at 12:3 Comment(4)
Thanks, I'm awaiting a response from Google developer support for my latest support request. I'll try this after I get a response from them (I don't want to confuse them by uploading yet another APK). Will let you know how this turns out.Tied
Hope you don't have to wait too long. They don't exactly have a reputation for swift responses. :-)Basic
I've gone back and forth a couple of times with them already, but my latest question has gone unanswered for coming up on 22 hours. It's frustrating having to wait, but at least this isn't mission critical or anything.Tied
Just wanted to let you know that I found the issue, see my answer on this question. Thanks for your help.Tied
A
7

Finlay, I have faced same issue in my application. I have developed Phone Gap app for android:minSdkVersion="7" & android:targetSdkVersion="18" which is recent version of android platform.

I have found the issue using Google Docs

May be issue is that i have write some JS function which works on KEY-CODE to validate only Alphabets & Number but key board has different key code specially for computer keyboard & Mobile keyboard. So that was my issue.

I am not sure whether my answer is correct or not and it might be possible that it could be smiler to above answer but i will try to list out some points which should be care while we are building the app.I hope you follow this to solve this kind of issue.

  • Use the android:minSdkVersion="?" as per your requirement & android:targetSdkVersion="?" should be latest in which your app will targeting. see more

  • Try to add only those permission which will be use in your application and remove all which are unnecessary .

  • Check out the supported screen by application

    <supports-screens 
    android:anyDensity="true"
    android:largeScreens="true"
    android:normalScreens="true"
    android:resizeable="true"
    android:smallScreens="true"
    android:xlargeScreens="true"/>
    
  • May be you have implement some costume code or costume widget which couldn't able to run in some device or tab late so before writing the long code first try to write some beta code and test it whether your code will run in all device or not.

  • And I hope Google will publish a tool which can validate your code before the upload the app and also says that due to some specific reason we are not allow to run your app in some device so we can easily solve it.

Asher answered 25/10, 2013 at 7:23 Comment(0)
E
7

Permissions that Imply Feature Requirements

example, the android.hardware.bluetooth feature was added in Android 2.2 (API level 8), but the bluetooth API that it refers to was added in Android 2.0 (API level 5). Because of this, some apps were able to use the API before they had the ability to declare that they require the API via the system.

To prevent those apps from being made available unintentionally, Google Play assumes that certain hardware-related permissions indicate that the underlying hardware features are required by default. For instance, applications that use Bluetooth must request the BLUETOOTH permission in a element — for legacy apps, Google Play assumes that the permission declaration means that the underlying android.hardware.bluetooth feature is required by the application and sets up filtering based on that feature.

The table below lists permissions that imply feature requirements equivalent to those declared in elements. Note that declarations, including any declared android:required attribute, always take precedence over features implied by the permissions below.

For any of the permissions below, you can disable filtering based on the implied feature by explicitly declaring the implied feature explicitly, in a element, with an android:required="false" attribute. For example, to disable any filtering based on the CAMERA permission, you would add this declaration to the manifest file:

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


<uses-feature android:name="android.hardware.bluetooth" android:required="false" />
<uses-feature android:name="android.hardware.location" android:required="false" />
<uses-feature android:name="android.hardware.location.gps" android:required="false" />
<uses-feature android:name="android.hardware.telephony" android:required="false" />
<uses-feature android:name="android.hardware.wifi" android:required="false" />

http://developer.android.com/guide/topics/manifest/uses-feature-element.html#permissions

Enceinte answered 3/11, 2015 at 13:49 Comment(1)
Thank you! I had no idea uses-permission defaulted to the feature being required.Southerner
S
6

I have a couple of suggestions:

  1. First of all, you seem to be using API 4 as your target. AFAIK, it's good practice to always compile against the latest SDK and setup your android:minSdkVersion accordingly.

  2. With that in mind, remember that android:required attribute was added in API 5:

The feature declaration can include an android:required=["true" | "false"] attribute (if you are compiling against API level 5 or higher), which lets you specify whether the application (...)

Thus, I'd suggest that you compile against SDK 15, set targetSdkVersion to 15 as well, and provide that functionality.

It also shows here, on the Play site, as incompatible with any device that I have that is (coincidence?) Gingerbread (Galaxy Ace and Galaxy Y here). But it shows as compatible with my Galaxy Tab 10.1 (Honeycomb), Nexus S and Galaxy Nexus (both on ICS).

That also left me wondering, and this is a very wild guess, but since android.hardware.faketouch is API11+, why don't you try removing it just to see if it works? Or perhaps that's all related anyway, since you're trying to use features (faketouch) and the required attribute that are not available in API 4. And in this case you should compile against the latest API.

I would try that first, and remove the faketouch requirement only as last resort (of course) --- since it works when developing, I'd say it's just a matter of the compiled app not recognizing the feature (due to the SDK requirements), thus leaving unexpected filtering issues on Play.

Sorry if this guess doesn't answer your question, but it's very difficult to diagnose those kind of problems and pinpoint the solution without actually testing. Or at least for me without all the proper knowledge of how Play really filters apps.

Good luck.

Shanel answered 7/5, 2012 at 3:41 Comment(8)
Thanks, that gives me some specific ideas. Originally I didn't have any <uses-feature> tags at all, that was an attempt to make it compatible with more devices rather than fewer. I will try changing SDK version tags, that seems like the most likely approach. I should add that I used minSdkVersion="4" because that version no longer implied some permissions (read phone state, modify sd card) that my app doesn't need.Tied
Changing the SDK versions to android:minSdkVersion="5" android:targetSdkVersion="15" did not help either. I have contacted Google Play developer support and hopefully they can tell me why. It sure would be nice if the reason for filtering were shown on the Play app page.Tied
Yes, that would be great. Meanwhile, did you try setting faketouch as required= false ?Shanel
The latest iteration removes all <uses-feature> tags because Google support told me the reason it was unavailable for my device was because of the android.hardware.faketouch feature. That seems ridiculous, especially since one of my previous versions didn't have the <uses-feature> tags either, but whatever. I'm awaiting their response and I don't want to confuse them by uploading yet another version. It would be nice if there were a way to test this without repeatedly uploading and publishing new APKs.Tied
I wouldn't say ridiculous, because it's a flag added on later sdk versions (api 11), hence why I suggested compiling against and targeting api15 (remember to change your project.properties, not just manifest). I'm still surprised setting it as required = false didn't work though.Shanel
I did discover that I was using quite an old SDK. However, updating to the latest SDK, using api 15 (changing both project.properties and manifest) didn't seem to help. My current plan is to publish a dead simple fresh "hello world" application and see if that works; if so, then start adding stuff until I find out what the problem is. If the test application doesn't work, open a new support request with Google.Tied
My hello-world test app is compatible with my phone. I should have a resolution for this soon. Can't wait.Tied
Just wanted to let you know that I found the issue, see my answer on this question. Thanks for your help.Tied
N
6

To give an extra solution to the above 'This app is incompatible with your...' problem, let me share my solution for a different problem cause. I tried installing an app on a low-end Samsung Galaxy Y (GT-S6350) device and got this error from the Play store. To test various AndroidManifest configurations, I created an account and followed the routine as described in https://mcmap.net/q/212214/-my-android-app-shows-as-quot-this-item-is-not-compatible-with-your-device-quot until my device showed up in the supported device list.

It turned out that a lot of devices become incompatible when you use the Camera permission:

<uses-permission android:name="android.permission.CAMERA" />

When I removed that specific permission, the application was available for 1180 devices instead of 870. Hope it will help someone

Newberry answered 28/6, 2012 at 11:29 Comment(1)
Maybe, this can help: <uses-permission android:name="android.permission.CAMERA" /> <uses-feature android:name="android.hardware.camera" android:required="false" />Racehorse
E
3

Typical, found it right after posting this question in despair; the tool I was looking for was:

$ aapt dump badging <my_apk.apk>
Era answered 22/4, 2013 at 11:29 Comment(1)
It looks like you meant to post this answer on #16146427 instead.Tied
C
3

Though there are already quite a few answers, I thought my answer might help some who have exactly the same problem as mine. In my case, the problem is caused by the following permissions added per the suggestion of an ad network:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

The consequence of the above permissions is that the following features are added automatically:

android.hardware.LOCATION
android.hardware.location.GPS
android.hardware.location.NETWORK

The reason is that "Google Play attempts to discover an application's implied feature requirements by examining other elements declared in the manifest file, specifically, elements." Two of my testing devices do not have the above features, so the app became incompatible with them. Removing those permissions solved the problem immediately.

Creditable answered 26/2, 2015 at 14:13 Comment(1)
This is one of the most commonly used permission.Feigin
G
2

I found an additional way in which this problem occurs:
My LG phone's original OS was Froyo (Android 2.2) and was updated to ICS (Android 4.0.4). But the Google Play Developers' Console shows that it detects my phone as a Froyo device. (Google Play did not allow the app to be downloaded because of the false 'incompatibility', but it somehow still detects the installation.)

The phone's settings, in 'software', shows ICS V4.0.4. It seems that the Google Play server info for the phone is not updated to reflect the ICS update on the device. The app manifest minSDK is set to Honeycomb (3.0), so of course Google Play filters out the app.

Of addition interest:
The app uses In-app Billing V3. The first time through IabHelper allows the app to make purchases through the Google Play service. But after the purchase is made, the purchase is NOT put in the inventory and IabHelper reports no items are owned. Debug messages show a 'purchase failed' result from the purchase even though the Google Play window announces "purchase successful."
Goffer answered 17/7, 2013 at 13:53 Comment(0)
C
1

I also had the same problem. I published an App in Test mode created with React Native 59. it wasn't compatible for certain tester. The message wasn't clear about why the app is not compatible , after i figured out that i restricted the app to be available only for certain country . that was the problem, but as i said the message wasn't clear. in Play Store WebApp the message is: "this app is not compatible with your device". in the mobile app the message "This app is not available in your country"

Cymogene answered 3/12, 2019 at 13:10 Comment(0)
P
0

I had the same problem. It was caused by having different version codes and numbers in my manifest and gradle build script. I resolved it by removing the version code and version number from my manifest and letting gradle take care of it.

Peltate answered 16/6, 2014 at 18:46 Comment(0)
F
0

If you're here in 2020 and you think the device receiving the error message should be compatible:

Several other major apps have run into this including Instagram (1B+ installs) and Clash of Clans (100M+ installs). It appears to be an issue with Google's Android operating system.

To fix the “your device is not compatible with this version” error message, try clearing the Google Play Store cache, and then data. Next, restart the Google Play Store and try installing the app again.

[https://support.getupside.com/hc/en-us/articles/226667067--Device-not-compatible-error-message-in-Google-Play-Store]

Here is a link to Google's official support page that you can link to your users on how to clear the cache: https://support.google.com/googleplay/answer/7513003

Flotation answered 11/6, 2020 at 14:10 Comment(0)
L
0

In Android some permissions <uses-permission> will imply <uses-feature> requirements to the app.

For example <uses-permission android:name="android.permission.BLUETOOTH" />
Will imply <uses-feature android:name="android.hardware.bluetooth"/>

You can check the whole list here https://developer.android.com/guide/topics/manifest/uses-feature-element#permissions

Lindsley answered 9/12, 2020 at 16:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.