I was following through a Udacity course on android , and these terms seem to confuse me
(i use android studio 1.x latest version)
In my build.gradle i have these
compileSdkVersion 21
buildToolsVersion "21.1.2"
......
minSdkVersion 10
targetSdkVersion 20
versionCode 1
versionName "1.0"
....
compile 'com.android.support:appcompat-v7:20.0.0'
My assumption
If I leave the app theme as default that is in my manifest file,i set it to use app:theme and in styles.xml it is by default
appcompat.light.darkaction bar
I figured out the appcompat theme means ,it changes to use the theme for the version of the target SDK irrespective of the device OS version
when i chose API 21 ,it looked like a material app
when i chose API 20, it looked like a kitkat app
(both on my device which runs ICS)
so target SDK is contolling the look and feel of my app irrespective of device OS,
it defines what highest version of android the device can support , right?and by default the look and feel change to the latest or the target API look and feel whilst using app:compat theme still enabling it to run on lower sdks ,,as low as API 10
and minsdk is the minumum supported ,
am i right till here?
Now what confuses me is
what's compile SDK , should it always be the latest available ?
Example : material didnt show app icon in action bar icon , i didn't like it , and switched to API 20
to follow with the MOOC videos
but should i leave compile sdk as 21 , wont that make the app look like material , cause i'm confused as it didnt?
And a final question ,
I want to test the app on devices running gingerbread, i don't have any,
can you suggest some typical AVD config for gingerbread devices(cause i know a lotta people still use it in developing nation),
what ram,screen size and pixel density should i use that fits a typical gingerbread device?
so target SDK is controlling the look and feel of my app irrespective of device OS,
Yes. (among other things)
it defines what highest version of android the device can support , right?
No ! The target SDK indicates the SDK you use to test your app. You can use a target SDK 20 and run your app on a device with API 21 installed : it will use the KitKat l&f (i.e level 20).
How is it possible ? When an app targeting API 20 is running on a device with API 21 : the system will automatically enable some backward compatibility hook so that your app behaves just like it behave on older versions (i.e. targetVersion) of the OS.
The maximum sdk supported is the maxSdk attribute (rarely used and not recommended). If you specify a maxSdk 20 : you won't be able to install your app on a device running SDK 21+
The compile SDK level is the version of the sdk you use to compile your app. If you choose the latest one : the users of the latest android version will benefit of code that is optimized for them. It will allow you to use the latest features of the sdk... but be careful when you write code using new apis since it will crash on older devices.(see here under)
The minimum sdk version may be lower than the compile sdk. In your example you are declaring that your code can be executed on API level 10, but compiled with api level 21... that's OK but you MUST ensure that every calls to API that don't exist in API-10 won't be executed on a device running API-10.
Let's illustrate this tricky point. Assume : compileSdk = 20 ; targetSdk = 20 and minSdk = 10
if (Build.VERSION.SDK_INT >= 13) {
apiCallToSomethingAvailableOnlySinceApi13();
}else {
//put here some alternative code to perform something similar
//(but probably degraded) feature
//on device running API 10, 11 or 12
//device with api 9 or lower are exclude anyway (because minSdk is 10)
}
To summarize :
minSDK : it is possible to install the app on a device with at least this level and the developer wrote defensive code to ensure that all calls to api more recent than minSdk won't be executed on device running the minSdk version.
targetSDK : the app was tested on this level and more recent devices must enable backward compatibility hook so that the app still behave as if it was running on this level even on more recent devices.
compileSDK : the code is optimized to run on this level. (usually safe to put it the same as targetSDK)
maxSDK : you cannot install the app on a device running higher API (not recommended and most of the time not useful).
Related
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:
I read that berlin is compatible with marshmallow, but i see that by default in the AndroidManifest.template.xml we have :
<uses-sdk android:minSdkVersion="%minSdkVersion%" android:targetSdkVersion="%targetSdkVersion%" />
i don't know where delphi took the variable to update %targetSdkVersion% but it's seam to be all the time 14 and i don't see any way to configure it
i would like to replace %targetSdkVersion% by 23 (marshmallow api level, to support the app permissions), but is it safe to do so or it's will introduce many other bug ?
FireMonkey was developed to work against a certain range of Android functionality. As you can see from the RAD Studio Platform Status page FireMonkey apps built with Delphi 10.1 Berlin have a lowest supported Android version of 4.0.3, which corresponds to Android API Level 15.
The minSdkVersion field is supposed to be set to the earliest Android version your apps will work with so in truth this should probably be set to 15 but actually is set to 14 (Android 4.0-4.0.2).
If you look back at an Android manifest file generated by Delphi XE7, which supported Android 2.3.3 (API Level 10) it specifies a min SDK version of 9 (Android 2.3-2.3.2), which is the version of Android that introduced the NativeActivity type underlying every Delphi FireMonkey Android app. Again, this seems a little bit out of kilter with what is documented as lowest supported version.
Anyway, minSdkVersion can be used by Google Play store to filter your app out of the listings for someone running a lower version of Android. It is also checked when you install an app on a device; Android won't let you install on a lower version of Android.
targetSdkVersion, on the other hand, indicates what version of Android your app has been tested with and works sensibly with. It can often be higher than minSdkVersion if your your app needs to use features introduced in Android versions later than minSdkVersion.
If you want to use a feature from API Level 23 then sure, you'll need to update that manifest part. Just remove the %targetSdkVersion% template from the Android manifest template file and replace it with the required version.
Problems that you might run into:
You'll either need to check the Android version and, if lower than your targetSdkVersion, not use those features that aren't available or set minSdkVersion to a suitably higher version to ensure the app can only run on devices that have the features you wish to use.
FireMonkey code not aware of differing behaviour in API Levels may
function adversely. In your case you may get issues because of the
different runtime permissions behaviour enabled in API Level 23.
Actually I can't currently think of any more issues, though a good amount of testing is recommended. You might have more to think about in a regular Android app using visual activities and so on, when different API levels may affect the theming or other UI elements. You can see the various things that change when you target target SDK versions on this Android documentation page.
By the way, the use of the SDK Manager in the Tools. Options... dialog is entirely irrelevant to the question of how to update the value in the generated manifest file. The only evident way to change it is to manually edit the Android manifest template file as per the documentation, and mentioned in a comment.
The only relevance of the SDK Manager is that the default Android SDK installation for Delphi 10.1 Berlin installs the Platform libraries for API Level 22. If you want to use a feature from API Level 23 you might think that updating those platform libraries might be necessary, but of course if you're doing the coding in Delphi then you're (presumably) actually just compiling against import definitions of the features in that higher API level, and so whether or not those features are contained in the android.jar file is of no consequence.**
** I'm happy to be proved wrong on this count, but I have never observed a connection between the manifest and what the SDK Manager is set up against.
This code is some basic code to set up tabs in Android.
final ActionBar actionBar = getActionBar();
actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS);
If you write this code in a project where targetSDK < 20 or compileSDK < 20 (I don't know what the difference is between versions of compileSDK and targetSDK) then it is fine.
However, if you have compileSDK higher, e.g. 23, then Android Studio will tell you that the code above is deprecated (and moreover is removed from SDK, I guess).
And it will crash my app if i run it on device (btw on Android level 20, though the target of project was set to 23 and compiled version too 23, so it crashes because it is deprecated and removed from SDK level 23).
Questions:
1) What happens if I compile my project with compileSDK version and
targetSDK version set to 20 (where there is no problem with being
deprecated) and try run it on Android with SDK 21 or 23 where these
functions are obviously removed from SDK? Will the app crash or work?
2) What happens if I decide to target the "high" SDK (e.g. 23)? That
is, I will leave the "old" code mentioned above and will use some
"new" code for tabs, which appeared in SDK 23 or so (which didn't
exist in lower SDK); then I will try to run the application on
Android with lower SDK, e.g. 20. Will the app crash or work?
edit:
Btw now i launched project with targetSDK and compileSDK 20 on Android with level 22 and it worked.
So it seems the only thing that really matters is the compileSDK version? Doesn't even matter on the SDK version of device but it really matters the compileSDK?
Because as i said about the two tests - project with bad HIGH SDK launched on device with good LOW SDK = crash. Project with good LOW SDK launched on devide with bad HIGH SDK = not crash.
But the logic of course say that it must also matter on android version of device (eg to access some new functions.. or really only matter on compiledSDK or at least from view of backwards-functionallity)?
Need some opinions of experts on this.
However, if you have compileSDK higher eg 23, then Android Studio will tell you, the code above is deprecated (and moreover removed from SDK i guess).
No. getActionBar() is not deprecated. setNavigationMode() is deprecated but not removed.
What happens, if i compile my project with compileSDK version and targetSDK version eg 20 (where is not problem with deprecated) and will try run it on Android with SDK eg 21 or 23 where are these functions from SDK obviously removed? Will app crash or work?
The app should work fine. "Deprecated" means "we think that there is a better solution and we would prefer that you use it".
What happens, if i decide to target the "high" SDK that means eg 23, i will leave the "old" code mentioned above and will use some "new" code for tabs, which appeared eg in SDK 23 or so (that means didn't exist in lower SDK) and i will try run the application on Android with lower SDK, eg 20? Will app crash or work?
First, I am not aware of any "'new' code for tabs, which appeared eg in SDK 23". The Design Support library has the only new tab implementation that I can think of, and it works back to API Level 7.
Second, your app should fail to compile, if you are trying to use something that is newer than your minSdkVersion without adequate checks (e.g., using Build.VERSION.SDK_INT and bypassing that code on older devices).
In the end, if you refer to a class, method, field, interface, and so on that does not exist on the older API level, your app will crash if and when that code gets executed. A typical error is VerifyError, though it depends a bit on the nature of what it is that you are trying to use that does not exist.
With respect to tabs, there are countless implementations available to you. Most come in the form of third-party libraries tied to ViewPager. In terms of the Android SDK, there the aforementioned TabLayout from the Design Support library, FragmentTabHost, and PagerTabStrip (though the latter has a bug in the 23.0.0 edition of the support-v4 library, apparently).
Deprecated API are still available, so you're free to use them - the app won't crash on neither of platforms. However, it's advised that you read the documentation to understand why the API have been deprecated: usually developers provide alternative solutions.
Here is some explanation on compile/target/minSDK.
1) What happens, if i compile my project with compileSDK version and
targetSDK version eg 20 (where is not problem with deprecated) and
will try run it on Android with SDK eg 21 or 23 where are these
functions from SDK obviously removed? Will app crash or work?
Android Studio is probably only warning you that the API has been deprecated, but not removed. If it had been removed, setting the compile SDK to 23 should break your compilation. Your application should work fine even if it is using a deprecated API, but you should update that when you have the time as it is no longer the recommended one.
2) What happens, if i decide to target the "high" SDK that means eg
23, i will leave the "old" code mentioned above and will use some
"new" code for tabs, which appeared eg in SDK 23 or so (that means
didn't exist in lower SDK) and i will try run the application on
Android with lower SDK, eg 20? Will app crash or work?
When you use an API that has been introduced in SDK 23, you will need to set compileSDK to 23 as well. In case you set your minSDK to 22, you will be able to install it on a device that is using SDK 22, however, your app will crash with a NoSuchMethodError if you try to use that method. You can however check the SDK running on the device (use Build.VERSION.SDK_INT) and not call that method in this case.
I’m building an Android app which should run on every device with Bluetooth Low Energy, which means a minSDK of 18. I’m not sure as to which targetSDK I should use however. I read online that it is good practice to always use the latest version for this (API 22). Is this the case, or should I build my application with every targetSDK that I support, i.e. build with the SDK 18 for applications that run API 18, build with SDK 19 for devices with API 19, …?
I’m confused since to start a BLE discovery I can use either startScan() or startLeScan(). The Android documentation tells me: "startLeScan() was deprecated in API level 21, use startScan() instead". I’m unsure what impact this has on which targetSDK I should use to compile my app with. Will devices running API 18 will be able to run my app if I compile with SDK 22 and use startScan(), and will devices running API 22 be able to run my app if I compile with API 18 and use startLeScan()? Or should I really just build my application with every targetSDK that I support like mentioned above?
Let me answer this for you.
1) you already know minSDK should be 18(cool). Because LE supports is there on or after that.
2) If you build your app using target sdk 18, it will work on devices supporting Android 5.0/5.1 also.
3) If you build your app using target >sdk 21, and use startLeScan instead of startScan(startScan is introduced in 5.0/sdk21), it will work on all devices running on >18 api level.
4) Now the tricky part, there are also other apis which are available on 5.0+, which were missing on lower versions. I will suggest build the app using target of the latest sdk (currently 23).
i) Use different apis to achieve same results in different versions. Like if the phone running on lower than Android 5.0, use startLeScan, else startScan.
ii) There are differences on Android 5.0 and 5.1 also, so use those methods accordingly.
5) Some apis like startLeScan are deprecated, but I know, they are still working as they have tied them up with new apis. so until they remove the old apis, they will work on all platforms. This is precisely what deprecation means :)
So answer of your question "Which target sdk should be use", answer is latest sdk :), and call respective apis based on SDK version. You can get SDK version on run time via android.os.Build.VERSION.SDK_INT
I'd recommend to use Android 5.0 and above. Why? This video quite clearly states "BLE in Android below 5.0 is crappy".
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: