Getting a call to require API level 11 (current min is 1) problem after when I have added fragment and drawer. Did everything couldn't find a single solution.
Re-coded program but just when I add Fragment and Drawer
Changed API level
As you said you are using fragments on your project, you need to declare the minimum sdk version at least to 11 since fragment minimum api requirement level is 11. If you really need to target less than 11 and use fragments, follow this tutorial.
Note: I suggest using at least a greater api level like 19 or 20 to get the advantage of the matured android ecosystem. The distribution of android indicates that under 11 is 0.3% and under 19 is 3.8 cumulatively. So no point in targeting <11 and putting the time on it. When the app grows, the problem might arise since modern libraries and animations are not support.
Related
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.
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.
If I specify the minimum SDK as 2.0 and the target SDK as 4.1,will I have to write explicit code to ensure backward compatibility. Like if I want to use a gesture detection feature introduced in SDK level 7 and I set the target as 7 and minimum to 3. I am asking will I need to write explicit code(which doesn't include the gesture detection features) so that it runs in targets less than 7 but greater than 3?
Yes, you will have to avoid calling future APIs when running on older versions of Android. You can organize your code to select an appropriate code path at runtime, depending on the version of your OS.
An example of how to preserve backwards-compatibility when using a new API.
Yes, you will need to, but I don't see any logical reason to still support any API before 8 (2.2).
It's literally 1.6% of the market. It's not worth the effort to maintain and support such early versions any more.
That said, if you need to do version specific code, this is the way to handle it:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR) {
//Use API 7+ code
} else {
//Use backwards compatible code
}
You should check out the Android official site on how to guarantee backwards compatibility to minimum level 4 (which is negligible up until api level 7 anyway. The slightly more significant share is usually api level 8 upwards), and always use the latest support library.
Of course there are some minor code changes (such as getSupportFragmentManager() in replace of getFragmentManager(),etc). The worst you it can happen is NoSuchMethodException so you have to be real careful not to call API's that does not exist in lower platforms. The sdk should be very clearly advising that when it happens.
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.