I have a tablet with mdpi screen (xlarge). Is it possible to emulate some other screen configurations on it? I have layouts for middle-size screens and I want to see how they will look like without using emulator (it causes a lot of pain for my PC).
For example, I've seen something like that on iPad (when its running iPhone apps)
can try this link http://developer.android.com/guide/practices/screen-compat-mode.html
add in the manifest file
There are two versions of screen compatibility mode with slightly different behaviors:
Version 1 (Android 1.6 - 3.1)
Version 2 (Android 3.2 and greater)
Disabling Screen Compatibility Mode
If you've developed your application primarily for versions of Android lower than 3.0, but your application does resize properly for larger screens such as tablets, you should disable screen compatibility mode in order to maintain the best user experience. Otherwise, users may enable screen compatibility mode and experience your application in a less-than-ideal format.
By default, screen compatibility mode for devices running Android 3.2 and higher is offered to users as an optional feature when one of the following is true:
Your application has set both android:minSdkVersion and android:targetSdkVersion to "10" or lower and does not explicitly declare support for large screens using the element.
Your application has set either android:minSdkVersion or android:targetSdkVersion to "11" or higher and explicitly declares that it does not support large screens, using the element.
try removing
<uses-sdk android:minSdkVersion="10">
from your AndroidManifest File.
by this, if your project uses like GingerBread then it will show in 480x800
Related
I'm working in Android Studio, this app is aiming to target devices from API 10, several features I am using for supporting old and new devices I am getting from appcompat library.
When I test in my phone, the app design seems Ok, but I know I have to mantain compatibility for other devices, like tablets. Untill now, I only have created folders in drawable, for different screen densities (mdpi, ldpi, xhdpi...).
The point is how can I support different sizes (i.e. one layout for small phones, other for tablets...). I heard about create folders in layout like small, medium and large, but in Google developers site, this is not recommended, I should use intead sw...dp, however it seems is supported only for api 13 and above.
I am considering make an app for phones and other for tablets, unless there is something I can do, keeping support for api 10 and above and supporting different screen sizes.
As you said, in the android documentation you can find (http://developer.android.com/intl/es/guide/practices/screens_support.html):
A set of four generalized sizes: small, normal, large, and xlarge
Note: Beginning with Android 3.2 (API level 13), these size groups are
deprecated in favor of a new technique for managing screen sizes based
on the available screen width. If you're developing for Android 3.2
and greater, see Declaring Tablet Layouts for Android 3.2 for more
information.
It tells you to not use them just if you are designing for API 13 and above. If you don't then you should use the deprecated identifiers.
I don't think make an app for an API lower than 15 has much sense, here you can see some charts of API distribution:
http://developer.android.com/intl/es/about/dashboards/index.html
With API 15 you are covering the 96.4% of the users.
I am currently repacking my Android application for the Blackberry playbook but I am having some issues with the layout.
I have a custom layout for the Nexus 7 which I would like to use on the Playbook. This layout is contained in layout-sw600dp. I know this folder naming convention only came into place in Android 3.0+ and as the Playbook uses Android 2.3.3 this is not used.
The playbook currently seems to be using resources in the layout-xlarge folder. Layouts in this folder are geared towards 10 inch tablets and look poor on the Playbook.
Is there anyway I can test if the device is a Playbook and make it load the same layouts as the nexus 7 without changing the xlarge layouts.
I am using layout-xlarge-v9 (by version of gingerbread, which should(1) not be in any xlarge tablet)
Edit to add a note about qualifier precedence and version qualifier
You need to use the version qualifier at the end.
layout-xlarge-v9
layout-xlarge-land-v9
Also, this gets version 9 and higher, so your old layout-xlarge should be now:
layout-xlarge-v11
layout-xlarge-land-v11
I agree on being annoying that it considers itself xlarge
(1) should, because honeycomb was designed for that, but you may find some low-end Android tablets that do, but probably you don't care that much about that segment
My app has different layouts and styles for xlarge screens. This is important because on phones it is only used in portrait and on tablets it is only used in landscape.
A user contacted me a few days ago because since I published the update with the tablets layouts he can't see some of the objects in my main activity (prior to this update I only had portrait layouts - also on tablets). He uses a 7 inch tablet running Android 2.3.3 and for some odd reason it is using the layouts and styles from the xlarge directories even thew it should use the default layouts and styles.
I tested it on the emulator and had the same problem. I then changed only the android version to 3.1 (did not change width, height and density) and it worked as expected - the default layouts were used.
I don't want to use version qualifiers (layout-xlarge-v13) because then users with old android versions that have an xlarge screen will get the wrong layouts. For android 3.2 and up I could use sw720dp but older versions will not use this so problem remains.
I am able to tell at run time that the device is not large enough for the xlarge layouts but what can I do in that situation? Is there a way to make it use the default resources?
Android doesn't give its blessing to any 7-inch tablets running Gingerbread or below since Honeycomb was released. This means your device must be either old, or non-CTS compliant. You are looking at an extremely small pool of devices that are: API level 7-10 (roughly), 7-10 inches in size, that live outside the main Android ecosystem.
If you want to support such devices, I would recommend that you make layout-large-v7 and layout-large-v11. Assume that these nonstandard tablets will select the first one, and design for low- or medium-density 1024x600-pixel displays.
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.
we have a problem related to the manifest file and the property "android:minSdkVersion".
The issue is: If our platform is 2.0 and we use the property "android:minSdkVersion=3" (3 = sdk 1.5) the graphics get corrupted (In details, the application's resolution get reduced to a 2/3 part of the original size, this is, when the resolution should be 480x720, it becomes in a 320x480). This is happening on the Android emulator, and on the devices Droid/Milestone (Which are platforms 2.0). When we switch the property to "android:minSdkVersion=4" (4 = sdk 1.6) the problem gets solved, but when we want to put that version on platform 1.5, Android doesn't allow us to install it.
It would help us to know any conflict regarding graphics within the 2.0 sdk, or any known problem around the "android:minSdkVersion" in the manifest.
Thanks!
If you specify targetSdkVersion as well as minSdkVersion your application will start to work correctly on all platforms.
So have an entry in your manifest like this:
<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/>
This is covered in the Android API Levels page in the Android Developer documentation.
I assume you're specifying different assets for different screen densities using directories like res/drawable-mdpi, res/drawable-hdpi and so on?
Android 1.6 (API level 4) was the first version of the SDK to support multiple screen densities, so it knows the significance of these directory names and so can successfully select the correct drawable from your res folders for the particular device it's running on.
However, if you run an application developed in this way on an Android 1.5 device (API level 3), then the framework does not know that it should only use the medium DPI resources (as there are no Android 1.5 devices released with anything other than medium DPI screens (AFAIK)). So in this case, the framework can end up choosing seemingly randomly from all the available resource in your APK, whether they're intended for high density screens or medium density screens, or whatever.
However, I haven't seen the reverse happening that you are, i.e. a 2.0 device appears to select drawables for, or assumes, a different screen density.
I would make sure your res directory layout is correct, and that you're using density-independent measurements in each of your layouts as appropriate.
But if you want to support multiple screen resolutions and densities and support Android 1.5 devices in a single APK, then I don't believe it's possible.
Add this tag in your AndroidManifest.xml to support multiple screen densities.
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:anyDensity="false" />