I'm using android version 2.2 and I cant find android.bluetooth.IBluetoothA2dp in the bluetooth sub-package android.bluetooth.
Do I have to upgrade to a higher version for this file to be available. Or what else should I do so I could be able to implement this interface to use it in my project?
I'm not sure why you need IBluetoothA2dp and not the BluetoothA2dp. But the IBluetoothA2dp interface is a hidden interface (see here). At least up to Android 3.0 (not including).
As for BluetoothA2dp class it was publicly introduced in API Level 11 (Honeycomb, Android 3.0). It was first introduced in Android as earlier as API Level 3 and marked as hidden. Then it was dramatically changed in API Level 5 at still was marked as hidden. And officially released only in API Level 11.
You can use reflection to access that class on earlier platforms, but that's a tricky and not recommended way.
Related
I am working on an android video calling application, which currently supports android kitkat (api level 19) . I need to add support for jelly beans(api level 16).
I have done most of the things. But i am using EGL14 class right now, which is not there in android api level 16, as it was introduced in api level 17.
I want to know how and with what to replace it .
The previously available version is EGL10 from the javax.microedition.khronos.egl package, which has been available since API level 1. The reference page is here: http://developer.android.com/reference/javax/microedition/khronos/egl/EGL10.html.
It is overall fairly similar, even though the Java bindings were implemented somewhat differently. And of course it does not have features from newer versions.
If you want to see examples of how typical calls look for both of them in comparison, you can check out my answer to this question here: http://developer.android.com/reference/javax/microedition/khronos/egl/EGL10.html. It contains code to create a context from scratch with both versions.
My app so far has been using the appcompat_v7 support library so that I can use fragments for my min target of api 8 and beyond. I just found out that PreferenceFragment requires API 11 and is not apart of the support library.
My question is it safe to use the deprecated addPreferenceFromResource even on API 11 and higher? So that I can maintain my target 8?
As I understand, the question is about using PreferenceActivity.addPreferencesFromResource(). It's perfectly fine to use it if you are targeting API level prior to 11, because on that API levels it is not deprecated.
The only problem that may arise someday is that Google announces that from certain Android version it won't support some older API levels, which (I believe) isn't going to happen in observable future.
Is there any way to detect the current version of android and use one code path for one version, and another code path for a later version?
Something like ClipboardManager, there is a new version in API level 11, but the only way of accessing this new class is by telling mono for android that the minimum requirements is API level 11.
I "think" you can get around this using java reflection, but I imagine this wouldn't work when using Mono for Android. Has anyone got any advice on how you can use both ClipboardManager's, the early one on earlier versions, the later one on later versions, without setting the API level as 11 or higher.
This is a generic example, not limited to ClipboardManager. I am sure I will come across more classes that I could optionally use if it is available.
Sure there is. Just make sure to set your target API level in the manifest.
When wanting to use API 11 for instance you could do something like this:
if ((int)Build.VERSION.SdkInt >= 11)
{
//Execute API 11 and up code here
}
However if you are using methods and classes that are only present in API 11, VS might complain that it cannot find them, so you can surround them with a pre-processor symbol like:
#if __ANDROID_11__
// your API 11 and up code here
#endif
Maybe stupid question but I am developing for android 2.2 to 4.1. Can I use this functionality http://developer.android.com/reference/android/preference/PreferenceFragment.html which is available only from API 11?
or must I use old http://developer.android.com/reference/android/preference/PreferenceActivity.html which has some deprecated methods.
Will old API works well on android 4.1?
PreferenceFragment will not work on 2.2 and 2.3 (only API level 11 and above). But above versions can use the older one. So you could just go with the old PreferenceActivity - deprected methods just mean that they should be avoided, but they usually still works.
CommonsWare have before wrote, that to offer the best experience for the user and still support version 2.2, you should implement two PreferenceActivity classes and then decide at runtime which one to invoke. This can be done by checking Build.VERSION.SDK_INT and compare against '11'.
See the accepted answer here for implementation:
PreferenceActivity Android 4.0 and earlier
yes you can use. right click on project --> select properites --> click on android --> select any target ..
any higher version google taget can run in lower version i.e, classes can be imported.. but it may possible to throw the exception if lower version wont support the class ...
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.