Change android target sdk version

Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion

Depending on the time of the year, it might only be a few months after you release an app that a new version of Android is announced. What does that mean for your app though — is everything going to break?

You’ll be happy to know that forward compatibility is a strong focus of Android — existing apps built against prior SDKs should not break when the user updates to a new version of Android. This is where compileSdkVersion, minSdkVersion, and targetSdkVersion come in: they control what APIs are available, what the required API level is, and what compatiblity modes are applied, respectively.

compileSdkVersion

compileSdkVersion is your way to tell Gradle what version of the Android SDK to compile your app with. Using the new Android SDK is a requirement to use any of the new APIs added in that level.

It should be emphasized that changing your compileSdkVersion does not change runtime behavior. While new compiler warnings/errors may be present when changing your compileSdkVersion, your compileSdkVersion is not included in your APK: it is purely used at compile time. (You should really fix those warnings though — they were added for a reason!)

Therefore it is strongly recommended that you always compile with the latest SDK. You’ll get all the benefits of new compilation checks on existing code, avoid newly deprecated APIs, and be ready to use new APIs.

Note that if you use the Support Library, compiling with the latest SDK is a requirement for using the latest Support Library releases. For example, to use the 23.1.1 Support Library, you must have a compileSdkVersion of at least 23 (those first numbers need to match!). In general, a new version of the Support Library is released alongside a new platform version, providing compatibility shims to newly added APIs as well as new features.

minSdkVersion

If compileSdkVersion sets the newest APIs available to you, minSdkVersion is the lower bound for your app. The minSdkVersion is one of the signals the Google Play Store uses to determine which of a user’s devices an app can be installed on.

It also plays an important role during development: by default lint runs against your project, warning you when you use any APIs above your minSdkVersion, helping you avoid the runtime issue of attempting to call an API that doesn’t exist. Checking the system version at runtime is a common technique when using APIs only on newer platform versions.

Keep in mind that libraries you use, such as any of the Support Libraries or Google Play services, may have their own minSdkVersion — your app’s minSdkVersion must be at least as high as your dependencies’ minSdkVersion — if you have libraries that require 4, 7, and 9, your minSdkVersion must be at least 9. In rare cases where you want to continue to use a library with a higher minSdkVersion than your app (and deal with all edge cases/ensure the library is only used on newer platform versions), you can use the tools:overrideLibrary marker, but make sure to test thoroughly!

When deciding on a minSdkVersion, you should consider the stats on the Dashboards, which give you a global look on all devices that visited the Google Play Store in the prior 7 days — that’s your potential audience when putting an app on Google Play. It is ultimately a business decision on whether supporting an additional 3% of devices is worth the development and testing time required to ensure the best experience.

Of course, if a new API is key to your entire app, then that makes the minSdkVersion discussion quite a bit easier. Just remember that even 0.7% of 1.4 billion devices is a lot of devices.

targetSdkVersion

The most interesting of the three, however, is targetSdkVersion. targetSdkVersion is the main way Android provides forward compatibility by not applying behavior changes unless the targetSdkVersion is updated. This allows you to use new APIs (as you did update your compileSdkVersion right?) prior to working through the behavior changes.

Much of the behavior changes that targetSdkVersion implies are documented directly in the VERSION_CODES, but all of the gory details are also listed on the each releases’ platform highlights, nicely linked in the API Levels table.

For example, the Android 6.0 changes talk through how targeting API 23 transitions your app to the runtime permissions model and the Android 4.4 behavior changes detail how targeting API 19 or higher changes how alarms set with set() and setRepeating() work.

With some of the behavior changes being very visible to users (the deprecation of the menu button, runtime permissions, etc), updating to target the latest SDK should be a high priority for every app. That doesn’t mean you have to use every new feature introduced nor should you blindly update your targetSdkVersion without testing — please, please test before updating your targetSdkVersion! Your users will thank you.

Gradle and SDK versions

So setting the correct compileSdkVersion, minSdkVersion, and targetSdkVersion is important. As you might imagine in a world with Gradle and Android Studio, these values are integrated into the tools system through inclusion in your module’s build.gradle file (also available through the Project Structure option in Android Studio):

The compileSdkVersion, being a compile time thing (who would have guessed!), is one of the android settings alongside with your build tools version. The other two are slightly differently in that they are declared at the build variant level — the defaultConfig is the base for all build variants and where’d you put default values for these, but you could imagine a more complicated system where specific versions of your app have a different minSdkVersion for example.

minSdkVersion and targetSdkVersion also differ from compileSdkVersion in that they are included in your final APK — if you were to look at the generated AndroidManifest.xml, you’d see a tag such as:

You’ll find if you manually put this in your manifest, it’ll be ignored when you build with Gradle (although other build systems might certainly rely on it being there).

Putting it all together

If you made it through the bolded notes, you’ll notice a relationship between the three values:

This intuitively makes sense — if compileSdkVersion is your ‘maximum’ and minSdkVersion is your ‘minimum’ then your maximum must be at least as high as your minimum and the target must be somewhere in between.

Ideally, the relationship would look more like this in the steady state:

You’ll hit the biggest audience with a low minSdkVersion and look and act the best by targeting and compiling with the latest SDK — a great way to #BuildBetterApps.

Join the discussion on the Google+ post and follow the Android Development Patterns Collection for more!

Источник

How to change Android minSdkVersion in flutter project

I was trying to start a flutter project for an App using bluetooth to communicate. For that, I was using flutter blue.

Unfortunately, when trying to run (on an Android device) the first example I created I was met with the following error:

If I were on Android Studio, I’d know how to bump up the Android minSdkVersion, but on a flutter project (using VSCode) I was a little lost.

Is it possible to increase the minSdkVersion with flutter, and how?

7 Answers 7

It is indeed possible to increase minSdkVersion, but it took me way too much time to find it out because google searches mostly yields as result discussions about the absolute minimum Sdk version flutter should be able to support, not how to increase it in your own project.

Like in an Android Studio project, you have to edit the build.gradle file. In a flutter project, it is found at the path ./android/app/build.gradle .

The parameter that needs to be changed is, of course, minSdkVersion 16 , bumping it up to what you need (in this case 19).

Seems obvious now, but took me long enough to figure it out on my own.

You can change the minSdkVersion in the file Project_Name/android/app/build.gradle , defaultconfig :

If your app requires a specific minimum version of the Android platform, you can specify that version requirement as API level settings in the app’s build.gradle file. During the build process, these settings are merged into your app’s manifest file. Specifying API level requirements ensures that your app can only be installed on devices that are running a compatible version of the Android platform.

You have to do set minSdkVersion in build.gradle file, located in /android/app and set a value in the defaultConfig block:

There are two API level settings available:

• minSdkVersion — The minimum version of the Android platform on which the app will run, specified by the platform’s API level identifier.
• targetSdkVersion — Specifies the API level on which the app is designed to run. In some cases, this allows the app to use manifest elements or behaviors defined in the target API level, rather than being restricted to using only those defined for the minimum API level.

To specify default API level requirements in a build.gradle file, add one or more of the settings above to the defaultConfig <> block, nested inside the android <> block. You can also override these default values for different versions of your app by adding the settings to build types or product flavors. The following build.gradle file specifies default minSdkVersion and targetSdkVersion settings in the defaultConfig <> block and overrides minSdkVersion for one product flavor.

For more information, see the uses-sdk-element manifest element documentation and the API Levels document.

Источник

Change android target sdk version

Adding to the importance of resolving this issue is very soon Google store won’t accept submission of sdk level less than 30.

This is not related to this issue. Targeting API 30 still works via android-targetSdkVersion preference, so that’s not a problem. Additionally we will bump our default target SDKs on our major releases to match the requirement of Google Play store.

The issue described in this ticket is Cordova will still attempt to the default platform SDK (currently API 29) even when targetSdkVersion is set to a different API level. So the current workaround is to simply have both platform 29 & 30 installed.

I’ve had a chance to do some digging on the cause and I’ve found 3 things that Cordova tooling must do:

(1) Ensure compileSdkVersion matches targetSdkVersion

compileSdkVersion is the SDK that the application is compiled against, while the targetSdkVersion is an assertion that you’ve tested your application at the target SDK level for compatibility. If the platform API level is higher of the target, then the platform will enable backwards-compatibility behaviours.

There isn’t any real reason to have a compileSdkVersion set that is different than the targetSdkVersion and doing so can cause an unstable application. Currently, the android-targetSdkVersion overrides but doesn’t modify compileSdkVersion creating this possibility. Cordova should force compileSdkVersion and targetSdkVersion to be equal.

There is currently no config.xml preference to set the compileSdkVersion , and the lack of this feature should remain. There is a cdvCompileSdkVersion cordova gradle flag, which I think should become deprecated and potentially removed in cordova-android@10 and replaced with a cdvTargetSdkVersion flag to match the config.xml ‘s android-targetSdkVersion preference.

(2) Ensure android/project.properties has the correct target

Currently, Cordova does not modify the target attribute inside /platforms/android/project.properties and it remains set to android-29 which will cause the Android Gradle Plugin (AGP) to download Platform 29.

(3) Ensure android/CordovaLib/project.properties has the correct target

Currently, Cordova does not modify the target attribute inside /platforms/android/CordovaLib/project.properties and it remains set to android-29 which will cause AGP to download Platform 29.

Additionally, a warning should be printed for when the SDK is overridden and uses a value other than the Cordova default target SDK, similar to the min sdk override warning. Using an alternate SDK level is not really a supported feature, so this preference is more-or-less «use at your own risk» (and really should be documented as such).

All 3 actions must be done in order for the AGP to not download API 29.

I cannot give any timeline for when I’ll personally be able to do the above, but I’ll support any PR that does what is described above.

ICYMI: You can workaround this issue by installing both Platform 29 & 30. You can still build APKs targeted against API 30.

Источник

How to change target build on Android project?

I currently have an Android project in Eclipse.

I created it with a target build of 1.5 (sdk 3).

Now I want to change it so that it has a minSdk of 3 and targetSdk of 8.

To do this I see that I must build against the newest SDK (2.2)

To do this in Eclipse I right click on my project, go to properties, click on Android and change the project build target to Android 2.2 and click apply and then ok.

However this appears to have no affect and when I try it again the target build is set back at Android 1.5.

Am I missing a step or something?

13 Answers 13

Right click the project and click «Properties». Then select «Android» from the tree on the left. You can then select the target version on the right.

(Note as per the popular comment below, make sure your properties, classpath and project files are writable otherwise it won’t work)

You can change your the Build Target for your project at any time:

Right-click the project in the Package Explorer, select Properties, select Android and then check the desired Project Target.

Edit the following elements in the AndroidManifest.xml file (it is in your project root directory)

In this case, that will be:

Rebuild your project.

Click the Project on the menu bar, select Clean.

Now, run the project again.

Right Click Project name, move on Run as, and select Android Application

By the way, reviewing Managing Projects from Eclipse with ADT will be helpful. Especially the part called Creating an Android Project.

Another way on the command line if you are using ant is to use the android.bat script (Windows) or android script (Mac). It’s in $SDK_DIR/tools.

it will regenerate your build.xml, AndroidManifest.xml, etc.

There are three ways to resolve this issue.

Right click the project and click «Properties». Then select «Android» from left. You can then select the target version from right side.

Right Click on Project and select «run as» , then a drop down list will be open.
Select «Run Configuration» from Drop Down list.Then a form will be open , Select «Target» tab from «Form» and also select Android Version Api , On which you want to execute your application, it is a fastest way to check your application on different Target Version.

Edit the following elements in the AndroidManifest.xml file

Well I agree with Ryan Conrad on how to do it in eclipse, have you ensured you have changed your manifest.xml?

The problem sometimes occurs when there are errors in the project.

For instance, if your project is configured with a target of 3.2 but the 3.2 libraries are not available, you will not be able to change the version to 4.0!

The usual (perhaps brutal) solution I use is to create a new project with the correct target and copy src, res and manifest into the new project.

This seems to work:

1. Change the selected through the build properties as normal
2. Manually edit project.properties AND default.properties to make sure they both reflect the desired target.
3. Close the project and re-open it

I always run Android Tools | Fix Project Properties after making any changes to the build target.

Источник