I looked in http://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates%28long,%20float,%20android.location.Criteria,%20android.app.PendingIntent%29
and there is function requestSingleUpdate but in code in Eclipse I am getting error when I want to use requestSingleUpdate, like that function doesn't exists. Did anybody have the same problem ?
That function was implemented in API level 9 (Android 2.3). Most likely your project targets a lower API level. You can raise the target level to 9 or greater. Or you can use reflection to test if this method is available on the phone your app gets executed and use it only in this case (+ have fallback code for older versions).
It was introduced in API 9. If you're using less than that, then it won't be available.
Related
I read about targetSdkVersion in the Documentation and I know what targetSdkVersion is. But my question is when targetSdkVersion is 19 and if minSdkVersion is 8.. Now if my app uses API 16 in some parts of the code, does my app run in android 2.3 ?
Your app will still run BUT you have to check the Android Version before using the specific method. Android Studio generally prevent you about possible issue. If you're using a API 16 method on API8, is likely the app will crash. It will throw a NoSuchMethodException or a ClassNotFoundException (depends). This is why you have to check the version running to prevent crash.
Example
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.JELLY_BEAN){
view.setBackground(drawable);
} else {
view.setBackgroundDrawable(drawable);
}
Annotation
You can also use Annotation to specify a method that will run on a specific version and above :
#TargetApi(Build.VERSION_CODES.JELLY_BEAN)
public static void setBackground(View view, Drawable drawable){
view.setBackground(drawable);
}
If you will use code from api 16 on device with android 2.3,probably will be NoSuchMethodException.
The short answer is: yes. The long is, only if you don't use higher level API calls. The MinSDKVersion tag is used by the market to indicate that lowest device OS that that app can be installed on. The target SDK version is used to indicate the API level that you would like to compile with, which gives you access to the higher level API calls. However, if you do that, you will have you guard some of your code as some devices (the minSDKVersion devices) may not have the desired API.
No forget about running, if ur using the API's available for API level 16 and not available on API level 2.3. First thing is Eclipse will give u an ERROR stating that ur minimum sdk ver is 8 where in the API(a method or a function) which ur using is not available for sdk ver 8.
So u can check ur sdk version and make decisions based on that. This is also applicable the vice versa , that is suppose the method which u will be using is deprecated will be shown as a warning to u in Eclipse. That particular functionality may work upto some sdk version and then it might completely lose its functionality after some API levels and the support is completely stopped in the upcoming API level.
Here is a small example of how to make use of this check:
private int currentApi = Build.VERSION.SDK_INT;
if(currentApi >= 16){
btnIconTxt.setBackground(new ColorDrawable(Color.parseColor(btnColor)));
}
else
btnIconTxt.setBackgroundDrawable(new ColorDrawable(Color.parseColor(btnColor)));
The setBackgroundDrawable(Drawable)[this method wont work properly on KITKAT] is deprecated from API level 16, so a precheck and using appropriate methods is better. If the API level is greater than or equal to 16 then go for the first one in this case.
I made the mistake of not taking into consideration of the API level of each method used in my code. So after coding 500 lines, I have no idea what is the highest Android API level I have used in my code.
Obviously, I hope I do not have to check through every single line of method for its API level so I am wondering is there an option in Eclipse to check the highest API level method which I had used.
Set your target SDK level to your minimum SDK, set your project build target to be the same API level, recompile and fix the errors as they show up.
Note that you will still have to handle API behavior changes like what happened with AsyncTask, but its a start.
The latest Android APIs have some helpful methods that are not available to older Android versions. The DatePicker, for example, has a new method called setCalendarViewShown() that is not available for old APIs such as Android 2.2 (level 8) and so on.
However, I've set the minimum API level to 8 and the target level to 16. So I would like to use these methods if available (on level 11+ devices).
Now I've tried to distinguish between several API levels programatically and, if available, call the method like this:
if (android.os.Build.VERSION.SDK_INT >= 11) {
datePicker.setCalendarViewShown(false);
}
Is this approach okay? In Eclipse, there's just some warnings, but they can be suppressed, of course. Due to checking for the SDK_INT, this code should be fine and cause no problems, shouldn't it?
Is this approach okay?
I'd use Build.VERSION_CODES.HONEYCOMB instead of 11 for readability, but otherwise yes.
In Eclipse, there's just some warnings, but they can be suppressed, of course.
Eclipse will point out that setCalendarViewShown() does not exist in API Level 8. It has no reliable means of confirming that you are only calling that method within a version guard block, so it just complains. Using the TargetApi(11) annotation will get rid of it, while still ensuring that if you add something else to the method that needs something higher than 11, you will get warned again.
Due to checking for the SDK_INT, this code should be fine and cause no problems, shouldn't it?
Yes.
BTW, in this particular case, there's an XML attribute you could use (android:calendarViewShown) to replace the call. As XML attributes are automatically ignored on older versions, you could then skip the Build check.
Can you explain to me how I should determine the correct value for targetSdkLevel?
Let's say I want to build an app that works on all the versions from android 2.3.7 to 4.0.3, how should I set minSdkLevel and targetSdkLevel?
The former should match the API level of android 2.3.7 and the latter should match the API level of 4.0.3?
Then, when I develop my app, should I use only Methods/classes available in the oldest supported sdk level?
When I compile the app does it compile for 2.3.7 or 4.0.3?
I can not understand the purpose of targetSdkLevel, since the apk can not be compiled for the newer version specified in this tag, otherwise it could not work on versions down to the one specified by minSdkLevel... Why should I not set targetSdkLevel to the latest available level?
I've read also the official info about uses-sdk Manifest tag, but I still do not understand.. Can you help me clarifying this topic?
EDIT: thanks to all of you and excuse me for the duplicate question. I've read this Blog post and it really helped me. Great answers from all of you.
You should only use methods/classes available in the SDK specified by minSdkLevel, or otherwise wrap them with a proper check for the runtime API version.
Your application will be compiled with the SDK specified in the project itself, not by the one specified by either minSdkLevel nor targetSdkLevel.
You should set targetSdkLevel to the highest level API that you have tested the application with. This is because compatilibity behavior will be enabled/disabled for your application based on this value.
It clearly is explained here: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
minSdkVersion:
An integer designating the minimum API Level required for the
application to run. The Android system will prevent the user from
installing the application if the system's API Level is lower than the
value specified in this attribute. You should always declare this
attribute.
And for targetSdkVersion
An integer designating the API Level that the application targets. If
not set, the default value equals that given to minSdkVersion. This
attribute informs the system that you have tested against the target
version and the system should not enable any compatibility behaviors
to maintain your app's forward-compatibility with the target version.
The application is still able to run on older versions (down to
minSdkVersion).
What is that you don't understand here?
This is how you would set it:
<uses-sdk android:minSdkVersion="10"
android:targetSdkVersion="15"/>
You can read about the changes here, for API Level 14: http://developer.android.com/sdk/api_diff/14/changes.html
and here for API Level 4: http://developer.android.com/sdk/api_diff/4/changes.html
Build using the target, and then you can check and gracefully downgrade if the user is below the target. For example, if you are creating a location aware app, you might want to use PASSIVE_PROVIDER which is available starting with version 8. You could set the min version lower than 8 and check the android version. From there you could decide to use or not use PASSIVE_PROVIDER based on the version.
google suggests that you always use the latest version of the targetSdk , and also gives the lint tool to check for you that your classes and methods aren't too new for the minSdkVersion .
in case of a warning , you will need to think of how to handle it.
do note that as people has mentioned here , setting the targetSdk also means that it will change some aspects of the app .
one aspect is how the app treats the menu button : if you set the targetSdk to 11 or above , it means that you can't assume that there is a menu button , so you will have to deal with the action bar and put the options there in some way (or any other way, depending on your app design) .
if you set it to 10 or below , android will add this button (shown as 3 dots) on the screen for devices that don't have the menu button , like the htc one x or the galaxy nexus . do note that for some devices it looks ugly (takes a whole row for the htc one x , for example) .
so , in short , i would suggest setting the minSdk to the minimum that you can , in order to support as many people as possible , and the targetSdk to the maximum that you can , in order to enjoy all of the benefits that it can give you .
I am using API level 8 , documentation says its available after API level 5 !
http://developer.android.com/reference/android/media/ExifInterface.html#TAG_EXPOSURE_TIME
I am trying to use like this ,
exifObj.getAttribute(ExifInterface.TAG_EXPOSURE_TIME)
but not able to resolve the ExifInterface.TAG_EXPOSURE_TIME in eclipse !
I get make , model etc. but few tags like exposure time and aperture I am not able to use !?
You have misread the documentation.
TAG_EXPOSURE_TIME is available since API level 11.