This is how I handle a deprecated method:
int layoutDirection ;
if (getContext().getApplicationInfo().targetSdkVersion > Build.VERSION_CODES.JELLY_BEAN_MR1) {
layoutDirection = getLayoutDirection();
}else {
layoutDirection = getResolvedLayoutDirection();
}
The problem is that getResolvedLayoutDirection() has been removed at JELLY_BEAN_MR1 and above. So since my project targets API 20 the method cannot be found and I get an error.
If I keep it foolish:
int layoutDirection = getLayoutDirection();
The project compiles and runs but still I get an error to add either the TargetApi or SuppressLint annotation. getLayoutDirection() docs have:
For compatibility, this will return {#link #LAYOUT_DIRECTION_LTR} if
API version is lower than {#link
android.os.Build.VERSION_CODES#JELLY_BEAN_MR1}.
So suppressing lint should be fine.
Should I suppress the lint error or fix it somehow else (possibly make getResolvedLayoutDirection() accessible)?
The approach to conditionally check whether a method is available is to check the version of Android that the device is running, via Build.VERSION.SDK_INT:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {
layoutDirection = getLayoutDirection();
}
else {
layoutDirection = View.LAYOUT_DIRECTION_LTR;
}
And add #TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1) to the method containing the above block to indicate to the build tools that, for that individual method, to consider your minSdkVersion to be 17 instead of whatever it normally is, for the purposes of generating Lint warnings and errors.
Related
The code I want to use:
window.addFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED)
There is FLAG_SHOW_WHEN_LOCKED that is deprecated in the API 27 and its alternative setShowWhenLocked added in the API 27
How should I use it properly if the minSdk in my project is 21 and the targetSdk is 33?
I get the warning is deprecated. Deprecated in Java
Even if I handle it this way:
if(Build.VERSION.SDK_INT >= 27) {
setShowWhenLocked(true)
setTurnScreenOn(true)
} else {
window.addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD or
WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED or
WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON)
}
I still get the warning. What is the right way to support both old and new API?
TLDR
1.Use different code for different API versions.
2.Ignore/surpress this warning if you properly proccess all the API versions that your app is created for
3.If there is a new alternative that works for all the API levels - use it
Instruction
Use Build.VERSION.SDK_INT in the condition to behave accordingly to the SDK_INT
Use setshowwhenlocked if SDK_INT>=27 and FLAG_SHOW_WHEN_LOCKED if SDK_INT<27
Surpress the warning
Example with the FLAG_SHOW_WHEN_LOCKED/setShowWhenLocked
if(Build.VERSION.SDK_INT >= 27) {
setShowWhenLocked(true)
setTurnScreenOn(true)
} else {
#Suppress("DEPRECATION")
window.addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD or
WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED or
WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON)
}
But why do we have to surpsess the warning?
The warning exists only because #Deprecated APIs do not have any metadata that would indicate which SDK they were deprecated in. as you can see in this issue.
We can surpress the error because we have properly processed both old api (5-27) and new api (27>)
Warning
Do not surpress these warnings if the code is not properly processed by using if conditions where the right API is used.
Example how you must not do
#Suppress("DEPRECATION")
window.addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD or
WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED or
WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON)
Your minSdk is 21 and targetSdk is 33
This code will work on devices with 5-27 API (Android 5 - Android 8.1) but will not work on new devices. You must properly handle both conditions.
Example with the Vibrator
The old way to get the vibrator
context.getSystemService(VIBRATOR_SERVICE) as Vibrator
The new way to get the vibrator
val vibrator = if (Build.VERSION.SDK_INT >= 31) {
val vibratorManager =
context.getSystemService(Context.VIBRATOR_MANAGER_SERVICE) as VibratorManager
vibratorManager.defaultVibrator
} else {
#Suppress("DEPRECATION")
context.getSystemService(VIBRATOR_SERVICE) as Vibrator
}
Will show you the warning `'VIBRATOR_SERVICE: String' is deprecated. Deprecated in Java`. Go to the [documentation](https://developer.android.com/reference/kotlin/android/content/Context#vibrator_service) and see that this constant can be used in the API 1-31 so we must. And in both IDE and documentation there is the info about the alternative: `Deprecated: Use android.os.VibratorManager to retrieve the default system vibrator.`. As you can see the [VibrationManager](https://developer.android.com/reference/kotlin/android/os/VibratorManager) is added in the API 31 therefore we must write the different code for different sdk versions
If an alternative is backwards compatible
If an alternative is backwards compatible you can just use it instead of the old way
Example
If you inherit AppCompatActivity in your activity:
class SaveMyLifeActivity : AppCompatActivity()
You can meet the warning startActivityForResult(Intent!, Int): Unit' is deprecated. Deprecated in Java if you call startActivityForResult:
val intent = Intent(this, SaveMyLifeActivity::class.java)
startActivityForResult(intent, 0)
You can press Alt+Q (Default keybind) to see the Context info(it is called this way in the AndroidStudio is you check your keymap) or use the website do see the documentation
Take a look to the words that this method is deprecated and you must use registerForActivityResult instead. This method can be called in any version right now, there are no Added/Deprecated "section" in the documentation.
Question: How have you found this documentation? I google AppCombatActivity startActivityForResult and come to this documentation. There is no word about startActivityForResult.
Answer: Open the context info about this method in the IDE (Alt+Q) and look at the bottom of the Context info . There is a class name where this method is located in (ComponentActivity). You have to google ComponentActivity startActivityForResult instead of AppCombatActivity startActivityForResult
I was messing around with MeasureSpec when I came across this bit of text:
Note: On API level 17 and lower, makeMeasureSpec's implementation was such that the order of arguments did not matter and overflow in either value could impact the resulting MeasureSpec. RelativeLayout was affected by this bug. Apps targeting API levels greater than 17 will get the fixed, more strict behavior.
So that got me wondering: If I build an app for API 14 but I run it on an API 22 device will it fix the bug or will < API 17's bug still exist on the 22 device?
makeMeasureSpec(API 17<) method's implementation is the following:
public static int makeMeasureSpec(int size, int mode) {
if (sUseBrokenMakeMeasureSpec) {
return size + mode;
} else {
return (size & ~MODE_MASK) | (mode & MODE_MASK);
}
}
As you can see it's return value is depending on the value of sUseBrokenMakeMeasureSpec which value is assigned in the View class's constructor:
sUseBrokenMakeMeasureSpec = targetSdkVersion <= JELLY_BEAN_MR1;
So only the app's target will determine the behaviour. By doing it this way a newer system can maintain compatibility with an older app which expets the old behaviour.
In an Android app, we wish to have an iOS-like horizontal scroll wheel, and we are using HorizontalPicker.
This requires API 17 for calls getTextDirection() and getLayoutDirection().
For getTextDirection, the usage is:
switch (getTextDirection()) {
default:
case TEXT_DIRECTION_FIRST_STRONG:
return (defaultIsRtl ? TextDirectionHeuristicsCompat.FIRSTSTRONG_RTL :
TextDirectionHeuristicsCompat.FIRSTSTRONG_LTR);
case TEXT_DIRECTION_ANY_RTL:
return TextDirectionHeuristicsCompat.ANYRTL_LTR;
case TEXT_DIRECTION_LTR:
return TextDirectionHeuristicsCompat.LTR;
case TEXT_DIRECTION_RTL:
return TextDirectionHeuristicsCompat.RTL;
case TEXT_DIRECTION_LOCALE:
return TextDirectionHeuristicsCompat.LOCALE;
}
Looking at dashboard, I see ~20% of devices using APIs 15 or 16, so I'm thinking we should target API 15 rather than 17.
How should I change this code?
Is there a way to only run this code if the device is new enough? If so, what should the function return for an older device?
Is there an alternative mechanism I should rewrite this method to use?
Never mind. Leaving this question here in case it is useful to others, to know how to work around APIs missing in a given version.
My real issue was not knowing how to mark the calls so that "lint" would not complain about them.
Here is the complete implementation in HorizontalPicker:
private TextDirectionHeuristicCompat getTextDirectionHeuristic() {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
return TextDirectionHeuristicsCompat.FIRSTSTRONG_LTR;
} else {
// Always need to resolve layout direction first
final boolean defaultIsRtl = (getLayoutDirection() == LAYOUT_DIRECTION_RTL);
switch (getTextDirection()) {
default:
case TEXT_DIRECTION_FIRST_STRONG:
return (defaultIsRtl ? TextDirectionHeuristicsCompat.FIRSTSTRONG_RTL :
TextDirectionHeuristicsCompat.FIRSTSTRONG_LTR);
case TEXT_DIRECTION_ANY_RTL:
return TextDirectionHeuristicsCompat.ANYRTL_LTR;
case TEXT_DIRECTION_LTR:
return TextDirectionHeuristicsCompat.LTR;
case TEXT_DIRECTION_RTL:
return TextDirectionHeuristicsCompat.RTL;
case TEXT_DIRECTION_LOCALE:
return TextDirectionHeuristicsCompat.LOCALE;
}
}
}
It already has logic to handle older builds!
So all that is needed is to mark the two calls getLayoutDirection() and getTextDirection() so that lint does not complain.
The simplest way to do so, without hiding problems elsewhere, is to mark this method to suppress lint complaints about API versions:
#SuppressLint("NewApi")
private TextDirectionHeuristicCompat getTextDirectionHeuristic() {
...
CAUTION: Only make such a change, after examining the lint complaints and the logic, and your AndroidManifest.xml, to be sure the complaints can be safely ignored.
In my case, manifest has minimum API = 15 and target API = 19, the two complaints were "Call requires API level 17, minimum is 15)", and
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
directs all devices less than 17 to use the one-line implementation, which does not use the API 17 calls. That is, the calls will only be made on devices with API 17 or above.
You can use ViewCompat from android.support.v4 with something like :
if (ViewCompat.getLayoutDirection(mView) == ViewCompat.LAYOUT_DIRECTION_RTL) {
//...
}
For instance, this code:
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.GINGERBREAD) {
myCalendarView.setOnDateChangeListener(
new OnDateChangeListener() {
#Override
public void onSelectedDayChange(CalendarView view, int year, int month, int dayOfMonth) {
Toast.makeText
(
getApplicationContext(), ""+dayOfMonth, 0
).show();
}
}
);
}
Gives error:
Description Resource Path Location Type Call requires API level 11
(current min is 8):
android.widget.CalendarView#setOnDateChangeListener example.java /example/src/com/example/example line
20 Android Lint Problem
I understand why I get this error compile-time. But is there any way to mark a source Java class to only be used on certain API level-11? Or surround code blocks with a define/similar so the code is late-bound/jitted only on devices above API level-11? What is the best solution to achieve what I want? (Which is to provide an activity with CalendarView on devices capabile of it.)
I'm not sure if this is going to solve your issue,
but what you are using to check version is not working under API 9
(and you are supporting since API 8).
You should use:
if (Build.VERSION.SDK_INT > 9) {
Or as problematic function is API 11, check for "SDK_INT>10"
Then for lint errors on eclipse, do as people comment, disable lint errors or add the #SuppressLint("NewAPi") or the target to that function to 11.
For anyone stumbling upon this much later, conditionally executing code based on the API version at runtime is currently a valid way of supporting different platform versions.
See: https://developer.android.com/training/basics/supporting-devices/platforms#version-codes
Where it says:
Android provides a unique code for each platform version in the Build
constants class. Use these codes within your app to build conditions
that ensure the code that depends on higher API levels is executed
only when those APIs are available on the system.
And gives examples:-
Java:
private void setUpActionBar() {
// Make sure we're running on Honeycomb or higher to use ActionBar APIs
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
ActionBar actionBar = getActionBar();
actionBar.setDisplayHomeAsUpEnabled(true);
}
}
Kotlin:
private fun setUpActionBar() {
// Make sure we're running on Honeycomb or higher to use ActionBar APIs
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
actionBar.setDisplayHomeAsUpEnabled(true)
}
}
In one of our methods, we use smoothScrolling in a list view. As this method is not available before API Level 8 (FROYO), we used the TargetApi annotation to prevent the method from being called in previous SDK versions.
As you can see, we do use TargetApi annotation both in class definition and in statements that use the objects of the class. This is more than needed.
Our problem is that the TargetApi annotation is not taken into account and make our emulator crash in version ECLAIR (SDK 7). By tracing, we just realize that the code that should only be executed in versions 8+ is also executed in version 7.
Are we missing something?
This code is in a listener :
#TargetApi(8)
private final class MyOnMenuExpandListener implements OnMenuExpandListener {
#Override
public void onMenuExpanded( int position ) {
doScrollIfNeeded( position );
}
#Override
public void onMenuCollapsed( int position ) {
doScrollIfNeeded( position );
}
protected void doScrollIfNeeded( int position ) {
if ( mListViewDocuments.getLastVisiblePosition() - 2 < position ) {
mListViewDocuments.smoothScrollToPosition( position + 1 );
}
}
}
And the listener is registered this way :
#TargetApi(8)
private void allowSmothScrollIfSupported() {
if ( Build.VERSION.SDK_INT >= Build.VERSION_CODES.FROYO ) {
//This if should not be necessary with annotation but it is not taken into account by emulator
Log.d( LOG_TAG, "Smooth scroll support installed." );
folderContentAdapter.setOnMenuExpandListener( new MyOnMenuExpandListener() );
}
}
BTW, we run the code in debug mode, so the issue is not related to obfuscation removing annotations.
#TargetApi does not prevent any code from being run, it is merely for annotating code and preventing compiler errors for new APIs once you know you are only conditionally calling them.
You still need to add something along the lines of
if (Build.VERSION.SDK_INT > 7){
//...
}
With almost one year of more thinking about this, I would like to add a tiny complement to #Guykun 's answer :
The #TargetApi will be only be used by tools to say developers "Hey, don't use this method below XXX android SDK". Typically lint.
So, if you design a method like :
if (Build.VERSION.SDK_INT > 7){
//...
}
then you should add #TargetApi( 7 ) to your method's signature.
BUT, if you add an else statement, and provide an alternative that makes it work for all versions of Android like :
if (Build.VERSION.SDK_INT > 7){
//...
} else {
//...
}
then you should not add #TargetApi( 7 ) to your method's signature. Otherwise, other developers will think they can't use your method belw api level 7, but indeed, it would work for them as well.
So this annotation has to be used, for static analysis, to indicate the minimum api level supported by the method. As in :
#TargetApi( 7 )
public void foo() {
if (Build.VERSION.SDK_INT > 7){
//...
else if (Build.VERSION.SDK_INT > 10){
//...
}
}
and even better, use constants defined in android.Build.VERSION_CODES.*.
BTW, you would have noticed that this is useless for private methods indeed, except to get a cleaner code and help to promote the method public in the future.
To enforce lint error when using a method targeted towards higher Api Level, you can use RequiresApi instead of TargetApi and whenever you'll try to use the method without checking the version code, you'll get compilation error.
This is what the documentation says about RequiresApi
This is similar in purpose to the older #TargetApi annotation, but
more clearly expresses that this is a requirement on the caller,
rather than being used to "suppress" warnings within the method that
exceed the minSdkVersion.