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
Related
As we all know that Google launch new feature of distributing android apk using android-app-bundle that has so many advantages.
So my question is, how my app will behave if I place all the images/resources in single folder like drawable-xxxhdpi. e.g. Lets say I have one application that uses 5 images. Instead of taking different sizes for different resolutions, I place all the images in single folder (drawable-xxxhdpi) assuming lets android handle it based on device resolution.
As we know that android-app-bundle generates different different apks based on resolutions, languages and so on.
So in that case what will happen to my app ? How APKs will be generated for different resolutions (Android itself re-scales images and generates bundle ?) What will happen to app, will it crash or working properly for smaller resolution devices ?
I know this is non- coding question but its technical question. I tried to search for this but not able to find exact answer of it.
I may help to others as well.
Your app will work the same as before: Play serves to a given device the files that the Android platform would have loaded if it had served the APK with all the files.
In other words, if an mdpi device would have loaded the resource res/drawable-xxxhdpi/icon.png, then that's what Play will serve to that device.
--
Also, slightly unrelated to your question, but note that there are some downsides to providing resources only in xxxhdpi (regardless of whether you publish an APK or an Android AppBundle):
The Android platform will have to rescale these images at runtime on lower resolution devices, thus taking some CPU time and making your app slightly slower.
Your app is bigger than it could be on lower resolution devices. If you provided also the same resource in mdpi, it would obviously be smaller, and that's what Play would serve to an mdpi device, thus making your app smaller for those devices.
Resource not found exception will be triggered in devices with lower resolutions
Good and very helpful question, I think your application will work fine on xxxhdpi devices but those devices which are mdpi or hdpi will face layout issues. I don't think so there would be any other issue than this.
I am developing one android application & planning to use it on android phones and tablets. Currently I am testing it with help of avd (Galaxy nexus). To use it on different devices with different sizes and densities, I want to test it on different avds.
My problem is instead of setting number of devices, can anybody suggest me few common avds whose configurations will cover most of standard devices (small, normal, large, xlarge).
In my eclipse, I am getting some nexus avds(10, s, one, 4, 7 etc) and some other devices( like 10.1"wxga, 5.4"fwvga etc etc). I am using adt bundle provided by google.
Thank you.
Why dont you use Samsung Remote testing lab.It provide to test your apps on different screen resolutions and also with the devices that do support temperature sensor etc.Please follow this link.I dont have any temperature sensor mobile but i need to test in one of my project.So i use Samsung galaxy Tab 3 for this purpose and also for some other things.I have also shown you the output.If you still need any help comment here.I think this might helps you :)
First of all you have to figure out which sort of devices you are going to target.
This link may be helpful to figuring out what type of filter you want to use in order to decide the targeted devices.
For most of the UI part you can rely on the AVDs provided by the Google Bundle choose the desired test AVDs (ldpi, mdpi, hdpi, xhdpi, xxhdpi).
But you should be ready for the surprises because some devices behave differently than the others. I mean the same build may be working fine for most of the devices but for a particular device the UI behavior may be different.
All the best.
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.
In our Android we use different layouts for different screen resolutions, using the resource selection mechanism described at
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
This works great, except for some devices which report the wrong screen size.
In particular we would want to use the same resolution on the Kindle Fire and the Nook Tablet. These have 600x1024 screens and thus should report themselves as having "large" screens. The Kindle Fire does so, but the Nook Tablets picks the "xlarge" resources:
http://nookdeveloper.zendesk.com/entries/20814001-emulator-loads-xlarge-layout
I can detect that the application is running on a Nook Tablet, and add a special case for it, but I have not found how I can force the resource selection mechanism to pick up resources for a certain screen size.
The simple solution (that you're probably not looking for) would be to not have an XLarge set of resources available for the Nook release. This causes both Nook devices to load the same resources. That's what I did, but since I didn't have a great set of XLarge changes this wasn't a big deal for me.
Sadly, Android didn't fix this issue until 3.2, which has minimum width selectors rather than the old bucket system. Nook is hanging tight at 2.3.4, though, so you'll need to roll your own if you want a better size selection system.
Personally, I haven't targeted 10" tablets as much as 7" tablets, because the top sellers are currently the Kindle Fire and Nook devices. The high profile of Nook may make it worth creating a separate build.
I'm developing an Android app that absolutely needs to support Android 2.1+ devices, including tablets and phones.
The tricky part is I want to be able to provide roughly the same user experience on Android 2.x tablets as on bone fide Honeycomb tablets. I'm planning on using the Compatibility package so that Fragment support is always available, but...
The problem I've got at the moment is I've bought a Hannstab for testing, and discovered that it reports to apps that it has a "large" screen, despite actually being 10.1 inches. This would technically make it "xlarge", but of course that category was not included in Android 2.2 (which it runs), hence it's "large". I originally intended to just use resource qualifiers and treat all xlarge devices as tablets, and everything else as phones but now I realise I can't do that.
Would it be so bad to treat all xlarge and large screened devices as tablets? This would include Dell Streaks and other 5 to 7 inch screen devices as I understand it.
Is there a better alternative? I haven't really got my head around fragments properly yet so a fragments-based solution might be obvious to someone who has.
I've noticed that typically, apps I install on my Hannspad use their normal phone UI, with the exception of Evernote which uses a specific tablet interface - I wish I knew how they'd done that.
The new "Smallest Width" resource qualifier introduced in Android 3.2 would solve this problem by doing away with the generalised screen size buckets altogether. Presumably I could copy this approach by writing code to work out the screen width in dp and then adding fragments to the activity as appropriate. Is that wise? I'd rather avoid that kind of work if it's going to be a pain.
Cheers
Would it be so bad to treat all xlarge and large screened devices as tablets?
If your question really is "is it OK to use the same layouts, etc. for -large and -xlarge devices", that certainly can work. It's certainly where I would start.
Bear in mind that device manufacturers really are the ones who determine what is -large or not. It would not surprise me to find some manufacturers creating 5" devices to categorize them as -normal, because they feel that -normal apps tend to work better on their devices than do -large apps.
I've noticed that typically, apps I install on my Hannspad use their normal phone UI, with the exception of Evernote which uses a specific tablet interface - I wish I knew how they'd done that.
Probably using -large/-xlarge resources. I don't know if they are using fragments or not.
In terms of screen sizes, fragments really are for cases where the -large/-xlarge UIs are basically a bunch of -small/-normal sized UIs snapped together like LEGO(R) blocks. In Evernote's case, their -large/-xlarge UI does not fit that pattern, so they may or may not have used fragments.
Fragments offer some other advantages for memory management and configuration changes (e.g., screen rotation), so you might consider using fragments even if you are not sharing fragments between major groups of screen sizes.
Is that wise?
If possible, I would hold off on making that decision until Ice Cream Sandwich ships and we start seeing how some of this stuff will play out on smaller-screen devices.