Which Android SDK for multi-version support? - android

If I want to develop an app for API 7 through to 18. I understand I should set minSdkVersion to 7 in the manifest, and I assume I should set 18 as targetSdkVersion. But I'm confused by what SDK I should use for development. Should I be using the SDK for 2.1 (API 7) or 4.3 (API 18)? I don't want compatibility behaviours as I want to completely control and specify what to do on each platform version. And what about the support library? Would I use support libraries 8-18 or 1-7?
(Posted here because development questions are off-topic for android.stackexchange.com)

You can and should use the newest SDK. Eclipse or Intellij will automatically take care of letting you know if you are attempting to use a component that is only available in newer APIs. You will only want to use support library v7 and below since you intend on supporting API 7 and above. A lot of your worries will automatically be taken care of by your IDE. It will let you know if you are trying to use things that are not available in your minimum API level (which you indicate in your manifest file).

Related

Minimum API level required for non-Support Library android projects

Does anyone know what the lowest minimum API level is for Android projects that don't require any Support Libraries? 21 or 22 was my guess but I may be wrong. I don't need any Support Library features for my future project.
Does anyone know what the lowest minimum API level is for Android projects that don't require any Support Libraries?
API Level 1. After all, the Support Library did not come into existence until after API Level 11 shipped. We developed Android apps for a few years without such a library.
If you are asking what is the min sdk to support in order not to have to use support library then the answer is there is not such a thing. You will end up using a support library in the future because android api is always being updated.
If you do not want to use library supports then you need to develop apps to use only basic features including in API 1.

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.

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 Action compatibility from 2.2 to 4.2

I am trying to create an Application on Android and want to target apps all the way down to Android 2.2.
I am a bit confused on how to configure the application
Min SDK: 2.2
Target SDK: 4.1
Compile SDK against: 4.2
This is the default config i got when i created a new Android Project.
Should i still need to use ActionBar Sherlock to support the older versions ?
Unless you are using any API's not available for lower versions, you will not require any additional libraries like ActionBarSherlock.
However, if you are using any specific API's and want to make them backward compatible, for example Fragments, ActionBar, etc then you can make use of the Support Library which supports a minimum API level of 4.
Quote from the Support Library Page:
Minimum API level supported: 4
The Support Package includes static "support libraries" that you can
add to your Android application in order to use APIs that are either
not available for older platform versions or that offer "utility" APIs
that aren't a part of the framework APIs. The goal is to simplify your
development by offering more APIs that you can bundle with your
application so you can worry less about platform versions.
ABS is an extension of the Support Library. This is from the ABS page Link: ActionBarSherlock:
The library will automatically use the native action bar when
appropriate or will automatically wrap a custom implementation around
your layouts. This allows you to easily develop an application with an
action bar for every version of Android from 2.x and up.
To summarize, if you are making use of API's not available in older SDK's, then you can use either of the two listed above. If you are not using API's specific to newer SDK's, you will not need ABS or the Support Library.
Min SDK = Least API you want to support ie., 2.2
Target SDK = API you want to test on. If not set will take default value as Min SDK. Usually target will be the Max API you want to support or the Latest API. This is to tell the Application to use the latest API Features, but if not possible allow backwards compatibility.
I never heard about Compile SDK
and you don't need any Support libraries if you are using only 2.2 API elements.
For something like Fragments etc.., which are not present in <3.0 API you must use Support Libraries.

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.

Categories

Resources