Support newer api functions if available - android

My Question: Can I support an older api and use functions of a newer api if available?
My Situation: I'm building a simple app that I want to support some advanced functions with the UI if available. But the API level I'm supporting is 13 so I can support Android 3.2. Specifically, I want to use the View.SYSTEM_UI_FLAG_* variables, but those are not available in api level 13.

Yes, you can check that at runtime:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
// my code using HC API
} else {
// code that works on older API
}
and you have to set android:targetSdkVersion of your app's Manifest to highest API version you want to support, otherwise you will not be able to build it.
Please see this <uses-sdk> related article.

Related

If I need to target Android API 18 and a method is deprecated in a later API version, how to proceed?

I would like to use a method that was introduced in Android API 18 but was deprecated in API 21. However, my app must be compatible with devices with API 18 installed.
Is the proper thing to do to simply continue using this deprecated method? Or should I check the version and have two versions of my code, one for API 18 and one for API 21 and later?
You can use the method that supports in API 18 and though it is deprecated it does not create you any problem. If you still want to put some validation around it then
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.JELLY_BEAN_MR2&&android.os.Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.LOLLIPOP) {
// write your code here which should work for version between 18 and 21.
}
else if(android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP)
{
// write the alternate code for API 21+
}
Use something like:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {}
if you're developing for less than Lolypop than you can use it , if you want the new androids use the replacement
https://developer.android.com/reference/android/bluetooth/le/BluetoothLeScanner.html
From Deprecated Annotation documentation
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
No one says that will be removed but...imho is better to rewrite the code (if possible) and use the new backward compatibility method.
If you cannot do this check on SDK API version manually.

Do I have to write explicit code to ensure the backward compatibility?

If I specify the minimum SDK as 2.0 and the target SDK as 4.1,will I have to write explicit code to ensure backward compatibility. Like if I want to use a gesture detection feature introduced in SDK level 7 and I set the target as 7 and minimum to 3. I am asking will I need to write explicit code(which doesn't include the gesture detection features) so that it runs in targets less than 7 but greater than 3?
Yes, you will have to avoid calling future APIs when running on older versions of Android. You can organize your code to select an appropriate code path at runtime, depending on the version of your OS.
An example of how to preserve backwards-compatibility when using a new API.
Yes, you will need to, but I don't see any logical reason to still support any API before 8 (2.2).
It's literally 1.6% of the market. It's not worth the effort to maintain and support such early versions any more.
That said, if you need to do version specific code, this is the way to handle it:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR) {
//Use API 7+ code
} else {
//Use backwards compatible code
}
You should check out the Android official site on how to guarantee backwards compatibility to minimum level 4 (which is negligible up until api level 7 anyway. The slightly more significant share is usually api level 8 upwards), and always use the latest support library.
Of course there are some minor code changes (such as getSupportFragmentManager() in replace of getFragmentManager(),etc). The worst you it can happen is NoSuchMethodException so you have to be real careful not to call API's that does not exist in lower platforms. The sdk should be very clearly advising that when it happens.

android - SDK 4.0 on android 2.1

Even though I have done some app on android, I am still confused. Is it possible to use functions in SDK 4.0, and run the app on android 2.1 or lower?
I tried methods you guys mentioned but got an error -
Field requires API level 11 (current min is 7): android.os.AsyncTask#THREAD_POOL_EXECUTOR, if I change min to 11, the app can't install on android 2.1, so even I can use higher API, but it still can't run on android lower version...how to fix that?
From Kzinch's advice, set TargetApi to 11, then it's working!
If you want a program that runs on both SDK4 and SDK 2.1 you have two possibilities. One is to provide alternative implementations on your code when they are needed i.e., if some function from SDK4 is not available in the SDK2.1 then you add a conditional block to your code that check the SDK version and provide code for each branch.
The other possibility is to use the Android Support Libaries in order to use the same code for both SDKs (no conditional blocks required). If you need a function provided by the SDK4 but not for the SDK2.1 you can check if that function is provided by a support library. If it is you can use it and your code will run fine on both SDK4 and SDK2.1 without requiring any version checking. For instance, if you need to use the LruCache class which is available since API level 12 (and so not available on SDK2.1) you can use the v4 support library which provide that function and works on SDK2.1 and SDK4. So in your code you would use
import android.support.v4.util.LruCache;
instead of
import android.util.LruCache;
Yes, you can use functions from the higher API in your code, but you must make sure they are never called on the lower API in runtime.
You should make checks for API level in runtime and provide alternative implementation that exists for that API level.
Let me provide some simple example:
SharedPreferences.Editor edit = PreferenceManager
.getDefaultSharedPreferences(getActivity()).edit();
edit.putInt(KEY, VALUE);
if (Build.VERSION.SDK_INT >= 9) {
edit.apply();
} else {
edit.commit();
}
apply() method is a faster (asynchronous) implementation of commit() method, but it not supported on the API level less than 9. With the help of API version check it all works perfect for all devices.
Update #TargetApi annotaion may be used to suppress Lint warnings/errors for API checks.
it doesn't matter what SDK level you compile your code against. Important is which methods/classes are you calling/instantiating.
If you use any newer classes or methods your code WILL crash running on older devices.
The suggested method to deal with it is Lazy Loading: http://android-developers.blogspot.co.uk/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
and remember, I'm saying this about the SDK.
The compatibility pack is a library developed by google that you can add to any project and use the functions of the library without issues.
Furthermore, there're 3rd party libraries (such as the ActionBar Sherlock http://actionbarsherlock.com/ that aims to bring higher SDK level functionalities to lower SDK levels)
No. You cannot use methods from higher API, because the code to handle it is simply not present on lower version of API. You can, however target as high API version as possible, but you may take care to call these methods on right API. You can easily check that at runtime with. i.e.
f( Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB ) {
// code to be run on Honeycomb and higher versions
}
If you are using the API which are specific to higher version, then the app wont work in older version.As those are not defined in the older version it will throw an error.That is the reason we restrict apps before uploading into market using minSDK in AndroidManifest.xml.

Higher API calls when lower SDK targeted

My app supports minSdkVersion=10 and targeting 16. I want to call methods specific to API level >= 14 if a specific device supports them. I could check running OS version at runtime and whether call or not higher API methods but when I specify min SDK version, methods that exist only in versions higher than 10 are not visible.
Is there any way to use higher API methods than minSdkVersion?
You can test the device's API with this:
if(android.os.Build.VERSION.SDK_INT >= 14) {
// Do something fancy
}
else {
// Do something regular
}
In addition of checking the current version you should also add #SuppressLint("NewApi")to your method so the compiler want yell about it.
Methods from higher API are invisible and inaccessible because project's target SDK is lower than SDK which methods are going to be used. For example: if you want to use methods from API 14 Android project target SDK should be at least 14 or even better the latest (currently 16). That is kind of obvious but I missed it. After that the solution Sam gave a reference to is in use.

Android application limiting features to support backwards compatibility

I have an Android app that has a minimum API level of 4 (Android 1.6) and I have some users who use this version of Android. However, I would like to implement a feature that uses NFC, which requires Android 3 or higher (API level 9+). This means that I would have to change the minimum API level in my manifest file, which will alienate users using older versions of Android. So is there a way to programmatically disable the feature that uses NFC if the device is incompatible and still allow the use of other features instead of locking out users using older versions of Android?
Set the min-sdk to 4 and the target-sdk to 9 and use something like this in your code:
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB){
//your API-9 specific code here
}else{
// an alternative code
}
this for the java part, in XML the newer attributes are ignored so its safe to add what you need
Read this http://developer.android.com/resources/articles/backward-compatibility.html . You can check if method exists using reflection API. Read previous questions: Check if method exists
You need yo encapsulate API level specific code to external classes and use reflection for calling them (using interface for example)

Categories

Resources