In what scenarios would the Target SDK version and Build SDK version ("Compile with" in screen below) differ?
I'm trying to figure out why Target SDK wouldn't be used for both providing the API level the application is designed to run on, as well as compiling against the same SDK.
In what scenarios would the Target SDK version and Build SDK version ("Compile with" in screen below) differ?
When the developer sets them to be different values.
I'm trying to figure out why Target SDK wouldn't be used for both providing the API level the application is designed to run on, as well as compiling against the same SDK.
At the point in time when you create a new project, setting the build SDK and the target SDK to be the same is reasonably common, which is why that's the default in the new-project wizards.
However, developers may well want to raise the build SDK to a newer API level, while leaving the target SDK alone. The target SDK version controls some elements of forwards compatibility and therefore may change things that the developer is not ready to address just yet.
For example, suppose a developer created an app in mid-2013, and at that time set both the build SDK and the target SDK to be 18. Then, early this year, the developer started poking around with Android 4.4 (API Level 19). The developer wanted to add printing capability to her app. The simplest way to support API Level 19 printing is to set the build SDK to 19, so she could reference the relevant classes directly. However, KitKat also changed the behavior of classic AlarmManager methods like set() and setRepeating(), and she decides that she's not ready to deal with that just yet. Since those changes are tied to the target SDK version, she leaves her target SDK version on 18 for the time being, making a note to work on supporting the new inexact nature of AlarmManager alarms in the future. Hence, at this point, her build SDK is 19 and her target SDK is 18.
Target SDK: Highest API level that the application have been tested. The application should be compatible with all the devices with this API level or more recent API.
Compile with: API level with the application have been compiled. For default it's the highest possible level (now it should be Android 4.4.4 kit kat)
Related
The new version of SDK for Qt 5.12 doesn't include SDK Manager in the Tool folder, hence I needed Android Studio to Add/Remove the packages.
I know that APIs must be chosen based on the target and purposes. But since the APIs are new (28) and there are different options to download, it's rather puzzling what to download.
I don't have a real Android device nor want I use the Emulator. I merely wish to Build the program using Android kits and create APK files from them. Afterwards I will test those APK files on real Android devices which include new or middle aged smartphones and tablets.
For these purposes what packages should I install, for instance, what check boxes are needed to be checked here in the screenshot below. I will repeat the pattern for a number of lower APIs then.
If you don't want an emulator, then you don't want the "system images".
As for the API level, it really depends on what is the minimum API you want to target. If you download only the latest API, you significantly limit your targets, as the app will only run on the latest and greatest version of Android.
The safe lower limit seems to be API level 19, which is android 4.4. So you can use that to build your apps, and they will run on any version onward.
Additionally, if you want to publish to the market, you will have to set your target API to some of the latest versions, because google won't accept any older. Note that the "target SDK" is different from the "minimum required SDK", which you can still have at version 19.
There isn't much point in installing the latest SDK versions, as Qt isn't really using their features, I mean unless you are doing some Java native android app development.
The documentation for Qt 5.12 says "API 21", but 19 seems to work just fine, and it allows to target older devices that are stuck without OS updates - currently around 7-8% of active devices. Still, if you don't care about that, you should go with the recommended API version 21.
I was following setup guide for android in react-native documentation
and have it up and running correctly using suggested SDK v23
However there are much newer SDK versions available, I would like to set v23 as a minimum SDK version, but use latest one as my main one.
Being new to android I'm not sure on how to achieve this, what steps should I take? I can see option to edit sdk versions in some xml files and can download latest one using Android Studio.
As a side note, what are my limitations of using SDK v23? Will it not work on newer devices, do I loose out on performance etc... ?
According to some sources React Native does support up to API level 25, but there seems to be some disagreement on the issue. So according to official sources, React Native only supports Android API level 16 to level 23.
I haven't used React Native myself, but assuming versioning works the same as native development, an application with a compileSdkVersion lower than the version it is running against will run fine. The only limitations on the application would be that it would be unable to access the new features and APIs introduced by those higher SDK versions.
For example, Android 8.0 (API level 26) introduced a new Picture-in-Picture API, but the method used to enter picture-in-picture mode would not be available in code compiled against API level 23. Some new features may effect performance (usually positively), but an application compiled against API level 23 won't perform any worse on on a device running on API 26 than one running on API 23.
so im working on a small utility app to get started on the play store and ive come across a few issues which has led me up to this
It is forbidden to downgrade devices which previously used M permissions (target SDK 23 and above) to APKs which use old style permissions (target SDK 22 and below). This occurs in the change from version 1 (target SDK 23) to version 2 (target SDK 19).
for a small app like this it would be irritating for it to only be available on newer versions considering it doesnt require much. I cant remove the apk nor can i delete the project entirely so the question is should i just publish it for sdk 23 or should i just leave the project alone and make an entirely new one?
You are mistaken. Target SDK means the latest supported version. But it would still allow applications be installed on newer versions. Min SDK version means the earliest supported version.
If Target SDK is set to 23, and update comes out, which is 24, then app would still work on that device, however, whatever new features SDK 24 brings, won't be available.
You can read more at API Guides
I know there are plenty of documents over the internet but I have still some doubts about what SDK to install on my computer to create an android application for nearly %100 devices to working with. Google Play says that if I use API 8 (which is Android 2.2) then my application work nearly all Android devices.
So I downloaded API 8 and API 22 (Android 5.1, was default installed by Android Studio itself) and I don't know if it works or not if I select Minimum SDK to API 8 while creating a new project.
So seriously guys, what the heck is going on?
What SDK Platform(s) you install has little to no impact on what versions of Android you can support.
If you create a new Android Studio project via the new-project wizard, you will find an app/build.gradle file. In there, you will find a setting named compileSdkVersion. This controls what version of the Android SDK you are compiling against (i.e., what JAR is used to satisfy compile-time references to Java classes like Activity and TextView). Whatever value you specify for compileSdkVersion must be an "SDK Platform" that you have installed from the SDK Manager.
In a newly-created project given your setup description from your question, you will see that compileSdkVersion is 22, lining up with pre-established API Level 22 edition of the SDK Platform.
However, this does not mean that your app will only run on API Level 22+ devices. Much of what is in the API Level 22 edition of the Android SDK has existed in previous versions of the SDK.
The minSdkVersion property in the same app/build.gradle file says how old you are willing to go -- what is the lowest API level you are willing to support. Right now, I think a new project will be set up with minSdkVersion of 15, though that varies over time. More importantly, you can change it to be whatever you want, and you do not need the SDK Platform installed for whatever level you choose.
If, in your code, you reference stuff in the Android SDK that is valid for your compileSdkVersion but is newer than the minSdkVersion, the build tools will point out the discrepancy, so you can make sure that you know what you are doing. This is how Android handles progressive enhancement -- you see what version of Android you are running on (Build.VERSION.SDK_INT) and use newer APIs where you can, falling back to older APIs as needed.
TL;DR: So long as your compileSdkVersion has a value for which you have an installed SDK Platform, you're set.
It depends on the application you are developing. And the resources that it will need. It's true that if you use the oldest version (API 8) and your application is simple enough, then it will work on any device.
But there are limitations to it. on older APIs you will not be able to use new features as Navigation drawer for example
I would recommend API 11 or 14, that covers most of the devices and features nowadays.
You should consider the design you want to create on your app
You can see the market share of the different api versions here: https://developer.android.com/about/dashboards/index.html
Then you have a trade-off of how advanced APIs you want to use vs. how many devices you want to support.
I wanted to know the consequences of having targetSDK > buildTarget.
I recently observed that if I keep the buildTarget=16 and targetSDK=17 the tabs on my tablet (running 4.1.1, API Level 16) moves to the center of the actionBar. I was unable to rationalize the behavior. Can somebody shed some light on why this happened?
Nice question! I had a similar behavior some time ago, when buildTarget and targetSDK differed in the described way. It took me some time, to figure it out, but I will try to summarize my understanding.
You have to distinguish between three important values:
minSdkVersion:
This is the lowest available version, on which the app will (or should!) run. When installing an .apk onto Android, the value will be checked and if the Android version you're running on, is lower than the specified version, it won't install.
buildTarget:
That's the SDK on which the application's .apk will be compiled (and Eclipse will be target that value too, for checking for compilation errors). If the buildTarget is higher than the minSdkVersion, you will be able to install the app even if your Android version does not support all methods. By default, this is set to the latest version of Android available in your SDK. You can still build your app to support older versions, but setting the build target to the latest version allows you to enable new features and optimize your app for a great user experience on the latest devices.
You need to check if the methods you are using are present at runtime if running on a lower API level, otherwise the application might crash!
targetSdkVersion:
The targetSdkVersion specifies on which SDK platform your app should run fine. So, if you tested against API 17, you can add API 17 as targetSdkVersion. If using an Android version > targetSdkVersion, the Android system will enter into some kind of forward-compatibility mode to ensure support for the application. This compatibility behavior will be entered to ensure that your app continues to work the way you expect, as there might be some changes in behavior between never API levels (here are some of the most important changes). So, any application developed for a lower API level will be able to run on a higher version, as the old behavior (like obsolete values) might be "simulated" within the compatibility mode.
For example:
If you set targetSdkVersion to HONEYCOMB (API 11), the default theme will be changed to Theme_Holo (that's the dark holographic UI). Setting targetSdkVersion to a lower value will affect the system to stay on the default light theme, regardless which build API you will use!
In your case, there don't seem to be many noticeable changes between API 16 and 17, that should affect in a design change, but I guess, the higher targetSdkVersion will affect in some additional changes at compile time (like including additional classes, themes, values, ...), that will affect in a different behavior, just like in the theme example above.
I hope, that helped you a bit, to figure out the weird behavior. Here is some more related information to read in the Android Developer documentation.
PS: There is some kind of forward-backward-hell: The Android system is backward-compatible, so that the forward compatibility of Android applications is ensured. That means: If you update your Android version via OTA e.g., all old applications should stay running (so they will stay forward compatible).
The build target is for app development, the target SDK is for app compatibility.
The build target specifies which API you have access to while implementing the app. Like if you set the build taget to android API level 10 then as far as your code is concerned, there is no such thing as an ActionBar. The API you use during development is just a stub implementation of Android, this is way it has to be emulated or run on a real device. Therefore, the build target defines (to the compiler and your IDE) Android interface you are using. Once compiled, there should be no difference based on build target (the Android system doesn't see the build target, it's a compile-time flag). This is a strict contract between you and the android compiler (and your IDE) that defines which components in Android you are able to use in your application, as you will get compilation errors if you try to use something that is beyond the Android version set as your build target.
The target SDK is a contract you sign with the Android system, assuring it that your app is prepared to work properly from you minimum SDK up through to the target SDK (effective the maximum SDK, as the maximum SDK setting should generally be avoided). I believe there are a few things that don't get forward-compatibility, like some of the security changes (probably changes the come from beyond app development and are system-wide). This contract is an agreement that means you have performed measures to make sure that your app handles any changes in the Android API in that range, such that it provides behavior you expect in all situations. The other end of the contract is from the Android system, it agrees to use Android implementation that does not exceed your target SDK, even when on a device running a higher version of Android (this excludes the few changes that I mentioned previously).
The note on forward-compatibility implies that your build target should always at least match your target SDK. You are saying that you have tested your app to run at your target SDK, so why build it against a lower API level?
Real life example of build target and target SDK in action:
ActionBarSherlock provides backward-compatible ActionBar. Here are quotes from requirements to use the library at this time.
The library itself must be built against Android 4.0 (API level 14). Your project should be built using the latest version of the SDK as possible as long as it is 4.0 or newer.
Targetting API level 11 or newer is required as it will cause Android to automatically add the native action bar when run on newer devices. Since you will be compiling against new APIs but your app will likely be run on devices with older versions of Android extra care must be taken to either avoid using or properly check and call any methods that were introduced after your minimum SDK version.
The first paragraph shows that a build target that contains the 4.0 ActionBar API is required, as the library makes use of it and can't compile without it. The second paragraph shows that a target SDK that contains the 3.0 ActionBar API is required as the library uses the native ActionBar on such devices, but the Android system won't provide the ActionBar if your target SDK is lower than 3.0 since that tells it not to use anything newer than your target (like the 3.0 ActionBar).
Some references:
Build Target
Target SDK