sorry if this question was already asked but I couldnt find anything.
Starting November 2018 all Android Apps need to target API lvl 26 or else you cant release any new updates. So I understand that when I target my App to API lvl 26 there will be features that wont work anymore. Like for example implicit broadcast receivers. Now my question. Will those old features that are deprecated in API lvl 26 stil work for devices that use older APIs? For example when someone uses a device that runs on API lvl 21. Will those devices still support those features even if my app targets API lvl 26?
I hope you understand what I mean.
Thanks in advance
Yes, though deprecated methods and functionalities should be avoided, devices that are running API level 21 will still support those features while your app is targeting any API > 21. This is true for any future requirement like this as well, until it is explicitly stated that the features will be removed.
Make sure that your app's min SDK is still at 21 or lower.
Related
it took quite a few days to realize that something wrong is going on with old devices with API lower than 23 and I searched intensively but without an answer. So when I found my answer I thought that it's worth sharing with the community
I used multiple emulator versions but the weird thing is that some devices couldn't either load the video (sudden stop) or it loads it till showing the thumbnail and it freezes, so the answer is basically that nothing is wrong with ExoPlayer, it's just the emulator that cannot play the media with an emulator with lower API than 23 due to a decoder issue but mainly on a usual use ExoPlayer will function properly with android devices of 16+ API. you can check the DOCUMENTATION for more details.
I would rather not upgrade my Android min API level as some users are still on API 14. However Facebook requires that I upgrade to API 15 to integrate the Facebook Android SDK. Are there any advantages/disadvatages to using tools:overrideLibrary=“com.facebook” to force usage in my gradle build? What be the best practice to integrate the API?
The amount of users between API 14 and 15 is VERY small. If you take a look at the Android dashboard statistics, it's almost none.
According to Android Studio, it doesn't even equal to 0.1% of users.
They both end up at 97.4%.
For something that small, I wouldn't recommend changing lib and I would say you should change your mininum API.
If a user using API 14 and they don't have facebook, they won't care abou this at all.
Just my opinion.
Hello fellow Android Devs!
My Question/Topic today is about the "Minimum SDK" we set for our Projects..
For years now, "API-15" (IceCreamSandwich/4.0.3) has been typical, covering 97.4% of users.
However, I've recently noticed now that "API-16" (JellyBean 4.1) has caught up, at 95.2%!
Over the past few years, the percentages were MUCH further apart, making API-15 the go-to.
SO, MY QUESTION IS:
Are there any advantages to setting API-16 as my Project's "Minimum SDK", instead of API-15?
For example, less need for certain support libs, or better compatability with anything, etc. etc.?
Basically, ANY reason at all why choosing API-16 as my "Minimum SDK" might benefit anything?
..Thoughts?
I've worked on apps with both 15 and 16 as the minSdkVersion. I would recommend a minApi of 16, particularly if you use SQLite.
Api 16 has:
SQLite 3.7.11. You now have setForeignKeyConstraintsEnabled for your SQLiteDatabase.
Up navigation. Api 16 supports android:parentActivityName in the manifest, so you don't also have to have metadata tags.
Font families in xml. For your password EditText, you can now set android:fontFamily=sans-serif, so it no longer defaults to monospace.
The drawback is that the Samsung Galaxy S2 runs on API 15, so if this is an important demographic for you, you'd be missing out on them if you use minApi 16. All of my new projects are minApi 16.
Android 4.1 (API 16) has Has offline voice recognition. Offline voice recognition enables you to perform voice actions, like dictating texts or using various voice commands, without an internet connection.
Is there any advantage to setting the compileSdkVersion in the manifest to less than the latest api build number, or should you always set it to the latest api build?
android {
compileSdkVersion 22
When I say advantage I mean in terms of performance of the app, of compile time of the app, of size of the apk etc. I'm speaking, of course, of cases where you can set it lower - i.e. an app that doesn't use shared transitions or any features of lollipop.
No, there is not.
Also, thanks to commonsware for pointing that out, but there is a difference between compileSdkVersion and targetSdkVersion. See this previous answer on Stackoverflow.
Just don't set it to the latest M Preview right now. Not that you did, I'm just saying this for new Android developers that are reading this. Android M is a preview version and it's not meant for apps in production yet.
That being said, if you're just editing the code of an application that someone wrote a couple of years ago and your boss tells you not to waste more time than you have to on a tiny little change he wants you to make, then you might as well stick to that plan and only compile to the initial api that was originally used.
Also, there is the case of security audits and certifications. If a government agency or a security company hasn't had the time to audit the latest version of an OS or sdk, then you may be stuck compiling only to the version that was last certified.
First, there is a difference between targetSdkVersion and compileSdkVersion.
compileSdkVersion
The compileSdkVersion gives your app access to the newest APIs, styles and themes. You will have a compilation error if you try to use an API introduced in a more recent Android version than compileSdkVersion.
targetSdkVersion
targetSdkVersion indicates which API version your app has been tested against.
Targeting an older version enables compatibility behaviours, to make sure the app continues to work the same way.
Updating the targetSdkVersion to a newer version may introduce subtle behaviour changes, so make sure your know the new APIs and test the app properly if you do that. For example: calling AlarmManager.set() when targeting API < 19 will schedule the alarm at the exact time, because that's how it used to work before. Calling the same method while targeting API 19+ will allow the system to adjust the alarm delivery time by a few minutes to save battery life, and if you want the exact time behaviour you need to call the new method AlarmManager.setExact().
The compileSdkVersion must always be equal or higher than the targetSdkVersion.
No actually it does not make any changes. But i would suggest you to use the latest one to compile it just to be sure.
I'm new to android development.
I'm studying with outdated books, so I'm really confused about new methods.
I'm going to make a simple and light app which can be run even on old devices.
So when I created a new android project, I set "Minimum Required SDK" to API 8, "Target SDK" to API 22 and "Compile With" to API 22.
Does this setting mean the app can work on the devices of API 8, even though I use the methods of API 22?
I'm asking this question due to deprecated methods.
I completed almost a half of my app developing using deprecated ones.
Can I just replace them all with new ones?
Or do I have to prepare multiple codes using different methods to support different platform versions?
(deprecated methods for older versions, and new ones for newer versions?)
Does this setting mean the app can work on the devices of API 8, even though I use the methods of API 22?
Yes. min sdk version is used to restrict the devices running OS with API level < minsdk from using app. Your app won't be shown in the play store for those devices.
I'm asking this question due to deprecated methods.
I haven't faced any issues till now due to depreciated methods. However, I would suggest to use min sdk version as 14 as Google has introduced many UI tweaks and enhancements. If you do some market research, using minsdk version = 14 would cover around 85% android market.
Can I just replace them all with new ones?
Yes, you can.
Or do I have to prepare multiple codes using different methods to support different platform versions?
(deprecated methods for older versions, and new ones for newer versions?)
You can do it also. Older versions do not have support have fragments. Fragments improve user experience drastically for tablets. Similarly, material design for Lollypop devices is awesome. Thee are few examples where you can opt for API level specific implementation. However, it is better to switch for api level >= 14
To clear up your confusion:
Minimum Required SDK
The minimum version of Android you're going to support. To target the largest market share, I recommend API level 14 or above.
Generally, the lower the number, the more Android devices you're targeting.
Target SDK
Basically, all this is saying is what SDK have you tested your app with. If that's KitKat then you can write in the number 19 which is the API number of KitKat, for example. You can find a list of API numbers here. As you test your app with higher and higher versions of Android, you can increase that number.
Setting the Target SDK to be a higher number will mean that you target a lot more devices.
Compile With
Specifies what API number of Android you want to compile your app with.
By default this is the latest version of Android available in the SDK Manager. Should be set high to improve user experience.
Deprecated Methods
As to your question about deprecated methods: You can continue using them. They are deprecated in favour of a newer alternative that may or may not be better in terms of functionality.
Deprecated methods will still work, the deprecated keyword just tells you that there is a newer preferred way to do it. Android is really good at backward compatibility so something compiled for API level 8 should mostly work on newer devices to.
You're going to have to use multiple code branching on version. You can check your system version at runtime like this:
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);
}
}
API 8 is really old. Have a look at the version pie chart
You can find more information about this on the Android developers website