When I run my application on Android 2.3.3 then it show different look and feel to android 4.0. When I run my application in Android 4.0, I want it to have the same look and feel as Android 2.3.3.
There are already a lot of questions asked on this topic but all the questions are "How to give higher version look and feel to lower version". But in my case I want to give lower version Look And Feel to higher version.
There is one solution which is, if I compile my application with Android 2.3.3 and run on Android 4.0 then it give Android 2.3.3 Look And Feel. But here I am not able to add features from Android 4.0, so this option is not a right way to achieve my goal.
So what I need to do?
Here I am attaching Look And Feel which I want:
But instead of above Look And Feel it show following look And Feel on Android 4.0
Set your Application's theme to #android:style/Theme in your app's manifest.
For example:
<application
android:icon="#drawable/ic_launcher"
android:label="#string/app_name"
android:theme="#android:style/Theme" >
This will set your Application's Theme to the former default Android theme, which has been replaced by Holo in newer versions of Android.
You can also select the DeviceDefault theme in a similar manner.
Make sure your targetSdkVersion is set to a value of 10 or lower, and that your application does not declare a theme based on Holo when running on newer versions. This will keep the Holo theme elements from being applied on newer devices.
Related
I've taken the basic Hello World app from the SDK examples and have been learning Android by modifying it. Currently I'm trying to change the Theme. I'm testing it on my Nexus 7 running the latest OS and I'm using Eclipse.
In my manifest I have
android:theme="#style/AppBaseTheme"
In values-v11/styles I have
style name="AppBaseTheme" parent="android:Theme.Black
I've tried using Holo and am aware I need to be V11 or higher to do that.
When I try running my app it starts on the tablet and I can see the black background as expected, but before it can draw any components Eclipse goes to debug mode in ActivityThread.performLaunchActivity and then into ZygoteInit$MethodAndArgsCaller.run() before my app dies.
If I use this it's fine:
style name="AppBaseTheme" parent="#style/Theme.AppCompat.Light"
I feel I'm missing something obvious or there's a fundamental part of Themes that I don't understand. I have tried removing the .android/ directory and restarting Eclipse, that fixed a few other issues.
I know the # symbol in this context denotes that it is an inbuilt style by android. Does that mean I have to add something to my app to link in other themes? If so what exactly?
Reading the Compatibility section of Android L Developer Preview (http://developer.android.com/preview/material/compatibility.html) I've seen that i can create an APP using L-sdk and also be able to run it on older sdk (like KitKat).
I've created a new project using Android L sdk and configured "build.gradle" as said in this post: Android Studio : Failure [INSTALL_FAILED_OLDER_SDK].
I've tried both the configurations:
the one proposed in question that gives me this error:
pkg: /data/local/tmp/com.example.{my user name}.materialapp
Failure [INSTALL_FAILED_OLDER_SDK]
and the one proposed in answer that gives me error on
<style name="AppTheme" parent="android:Theme.Material.Light"></style>
I've searched on others question on StackOverflow but I can't find no solutions.
SOLUTION:
Android L preview material style can be used only on devices that run Android L.
The "compatibility" is only a preview and it's not enabled.
You have to create 2 different styles.xml files with the same name that you will put in different folders.
The first, will go here:
res/styles.xml
and will look NOT have a reference to the Material theme (use the Holo theme):
so would have something like this:
<style name="AppTheme" parent="android:Theme.Holo.Light"></style>
The second will go here:
res/values-v21/styles.xml
and WILL contain the reference to the new Material theme, and would have:
<style name="AppTheme" parent="android:Theme.Material.Light"></style>
The Android framework will automatically use the correct one depending on which API the device supports (so on API 21 devices it will use Material, and on all other devices, it will use whatever else you define).
This has changed since the original answer, as Google released better support for Material design in the AppCompat libraries (which support mostly all versions of Android).
At this point, you should be using these libraries for all development, then you will be able to support Material design related features in all your apps.
Here is how to set it up: https://developer.android.com/topic/libraries/support-library/setup.html
I have a PhoneGap 3.1 project running on Android which is working fine - compiled with Android API lvl. 19. However, the native dialogs/alerts are using the Froyo/Android 2.x look and feel, whereas I'd like them to use the ICS/Android 4.x look and feel. In an older version of my , I did manage to get the dialog theme using ICS by updating the targetSDKVersion in AndroidManifest.xml. However, this has not worked in my 3.1 project.
This is an example of how they look in the version of my app running PhoneGap 2.5:
This is an example of how they look in my app running PhoneGap 3.1:
I do believe this to be less of a PhoneGap issue, but more an Android Eclipse project setting. But I have the no idea what I need to change to fix this? Could someone advise please? Thanks!
Don't worry - fixed it myself. For those who want to know, there is the following tag set in the default manifest file. By default, this is set to:
android:theme="Theme.Black.NoTitleBar"
Changing it to the following fixed it:
android:theme="Theme.DeviceDefault"
Quite simple I guess :).
Update
As of org.apache.cordova.dialog v2.9.0, the guys on the Cordova project changed the Android source to contain a default theme value to a hard coded value, as follows:
new AlertDialog.Builder(cordova.getActivity(), AlertDialog.THEME_DEVICE_DEFAULT_LIGHT);
It is frustrating, but you can comment out this line and replace it with:
new AlertDialog.Builder(cordova.getActivity());
To restore previous behaviour and have Cordova use the value specified in AndroidManifest.xml.
could anybody tell me how can I set a theme for my application which will change when version of Android will change. For example if anybody will use my app on Android 2.1 theme will look like this: http://daily-money.googlecode.com/svn/wiki/img/prefs.png
But if anybody will use my app on for example Android 4.0.3 theme will look like this: http://img.tapatalk.com/dcff019c-27ba-1e1a.jpg
I have used minSDK 7.
Thank you.
What you want is detailed in on this page: http://android-developers.blogspot.com/2012/01/holo-everywhere.html
In the section titled "Defaults for Older Apps"
You setup 2 theme files, one in the values directory and one in the values-v11 directory. Then you reference that theme file in the Manifest. As outlined in the page I linked above. You need ALL THREE blocks of XML outlined on that page under the "Using Holo while supporting Android 2.x" section.
first get the version of android running on the device :
if (android.os.Build.VERSION.SDK_INT >= 11) {
....
en after you can use setTheme(..) before calling setContentView(...)and super.oncreate() and it should work fine
#letroll, what parameter do you pass to setTheme? Does it require increasing min sdk to 13 to make the SDK available?
I have an app to release which works on all android screen-sizes (except smaller) and densities above SDK version 2.0.
It will also run on extra large screens.
Currently I have added this:
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="false"
android:anyDensity="true"
/>
But I also need to add android:xlargeScreens="true" , to allow it visible in android market on extra large screen devices, since by default it is false.
But to add android:xlargeScreens I need to change my eclipse targetsettings to 2.3 as this attribute was added from API level 9.
So what should I do with my target compilation settings for this scenario ? Should it be 2.3 while compiling ? If yes, then will the app not give any problems while running on devices with 2.0 version ?
Yes you need to change the uses sdk to 2.3 but make sure that you are not using any newer apis which are not in 2.0 or whatever your minimum supported sdk version is. Or in case you want to use them you have to use reflection.
But more about how to use the sdk versions is here and more about uses-sdk is here.
I do the same in my application and make sure you test your application in both[all] the versions before you release.
Best,
Achie.
I'm moving this from the comments to make it more clear for others looking at this question in the future.
When supporting both old and new versions of Android it can be confusing how applications manage to run despite many things change with in the frameworks during each new release, I'm going to try and clarify this here.
An application written for the 1.5 sdk can only call functions that exist for that API level, so for instance the multi touch api's didn't exist in 1.5 and never will. Now you say "Ok but I don't need to call any newer APIs, I just want my app to work in 2.3 and have a2sd support" And I say "Ok, just change your targetApi in the manifest, set the minSDK and compile against 2.3 and you're good to go."
Now why does that work? What if the onMeasure() method for ListView was changed in 2.2 and now calls betterCalculateFunction() within onMeasure()? Why does my app still work?
This is the advantage of late binding in Java. You see, Java is never compiled until it reaches a device and is running, what you are doing in Eclipse is converting it to byte code which contains a bunch of byte code instructions that are later interpreted by the device. The byte code will NEVER contain a reference to betterCalculateFunction() though (unless you directly call it. Calling onMeasure() is indirect). This can happen because when your code is running on the device it gets linked against the Android framework on the device and your code calls onMeasure() directly because it is a public outward facing API. The path of execution will then enter the framework and call whatever it needs to, then once its done return to your code.
So on 1.5 you might see
doStuff (your code) -> onMeasure
(public API) -> done
and 2.2
doStuff (your code) -> onMeasure
(public API) ->
betterCalculateFunction (private
function) ->done
Now if you need to call functions that may or may not exist depending on API level then I suggest you look at a related answer of mine here stackoverflow: gracefully downgrade your app
Hope that clears some things up.
I haven't tried 2.3, but that's what I do with 2.2.
I compile for 2.2 and test on 1.6 to make sure everything works how I'm expecting. I haven't run in to any issues with it.
To double check, set your target for 2.3 and then setup an emulator for a lower rev version to make sure it all works.
The default value for android:xlargeScreens is true, so you don't have to change anything - it's on by default, as long as your minSdkVersion or targetSdkVersion is higher than 4.
http://developer.android.com/guide/topics/manifest/supports-screens-element.html
Here is an official Android developer blog explanation of how this works:
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
In summary: you can use the newest XML whilst still supporting the older OS versions in a back compatible way.
While reading this blog post I guess I have an answer on my old question. An extract below (which is for another manifest attribute "requiresSmallestWidthDp" introduced from 3.2):
"The catch is that you must compile your application against Android 3.2 or higher in order to use the requiresSmallestWidthDp attribute. Older versions don’t understand this attribute and will raise a compile-time error. The safest thing to do is develop your app against the platform that matches the API level you’ve set for minSdkVersion. When you’re making final preparations to build your release candidate, change the build target to Android 3.2 and add the requiresSmallestWidthDp attribute. Android versions older than 3.2 simply ignore that XML attribute, so there’s no risk of a runtime failure."
For different screens you have to create multiple apk then it reduces size of your application.In each application's manifest you have to define according to following link.
http://developer.android.com/guide/practices/screens-distribution.html