Support higher version of android api - android

I want to launch NFC settings activity, which is done using action ACTION_WIRELESS_SETTINGS prior to API level 16. But in API level 16 and above it is done using ACTION_NFC_SETTINGS.
I am compiling my source using Android 4.0.3 which is API level 15.
How can I support for higher level so that it can open NFC settings in all versions.
Do i need to compile my source with API level 16 or higher and make min sdk version 15?

You would typically compile your application with the SDK of the highest API version that you use in your code (or the latest available SDK). In your app's manifest you add the minimum and target SDK versions:
<uses-sdk android:minSdkVersion="..." android:targetSdkVersion="..." />
These values define how your app will be treated on a device in terms of (backwards) compatibility features.
Then, in your code, whenever you use API calles that are not available on a certain API level, you would surround those calles with a check for the Build.VERSION.SDK_INT (as JaKoZo showed).
With regard to the NFC settings, you could do even without that check and instead catch the exception that is thrown when no activity is registered for the ACTION_NFC_SETTINGS intent:
try {
this.startActivityForResult(
new Intent(android.provider.Settings.ACTION_NFC_SETTINGS),
1); // magic number to detect when this startActivityForResult returns
} catch (Exception e) {
try {
this.startActivityForResult(
new Intent(android.provider.Settings.ACTION_WIRELESS_SETTINGS),
1); // magic number to detect when this startActivityForResult returns
} catch (Exception e1) {
}
}
Instead of the constant ACTION_NFC_SETTINGS, you could also use the hard-coded string "android.settings.NFC_SETTINGS". While I don't really recommend this, you would not need to build against a higher API level (if it's only that constant that causes you to do so).
[...]
this.startActivityForResult(
new Intent("android.settings.NFC_SETTINGS"),
1); // magic number to detect when this startActivityForResult returns
[...]

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
//do stuff
}
u mean this?

Related

Use setRequiredPasswordComplexity(passwordComplexity : Int) in API less than 31

I want to set password policy on screen lock and now I use setPasswordQuality(ComponentName admin, int quality) in DevicePolicyManager but this method is deprecated on API 31 and they add new method(setRequiredPasswordComplexity(passwordComplexity : Int)).
I can use this method in API < 31?
If I can,how should I use it?
https://developer.android.com/reference/android/app/admin/DevicePolicyManager#setRequiredPasswordComplexity(int)
As the documentation already states the method was added in API 31 and since there is no backward compatibility library for this so this functionality can only be used on devices with api 31 or above
I think your problem might solve here. You can check the build version by
if (android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.S){
// Do something for version 31 and above versions
} else{
// do something for phones running an SDK before 31
}

Call requires API level 11 (current min is XX) - For AlertDialog.Builder.Ctor

I try to use constructor of AlertDialog.Builder which gets a context and a theme:
AlertDialog.Builder b = new AlertDialog.Builder(this, 0);
It shows an error on my Eclipse (marking the "Builder" type): "Call requires API level 11 (current min is 7)".
When I use the constructor which gets only the context (without theme), it doesn't show this error.
I want to be able to deploy my app also on old androids (such as version 2.1 etc.). Is there any convenient way for me to use the simple constructor of AlertDialog.Builder when it's an old version, and to use the more complicated constructor when it's API 11 and above?
Just out of curiosity, how does the compiler know what API version is needed for the use of a certain method?
You may use the const Build.VERSION.SDK_INT on an if clause, to check if your API level is above or below the required level (You will probably have to add an annotation to suppress the API level warning / error from that method / class).
Android Lint does that for you. It checks which methods and ctors are allowed on a certain API level.
Example:
if(Build.VERSION.SDK_INT >= 11) {
//API level 11 and above ctor here
} else {
//Lower than API level 11 code here
}

Using Android Beam less API level 14

So, that's my problem, I wanna have one Activity to work on all of the API level I support on my Activity (from API level 8 to current API level).
My problem is that if I want to use Android Beam I need my Activity to implement
NfcAdapter.CreateNdefMessageCallback
and
NfcAdapter.OnNdefPushCompleteCallback
but I cannot make it work if the SDK level is below 14.
Does anyone know if I can do something else to make it work like for example youtube application does or do I need to have two different applications, one for Android less API 14 and another one for Android API 14?
Do not use the interface implementation directly in your activity.
Instead, check the SDK level and set the callback manually if you are above SDK14
e.g:
private class myCallback implements NfcAdapter.CreateNdefMessageCallback {
#Override
public NdefMessage createNdefMessage(NfcEvent nfcEvent) {
// Your callback code
...
}
}
MyNfcAdapter.setNdefPushMessageCallback(new myCallback, activity, activities);

Is it possble to target Android 2.1 and use CalendarProvider on devices with Android 4.0 and higher?

Is it possble to target Android 2.1 and use CalendarProvider on devices with Android 4.0 and higher or is it can only be achieved by creating 2 separate APKs?
That depends on what you mean by "target".
If you mean "set targetSdkVersion" to Android 2.1, you can still use whatever APIs you want, so long as you only try calling them when you are running on a device that has them.
If you mean "set the build target" to Android 2.1, you can still use whatever APIs you want, so long as you use reflection to access the ones that are newer than API Level 7. Since CalendarContract is a content provider, that mostly is a matter of accessing various static data members, such as CONTENT_URI. Here is an example of using reflection to get at a CONTENT_URI value:
private static Uri CONTENT_URI=null;
static {
int sdk=new Integer(Build.VERSION.SDK).intValue();
if (sdk>=5) {
try {
Class<?> clazz=Class.forName("android.provider.ContactsContract$Contacts");
CONTENT_URI=(Uri)clazz.getField("CONTENT_URI").get(clazz);
}
catch (Throwable t) {
Log.e("PickDemo", "Exception when determining CONTENT_URI", t);
}
}
else {
CONTENT_URI=Contacts.People.CONTENT_URI;
}
}
(note: this example is designed to run on Android 1.5 and higher -- depending on your minSdkVersion, you could use Build.VERSION.SDK_INT instead of new Integer(Build.VERSION.SDK).intValue()).
If by "target" you mean something else, then we would need clarification of your use of the verb "target".

What if I want to release an update with higher minSDK than the one on the market?

I have released an app on the market with minSDK set to 4 (Android 1.6) but now I want to release an update with features unavailable in 1.6 so I need a higher minSDK.
So, my question is: Will users running 1.6 be notified of this update?...and if yes will they be able to download/install it?
No they shouldn't be notified of the update. The market will filter the application out all together and they will no longer be able to see it or receive updates.
If you want to add features that use a higher api level but not exclude user's of a lower api level you can use some reflection to enable this:
public static Method getExternalFilesDir;
try {
Class<?> partypes[] = new Class[1];
partypes[0] = String.class;
getExternalFilesDir = Context.class.getMethod("getExternalFilesDir", partypes);
} catch (NoSuchMethodException e) {
Log.e(TAG, "getExternalFilesDir isn't available in this devices api");
}
This piece of code is saying:
Within the Context.class have I got this method
getExternalFilesDir (API level 9)
If so instantiate the variable getExternalFilesDir as a reflective call to this method else leave it as null.
Then later on you can simply do
// If the user's device is API9 or above
if(getExternalFilesDir != null){
// Invoke is basically the same as doing Context.getExternalFilesDir(var1, var2);
getExternalFilesDir.invoke(variable1, variable2);
} else {
// User cannot use this method do something else
}
Hope that helps

Categories

Resources