I want to attempt to add a feature (notification channels) which requires target SDK level 26 to an open-source Android project that currently targets SDK level 22.
Looking at the documentation for notification channels, I saw something disturbing: apparently increasing the target level can cause previously valid uses of the API to function differently — in this case, notifications that don’t specify a channel will no longer be displayed. That tells me there could be other things that would break as well just from changing the target level.
How can I find every API call in the project that I need to examine for possible incompatibility when changing from level 22 to level 26? Alternatively, is there a way to isolate sections of code so that the code I’m not changing still uses level 22, and only the new code uses 26?
I want to attempt to add a feature (notification channels) which requires target SDK level 26
If you have targetSdkVersion set to 26 or higher, then notification channels are required. If your targetSdkVersion is set below 26, notification channels are not required, but AFAIK you can still set them up, if you are running on an API Level 26+ device. Personally, I have never tried this; keeping your targetSdkVersion up to date is fairly important in modern Android app development.
How can I find every API call in the project that I need to examine for possible incompatibility when changing from level 22 to level 26?
In general, you can't. You are welcome to read the release notes for Android; in the past couple of releases, Google has been better about specifically calling out the changes that are triggered by targetSdkVersion. You can also read the JavaDocs for the associated Build.VERSION_CODES value (e.g., the JavaDoc for M), as they list changes triggered by targetSdkVersion. The IDE might give you some warnings. Beyond that, it's a matter of testing.
Alternatively, is there a way to isolate sections of code so that the code I’m not changing still uses level 22, and only the new code uses 26?
Put them in completely independent apps. Otherwise, no. The targetSdkVersion is a per-app setting, not a per-file or per-class setting.
Related
does TargetApi mean that code must be called under a specific version or
must be called greater than or equal specific version?for example
TargetApi(23) means that use for (23 and below ) or (23 and above)?
Target Api 23 means that the annotated method should run only on api 23+ devices. You should use it with IF check for api level of the device. If your app's minimum api level is lower than 23 consider providing a method for older devices.
From TargetApi docs:
Indicates that Lint should treat this type as targeting a given API level, no matter what the project target is.
It's used purely for the linter. Instead of using targetSdkVersion specified in your build.gradle, it will use this API.
When should you use this?
Perhaps when you're using a deprecated API, but you don't want the linter to continue warning you. You explicitly tell the linter, I know that this is deprecated but I don't care, I am using it as if I was on an older API level. You might (should) also add a comment nearby.
If I use reflection to use a method from a higher Sdk when i can, do I need to raise my targetSdk to that higher sdk or can I keep it at my current, lower version?
See https://stackoverflow.com/a/4994039/1685098, http://android-developers.blogspot.co.nz/2010/07/how-to-have-your-cupcake-and-eat-it-too.html and http://developer.android.com/guide/topics/manifest/uses-sdk-element.html.
Although those resources suggest you should raise your targetSdk, none of them specifically state that you must.
Note especially the android developer documentation, however, which recommends you set targetSdk to the highest SDK level you have checked against.
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.
I would like to know whether android has supports for the older versions. There are 15 different levels for android currently and I wonder about the followings.
Can a project made on level 5 be used on the devices whose level higher than 5?
How can I find the detailed differences between all the levels. For example, android.widget.VideoView starts with which level?
Assume I made a project based on level 8 nowadays and after a while like 2 years, level 20 has been introduced by that time. And I would like to use one of the classes that belongs to the level 20. I guess there is no way for me to use that class without upgrading my project level to the 20. In this case, is it possible that level 20 doesn't accept some of the classes I used with level 8? If yes, what can be the solution? Can I download the jar file of level 20 and reference it in my project manually? If possible, does this mean that I don't have to upgrade my project level to 20 in order to use classes of level 20?
I am going to start a project in a few days. However, I didn't decide the level yet. I got confused the differences of levels.
Yes Until know all Levels are backward compatible and most likley this will continue a while.
http://developer.android.com/reference/packages.html -> Filter by API Level
Yes you have to upgrade. But you can set the compatibility to a level below that. Than you have to take care that none of the Methods of lvl 20 will be executed in lvl <=19. You can do this by determine the current Version while running your App Build.VERSION.SDK_INT gets you the API level.
Hope this helps:
1- Yes A project made on lower levels will work on higher levels.
2- In the page of the component. For example for android video view you can check in the top right corner SINCE: API LEVEL 1
3-You are right, if you want to use level 20 classes your project will have to be upgraded to level 20, but as far as I know there are no compatibility issues for higher versions. You should take note about the deprecated classes though. Avoid using them because they might not be available later.
1 - yes. Android devices support running code from older levels.
2 - look through the Android docs. It even lets you filter by API level.
3 - Higher levels always let you use the lower level classes. It's just not recommended.
To decide what to support, I looked at the current distribution dashboard to see what was really out there and using the market. I went with level 7 for what I was doing, but that's just me. Level 8 would also be a good place to work from.
Also, if you want to access the better parts of the API on supported devices, but still work on older versions of the API, there's advice in the answers to this question.
What is the difference between targetSdkVersion set in the Manifest file and the Project build target set in the building environment (e.g. Eclipse) ?
I have tried to find more information on these two features, but I couldn't find any clear and specific explanation.
It seems like the Project build target decides on the API compatibility level, to be used during the compilation. When the targetSdkVersion only affects the visibility of the manifest elements of the given API level.
Could anyone confirm/expound this?
EDIT: Thanks guys for prompt responses. I forgot to mention in my question that I have read all the topics on Android Dev regarding these features and also googled it and searched it on Stack Overflow. So I understand the basic purpose of min/target/maxSdkVersion to be used in Android Market and in the Android System itself. However, according to other posts from people having problems with this Manifest option, it seems uses-sdk does actually have impact on how the the API level is interpreted. At least that is what I suspect.
A really good explanation is given here:
http://developer.android.com/guide/appendix/api-levels.html
However, it is still unclear for me whether the targetSdkVersion does affect the compilation/runtime of the APK on Android System? Or it is only for validation as the uses-sdk documentation suggests?
The targetSdkVersion attribute does indeed affect an application's runtime behavior.
Depending on what you set it to will determine whether compatibility features are enabled/disabled in the Android framework.
For example, once you set targetSdkVersion=11, your application's default theme will be set to #android:style/Theme.Holo -- meaning your application will have a Honeycomb-style UI widgets, will get an Action Bar, and will not have an Options Menu button at the bottom of the screen.
If you set targetSdkVersion to a lower value than, your default theme will continue to be #android:style/Theme -- regardless of which API level you're actually building against.
The targetSdkLevel also affects what the default values are for the <supports-screens> element, which in turn will determine whether your application runs in density compatibility mode.
Interesting note: Android Market doesn't actually use the targetSdkLevel attribute for anything at the moment. It's purely used at runtime for compatibility purposes, and possibly at compile time -- though I haven't looked into the behavior there. If people are curious about the compiler, I could check with the SDK team to get more information.
Of course, it's entirely possible that Market could decide to do something with this in the future.
The Build Target is used to know which SDK to compile your APK with. This means that if there are any Classes or methods that aren't available in your min SDK version, but are in versions after that, those Classes or methods will still be available to use. You will just have to make sure to check when you're using those and do alternate approaches if the user's SDK version isn't compatible with those classes/methods.
android:targetSdkVersion
An integer designating the API Level that the application is targetting.
With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here. Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications. This does not mean that you can program different features for different versions of the platform—it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.
You can find more information by referring to this URL:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
There's also a good article written by google on checking to make sure you're current users Android OS version will use the appropriate Classes/methods
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
In your "Create Project"-dialog in Eclipse, you specify the minSdkVersion. This is the API-Level that is required to run your application.
The targetSdkVersion-attribute only tells the Android Market that your App was developed (and maybe optimized) to run under the specified API-Level.
Build target is the one on which you will be testing the app. targetSdkVersion is the one your app was specifically developed for. Both are same most of the times.
You will find a detailed explanation here.
targetSdkVersion attribute informs the system that you have tested your app against the given version (api level) and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).
For further detail - http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
This question has already been adequately answered, but I want to point out that it is no longer entirely correct that the Google Play store does not use targetSdkVersion at all.
In the specific case where you set targetSdkVersion to 23 (Marshmallow 6.0) and upload your APK, even if you are uploading a Beta version, you will not be able to ever again submit an APK for that app that has a lower targetSdkVersion than 23.
This is because of changes to permissions between 22 and 23 which are not allowed to be reversed for a given app.
This can be a bit of a trap if you were just trying out 23 in Beta and not sure you were ready to support it yet.