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.
Related
I am a complete beginner in Android Development and just downloaded Android SDK to integrate it with Eclipse.
However, I don't know which Android version I should select in SDK Manager to allow a maximum number of people to download and use my app.
Here's a screenshot of the manager that is showing up on my screen.
Any kind of help would be really appreciated.
Thanks.
In fact, you don't need to download an OLD SDK just to allow OLD Devices to use your app.
This is done in your project settings via target SDK version and min API level(AndroidManifest.xml or build.gradle).
Define Audience
First, define the audience to your app.
HERE you can find the market share for every Android Version (this can change for each country but it may help).
If you check that table, you can see that only few devices are still using API 15 or older.
So, if you support API<15, you will only reach ~3% more people. If you can support them without lose any feature, good (not all android features are supported/ported to all versions). But if you may need to disable a feature (like that special Floating Action Button that you created) just to reach those devices, I think it does not worth.
So, based on that table, you define the audience
In my case for example, I like to build apps for devices with API from API_16 to API_24.
Usually, we always want to use maximum API available. Today, 24.
This way, I could reach ~97% of the people using Android.
But this is optional... I could select min API as 13... or 14.. or 4.. This is up to you..
After defining the audience
Target SDK
I usually set the target API according to the MAX API I want to support. So, for example, if the MAX API I want to support is API_24, this will be my target API and will download the SDK v24 (7.0).
Usually, you always will have the latest SDK installed since you always want to reach latest android version and enjoy all the new features.
MIN API
Now, you also have defined the min API version that you want to support. So, lets use API 16 for example (first JB version).
You will set this in your project file (AndroidManifest.xml). You don't need to download SDK 16 just because of that.
Setting Eclipse
As I said, min SDK will be set in your project. That would be done in your Android Manifest
Here, you can see that targetSdk is 24. It means that I just need to download SDK v24 to build this project. Even then, I'll be able to install this App in devices with API 16 or later.
Eclipse (AndroidManifest.xml)
<manifest>
....
<uses-sdk
android:minSdkVersion="16"
android:targetSdkVersion="24" />
...
</manifest>
Android Studio (build.gradle)
compileSdkVersion 24
buildToolsVersion "24.0.0"
minSdkVersion "16"
targetSdkVersion "24"
minSdkVersion Does Not Guarantee that your app will work
Note that settings above only allow your app to run in devices with API>=16 or API<=24. However, your app may crash or does not work in all devices within that range. This usually happens because some View Components or Methods were added or removed according to API version.
For example, Fragment was added only on API11. So, if you try to install your app in a phone with APIv11, it will work. However, if you install it in a device with API4, it will crash.
Another example is method Fragment.onAttach(Context context) which was added only in API 23.
That's why we use Support Library
Support Design Library it is a library created by Google which enables the developer to use features from new Android Versions in old Android versions.
So, for example, to add a Fragment which is compatible with devices with API<11, you should import and use Fragment class from package android.support.v4.app.Fragment instead of default version included in SDK (android.app.Fragment).
This way, your app wont crash.
Of course this is very basic example. It is just to illustrate...
Anyway, I hope I could help you
Regards
I have gone through the following links but they don't provide a clear and definitive answer to my question. This is what I could derive from the answers:
targetSdkVersion indicates that the app is tested against the target version and will run on all android versions from minSdkVersion to targetSdkVersion
with no compatibility issues.
Android Min SDK Version vs. Target SDK Version
what is the difference between "min sdk , target sdk and compile with " ? in android
My app's minSdkVersion=11 and targetSdkVersion=19, Now I am not sure whether devices with higher SDK versions will see my app on Google Play Store or not.
UPDATE: For those who may encounter this question here is a great article I found:
http://www.thedroidsonroids.com/blog/android/compile-min-max-and-target-sdk-versions/
As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform 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. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. 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 and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens).
Android Developer, So the answer is yes, but you might want to consider testing and updating to current SDK version.
Yes, devices with higher SDK versions will see your app. Features of newer SDKs like granular permissions in Android 6.0 will not be available if they are not supported in your code.
The documentation for android:maxSdkVersion makes the situation clearer:
Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.
It works on SDK 11 and upwards, as in your first Link stated.
Yes. Your app will be visible to the devices with higher sdk versions than your targetSdkVersion.
By specifying targetSdkVersion you can restrict google by applying default compatibility behaviours.So that you will get along with the api level of the device in which your app is running.
Yes, newer devices will see it. Let's do a thought experiment. Let's go back in time one year. We build an app, setting the minSDKVersion and targetSdkVersion to X, the highest available number in the toolset. Six months ago, X+1 got released. And today I just bought a new phone that runs X+1, and I'm very excited! Wait, what? That brand new app isn't in the store? But it worked on my old phone!
That would be crazy. :)
As a more concrete example, here's an app that has minSdkVersion 15
targetSdkVersion 17: https://play.google.com/store/apps/details?id=com.nasarallysport.rallyracetimer I just verified that I can see it in google play with my Nexus 6 on api 23.
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.
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