In addition to the general res/layout folder I have a res/layout-v3
folder for backward compatibility with Android 1.5, which has problems
with some RelativeLayout layouts.
It works perfectly with all phones and emulator versions tested so
far. Except of 2.1 (emulator and Nexus One). They choose to display
the Android 1.5 layout (res/layout-v3) instead of the default res/
layout.
Can anyone else confirm that? Is this an Android OS bug? If so, where
is the best place to submit the bug report?
UPDATE:
After reading up on https://developer.android.com/guide/practices/screens_support.html#qualifiers again (thanks Mark for the hint), especially this part
Resources that are for use only on a
specific API Level or higher. For
example, if your application is
designed to run on both Android 1.5
(API Level 3) and Android 1.6 (API
Level 4 and higher), you can use the
-v4 qualifier to tag any resources that should be excluded when your
application is running on Android 1.5
(API Level 3).
I changed my layout order from having
res/layout-v3 (for Android 1.5 only -> this was a wrong assumption I made)
res/layout (for anything else)
to my new configuration of having:
res/layout-v4 (for Android 1.6 and higher)
res/layout (for anything else -> in this case this would be Android 1.5 only)
If I understand the above documentation right and if my assumptions in the parentheses are correct this time it should work now. However, the result is the following:
Android 1.5 is using res/layout -> OK
Android 1.6 is using res/layout-v4 -> OK
Android 2.0 is using res/layout -> NOT OK
Android 2.1 is using res/layout-v4 -> OK
So why is Android 2.0 (on both Emulator and Motorola Milestone) not picking the right layout resource folder?
I tested it then again with 2.0.1 and it seems to work there. So that seems to be a bug in 2.0 which got fixed in 2.0.1
But now the weirdest thing: in order to make it somehow run on 2.0 I copied the res/layout-v4 folder to res/layout-v5 to force Android 2.0 using this layout resource. Didn't work. But then I tried copying it to res/layout-v6 (which is supposed to be Android 2.0.1) and voilà all the sudden it works with 2.0. Very strange! But I hope this workaround will help a few other people out there.
I've tested several devices and emulators (although not very thoroughly), and it seems that the selected resource folder is the one with the higher version <= device version.
Related
I'm trying to understand how the drawable folders in Android works. I found that in the resource folder in our project, it has the following folders:
res/drawable-ldpi/
res/drawable-ldpi-v8/
res/drawable-ldpi-v11/
res/drawable-mdpi/
res/drawable-mdpi-v8/
res/drawable-mdpi-v11/
res/drawable-hdpi/
res/drawable-hdpi-v8/
res/drawable-hdpi-v11/
res/drawable-xhdpi/
res/drawable-xhdpi-v8/
res/drawable-xhdpi-v11/
res/drawable-xxhdpi/
res/drawable-xxhdpi-v8/
res/drawable-xxhdpi-v11/
Can someone please educate me on how the fallback mechanism on these folders works? Also what does v8 and v11 mean?
From Android doc:
The API level supported by the device. For example, v1 for API level 1 (devices with Android 1.0 or higher) and v4 for API level 4 (devices with Android 1.6 or higher). See the Android API levels document for more information about these values.
-v8 and -v11 are API version but when android will determine the best match to use resource it will use them as "level" (and not strict api version number), e.g. with your project folders structure:
With device running Froyo (Android 2.2, API 8) with mdpi screen then resources will be taken from res/drawable-mdpi-v8/ folder
With device running Gingerbread (Android 2.3, API 10) with mdpi screen then resources will also be taken from res/drawable-mdpi-v8/ folder (because 8<10<11)
With device running Ice Cream Sandwich (Android 4.0, API 15) with mdpi screen then resources will also be taken from res/drawable-mdpi-v11/ folder (because 11<15)
--
Why default res folders are v-8, v-11,v-15... and not v-12,v-13 or v-16... ?
Because it was major releases of Android with changes on UI mechanism (e.g. Api 11 was the first Android optimized for tablets).
-v11 and -v8 are version qualifiers (you can read more here) for version 11 and 8 of android. If your app is running on one of them, then it tries to pick the drawable from the specific folder. If it is not in there, then it tries on the less specific. E.g. you are running and mdpi screen on Honeycomb, the first attempt is res/drawable-mdpi-v11/. If the drawable is not in there, it looks for it in res/drawable-mdpi/. The look up continues until the closest drawable to your configuration is found.
Sorry for the newbie question. I'm developing Android app using Xamarin studio and MonoDroid.
If I'm choosing target platform v2.3 then I have support for devices running Andoird OS v2.3+
but... for devices running v2.3 I have the same design as for devices running v4.0.3:
https://dl.dropboxusercontent.com/u/19503836/android_api10.png
Only if I choose project target platform v4.0.3 then I get expected design but in this case I have no support for devices running v2.3:
https://dl.dropboxusercontent.com/u/19503836/android_api15.png
Is it possible to have different design style activated for different Android OS versions having target platform v2.3?
You can use different layouts for different android versions. Just make different folders for the layouts. Res/layout is for default layouts, Res/layout-v14 is for android 4.3 and above. Just look for the API version you need and add it to the folder name.
You can also use different styles per version the same way. The styles are defined in a XML on res/values, just specify the API version in the folder res/values-vXX.
By your example it seems that by default your IDE is already creating different styiles for different versions, so look for that folders on your project tree.
You have more info on Android Developer
I'm currently on Android 4.1 for the Project Build Target. My issue is that I have two HTC One V's to develop with. These run 4.0 at the moment.
I figure I have 1 of 2 options. Either:
*Set the build target to Android 2.2 (the only other Android one available - why such a jump?). However, this causes a lot of red underlined error in my current code. And Wi-Fi direct requires 4.0 as the minimum.
*Upgrade the HTC One V to 4.1. Is this possible and would there be any drawback to doing this?
Which is the preferable option and why?
UPDATE:
Okay, so a quick search reveals that the One V cannot be upgraded past 4.0:
http://www.theinquirer.net/inquirer/news/2224379/htc-one-v-wont-get-android-41-jelly-bean
Bummer. Now I don't know what to do.
Ah. I see now what the problem was. Despite setting the min SDK and target SDK in the manifest, the build target still needs to be set in the project properties. I was confused as to why I only had 2.2 and 4.1 available. Now I realise more can be downloaded from the Android SDK Manager. This means I was able to download 4.0 and set that as the build target. My app can now be put on the HTC One V.
I suppose I originally only installed 2.2 and 4.1 because the android docs recommended I do only the earliest and latest recommended. Anyway, lesson learned!
I have downloaded the Android SDK(which i think has no version, it is standard). After installing Android SDK, Android SDK Manager comes which by default selects 3 things to be downloaded (1)Android SDK tools(2)Android 4.0.3 (API 15) and the things under it like documentation, samples etc (3)Google USB driver But at present i am having book on Android 3, so should i deselect the second option i.e. Android 4.0.3 (API 15) and select all things under Android 3.0 (API 11) or keeping Android 4.0.3 will be OK for Android 3.I know there are tutorials for Android 4.0.3 on Web so why should i go for Android 3 because i find it easy through books and i got Android 3 here in my place and still no Android 4. So what should i do?
You can install everything. I would recommend to install the API level you want to develop for. But it doesn't hurt (but wastes disk space) to install everything.
Sidenote: Android 3.0 is for tablets, 2.x for older and 4.x for the latest Android Smartphone devices.
You should select the API level that you will target. For example, I am writing an application for API level 7 (Android 2.1.x), so I've got that version installed on my machine. Of course, you can have more than one API level installed, so it is safe to install any combination (for example 3.0.x and 4.0.4 simultaneously - see last paragraph for the reason).
Once you've got a few API levels installed, Eclipse will allow you to change the target API for your project to any of the versions you have installed. The same applies for the command-line project creation.
There is actually one good use-case for installing a version newer than the one you are targeting in addition to the one you use: testing. You can create an emulation environment for a newer version of the API to ensure that your application does not crash and burn when the API levels do not match. If we were to extend my above example, a sensible set of levels to install is 3.0.x, 3.2, and 4.0.4. You can target the initial release of Honeycomb (unless you need anything from the later versions), and test with both the latest Honeycomb and Ice Cream Sandwitch.
Some of my application's users are on android 1.5, some on 1.6, and some 2.0.
So how do I release my app for all customers? If I release a 1.5 version, then the 1.5 phone can use it - but not the newer phones with smaller screens (aka Tatoo), they require 1.6 or higher? correct?
Thanks
What I do is set my app to build against Android 1.6, then I set the minSdkVersion in the manifest to 3 (which tells the Market to let Android 1.5 phones install it, and the targetSdkVersion to 4 (which tells phones with Android 1.6 and up that I've already tested it on 1.6 and not to give it any forward-compatibility help). By building against 1.6, Eclipse won't let me use any 2.0 APIs, but I know that it will still work on 1.6 and 2.0. It also won't let you automagically install it on a 1.5 emulator, so I export a signed APK and then use the "adb" tool that comes with the SDK to install it on the emulator via the command line, and hand-test it to make sure it's not stepping on any 1.6-specific APIs either.
The reason I don't build against 1.5 is that there is stuff only in 1.6 and up that I need to use, that 1.5 will safely ignore, and that is support for multiple screen sizes. I can include larger assets meant for the Droid screen in res/drawable-hdpi and have Droids autoload those, but if I'm building against 1.5, Eclipse doesn't know what I'm trying to do.
I hope I didn't make that sound too complicated, because it actually isn't - the Android SDK and resource framework makes it surprisingly easy to handle multiple screen sizes and platform versions. Just understand what it is you're doing, and use screen-independent pixel units in your layout XML, and you'll be fine.
Newer phones should run your older apps fine, depending on how they are coded. If you're using AbsoluteLayout and hardcoding references to pixel dimensions, you will run into issues. If you're just letting android do the calculations for you, should be fine. The API is explicitly backwards-compatible, so phones that run 1.6 or 2.0 will be able to run 1.5 apps just fine.
I'm building with a target of 1.5 and testing it on a 1.5 emulator, 2.0 emulator, and a 2.0 device. This allows me to make sure it will work with as many different devices as possible.