When I want to create an Android app that can use the recent supported features of Android, I use libraries like:
appcompat_v7
support_v4
What I haven't been able to determine is what is the earliest version of Android that an appcompat_xxx or support library can actually support. Where do I find this information?
It's all in the name - appcompat_v7 supports API 7 and later, support_v4 supports API 4 and later.
It's also clearly stated in the docs for each library, for example:
This library is designed to be used with Android 1.6 (API level 4)
and higher.
http://developer.android.com/tools/support-library/features.html#v4
Also, although this isn't always required, you should try to match up your targetSdkVersion with the respective version of the library. For example, if your targetSdkVersion is 19, you should use com.android.support:appcompat-v7:19.+
To be clear: the support libraries, as dictated by their name, are designed to support a minimum API level. Meaning - they can be safely used on devices running that API level, as well as devices on any later API level. If you attempt to use appcompat_v7 on a donut device (API level 4), or the leanback-v17 library on a Jellybean 4.1 device (API level 16), your app will likely crash with something like a ClassNotFoundException.
The libraries were originally supposed to provide the functionality of newer API levels to the older API levels, such that you could write nearly the same code and leverage the latest platform paradigms in a single APK that would support old and new devices.
Fragments are a perfect example of this. The Fragment class was introduced with Honeycomb (API level 11). Google then released the support_v4 library which contained a back-ported version of the Fragment class and it's respective APIs. Again, as dictated by it's name, this library could be safely used in an app that supports all the way back to API 4. If you install an app using the v4 library on a API 3 device, it will crash. If you install it on, say, an API 8 device, it will work as intended.
Perhaps you're getting caught up on the seemingly delicate nature of relying on a file name to specify the min sdk version - now this is a bit of a guess, but when the v4 library was first introduced, it was just a .jar file. Meaning, you could add it to your app's classpath, no matter what minSdkVersion you use, and it would compile without complaining. MY guess is that Google wanted to explicitly name these libraries using their minimum SDK version to avoid developers trying to use them in apps that are meant to support early API versions. Aside from their docs, which again very explicitly answer your question, the filename was perhaps was a risk mitigating approach to help developers who don't read the docs.
Fast forward to 2014, many of these libraries either come in the form of .aar files (via Gradle), or you need to import them as projects. This is because these libraries now include resources such as images and themes, which cannot be packaged into a .jar file. An added benefit here is that this allows Google to include an AndroidManifest.xml with the library which specifies a minSdkVersion. At compile time, the build tools' manifest merger will complain if your minSdkVersion is lower than the minSdkVersion specified in any included library projects.
Related
I'm just getting into Android development. I'll be using Xamarin.Android. Reading into this, and having toyed around with Android in the past, are AppCompat frameworks/libraries still necessary? I ask this because it seems that from Nov 1, 2019, all new app submissions require at least API Level 28 as the minimum, so what use would it be to include all these bloated appcompat libraries?
Correct me if I'm wrong or mistaken.
#wpa
AppCompat should not be necessary if you are starting a fresh new project. You can start using AndroidX libraries which will provide backwards compatibility. The requirement being mandated starting Nov 1, 2019 is not for the minimumSdk. It is for the targetSdk version. These are different. You can still have your minimumSdk to the lowest you want, but your app should target at least Android 8.0 (API level 26).
Please follow the link below for detailed information.
https://developer.android.com/distribute/best-practices/develop/target-sdk
Google requires set targetSdkVersion api level in 28 for currently apps in the Google Play Store, but if you are starting a new project, surely will start by default withe the latest android version 29.
Feel free of choose the minSdkVersion in your project.
targetSdkVersion: normally the latest android version available (for example API 29/Android 10)
minSdkVersion: the min Android SDK that your application can run on (for example since 21/ Android Lollipop)
androidx
Other hand, it is still necessary to support previous versions if your plan is to reach the majority of users using new features in old versions of android
However, according to android documentation, developers should be start projects using androidx libraries and not use appcompat library anymore.
Artifacts within the androidx namespace comprise the Android Jetpack libraries. Like the Support Library, libraries in theandroidx namespace ship separately from the Android platform and provide backward compatibility across Android releases.
https://developer.android.com/jetpack/androidx
https://developer.android.com/jetpack/androidx/versions/
https://developer.android.com/jetpack/androidx/migrate (if in the future you find an old project that needs to migrate to androidx libraries)
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).
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.
I found a lot of online resources regarding targeting a variety of Android versions from my min-SDK version up through my target-SDK. This includes doing things like reflection or wrapper classes to test for the advanced functionality that may be available only in the higher Android version I'm targeting.
What I cannot figure out is how to get this to work in Eclipse. Specifically, the problem I am running into is that if I choose a Project Build Target that matches my target-SDK then Eclipse will not allow me to select an AVD with a lesser Android version for debugging/testing. Therefore I can't test the reflection tricks to make sure they work for backwards compatibility. The alternative of choosing the lowest Project Build Target means that I cannot refer to any of the advanced classes/methods available only in the newest Android versions without getting compiler errors.
What is the correct way to organize an Eclipse Android project to make targeting multiple versions work?
(P.S. I'm trying to use the old, undocumented calendar access tricks alongside the new ICS calendar API.)
Thanks!
project.properties includes your build target. set this to android-15 (latest API).
In the manifest set min-sdk to the minimum sdk you are supporting for example 8 (froyo). This is the minimum API and it will only launch on devices with API bigger or equal than this.
Make sure you test all API's which are lower than the target as some methods might not work. An example for this is the ActionBar introduced in Honeycomb - it will not work on API's lower than Honeycomb.
My question popped up a very similar question, this one. But the accepted answer (the single one) points to another question, this one, which doesn't really answer the original question.
The Android documentation states:
The Build Target specifies which Android platform you'd like your
application built against.
But what does it mean really?
The way I see it, I can have the minSdkVersion=4 and targetSdkVersion=10 but set the build target to API Level 4. What will happen? Eclipse assumes I'm developing for API Level 4 and any method, constant or whatever defined on API Levels above 4 will not be available to me. If I try to use them, the application will not compile. I'm aware of this.
But let me put it differently...
Let's say I have only set minSdkVersion=4, targetSdkVersion is not defined. I am also not using any method or constant only available on API Levels above 4. In this situation, does it really matter the build target I pick? Will it have any impact in the final APK?
Build target
Build target is the API level Eclipse/IntelliJ/whatever IDE you’re using is building against. This
is simply used by the IDE/build system to know which APIs to offer
you. If you build against API level 14, the application will still be
able to run on API level 7, providing you don’t call any APIs that are
not available on API level 7.
I mostly set the build target to the same as android:targetSdkVersion,
though this is not required.
Source: http://simonvt.net/2012/02/07/what-api-level-should-i-target/
If you use a higher build target then you can write code that will work on earlier versions by using reflection, for example. If you want to be restricted to just API 4 then don't worry about the build target.
For an example of targeting earlier api levels when compiling for a higher one you can look at this question:
Android: how to code depending on the version of the API?
The way I see it, I can have the minSdkVersion=4 and targetSdkVersion=10 but set the build target to API Level 4. What will happen? Eclipse assumes I'm developing for API Level 4 and any method, constant or whatever defined on API Levels above 4 will not be available to me. If I try to use them, the application will not compile.
When you set the build target to API level 4, Eclipse will not let you compile any methods you use higher than that, because it strictly uses API level 4. However, when you put the build target to a higher API level, in your case API level 10, your APK is available for use for phones from API level 4 to 10.
The 2nd question's answer answers your question, that is the Android build target, both minSdkVersion and targetSdkVersion affects the range of users that are able to use your application.
EDIT:
Since you're not going to define targetSdkVersion and you're not using any features which is above API level 4, the targetSdkVersion will be the same as minSdkVersion. Whatever build target your chose will automatically be specified. It doesn't really matter which build target you pick unless it is below API level 4
From Android documentation of 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).