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.
Related
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).
I need to set the target SDK version of an Android project to API 14. But I do not have the same version available to compile the project. I know that the project can be compiled with a different version but I need to know whether it will cause any issue.
I received the error "Android manifest file is missing" even though it exists. When I cleaned and then built the project it was compiled but the application crashed. What am I doing wrong here?
These were my settings.
There should be no issues introduced when compiling with a higher version, it is even encouraged to do so. You can find more on that topic in this Medium article.
I would also like to bring your attention to the following blog, which contains some important information regarding SDK targeting in the near future.
Unfortunately I do not use Eclipse so I fear cannot provide any verified insight on that matter. However the suggestions I have found so far include:
Cleaning the project
Getting rid of characters such as ö,ë, etc.
Deleting the file and recreating it
The manifest issue was probably due to creating a project with the same name over and over again. However clean -> build the project helped me get rid of it.
Yeah. Android compile version can be higher than the target version.
Android compile version and target version do not have to be the same.
compileSdkVersion
The compileSdkVersion is the version of the API the app is compiled against. This means you can use Android API features included in that version of the API (as well as all previous versions, obviously). If you try and use API 16 features but set compileSdkVersion to 15, you will get a compilation error. If you set compileSdkVersion to 16 you can still run the app on a API 15 device as long as your app's execution paths do not attempt to invoke any APIs specific to API 16.
targetSdkVersion
The targetSdkVersion has nothing to do with how your app is compiled or what APIs you can utilize. The targetSdkVersion is supposed to indicate that you have tested your app on (presumably up to and including) the version you specify. This is more like a certification or sign off you are giving the Android OS as a hint to how it should handle your app in terms of OS features.
As for the manifest error, you could try (if you are using android studio) clicking File > Invalidate Caches / Restart or force a gradle sync
Thank you for your answers.
I think the manifest issue was due to creating a project with the same name over and over again. However clean -> build the project helped me get rid of it.
Yeah. Android compile version can be higher than the target version. Those two do not have to be the same.
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 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.
I know that android version 2.1 and below do not support GLES20. My code can run with both the fixed function pipeline (GLES1.x) and the programmable pipeline (GLES20) based on runtime determination of the version used by a android device and setting the GLES version accordingly.
My situation is that I would ideally like to keep my GLES20 code in my project and just not use the classes that use GLES20 at runtime when an android device of version <= 2.1 is detected. But when I set my project to 2.1 in Eclipse, GLES20 creates a compilation error. I assume that this is so because the Android2.1.jar does not contain GLES20 .
Is their a way I can keep my GLES20 code without getting compile errors when setting the android version lower and to just not use the GLES20 code at runtime, so that the running code will never use the GLES20 portions anyway.
Thanks
Okay, I figured out how. The element minSdkVersion and targetSdkVersion in the manifest allows this. I quote from the "Beginning Android Games" book. "This element allows us to deploy an application that uses APIs that are only available in newer versions to devices that have a lower version installed". So I will use this element accordingly, and develope in eclipse with my target android version set. I'll answer my question with this asap
The relevant documentation on Android developers, as linked by Mārtiņš Možeiko's comment.
developer.android.com/guide/appendix/market-filters.html