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
Related
I'm trying to scale my app to all screen sizes and I read that if I compile the app against android 3.2 then I'll be able to use the new qualifiers etc....But my question is - if I do compile it at this version, does that mean that mobile phones that have a lesser platform won't be able to download or run the app? Will I be excluding the majority of phones for the sake of including a very small percentage of phones that the tablets currently comprise?
You may compile your app using the newest SDK version of Android, or in your case 3.2, and the app should continue to run on older versions of Android. The only thing to be careful of here is to ensure that the API methods you use are still compatible with the older versions. These newer qualifiers that you mention would not be allowed for the older versions of your app, but there are some compatibility libraries that you may use for them found here:
http://developer.android.com/tools/extras/support-library.html
To ensure that your app is compatible with older versions of Android, you can install the newest ADT and also run Android Lint. Lint will point out functions that may not be available on different versions of Android, based on your manifest file. Your manifest file allows you to determine the minimum version of android that can use your app, as well as the ideal version of Android that your app is made for. Please refer to the following link for more details about versioning your app, and some backwards compatibility:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
I found a lot of online resources regarding targeting a variety of Android versions from my min-SDK version up through my target-SDK. This includes doing things like reflection or wrapper classes to test for the advanced functionality that may be available only in the higher Android version I'm targeting.
What I cannot figure out is how to get this to work in Eclipse. Specifically, the problem I am running into is that if I choose a Project Build Target that matches my target-SDK then Eclipse will not allow me to select an AVD with a lesser Android version for debugging/testing. Therefore I can't test the reflection tricks to make sure they work for backwards compatibility. The alternative of choosing the lowest Project Build Target means that I cannot refer to any of the advanced classes/methods available only in the newest Android versions without getting compiler errors.
What is the correct way to organize an Eclipse Android project to make targeting multiple versions work?
(P.S. I'm trying to use the old, undocumented calendar access tricks alongside the new ICS calendar API.)
Thanks!
project.properties includes your build target. set this to android-15 (latest API).
In the manifest set min-sdk to the minimum sdk you are supporting for example 8 (froyo). This is the minimum API and it will only launch on devices with API bigger or equal than this.
Make sure you test all API's which are lower than the target as some methods might not work. An example for this is the ActionBar introduced in Honeycomb - it will not work on API's lower than Honeycomb.
My App is coded with 2.2 "SdVersion 8" and when I run it in Ice Cream Sandwich I get the "Contex menu" down in botton right.
I want to take use of the new ICS interface. If I change the App to API-level 14 (Android 4.0) I get the new interface! (On 4.0 phone). BUT the App doesn't seem to start at all on phones with older Android-versions for example 2.2.
If I change minSdkVersion in the "API target 14" to 8 .. I get the old 2.2 interface on 4.0 devices.
So. Is it possible for an App to get the 2.2 interface on a 2.2 device, and 4.0 interface on a 4.0 device?
It is not possible to get the 4.0 interface on a 2.2 device without manually importing all of the resources you need from the Android source into your application and applying them correctly. The reason for this is all Android resources that are used to create the ICS theme are already on the phone. When you reference anything inside of the Android package you are actually referencing the Android version that is installed on a given device.
This is why for example when you open a dialog on an HTC device it looks different than it will on a Samsung device. Device manufactures usually customize some of these built in Android resources to give there device a special look than all other Androids.
So if you wanted to get the look of the ICS interface on all devices you could go into the android sdk you have downloaded and look in "pathToSDK/platforms/android-14/data/res". I would not suggest this as you might not get all of the required dependencies or you might have some conflicting styles that make it hard to see things. Also most users are comfortable with the theme they are used to seeing on their device and if there is an app that makes a major change to that it might take the user off guard.
Edit:
Sorry for my long winded answer as I think I misunderstood your question. You can get a 4.0 interface on a 4.0 and 2.2 interface on a 2.2 by setting the target sdk to 4.0 but leaving the min sdk on the lower setting. This is a deprecated doc but will explain how to do what you are looking for.
You can now also try the support library (appcompat v7 (library project), mediarouter v7 (library project), gridlayout v7 (library project), renderscript v8 (library jar), fragment backwards support v4 (library jar) v13 (library jar) ) from Google released with API Level 18. It can work all the way to 2.1 Eclair in some cases.
There is tutorials on how to import the library with Eclipse.
I have managed to do it with Netbeans Android plugin by adding it via the project properties in libraries section and then browse to the appcompat or other v7 project shown as android library project. The library jars are do
My app targets Android 1.5 to 3.2 and I'm making notification icons specific to those platforms. I'm finding it difficult to correctly to organize the icons for all these versions, including h/d/ldpi versions. I know in 3.2, the qualifiers changed, so I'm trying to account for this as well.
Currently, when I launcher in 3.2, it uses an icon for 2.3. My folder structure at the moment is as follows:
drawable
drawable-hdpi
drawable-hdpi-v9
drawable-ldpi-v9
drawable-mdpi-v11
drawable-mdpi-v9
drawable-v11
drawable-xlarge
Question is which folder (including any missing ones) should I put the platform & display/density specific icons in so I target 1.5 - 3.2 correctly?
You might try the Android Asset Studio for generating notification icons that follow conventions for different platform versions.
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.