How can I change the minimum SDK in an Android (Studio) project with recent (2020+) versions of Android Studio and Gradle?
During the creation of a new Android Studio project the wizard ask for the minimum SDK required.
Since the wizard generates a lot of boilerplate files and code, I assume that the boilerplate code is tailored to the minimum SDK chosen. My first objective is to generate a modern, lean, forward-compatible (Kotlin) app, so I chose API 31 (most recent non-beta on 29 Dec 2021). However, once the app (which is simple) is working, I would like to lower the minimum SDK to include as many devices as possible (without adding legacy dependencies, code, etc.). Is this a correct way to think about the relation between the choice of minimum SDK and the boilerplate code?
There are existing questions on older (2013) versions of Android Studio (and Gradle), e.g. here, but these do not work in modern versions of Android Studio and Gradle (I have only one build.gradle file and it does not mention any SDK, adding this gives errors).
EDIT: see below an image of the folder tree, as suggested.
I believe all you need to do is set minSdkVersion like provided by this answer. The problems you may encounter are going to be massively different based on what you're going to be doing, but mostly it should be OK. Of course, more you lower minSdkVersion, the more problems you will encounter, but it should be mostly ok to at least version 23.
However, minSdkVersion is usually chosen at the beginning. You should probably set it to 21 (which covers 98% of devices) and start from there (industry standard is currently at 23, which covers 94.1% of devices).
You should not be afraid of the app not being forward compatible because changes are usually quite small and there are ways to support different versions with ease and minSdkVersion doesn't even affect forward compatibility. Also, supporting multiple versions does not make the final size of the app any larger. Code that is not called for a specific version gets deleted at build time, so you don't have to fear having the app not lean because of lower SDK support. There is some build time performance penalty, but for a simple app, this is not noticeable. And in case there's a blocker with SDK version being too low, it's easier to raise it than lower it.
Bottom line here I'd say is, that it is easy to set a low minSdkVersion from the beginning. The amount of possible issues you'll encounter when lowering that version are probably not worth it and are also harder to fix than supporting a low SDK version from the beginning. And it all massively depends on the actual code.
Based on the comments by Ricky Mo.
The problem is that the default is the "Project View", which contains a build.gradle file that that defines the Kotlin version and the Android Studio Gradle plugin version.
The build.gradle file that defines the minSDK is found in the app folder (screenshot).
Alternatively you can switch from the "Project View" to Android. From the dropdown menu that open when you click "Project" (screenshot, highlighted).
Related
I got an email from google saying I had to update my targetsdk settings to be at least 26 by november 2018.
So having waited almost 2 years I finally tried to switch to android studio from eclipse where I come to realized we've just traded one set of known problems to another set of unknown problems. I purposefully waited to migrate so everybody else could suffer the bleeding-edge-everything-is-broken problems and in fact every problem I run into has a stack overflow response except this one:
the compilesdk version has to be the same as the support library.
the compilesdk version should not be lower than the targetsdkversion.
the targetsdk version and the compiler version should be the latest which is 28 at the moment
But there's no appcompat past 26.0.0-beta1 as far as I can tell so it's impossible to satisfy all of the requirements as far as I can tell.
What are you actually supposed to do?
Since Android Pie has been released a few days ago, I would wait for a stable Android Studio 3.2 release, because it has several refactoring options like migrating support lib to androidX etc. - so then you can go on with compileSdk and targetSdk 28 and also refactor the support libs to androidX (which will be necessary anyway). You can try that already with Android Studio 3.2 Beta but do not forget to raise the gradle version to at least 3.2-beta05 too, otherwise you might get unexpected errors, especially with migration of the old support libs.
Edit: If your current project is not even targeting API lvl 26, you'll probably have a lot of work to do anyway (depends on the features you use from the android sdk), imho it would be the best to go through the "behavior changes" articles first (brought for each new android version) to know how it may affect your app. So if you want to test it as quick as possible, simply use the current Android Studio version (3.1.4), raise target- and compileSDK to 28 and also the support libs. then, as soon as Android Studio 3.2 (and gradle plugin 3.2.0) is released, you can take advantage of the migrating feature for AndroidX. But for now, you should be more worried about the behaviour changes caused by the SDK update and not AndroidX. My first suggestion was just to wait for the android studio update to do that all in one step, instead of being annoyed at the next release when app compat will be deprecated.
There are appcompat libraries released after 26.0.0-beta1. The latest one is 28.0.0-rc01.
Use these:
compileSdkVersion 28
targetSdkVersion 28 and
implementation 'com.android.support:appcompat-v7:28.0.0-rc01'
You can actually check for the latest version of appcompat here
These are the latest. Feel free to ask me if there's anything else.
My app targets Android 4.4 and up. But I have SDKs from like 14-25 installed via the Studio SDK Manager. I don't use the emulator except on rare occasions - but when I do its typically for 4.4 & 5x. But collectively Android Studio is taking up over 100Gb of storage on my system...I need to reduce its size (big time)
What can I delete that allows me to still target 4.4 and everything newer?
This question has been asked a multitude of times but everything I researched did not provide a clear answer.
If I delete 14-24, and build my app with just SDK 25, can my app still support Android 4.4? Or do I need to hold on to specific SDKs so that my app will still support all Android versions 4.4 and higher? Please be specific, too many vague answers out there.
My app is a cordova/ionic app - many plugins references specific versions of SDKs - typically based on when the plugin was last updated. But quite often these plugins are tested with SDK 22, or SDK 21 (mainly because the author has never bothered to update/maintain the plugin - but it still works) - will those plugins still work if SDKs 14-24 are deleted and only SDK 25 is installed?
As mentioned, I occasionally need the emulator for specific system-images; in lieu of question #1 - if I want to try spin up Android 4.4 emulator do I also need to keep specific SDKs to support those system-images.
Using the Android Studio SDK Manager - does removing specific SDKs via the manager also delete things from my hard drive? I would think it would, but I read some other blogs where people were manually having to delete things.
the Build procedure depends of BuildTools and Android SDK. If you set "minSdkVersion: 10" and "targetSdkVersion: 27" then YOU SHOULD manage all code differences between all versions. There are two possibilities: (A) older method/class is not more available on newer SDK: then the bulld procedure will fail because you cannot call/use them directly but only via Reflection (B) newer method/class is not present in the older SDK: then the build procedure ends fine but your App will crash when THAT method/class is used if you don't manage that specific case using "if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.xxxx)..."
it depends of what kind of plugin they are. Are they AAR file? Are they an editable project that you could join/add to yours? are them external libraries? AAR files and .SO libraries are already compiled so they doesn't need any other/external file or development tool.
Emulator runs using its own "System OS" files, so all the development stuff is unuseful for it. You can run an Emulator even without having never installed a development tool (Android Studio or other things)
Removing items from the Manager should remove even its files, but in some case there could be a bug and nothing (or just partially) is deleted. But you can check your drive storage free space if it is increased.
I'm trying to create a project with min sdk 18 and target 21. When I initially create a project a select the minimum SDK as 18 however it gives me no option to target 21 and gives me 26 by default. It's giving me a number of features that aren't supported in 18/26 such as android:roundIcon in the manifest and some drawables that I'm having trouble removing without getting errors. I've tried setting the min and target sdk in the build.gradle and then rebuilding the project as well as 'Sync project with gradle files'
EDIT: After deleting the 'mitmap' directory it seemed to resolve the problem but I'm wondering if I should even be deleting this?
Some features are removed (deprecated) in newer API levels, and some features are added or replaced. Generally, you can set your minimum SDK to a low API for example to 15 but if you initially created the project with higher minimum, Android studio gets excited and tries to implement the new stuff, later when you change your mind and specify low API it complains "I thought you wanted the new stuff :(" says the studio.
So you will need to do some refactoring in that case to your code like you just did.
Same applies to existing projects that target minimum API of +21.
When you change it to lower minimum API level things will turn red and it will most likely ask you to do a lot of if/else checking to existing code for API level for some features that work on certain API levels.
I hope that helps.
I'm working on an Anrdoid app. It's almost finished. I've just noticed that the minSdkVersion is set to 21. Maybe I forgot it when I created the project. I'd like to lower it, because the app's users will likely to have older devices.
I don't think it's good idea to change the minSdkVersion to ~10, sit back, and hope it will compile and run fine in the future.
My idea was that I could check all the methods used in the project, their minimum API level, so I could know what I have to replace with alternatives. However, the project is a bit large. Searching for all methods' documentation one by one would take a lot of time.
Is it possible to automatically list the Android API specific methods used in my project, and their API level? Or somehow detect the highest API level that is required by an used method? Android Studio knows these numbers, it can fetch the documentation too. Or, is it safe to change the minSdkVersion and targetSdkVersion to a lower API level to know which methods aren't supported in an older device, and after I fix all errors/warnings the IDE will show me, will my app run fine?
Android Studio will give you warnings when you use methods that require a higher sdk version than your specified minSdkVersion. You can access the whole list of these warnings for the complete project by leveraging the Analyze -> Code Cleanup functionality. So what you can do:
Lower the minSdkVersion.
Click Analyze -> Code Cleanup in Android Studio. Select "Whole Project"
The relevant errors are part of these sections:
Android Lint: Correctness -> Attribute unused on older versions
Android Lint: Correctness -> Calling new methods on older versions
Android Lint: Correctness -> using inlined constants on older versions
Android Lint: Internationalization -> Right-to-left text compatibility issues
By trying different version numbers you can see how many changes are necessary. To decide for the correct minSdkVersion, you might want to consider the Android API level device stats.
So a strategy for deciding for a targetSdkVersion or minSdkVersion typically looks like this: You set the targetSdkVersion to the highest version number that you have tested your app with. The minSdkVersion should be set to a lower value - low enough so enough devices are supported, but high enough so there are not to many version specific workarounds necessary. Find details about these two values in the Android documentation.
I am not fully certain that I am not making any mistakes when setting API level when developing under Eclipse so here are some examples which I am not 100% certain about.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
Yes this practice is correct and is done to ensure support for the latest android versions.
When you set a minSdkVersion, then that's thr lowest version of Android your app will support and compiling with ant/gradle will show errors ehen you will use methods introduced in newer api levels for an older one.
Deprecated means that another method has replaced this one and that this one will spon be removed from the Android source code, so developers are encouraged not to use them. But yes they will work until they remain in the source.
The android.jar is a dependency of the methods and stuff included in the android OS, stuff that you'd be able to call and no I don't think framework.jar plays a role in this.
All external libraries are referenced and added to the apk. BUT only some of the google ones, those that are not primary. (Take a look at the gapps packages, that'll give you some specifics. Link: http://goo.im/gapps)
I hope I got this right and helped you to understand.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
Yes. That way you ensure you're always using the latest build sdk.
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
Just make sure that older devices will not get to that part of the code, using Build.Version.SDK_INT. This will give you the current SDK of the device.
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
Deprecated methods will continue to work, but better alternatives are available. When you have the option to use that better alternative, use it. When you're supporting devices that don't have this alternative yet due to older versions, continue using the deprecated method. You might have to do some if else branching based upon the Build.Version.SDK_INT value.
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
The newer devices contain the code of the older devices. Therefore it is not necessary to keep references to other versions.
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
The class files in the jar will be packaged in the .apk. The Google Play Services on the device communicates with your app using those classes.