Develop Reference

Firemonkey: can we update targetSdkVersion in AndroidManifest.template.xml?

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.

Android target sdk vs deprecated methods

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.

What SDK to install, seriously?

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.

Android and Eclipse: minSdk and compileWith

Well, I think that is not well explained and right now I'm a little bit confused. From this link:
Compile With is the platform version against which you will compile
your app. By default, this is set to the latest version of Android
available in your SDK. (It should be Android 4.1 or greater; if you
don't have such a version available, you must install one using the
SDK Manager). 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.
From this one instead:
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.
Now, as they are contradicting themselves, here I'll explain what I've understood: let's say that we compile with api 5. It means that if I run from 1 to 5, my application works but it doesn't for versions > 5. So:
Why I need to set the minSdkVersion if compileWith is set to 5?
What is targetSdkVersion?
The point is: if compileWith is set to the latest version, is it possible to use latest APIs and still have backward compatibility? I'm sure that I'm wrong and I'm missing something. Thank you.
Edit 1
Now I understand more but anyway I'm missing something: let's say that minSdk is 9 and target is 18 (my current sdk). It means that I cannot use anything specific to api 18 unless there's some support package for older versions, right? I'm thinking different: I would compile with the lowest version possible to get forward compatibility. I mean, if you compile a Windows application on Win2000, it will run till Windows 8 but I'm limited to Win2000 apis. If I compile with Windows 8, the backward compatibility should be checked on runtime and I can use Windows 8 apis on Win2000 only with "support packages" (it's an example, obviously). Right?
Edit 2
This is what I'm asking about Android (not about the JVM). Android is mixing forward with backward and I've mixed it more using the Windows example. FIY, It seems that Windows is backward compatible, as explained in the examples here. So, what about Android? It seems that the minSdk version should be tested from the developer, I mean: I should compile with latest version and test my application behaviour till the minimum api level that doesn't change it. So it seems that I need to test the backward compatibility by testing on every api level lower than the one with wich is compiled and they assure the forward compatibility. Right?
I think that I'm mixing forward and backward compatibility definitions. Everytime I read them they seem different.

from the Documentation you can read the following:
android:minSdkVersion
An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
and
android:targetSdkVersion
An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion.
This attribute informs the system that you have tested against the target version and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).
And to answer your last question, targeting the latest API will not allow you to execute any newer method or use any newer class on old phones, for that you need to use the support packages, with that you are able to obtain a close result to what you can do in newer APIs.
Hope this gives you a more clear idead of why you have those two values and the difference between them.
UPDATE:
Well about the example of something built for windows 2000 and working on windows 8, is not guarantee that it will work, that is why on windows you have the "run with compatibility" mode, and then you select according to what operating system you want to run it.
This is because maybe both OS (or APIs in this case) have the same method or option, they do it in a different ways or need other permissions. The same happens here, so the target SDK will be the reference frame against you tested and thus it will use that behavior if you run it on newer devides than the taget SDK.
For the APIs between the min and the target they will run as normally they do, and so you can always have a weird behavior and some patching might be need it, normally is most visible on the 2.x to 3.x jump.
UPDATE 2:
Well, let me try to explain it in a different way.
The minSDK will determine which methods and options you can use throughout the application, this means that if a method is only available after that API, you will not be able to use it and instead get an error message.
The targetSDK represents the lastest version of the API that you tested and so, if the phone has a newer API than the one you specified, it will try to behave as it was on the API version you specified, take for example this, in the section Important Behavior Changes:
This inexact batching behavior applies only to updated apps. If you've set the targetSdkVersion to "18" or lower, your alarms will continue behave as they have on previous versions when running on Android 4.4.
So, as you can see there, if you set the targetSDK to a previous API (before 19), it will behave as it use to, but if you target the newest API (at this moment API 19), then it will behave differently.
Hope i was clear enough, if not, please do not hesitate and ask.

Compiling with Android 4.X but supporting API Level 9

I'm working on an application which uses ActionBarSherlock. As it's documentation points out:
[...] the library requires that both it and your project are
compiled with Android 4.0 or newer. The project also requires that
you are compiling with JDK 1.6 in both your editor and any build
systems that you may be using.
So, that means I'll compile my application (and the library) against Android 4.X but in my Manifest, I declare that I'm targeting (e.g.) API Level 9.
This all works fine and well but there is something that disturbs me. From the FAQ:
What API level should I target in my manifest when using the library?
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.
That means, that I'll have to manually check every method call, so I don't use any that are not available in my targeted API Level (9 in my case)? This sounds wrong to me.
Is there a way to tell my IDE (IntelliJ), that I'm only using the API Level 9 (so I don't get any auto-completion for non-existing methods/classes and don't use them by accident) and then choose to compile it against another Android version?
Or can I use some automated checks (which run at compile time) to check for that?

The ADT's lint feature should take care of this by warning when API calls are being made for the wrong API version.
You should be compiling both ABS and your project with the latest SDK available (at present, 4.1). Your manifest should have a targetSdkVersion as high as possible (ideally matching your compilation SDK) and your minSdkVersion should be set to the lowest version you support.
Lint is partially integrated with IntelliJ IDEA and is also available as a command line tool.

You temporarily set your target SDK to the various lower ones and debug with it. Your final build then is with the latest SDK.

Set a Build target similar to that you have mentioned in your manifest.

as always , you should set the targetSdk to the maximum available on both the manifest and the project.properties file (as recommended by google on one of their videos) , so that the ADT&SDK would be able to optimize the ADK accordingly.
set the minSdk to the one that you wish to support your app from , and let Lint to tell you if there are any problems in case you use too-new-features.