So, I'm a little confused, I thought I understood the meaning of android:minSdkVersion, android:targetSdkVersion and target in project properties.
Right now I got these set to:
android:minSdkVersion="7"
android:targetSdkVersion="13"
And:
target=android-15
in project->properties->Android->Project Build Target.
When I try to run this application application on a device with Android 2.3.3 installed, I see a red cross against the device name but the application runs fine on it none the less.
What am I missing? If I'm building against 15, how is it running on android-7? This confusion stated after I integrated AdMob into my app which states it require minimum SDK level 13.
To describe one at a time:
android:minSdkVersion helps Google Play filter apps for the user based on their device. For instance, with minSdkVersion="7", someone browsing with a device that only supports 6 won't see your app on Google Play, and thus won't download it, find it doesn't work, and leave a bad review :)
android:targetSdkVersion is a signal to the device about which version of the API your app was tested against. New behaviors are often available by default with new versions of the platform, for applications that target at least that version of the platform. For instance, by setting your targetSdkVersion to 11 or higher, you get an overflow menu in the ActionBar (for Honeycomb and up devices) instead of the "legacy menu button of shame".
project.properties target is a signal to your local build system regarding which version of the platform you should be compiling your code against. Generally it's best to just set this to whatever you have set for the targetSdkVersion.
What am I missing? If I'm building against 15, how is it running on
android-7?
Android maintains backwards compatibility for just this reason. When you use API's that were added in version 15 of the platform, obviously they won't be there on a device running an an older device.
However, it's possible (and encouraged) to design your application in such a way as to take advantage of features added on new platforms, but "degrade gracefully" such that your application continues to run on older ones. There's an Android Training lesson on just this topic, called Supporting Different Platform Versions.
android:targetSdkVersion="13" Indicates that this application has been build by keeping the sdk 13 as target, to use its feature to full potential
android:minSdkVersion="7" indicates that it works on sdk 7 and above, but some of its features can be stripped down if certain features are not available in lower sdk. ie(less than sdk 13)
android:minSdkVersion="7" means you can't run this app in devices under 2.1(API-7). android:targetSdkVersion="13" the app is built targetting this API. the build target will be set to 13 and the methods and stuffs that are available till 13 will work.
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Related
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.
What do I need to consider before choosing the target android OS for app development?
This is my understanding of how to do it and any clarification would be appreciated:
Determine which OS version is currently in use the most. Look at distribution graphs etc.
Target that version.
that is what I read all the time, but I have some questions.
Suppose 4.0 is the version that is the most used among android phone consumers so I should target 4.0. Now, suppose that I don't use features that are unique to 4.0. will my app work with any version below 4.0 including 1.5, 2.3 etc.? Consider the reverse situation. If I target version 2.3 and if my app uses only features that are available to 2.3 will my app work on phones that are running version 4.0 even though I will not be using features that are unique to version 4.0?
thanks.
have a look at your AndroidManifest.xml
There is a targetSdkVersion and minSdkVersion if you want to support all devices running 2.2 and up then set minSdkVersion to api level 8 (android 2.2)
but in general, its a good practice to develop against the latest api as target (currently API 19, Android 4.4), so you can ensure it will work from your chosen min up to the newest OS api
so if you want to support at least Gingerbread up to KitKat do this in your manifest:
<uses-sdk android:minSdkVersion="9"
android:targetSdkVersion="19" />
and develop against api 19 :)
Suppose 4.0 is the version that is the most used among android phone consumers so I should target 4.0. Now, suppose that I don't use features that are new to 4.0. will my app work with any version below 4.0 including 1.5, 2.3 etc.?
Only if you don't use APIs that were introduced after the earliest version you want the app to run on.
If I target version 2.3 and if my app uses only features that are available to 2.3 will my app work on phones that are running version 4.0 even though I will not be using features that are unique to version 4.0?
Yes. Some functions get deprecated in newer OS versions, but most of them still work in newer releases for keeping compatibility.
I feel the thing to stress here is that Android is backwards compatible, so newer versions will almost be able to run apps developed for older OS versions.
The target version is the highest version you have tested it on. You should always target the absolute latest if you can. The min version is the lowest version that will be able to install the app.
So in the manifest, you would typically have something like this:
<uses-sdk android:minSdkVersion="9" android:targetSdkVersion="19" ...
Pick the minSdkVersion based on the features that are absolutely required for your app to function.
So you might wonder what the purpose of targetSdkVersion is. One reason is if your app has some optional features that are in later versions of the SDK. targetSdkVersion will allow you to use those later features, but you will need to protect those method calls with a check against the device's SDK with a call like
if (Build.VERSION.SDK_INT >= 11)
myMethodThatUsesFeaturesOnlyInHoneycombAndLater();
Another reason is that sometimes the Android team makes changes to some of the defaults in various settings on your classes, but to maintain compatibility for future versions on which you have not tested your app, they keep the old default if your app doesn't claim to target this later version.
For example, after Honeycomb, the menu is supposed to be integrated with the action bar. But old apps that were compiled with earlier SDKs have not been tested with Honeycomb or later, as proved by them having a targetSdkVersion of less than 11, so the OS knows to display the old style menu. Once this developer decides to test their app on a more recent targetSdkVersion, they update the value and the OS can trust that they have tested it on Honeycomb, so it can safely show the new style menu.
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've just started developing android apps and I am wondering about this right from the start.
Apparently it doesn't matter if you work with API 13 (3.2), you can still support Android 1.6. Is that true?
For AdMob to work, I had to start working with API 13 and have set
target=android-13
Someone please clarify this or point me somewhere to read it.
Apparently it doesn't matter if you work with API 13 (3.2), you can still support Android 1.6. Is that true?
That depends on what you mean by "work with API 13".
Having a build target of API Level 13, as you mention later in your question, simply means that is the version of the Android SDK you are compiling against. You will be able to reference classes and methods that exist on API Level 13 (and earlier). Your app can still run on any version of Android you want.
However:
You cannot call methods that do not exist in API Level 13 when you are not running on an API Level 13 device (and likewise for API Level 12, 11, 10, etc.).
If you wish to support Android 1.x, you cannot even reference classes or methods that do not exist on the device from a class that gets loaded by the VM.
In either of those cases, you will get a VerifyError, and your app will go "boom".
There are strategies for conditionally using newer-API stuff that allow you to avoid trying to use that stuff on older-API devices. Or, just stick to older-API stuff in the first place, even though you won't get compiler assistance to let you know when you are accidentally using newer-API stuff, given that you are using the newer build target.
Or, contact AdMob support and figure out why they need that build target.
In your Manifest file you can put the min sdk version you want to support and your target sdk version, they could be different, to support 1.6 specify android:minSdkVersion="4" as follows
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="13" />
I'm building an application, and need to support both 1.5 (Magic and Hero) and 1.6 (Tattoo) devices.
As Android SDK is forward compatible, it seemed logical to build against Android 1.5 SDK, and expect application to work on Tattoo.
While that's true, (I tested app, it works ok), I'm now having problems on Android Market.
On Tattoo, Market search by default filters android apps that doesn't have explicit support for small screens defined in AndroidManifest.
Problem is that attribute exists only on Android 1.6 SDK, so Building against Android 1.5 SDK is no an option anymore.
How safe is to build App agains A1.6 (with minSdkVersion="3") and run it on 1.5 devices?
Is there anything else I should take care of except just change target SDK?
Make sure you don't mix up minimum SDK version and target SDK version as these are different options.
For example, I use the following setting in the application for my manifest:
<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/>
The documentation says the following about targetSdkVersion:
In some cases, this allows the application 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.
So by specifying targetSdkVersion of 4 but having a minimumSdkVersion of 3 you'll have an application which should work on 1.5 devices and 1.6 small screen devices.