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:
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.
handleSilentException
method to report silently. It will at least tell you which hardware the app is working on.
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" />
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.
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
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.
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
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.
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
I have a couple of suggestions:
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. 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.
<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.
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.
faketouch
as required= false
?
<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.
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://stackoverflow.com/a/5449397/372838 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
Typical, found it right after posting this question in despair; the tool I was looking for was:
$ aapt dump badging <my_apk.apk>
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.
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.
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.
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"
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.
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
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
Success story sharing