Our app supports android 2.2 up. The app works on android 3.0 emulator. However we received report from honey comb device users that they do not see the app showing up in Market on their device. When they use Market website on PC and select their device to install, they got message of "App not compatible with your device".
Anyone, please advise what we need to do to make the app show in the Market for 3.0 devices. Is it something we need to add in manifest file or something we need to config during the publishing.
June Jorgensen
Have you set android:xlargeScreens="true" in the supports-screen section of the AndroidManifest.xml?
Have you tried setting the targetSdkVersion in the AndroidManifest.xml to 11 or 12?
Use "aapt dump badging" on your .apk to see the kinds of things in it that are used for filtering.
There is nothing in Honeycomb per-se that would prevent apps from being installed. However, there are characteristics of current Honeycomb devices that are of interest. For example, none of them are phones. Make sure you are not requiring telephony, either explicitly with a tag, or implicitly by requesting a telephony related permission (again aapt dump badging will tell you about this).
Related
I asked a question earlier about stopping tablets from an android app and I've added this line to the code:
<uses-feature android:name="android.hardware.telephony" android:required="true"/>
Now I want to verify it and be sure that the app cannot run on a tablet by testing it on an emulator. However, it seems like this requirement is always met on emulators. Is there another way to go about testing it?
You do, with that line, block all devices that do not have access to a SIM card from installing from Google Play. This isn't limited to tablets. THere may be phones without sim cards, and there are tablets with SIM cards and the ability to send text messages and make calls.
From Ken Wong's comment on the question:
Declared elements are informational only, meaning that the Android system itself does not check for matching feature support on the device before installing an application. However, other services (such as Google Play) or applications may check your application's declarations as part of handling or interacting with your application.
If you want to block tablets as a whole, that is basically impossible. This question offers a possible solution using the supports screens tag, but this, AFAIK, only makes the app incompatible on Google Play. If it is installed from a third party (USB debugging, APK mirror, from an APK file, etc) it can be installed. Once again we are back to the compatibility issue. The supports-screens tag is the same as the required tag: It is informational. Those who respect the tag doesn't allow installs. From this article:
An application that does not support small screens will not be available for small screen devices from external services (such as Google Play)
Small screens is just an example. If the support for any screen size is set to false, it will not be available from external services. Installing the APK directly (apk install outside Google Play or from USB debugging) bypasses it.
In addition, there are phones with xlarge screens. (They are more phablets I think the term is, but they are still phones. Just large ones).
So to summarize:
Using the required tag (should in theory) allow the app to install from third party sources, but Google Play shows it as incompatible. So USB debugging and APK installs (not from Google Play) allows install. Check for compatibility at runtime instead
Attempting to prevent tablets from accessing the app is basically stupid. Tablets can have SIM cards as well, blocking tablets because they have a bigger screen is not a good idea. Checking for the SIM card instead is the best way.
As for the emulator, AFAIK it would install in testing even though required is true. It will crash if you make calls to things it doesn't have. Have you checked to ensure the tablet emulator actually doesn't have telephony access?
Now I want to verify it and be sure that the app cannot run on a tablet by testing it on an emulator. However, it seems like this requirement is always met on emulators. Is there another way to go about testing it?
Well, required (as mentioned in a comment) is informational. The device itself doesn't check the conditions in the manifest (required = true at least). Once it is installed, check at runtime for compatibility. The required = true tag prevents installs from Google Play on unsupported devices (it shows up as "incompatible").
(Unfortunately) apps have a tendency to get pirated and uploaded to APK mirrors and similar sites (I know this from experience). These sites aren't like Google Play, and ignore the required = true calls. The app can be installed from these sites even on incompatible devices. So the best way to avoid incompatible usage is to check if the device has telephony access at runtime.
For checking on Runtime, that is a big field. Check this question for different solutions.
I am making an app which should only be installed on devices having the samsung airgesture capability. If the app were to be published on the play store that is very easy i can just select those devices, but it will not be published. So I thought of using the < use-feature > tag in the manifest so that the APK would not install if your phone does not have this feature. I could not find the identification of this feature to put that in the manifest. Some ideas?
Actually, i don't think that is possible. I checked the list of supported values for those tags and there is nothing related to this. http://developer.android.com/guide/topics/manifest/uses-feature-element.html#hw-features.
The fallback will be to have the app installed, but just display a message when the Device.model does not match the expected one
In the Google Play - Developer Console, you can specify on which devices you do not want your app installed.
This means, you have to know the devices with airgesture.
I'm wondering, if I have an APK that supports for example Android 2.3.7 and below and another that supports 3.0 and above what will happen if a user with a device with 2.3.7 updates it's OS to 4.0 ?
For example, a Samsung Galaxy S II update from 2.3.X to 4.0 ?
Will the app be auto-magically replaced? Will it crash?
I think it depends on your version numbering scheme. If the app version that supports 3.0+ has a higher version number than the one that doesn't, the market will likely show an upgrade available. It should update like any other app (but it may not be immediate): if the user has auto-updating on for the app, it will update itself after a while, but if not, it will appear to the user as having an update available and will wait on them to download it. Unless the permissions are different between the versions.
Whether it crashes or not will be determined by the app itself: what happens if you yourself install the 2.3.7 APK on a 4.0 device (which may or may not require a quick change to the manifest file)?
I'm pretty sure it won't be replaced. The documentation says, that you publish multiple APKs under one Google Play (Market) entry. So if user has a specific APK which has a max-sdk parameter set in Manifest, then it won't work on newer system. But if you don't have max-sdk specified and there are no conflicts, it will.
EDIT: But as Jon O said, it should be possible for the user to update the app, because it's still the same Google Play entry.
My application is targeted for API 8 (Froyo) minimum, however I'm getting a message in the Android Market that says "This report was sent in by a pre-Froyo client, which did not include a stack trace."
When does Android check that the Min-sdk is greater than or equal to the API version on the phone. Is it at runtime or market download time?
Your app's minSdkVersion is filtered by the Market and the phone, however there are a few ROMs out there that disable this filtering at the phone-level. If you're seeing a report from a phone that is below your minSdkVersion it usually means the user installed the app directly, not from the market, and their phone tried to run it even though the SDK version wasn't usable by the device. This would result in a bug report being posted to the Market, but the Market app doesn't ask the device how it got the app in the first place.
You'll see this once in a really long while--it's nothing to be alarmed about.
I believe it filters in the market. Perhaps somebody got ahold of your APK and distributed it to a pre-Froyo phone? Just a guess.
edit - taken from the ref http://developer.android.com/guide/topics/manifest/uses-sdk-element.html: An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
Perhaps you have confused minSdkVersion and targetSdkVersion?
I have about 20K active downloads of my app, but somehow five 2.1 users have sneaked on to my stats.
From manifest:
uses-sdk android:minSdkVersion="8"
My concern is that there are more 2.1 users trying it and unistalling it and thus messing up my active:total ratio, or worse 1 staring me.
This sometimes happens when users have modified firmware. The firmware reports one version, while the kernel may differ.
Could be that your app is pirated and available as direct apk download somewhere so the manifest logic might not take effect..
You should not worry about this, since there's absolutely no way to prevent it from happening. There's just as many incompatibilities in devices that are running different kernels and ROMs, even though they might be running the same Android version.