I changed the build target from 7 to 16, with the only reason that I want to compile with the newest SDK. I still want to target versions starting at 7.
My project compiles and ran without problems on 2 devices. But I'm not sure if this is safe. I don't want to realease and that it crashes on some devices, because some things I'm not aware of.
Does it anyways make sense to upgrade the build target, without any specific reason?
Edit: Just to make it clear - I'm not doing it to target newer versions or support new features (I'm already using the compatibility library). It's just, because, maybe with newer build targets the internals have been improved - like performance, etc.?
If you do not use any functionality of the new SDK version(s) it does not make sense to update this requirement 'just for upgrading it'.
When running your application on a device, it will use that version, so it already makes use of the newest internals.
The android library is backwards compatible (meaning it is compatible with older version). The support library provides forward compatibility (meaning it adds functionality to match the newest android library version), the support library is provided with the application (in the APK), so it is available when required. The application first tries to use the android library (so it always uses the newest internals for that device) and if functionality is not present, it tries the support library.
If you require some new functionality then you should upgrade to that SDK version. And (eventually) add code to check the running version and provide an alternative for devices with a lower SDK version.
To find out the SDK version at run-time, for providing alternatives, use android.os.Build.VERSION.
Related
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
I'm trying to scale my app to all screen sizes and I read that if I compile the app against android 3.2 then I'll be able to use the new qualifiers etc....But my question is - if I do compile it at this version, does that mean that mobile phones that have a lesser platform won't be able to download or run the app? Will I be excluding the majority of phones for the sake of including a very small percentage of phones that the tablets currently comprise?
You may compile your app using the newest SDK version of Android, or in your case 3.2, and the app should continue to run on older versions of Android. The only thing to be careful of here is to ensure that the API methods you use are still compatible with the older versions. These newer qualifiers that you mention would not be allowed for the older versions of your app, but there are some compatibility libraries that you may use for them found here:
http://developer.android.com/tools/extras/support-library.html
To ensure that your app is compatible with older versions of Android, you can install the newest ADT and also run Android Lint. Lint will point out functions that may not be available on different versions of Android, based on your manifest file. Your manifest file allows you to determine the minimum version of android that can use your app, as well as the ideal version of Android that your app is made for. Please refer to the following link for more details about versioning your app, and some backwards compatibility:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Is there a way to change the Android version on my app without redoing everything? I just realized that Nook Color only has version 1.4. Well, I have my app set at 3.2 ... so those who have the Nook Color will not be able to access it. Why on earth did I do this to myself!
I am using Eclipse.
You can certainly create multiple .apk files for different versions. See this article about it. However, you may not need to if you haven't used any 3.2 API calls. You may be able to just change the minimum sdk level in the manifest file, update the version code, and republish your app.
You don't have to redo everything , but you can't use 3.2 API on nook color. You'll have to lower your minSDK version in your AndroidManifest.xml to the nook and test your application. If it doesn't compile you can look at using the compatibility libraries allow your app to run on older versions of Android if you are using API calls that aren't available on whatever the nook runs. 1.4 isn't a real version FYI.
http://developer.android.com/sdk/compatibility-library.html
Now you might run into bugs that exist in earlier versions that have been fixed in 3.2. Those bugs might require you rework your features.
My app requires that devices are running at least Android 2.0 OS. Would it make more sense for me to compile my project with the 2.0 SDK or does it make more sense to always compile my project using the latest SDK, even if it's well beyond 2.0...?
The problem with compiling against 2.1 for example would be that I don't know if an Android 2.0 device would even run an app compiled with 2.1...?
You can target a later SDK version using android:targetSdkVersion while still permitting your app to be run on earlier versions (since apps are filtered out based on the android:minSdkVersion). If you use API's that aren't supported, your app will force close. So, you'll have to pay attention to the API level annotations in the documentation for all functions, and test your app on an emulator set to use the minimum SDK version.
However, the Android Developer's Blog has some good advice on how to write applications that support earlier SDK versions - at a cost of some added work, of course. Whether it's worth it depends on whom you want to reach, obviously.
I want my Android app to have maximum reach, and hence want to support all versions V1.5 onwards. I find some features lacking in V1.5 that are available in V2.0 or V2.1. Could I compile on V2.1, and then set minSDK for the app to run on 1.5?
Plain logic says 2.1 specific features would not work, but let me know your thoughts.
Also, what are some other workarounds? What would "you" normally do in such a situation?
This is definitely possible; some of the techniques for backwards compatibility such as reflection and wrapper classes are documented in this article:
Backwards Compatibility for Applications
Also, I'd recommend compiling against the 1.5 or 1.6 SDK, otherwise you may end up accidentally using classes/methods from later SDKs and running into runtime errors on 1.5 devices due to those APIs not being available.
I would think there are two ways to handle this. In both cases you can develop against the 2.1 SDK and on startup check out what version of Android you're running with. Then you can either swap out whole classes based on the version or you can just block certain calls to methods that don't exist in 1.5.