Develop Reference

Android Studio API level warning not showing on some newly added methods

Note: There is a question with a similar title however this is not a duplicate. If you wonder what question that is: question link The option is already enabled in my IDE.
Recently we have updated an app with some bug fixes but one of the changes caused a critical crash, depending on a method that has been added in API 29, and Android Studio didn't warn me about it which led to an unavoidable crash at user base.
If you wonder, I also have API 29 documentation downloaded in IDE, so I can see the sources, javadocs in it.
The method I've used is Parcel.writeBoolean(val) method. According to the documentation, this was added in API level 29 (I don't know why it's added this late but it was), however this is how it looks when I use it in the IDE. (Minimum API version is 21)
There are no warnings about the API usage. Hence I casually used it and it lead to a huge crash rate in our app.
Is there a way to check every method based on its API level? On normal cases (such as using Context.getSystemService(Class clazz) the IDE gives a warning that it is added in API level 23) it seems to be working, but on really newly added methods, it sometimes skips the warning.
Do I need to check every Android framework based method before using it? Or is there something that do this task properly? Any help is appreciated, thanks.

Well, apparently I had an old version of Android Studio (3.5.1), updating it to 3.6.1 solved the issue.

error in styles in API8 in Eclipse

could anyone please help me with this?
I opened an existing project and I get this error in the screenshot.

The problem is that you are using a style which require API 21. You are referencing a style called Widget.Material.ActionButton. So you need to put this reference in a v21 directory to use the CompatLibrary which I would recommend.
The real cause seems to be that you have a very low target SDK (like you wrote in the comments API 8). You should set it to the most newest one, it cannot break anything. So set the target SDK to API 21 or newer and it should work fine.

Does every Android device contains all previous SDK versions?

I'm just wondering, if the latest Android SDK installed on a device contains code of all the previous versions as well?
So if I target API level 10 in my app and install it on a device with Lollipop, will it just take and use Gingerbread SDK exactly as it was 3 years ago?
Or is there just one codebase for all versions with a lot of checks and switches which is then run by some kind of compatibility mode picking the correct code and enabling methods of the version of SDK I target?
I read the article about android:targetSdkVersion specified in Manifest but still would like to know how this works internally.

Ok, I just surfed a bit around on the source code (which you can find here: https://github.com/android/platform_frameworks_base). I'm not an engineer of the Android framework, I was just curious about your question and here is what I found.
It does not contain all the different versions of source code. You can imagine that this would result in a nightmare if more and more versions become available. Foremost, you would have different (buggy) versions of the same method without fixing them just to keep them the same.
In the source code, you can find places like these: (see https://github.com/android/platform_frameworks_base/blob/59701b9ba5c453e327bc0e6873a9f6ff87a10391/core/java/com/android/internal/view/ActionBarPolicy.java#L55)
public boolean hasEmbeddedTabs() {
final int targetSdk = mContext.getApplicationInfo().targetSdkVersion;
if (targetSdk >= Build.VERSION_CODES.JELLY_BEAN) {
return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs);
}
// ...
return mContext.getResources().getBoolean(R.bool.action_bar_embed_tabs_pre_jb);
}
So the Android developers do the version check in the code where necessary. But these checks are not as necessary as you think (I guess). What's the reason for changing a method?
method is buggy: All they need to do is fix the bug. Tests will make sure that the general behavior of the method keeps the same
method is deprecated: The guys can not remove the method, all they can do is mark it as deprecated and hope for the best. Compilers will do the rest.
method behavior has to change: Well, I guess that is something they can not do easily. They can work around with version codes (which is pretty ugly and becomes a maintenance nightmare), or they just introduce a new API. That's the reason why you'll find a lot of APIs just doing the same

If you have write down a code with latest android sdk and install it in your device. It means actually you are using latest android.jar(you can see android.jar in your project) file while compiling/Executing code.
Now If you install your application in ginger bread device then android.jar(latest) has a backward compatibility(if required) to run code in Gingerbread device.and if you define target sdk version 10 and running app on Higher API level ,then it will run smooth except your compatibility behavior disable in respective device other than targeted devices.

Monodroid: Access setLayerType of View-Class

I want to call the Method setLayerType of the View Class in a Mono for Android application. Unfortunatley I cannot access (or even see) the method. According to Mono Documentation everything should be there.
Can somebody help me with this?
Thanks,
faiko

I had the same problem. You can fix this under your project settings choose "Minimum Framework Version to Target" of Android 3.1 or higher. This has nothing to do with your minimum/target API level in your manifest.
After changing that, you will have to restart Visual Studio (or reload the project in question) and you'll notice it now references the v3.1 assembly of Mono which has some new APIs exposed.
You'll still want to wrap the call to this API around a version check like:
if (Build.VERSION.SdkInt >= BuildVersionCodes.Honeycomb) if your minApiLevel is less than 11.

Call methods of new Android APIs in SDK version switch

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.