I'm developing an app that's intended for high-end devices only. It already only supports API 17+ but I've noticed some older devices that run API 17 that I'd like to exclude. My question is:
What's the best way to filter out older devices that still run a relatively new Android version?
I'd like to avoid manually excluding specific devices in Google Play.
Filtering based on screen density
One thing that I'd certainly like to do is filter on screen density (I'd like to support only hdpi and higher). I've read the compatible-screens article but I don't really like the solution presented there because:
According to the article: "You should use it only as a last resort, when the application absolutely does not work with specific screen configurations."
I'll get a large list of combinations in my manifest (if I support hdpi, xhdpi, xxhdpi and xxxhdpi with screen sizes medium, large and xlarge I'll already have 12 combinations).
What if a new screen density (e.g. xxxxhdpi) or a new screen size (e.g. xxlarge) is added? To support those I'd have to update my manifest every time a new bucket is added.
It seems strange to me that I can't just specify that I want to support hdpi and higher in a single line in the manifest.
Filtering based on device features
I've also considered filtering on some feature that only high-end devices have, so I read the uses-feature article. However, it seems that I can only filter on things like bluetooth, camera and wi-fi and not on anything more indicative of a high-end device like hardware acceleration.
You just can't filter out specific device(s) using the AndroidManifest.xml file itself except the screen size/density etc. say if you need to filter out a specific handset/tablet for a specific vendor then is will not be possible using the manifest file only.
"What is the best way to filter out older devices that still run a relatively new Android version?"
Solution: There are options in Google Play Developer Console by which you can filter specific devices (handsets/tablets/models etc) according to vendor and model number for a particular app you have published.
To do this goto the APK section of your app:
Now click either on See List or Manage excluded devices the usage is very easy and self explanatory. This show show something like this:
Now All you need to do is just click on the button and it will be added to the Excluded Devices.
Hope it helps :)
Related
I have an app that targets Android 4.1+. My designer is working on a screen that has a lot of information and we are trying to make sure it will fit on the smallest possible screen size given my minimum Android version. Is there such a list for actual real existing devices?
Thank you.
Android as an operating system does not define a screen size minimum. However, if you really want a number to reference your best bet may be to consult the compatibility definition document. Google requires that vendors adhere to these requirements if they wish to include Google's proprietary apps in their devices (such as the play store). Almost all commercially available mainstream android phones fit into this category.
You can view the CDDs all listed here:
https://source.android.com/compatibility/cdd
And you can see here for android 4.1 screen sizes
https://source.android.com/compatibility/4.1/android-4.1-cdd - scroll to section 7.1.1
which states "Devices MUST have screen sizes of at least 426 dp x 320 dp ('small')" along with a few more rules
There is no master list as per API and screen size but here are few alternatives, I Don't know if you have gone through these links or not but here are few of them you might find helpful.
Device Metrics
PDF list of supported devices by play store
Wiki link for android devices
List of Jelly Bean devices
After finishing the programming part of my app I want to test it with the Android Emulator.
I tried to make my app density independent an now I want to test it with different emulator devices. Which resolutions and screen sizes should I test? Do you have a list of virtual devices, which you use to test your application before releasing?
Which api-Levels should I test? (My application uses bluetooth).
Thanks for your help.
Basically the correct answer here is to 'test every possibility'.
But this of course would be a huge job.
I usually take the Nexus devices as base lines, which will guide you through most of the possible and populair sizes.
Android versions you should check every one of them, starting with the version you want to support as lowest. Every version can react differently to not only your layout and styles, but also handle your java code differently .
You can find the Nexus devices and their sizes at http://developer.android.com/distribute/promote/device-art.html
Be sure to press 'Older devices'
In addition to this, you could try to get your hands on some populair devices from other manufacturers like Samsung and HTC, since they also have a hand in changing the way your layout and styles will behave.
There is no magic bulletproof answer.
You can use this Platform Versions to glean some information about what are the most common API lvls, and device densities being used.
But ultimately the answer to your question depends largely upon your target audience and the devices that they carry. The best case scenario is to test on as many different configurations as possible =) starting of course with the most widely used.
If you are designing an application, which is density specific, then you should test on all the possible densities. To test your application on various density device, you should have base device for each density for e.g Samsung Nexus - xhdpi, HTC One(hdpi) and similarly one base device for mdpi, ldpi. If you are also supporting Tablets have base device Tablets supporting different densities.
Additionally, you can avoid scaling with respect to device density by setting the following parameter in the manifest file supports-screens android:anyDensity=false
I encountered a weird behaviour when starting to test my app on some 7in Android models and I would like to find out if others are finding the same problem and what people recommend as a fix.
Here are the details:
The application has full tablet support, which is triggered with qualifiers for the layouts. xlarge devices get the tablet mode with multiple fragments being displayed on the screen.
For newer Android versions there are also some values that set variable that change the UI on the flow using the sw600dp qualifier as well as the xlarge one.
The problem:
I am now testing on the Kindle Fire and the RIM BlackBerry Playbook and also want to support the upcoming Google Nexus Tablet (or whatever it will be called) and other 7in form factor devices.
Both the playbook as well as the fire have a 7in screen and a 1024x600 screen resolution.
However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.
Both the tablet as well as the standard UI work fine, but imho the tablet mode is nicer and is fine to be used on the 7in device. However if I push the layout into the large qualifier to also get that tablet mode on the fire I will also get it e.g. on the Note or other quite a bit smaller devices.
With Android 4x I can use the sw600dp and other qualifiers but what about older versions? I assume a 7in device is supposed to behave like a tablet but what about e.g. the Note..
What are best practices for this scenario? Are my observations with the playbook reporting xlarge correct?
However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.
Device manufacturers are the ones who choose which buckets a device goes in with respect to size and density. This goes double for manufacturers like RIM and Amazon, who do not want the Play Store and therefore do not have to abide by any particular compatibility requirements the Play Store dictates, so they are welcome to thumb their noses at Google's guidance.
What are best practices for this scenario?
I can't tell you "best".
However, if there are specific devices for which you wish to override some layouts to use a specific size, here's what I would try (assuming the layout you would be using for normal cases is known as R.layout.main):
Step #1: Create res/layout/main_funky.xml as a symlink or hardlink to res/layout-xlarge/main.xml (and likewise for -land, etc.).
Step #2: In your Java code, wherever you refer to R.layout.main (e.g., onCreateView() of a Fragment), decide whether to load R.layout.main or R.layout.main_funky depending upon android.os.Build data to detect these oddball devices by model. Since R.layout.main_funky is one of your normal main layouts, all of your code that depends upon widgets should be unaffected by this choice.
Step #3: In your particular case, add MMPD (magic Maven pixie dust) to steps #1 and #2... :-)
Are my observations with the playbook reporting xlarge correct?
I bought a Playbook, determined that RIM's distribution model is... unpleasant, and did the bare minimum to have a book chapter on it. I haven't tried to see if it is -large, -xlarge, or something else.
That being said, the NOOK Tablet IIRC suffers from this (claiming to be -xlarge rather than -large).
I would expect a Google Nexus tablet, if such a thing comes to fruition, to correctly honor size buckets, plus be running a new enough Android version that -sw600dp and kin will work.
I have scoured the internet for this answer, and I feel like I keep getting close to it but then it turns out to not be quite what I want. If someone posts a quick link that specifies exactly what I need I will be quite disappointed in myself...
I am making an Android app whose minimum api is 4 and android version is 1.6. It works on tablets, but it is not optimized quite yet, so when I publish it I do not want tablets to be able to find it at all. I have read the support screens android pages about adding this code to my manifest:
<supports-screens
android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xLargeScreens="false"
/>
That particular code ( android:xLargeScreens="false") is not supported with android 1.6, so I cannot add that to my manifest. The definition of each screen is pretty vague as well... for instance, the large screen size is defined as "a screen that is significantly larger than a "normal" handset screen". Does that mean the largeScreens are tablets as well? Do I need to set that to false??
So since that is not an option, and knowing my specs... how do I filter my app in the android market so that it does not show up for tablets?
AFAIK, it is impossible to close that xlargescreen possibility - you have set the problem correctly.
Don't be afraid of all tablets - there are very many cheaper ones that have screen smaller than that of modern phones.
Don't be afraid of greater tablets, too. Their owners are accustomed that SW for elder than APK 9 versions are not optimized for their devices. It couldn't be.
Edit:
cite from the android developer guide:
Caution: If you use the <supports-screens> element for the reverse
scenario (when your application is not compatible with larger screens)
and set the larger screen size attributes to "false", then external
services such as Android Market do not apply filtering. Your
application will still be available to larger screens, but when it
runs, it will not resize to fit the screen. Instead, the system will
emulate a handset screen size (about 320dp x 480dp; see Screen
Compatibility Mode for more information). If you want to prevent your
application from being downloaded on larger screens, use
<compatible-screens>, as discussed in the previous section about
Declaring an App is Only for Handsets.
I think all you have to do is remove the screen support for big screens.
http://developer.android.com/guide/topics/manifest/supports-screens-element.html
So that the market would know your app is only compatible on certain screens.
I have reviewed the content of some of the currently best Android apps (not to mention that I often check the content of apps I personally or professionally use) and I see that they DO NOT support small screens. I do not mean they they literary do not support them by excluding them in the Manifest file. It's just that the directory LDPI is almost empty (except launcher icon and maybe a few other icons) and that layout-small directory does not even exist.
So the question is, should we bother to support the small screens when nowadays Android devices start from MDPI/NORMAL to up?
The whole point of Android is to be compatible with different hardware characteristics so I would tend to say "yes" it's important to consider low res targets.
Although, doing some research it's true that there are less and less ldpi devices. This article shows interesting results:
UPDATE:
watch that article on Android developer website for more up to date figures:
http://developer.android.com/resources/dashboard/screens.html
That, of course, depends on how compatible you want your application to be. If you want it to support older, smaller screens, then yes; otherwise, no. This sounds more like a business decision than a technical one.
I think you may be confusing density and screen size, as you're using the terms interchangeably.
Just because you have a small screen size, does not mean it has to be low-density. There are screens that register themselves as "small" to android, that are considered HDPI, based off their resolution.
Also, if you have MDPI images, it'll work just fine on devices reporting as "small", as most of that is based off the design of your layout and how well it flows across multiple screen sizes.
As you can see on the Android screen grid, small <> ldpi. http://developer.android.com/guide/practices/screens_support.html#testing
In closing, just because you aren't including LDPI images doesn't mean you don't support small screens.
This question, to me, comes down to time vs. reward. According to http://developer.android.com/resources/dashboard/platform-versions.html, a little over 3% of the market base are still running pre-2.1 phones. If Ice Cream Sandwich does what its supposed to do, hopefully these conversations will go the way of the dodo.
At this point very few people have those kinds of devices, and therefor most don't support it. However, those who do support it have a much greater chance of being used by that small percent, simply because no one else is selling to them.
If it makes sense for you app, and you have the time and energy to put into making it compatible, why not? On the other hand you shouldn't try to shoehorn something in and cause it to become a worse product for it.
Also they have released the ability to have multiple APKs based on different requirements, so we can develop apps targeted to earlier phones, without interfering, or adding code and resources, to our higher targeted apps.