Leaving target on API22 and running the app on Android 6 platform device, I see that DefaultHttpClient is still working, even though it isnt supported by the new platform.
How is it possible, does it work in a compatibility mode?
That it isn't supported does not mean it's been removed. In code you'll often see "deprecated" functions. These are functions that are not supported, but have purposefully not been removed.
In this case, you use the functionality from the Android API22 library. To preserve backwards compatibilty functionality of previous API's is almost never fully removed from the actual Android environment.
When compiling something with API level 22, the APK will actually contain parts of that library. In this case, that means that the DefaultHttpClient from API22 is actually included in your app. It doesn't use the version that is (not) on the phone. What parts are to be included in your app is decided in:
android {
compileSdkVersion 23
buildToolsVersion "23.0.0"
defaultConfig {
minSdkVersion 17
targetSdkVersion 23
}
}
Everything that is missing from API level 23 but is available in level 17 will get included in your app.
Related
For an Android application, how can I test what the lowest version/API of Android it can work on, without manually changing API level on the emulator?
The minSdkVersion set in the app level gradle file is the lowest API version it will work on.
There are other factors though...for example:
Lets say the minSdkVersion is 21...but you call a method that wasnt introduced until api 25 (and dont handle that), then it will crash...and not really work.
Open build.gradle of your app there should be written minSdkVersion which it supports.
My minSDK version is 16 and my targetSDK version is 27. The compileSDK version is 28.
Since the targetSDK version is 27 it should run on Oreo(8.0.0) without issues but some of the features don't work as intended. However they do work fine on Nougat.
Why is this so?
The targetSDK is stating what you built in the app to be able to handle. So, there might be a new feature in API 28 and you're saying your code was build against API 27 so if you're running on API 28 and there is support on 28 for how you used the api before, then it will try to maintain your API 27 coded behavior. There still exists the possibility your API 27 code will result in different or wrong behavior if run on API 28 though.
Please review the documentation as well:
https://developer.android.com/guide/topics/manifest/uses-sdk-element
"To maintain your application along with each Android release, you should increase the value of this attribute to match the latest API level, then thoroughly test your application on the corresponding platform version."
I have looked at the documentation for building with Gradle, but I'm still not sure what the difference between compileSdkVersion and targetSdkVersion is.
All it says is:
The `compileSdkVersion` property specifies the compilation target.
Well, what is the "compilation target"?
I see two possible ways to interpret this:
compileSdkVersion is the version of the compiler used in building the app, while targetSdkVersion is the "API level that the application targets". (If this were the case, I'd assume compileSdkVersion must be greater than or equal to the targetSdkVersion?
They mean the same thing. "compilation target" == "the API level that the application targets"
Something else?
I see that this question has been asked before, but the one answer just quotes the doc, which is what is unclear to me.
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.
For example, as the documentation states:
For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher...
The Android OS, at runtime, may change how your app is stylized or otherwise executed in the context of the OS based on this value. There are a few other known examples that are influenced by this value and that list is likely to only increase over time.
For all practical purposes, most apps are going to want to set targetSdkVersion to the latest released version of the API. This will ensure your app looks as good as possible on the most recent Android devices. If you do not specify the targetSdkVersion, it defaults to the minSdkVersion.
As a oneliner guide:
minSdkVersion <= targetSdkVersion <= compileSdkVersion
Ideally:
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)
Read more from this great post by Ian Lake
Late to the game.. and there are several great answers above-- essentially, that the compileSdkVersion is the version of the API the app is compiled against, while the targetSdkVersion indicates the version that the app was tested against.
I'd like to supplement those answers with the following notes:
That targetSdkVersion impacts the way in which permissions are requested:
If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the app requests permissions from the user at run-time.
If the device is running Android 5.1 (API level 22) or lower, or the app's targetSdkVersion is 22 or lower, the system asks the user to grant the permissions when the user installs the app.
If the compileSdkVersion is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. (ref)
With each new Android release...
targetSdkVersion should be incremented to match the latest API level, then thoroughly test your application on the corresponding platform version
compileSdkVersion, on the other hand, does not need to be changed unless you're adding features exclusive to the new platform version
As a result, while targetSdkVersion is often (initially) less than than the compileSdkVersion, it's not uncommon to see a well-maintained/established app with targetSdkVersion > compileSdkVersion
The compileSdkVersion should be newest stable version.
The targetSdkVersion should be fully tested and less or equal to compileSdkVersion.
The CompileSdkVersion is the version of the SDK platform your app works with for compilation, etc DURING the development process (you should always use the latest) This is shipped with the API version you are using
You will see this in your build.gradle file:
targetSdkVersion: contains the info your app ships with AFTER the development process to the app store that allows it to TARGET the SPECIFIED version of the Android platform. Depending on the functionality of your app, it can target API versions lower than the current.For instance, you can target API 18 even if the current version is 23.
Take a good look at this official Google page.
I see a lot of differences about compiledSdkVersion in previous answers, so I'll try to clarify a bit here, following android's web page.
A - What Android says
According https://developer.android.com/guide/topics/manifest/uses-sdk-element.html:
Selecting a platform version and API Level When you are developing
your application, you will need to choose the platform version against
which you will compile the application. In general, you should compile
your application against the lowest possible version of the platform
that your application can support.
So, this would be the right order according to Android:
compiledSdkVersion = minSdkVersion <= targetSdkVersion
B - What others also say
Some people prefer to always use the highest compiledSkdVersion available. It is because they will rely on code hints to check if they are using newer API features than minSdkVersion, thus either changing the code to not use them or checking the user API version at runtime to conditionally use them with fallbacks for older API versions.
Hints about deprecated uses would also appear in code, letting you know that something is deprecated in newer API levels, so you can react accordingly if you wish.
So, this would be the right order according to others:
minSdkVersion <= targetSdkVersion <= compiledSdkVersion (highest possible)
What to do?
It depends on you and your app.
If you plan to offer different API features according to the API level of the user at runtime, use option B. You'll get hints about the features you use while coding. Just make sure you never use newer API features than minSdkVersion without checking user API level at runtime, otherwise your app will crash. This approach also has the benefit of learning what's new and what's old while coding.
If you already know what's new or old and you are developing a one time app that for sure will never be updated, or you are sure you are not going to offer new API features conditionally, then use option A. You won't get bothered with deprecated hints and you will never be able to use newer API features even if you're tempted to do it.
My 2 cents: Compile against any version of the SDK but take care not to call any APIs that your "minimum SDK version" does not support. That means you "could" compile against the latest version of the SDK.
As for "target version" it simply refers to what you planned to target in the first place and have possibly tested against. If you haven't done the due diligence then this is the way to inform Android that it needs to perform some additional checks before it deploys your lets say "Lollipop" targeted app on "Oreo".
So the "target version" is obviously not lower than your "minimum SDK version" but it can't be higher than your "compiled version".
Not answering to your direct questions, since there are already a lot of detailed answers, but it's worth mentioning, that to the contrary of Android documentation, Android Studio is suggesting to use the same version for compileSDKVersion and targetSDKVersion.
compiledSdkVersion==> which version of SDK should compile your code to bytecode(it uses in development environment) point: it's better use last version of SDK.
minSdkVersion==> these item uses for installation of APK(it uses in production environment). For example:
if(client-sdk-version < min-sdk-versoin )
client-can-not-install-apk;
else
client-can-install-apk;
Quick summary:
For minSDKversion, see latest entry in twitter handle: https://twitter.com/minSdkVersion
TargetSDKversion: see latest entry in twitter handle: https://twitter.com/targtSdkVersion
or use the latest API level as indicated at devel https://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Compiled version:
make it same as TargetSDKversion
maxSdkVersion:
advice from Android is to not set this as you do not want to limit your app to not perform on future android releases
The Application settings of an Android project's properties in Visual Studio 2017 (15.8.5) has them combined:
Hy,
I have some basic doubts about developing with android studio:
minSdkVersion 15: with this configuration I am forcing to use only
the features from api level 15 and not higher. Is correct? For what I
read I dont think so
minSdkVersion 15 and compileSdkVersion 24: with this configuration I
can use api level until level 24. Is this correct?
minSdkVersion 15 and compileSdkVersion 23: with this configuration if I
use api features from api 23, this application wont work in an android
device with api level 20 for example, right?
With the previous configuration, and android device with api level 20
will be able to download and install the application because its api is
higher than the minSdkVersion 15 but will not be able to run because it
has features from api 23, right?
If I want to make sure that I want to use an api level and not higher
because of the previous problems commented, the configuration minSdkVersion 15 and compileSdkVersion 15 is the only way? is a common
practice?
Thanks a lot!
minSdkVersion 15: with this configuration I am forcing to use only the features from api level 15 and not higher. Is correct?
No. A minSdkVersion of 15 means that you do not want your app to run on devices with a lower API level than that. 15 corresponds to Android 4.0.3.
minSdkVersion 15 and compileSdkVersion 24: with this configuration I can use api level until level 24. Is this correct?
Your IDE will allow you to write code using classes, methods, fields, etc. from API Level 24. Your IDE should also warn you that using classes, methods, fields, etc. that were added to the SDK after API Level 15 may result in runtime errors.
minSdkVersion 15 and compileSdkVersion 23: with this configuration if I use api features from api 23, this application wont work in an android device with api level 20 for example, right?
Well, API Level 20 is a special Android version for the first-generation Android Wear devices. But if we switch that to API Level 19 (Android 4.4), if you blindly call an Android 5.1 (API Level 23) method, you will crash on Android 4.4. This is why the IDE will warn you about this, why you often see checks of BuildConfig.VERSION.SDK_INT, and why the SDK has these ...Compat classes (which try to hide a lot of these version differences).
With the previous configuration, and android device with api level 20 will be able to download and install the application because its api is higher than the minSdkVersion 15 but will not be able to run because it has features from api 23, right?
The device will attempt to run the app. How far it gets depends on how well the app is written. Again, you can create an app that uses newer-API features that gracefully degrades to run on older devices. This is not significantly different than how a Web site or Web app might want to use the latest HTML5 features but gracefully degrades to handle older or less-capable browsers.
If I want to make sure that I want to use an api level and not higher because of the previous problems commented, the configuration minSdkVersion 15 and compileSdkVersion 15 is the only way?
No. Again, the IDE will (usually) yell at you when you try using SDK features that are acceptable for the compileSdkVersion but are newer than the minSdkVersion.
is a common practice?
Not since 2010 or so.
FWIW, here is the documentation on this subject, limited as it may be.
I have looked at the documentation for building with Gradle, but I'm still not sure what the difference between compileSdkVersion and targetSdkVersion is.
All it says is:
The `compileSdkVersion` property specifies the compilation target.
Well, what is the "compilation target"?
I see two possible ways to interpret this:
compileSdkVersion is the version of the compiler used in building the app, while targetSdkVersion is the "API level that the application targets". (If this were the case, I'd assume compileSdkVersion must be greater than or equal to the targetSdkVersion?
They mean the same thing. "compilation target" == "the API level that the application targets"
Something else?
I see that this question has been asked before, but the one answer just quotes the doc, which is what is unclear to me.
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.
For example, as the documentation states:
For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher...
The Android OS, at runtime, may change how your app is stylized or otherwise executed in the context of the OS based on this value. There are a few other known examples that are influenced by this value and that list is likely to only increase over time.
For all practical purposes, most apps are going to want to set targetSdkVersion to the latest released version of the API. This will ensure your app looks as good as possible on the most recent Android devices. If you do not specify the targetSdkVersion, it defaults to the minSdkVersion.
As a oneliner guide:
minSdkVersion <= targetSdkVersion <= compileSdkVersion
Ideally:
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)
Read more from this great post by Ian Lake
Late to the game.. and there are several great answers above-- essentially, that the compileSdkVersion is the version of the API the app is compiled against, while the targetSdkVersion indicates the version that the app was tested against.
I'd like to supplement those answers with the following notes:
That targetSdkVersion impacts the way in which permissions are requested:
If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the app requests permissions from the user at run-time.
If the device is running Android 5.1 (API level 22) or lower, or the app's targetSdkVersion is 22 or lower, the system asks the user to grant the permissions when the user installs the app.
If the compileSdkVersion is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. (ref)
With each new Android release...
targetSdkVersion should be incremented to match the latest API level, then thoroughly test your application on the corresponding platform version
compileSdkVersion, on the other hand, does not need to be changed unless you're adding features exclusive to the new platform version
As a result, while targetSdkVersion is often (initially) less than than the compileSdkVersion, it's not uncommon to see a well-maintained/established app with targetSdkVersion > compileSdkVersion
The compileSdkVersion should be newest stable version.
The targetSdkVersion should be fully tested and less or equal to compileSdkVersion.
The CompileSdkVersion is the version of the SDK platform your app works with for compilation, etc DURING the development process (you should always use the latest) This is shipped with the API version you are using
You will see this in your build.gradle file:
targetSdkVersion: contains the info your app ships with AFTER the development process to the app store that allows it to TARGET the SPECIFIED version of the Android platform. Depending on the functionality of your app, it can target API versions lower than the current.For instance, you can target API 18 even if the current version is 23.
Take a good look at this official Google page.
I see a lot of differences about compiledSdkVersion in previous answers, so I'll try to clarify a bit here, following android's web page.
A - What Android says
According https://developer.android.com/guide/topics/manifest/uses-sdk-element.html:
Selecting a platform version and API Level When you are developing
your application, you will need to choose the platform version against
which you will compile the application. In general, you should compile
your application against the lowest possible version of the platform
that your application can support.
So, this would be the right order according to Android:
compiledSdkVersion = minSdkVersion <= targetSdkVersion
B - What others also say
Some people prefer to always use the highest compiledSkdVersion available. It is because they will rely on code hints to check if they are using newer API features than minSdkVersion, thus either changing the code to not use them or checking the user API version at runtime to conditionally use them with fallbacks for older API versions.
Hints about deprecated uses would also appear in code, letting you know that something is deprecated in newer API levels, so you can react accordingly if you wish.
So, this would be the right order according to others:
minSdkVersion <= targetSdkVersion <= compiledSdkVersion (highest possible)
What to do?
It depends on you and your app.
If you plan to offer different API features according to the API level of the user at runtime, use option B. You'll get hints about the features you use while coding. Just make sure you never use newer API features than minSdkVersion without checking user API level at runtime, otherwise your app will crash. This approach also has the benefit of learning what's new and what's old while coding.
If you already know what's new or old and you are developing a one time app that for sure will never be updated, or you are sure you are not going to offer new API features conditionally, then use option A. You won't get bothered with deprecated hints and you will never be able to use newer API features even if you're tempted to do it.
My 2 cents: Compile against any version of the SDK but take care not to call any APIs that your "minimum SDK version" does not support. That means you "could" compile against the latest version of the SDK.
As for "target version" it simply refers to what you planned to target in the first place and have possibly tested against. If you haven't done the due diligence then this is the way to inform Android that it needs to perform some additional checks before it deploys your lets say "Lollipop" targeted app on "Oreo".
So the "target version" is obviously not lower than your "minimum SDK version" but it can't be higher than your "compiled version".
Not answering to your direct questions, since there are already a lot of detailed answers, but it's worth mentioning, that to the contrary of Android documentation, Android Studio is suggesting to use the same version for compileSDKVersion and targetSDKVersion.
compiledSdkVersion==> which version of SDK should compile your code to bytecode(it uses in development environment) point: it's better use last version of SDK.
minSdkVersion==> these item uses for installation of APK(it uses in production environment). For example:
if(client-sdk-version < min-sdk-versoin )
client-can-not-install-apk;
else
client-can-install-apk;
Quick summary:
For minSDKversion, see latest entry in twitter handle: https://twitter.com/minSdkVersion
TargetSDKversion: see latest entry in twitter handle: https://twitter.com/targtSdkVersion
or use the latest API level as indicated at devel https://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Compiled version:
make it same as TargetSDKversion
maxSdkVersion:
advice from Android is to not set this as you do not want to limit your app to not perform on future android releases
The Application settings of an Android project's properties in Visual Studio 2017 (15.8.5) has them combined: