Sorry if this may seem trivial, but all Google gave me were links on how to add the support library. What is the purpose of the support library? For example, I had to use a CursorAdapter, but there were 2 different libraries that had it, android.widget and android.support.v4.widget. What is the difference between the two?
Thanks!
Here an excerpt taken from Understanding Android Support Library article, kudos to Josh Hight.
Why?
One of the great strengths of the Android platform is its support for a huge number and variety of devices. From your handset, tablet, and smartwatch to your television, car, and beyond, Android wants to be the all-purpose mobile computing platform. In terms of numbers, this approach has been very successful – there are likely more than 20,000 distinct devices at the time of this writing. That’s far more than any competing platforms.
Supporting all these devices, though, poses a couple of challenges. Users expect apps to function consistently on every device, despite significant differences in hardware and software. Meanwhile, because of unique challenges in delivering Android software updates to users, developers cannot always depend on users having access to the latest Android releases. In fact, developers should anticipate most of their users to be running releases that are 18 months old or older.
Without help from the Android team, developers would be forced to make some pretty ugly compromises in order to support most of their users. Fortunately, the Android team recognized that accommodating older devices and releases was strategically important. However, doing this in a way that doesn’t hamstring future releases presents an architectural challenge because the Android APIs obviously need to evolve over time. How can important new APIs be made available to the majority of Android users and not just those with newer devices lucky enough to run the latest releases?
The answer is one of the most important and peculiar design decisions made by the Android team: the Android Support Library.
When should I use the Android Support Library?
You should use one of the support libraries when you need specific framework features that are newer than the minSdkVersion of your app or that are not available in the standard framework.
However, Google considers the general use of the support libraries to be a best practice, even if not necessarily required.
Excerpt from Support Library:
Support libraries allow apps running on older versions of the Android
platform to support features made available on newer versions of the
platform. For example, an app running on a version of Android lower
than 5.0 (API level 21) that relies on framework classes cannot
display material-design elements, as that version of the Android
framework doesn't support material design. However, if the app
incorporates the Support Library's appcompat
library,
the app has access to many of the features available in API level 21,
including support for material design. As a result, your app can
deliver a more consistent experience across a broader range of
platform versions.
Related
Given an android app that many of its features are based on APIs that is from the latest android version (highest API level), like andvanced animations and notifications.
Now, this app needs to be comptatible with older android versions (lower API levels).
What is the best practice to do that?
Possible practices can (maybe) be:
Refactoring the entire app while compromising on more basic functionality. (then what? publish both versions?)
Somehow importing the high APIs we are using. (is it even possible?)
including both high and low API implementations and getting the app to figure out in run-time which implementation to use.
How google provides new android features to be available in older API levels via support librarys?
i wonder if the newer android API features like picture in picture,notification channels can be used
For those features specifically? No. The vast majority of the work for those features is done outside of your app and any code that your app links to. That work is done by core OS processes.
can i include the code to be used for this features to work in lower API versions
For those features specifically? No. Again, most of the work is done outside of your app.
Some features in newer Android versions can be "backported" to older versions. Mostly, that is for features that are purely implemented in code that your app links to. Google offers backports of some features as part of the Support Libraries. Other features might be backported by other developers, such as my backport of Android 7.0's network security configuration. Sometimes, the changes are just too complicated to backport, or nobody has "had the itch to scratch" to write the backport.
Talking about the two picture-in-picture (PIP) and notifications channel references you have given
Those are introduced in Android O and supposed to use from to above API level and won't support and unfortunately, there are no support libraries for this feature.
And for notifications you don't need channels it's another feature that Android has in API 26 otherwise your notifications may be dropped by the system to avoid we use notifications channel otherwise for the back support we don't need such requirement.
But other features supported are available as Android Support Library
Here is full list of API and features introduced in Android O
It depends upon the feature,if it involves only software implementation then already many developers create ports or workarounds for such things using native components already available
This may differ case to case and depend on many factors including jvm limitations,etc
I am confused on the purpose of the Android support library and when it is needed. It is my understanding that the major plus of using the support library is for Android to implement themes and UI features on its own in older versions without the need for the developer to explicitly define them. One of these key UI features is the Action Bar, which was introduced for tablets in Honeycomb, then added to the entire platform in Ice Cream Sandwich.
That said, let's suppose I want to develop an app that targets KitKat (the most recent API at the time of writing), but I only want to support back to API 16, the earliest version of Jelly Bean.
Jelly Bean includes the Action Bar, and there were few major UI changes between 16 and 19. Should I use the support library in this case? What benefit does it provide if I do use it? I am looking for an answer which explains the benefits of the support library, and an example use case.
Here is your answer—Always!
The following reasoning is copied straight from Big Nerd Ranch's Android Dev book. Emphasis mine:
This book uses the support library implementation of fragments over the implementation built into the Android OS, which may seem like an unusual choice. After all, the support library implementation of fragments was initially created so that developers could use fragments on old versions of Android that do not support the API. Today, most developers can exclusively work with versions of Android that do include support for fragments.
We still prefer support fragments. Why? Support fragments are superior because you can update the version of the support library in your application and ship a new version of your app at any time. New releases of the support library come out multiple times a year. When a new feature is added to the fragment API, that feature is also added to the support library fragment API along with any available bug fixes. To use this new goodness, just update the version of the support library in your application.
As an example, official support for fragment nesting (hosting a fragment in a fragment) was added in Android 4.2. If you are using the Android OS implementation of fragments and supporting Android 4.0 and newer, you cannot use this API on all devices that your app supports. If you are using the support library, you can update the version of the library in your app and nest fragments until you run out of memory on the device.
There are no significant downsides to using the support library’s fragments. The implementation of fragments is nearly identical in the support library as it is in the OS. The only real downside is that you have to include the support library in your project and it has a nonzero size. However, it is currently under a megabyte – and you will likely use the support library for some of its other features as well.
We take a practical approach in this book and in our own application development. The support library is king.
So... There will always be a support library because you will almost always have to support older devices for a variety of reasons:
Device owners may not be able to update to the latest version because:
Service providers and manufacturers are not bothered about updating a non-flagship type phone - costs money to regression test their bloatware on top of a new version of Android.
Some device owners (thankfully not all!) care very little about the Android version on their phone. Totally different situation with the Tinder app though.
Device owners may not have the resources to upgrade to a latest/newer device. App developers in developing countries probably face this issue. Google's Platform Versions statistics are not region specific, even though they probably should be!
Anyway, here is the gist: support libraries have the exact same functionality as OS/framework APIs and they have a compact size—since they have to be included in your APK, they don't increase the size very much. So we have established that there is no downside to using/including them. Now, the upsides are tremendous - look at the Fragment example above.
The Support Library is generally used when you want to easily support a wider range of OS versions with less version specific source - with it you can use features introduced in higher version of the OS on older platforms without having to worry and check whether this platform has that feature and do something in case it doesn't.
There are several versions of the support library - v4, v7, v8 and v13. They all add functionality that is introduced in the higher versions of the API then the version of the library. For example v4 may add functionality from API 5, 6, 7, 8... , while v7 - only from API 8 and above.
Other major feature of the libraries is that they are regularly updated so you may choose to depend on the support library for some feature rather than on the current OS version installed (which may introduce bugs in that feature).
Of course they have their downside too - the support library is an additional dependency for your project.
There is different version of the support library because each version contains new features not available in the previous ones.
On this page you can see each version with the modifications included.
http://developer.android.com/tools/support-library/index.html
The purpose of this support library it to give you access to features that the version you are targeting doesn't include. Is there anything in the latest API that you want to use but that the version you are targeting doesn't include ? if yes then you have to include the latest version of the support library (check before on the page above that the support library include what you need).
I find a good article at http://martiancraft.com/blog/2015/06/android-support-library/
It mentions:
Furthermore, in some cases, developers may think they have the choice
between framework and support implementations of a particular feature,
only to find out that support dependencies dictate that decision for
them. For example, the v7-appcompat library enables developers to use
Material Design UI features introduced in API 21. However, doing so
requires that all activities extend from AppCompatActivity, which
extends from the v4 support FragmentActivity. So, developers targeting
anything less than API 21 and wishing to use Material Design UI
features are forced to use v4 support Fragments, rather than framework
Fragments.
Google considers use of the support libraries a best practice, even if
not necessarily required. It includes v7-appcompat and v4 libraries in
most of its sample code as well as in Android Studio’s new project
templates. Google is clearly investing significant effort in these
compatibility libraries and expects developers to heavily rely upon
them.
I see a whole bunch of platforms / SDKs, everything from 1.x to 4.x.
Does this mean I have to build my app separately for all different versions?
My goal is to wrap my HTML5 web app and make it available as a native app in app stores.
You typically build against the latest SDK that you plan to support and test against. This usually means "the current SDK" and is represented in the manifest as "targetSDKVersion". Another value called "minSDKVersion" that indicates how far back you support in terms of the API level. Google maintains the API consistency across past versions of the SDK, so it's usually in your best interest to test against what is current.
However, in newer SDKs, there may be things that cause your app to look or behave differently, so when you update the SDK, tools, and targetSDKVersion, you may have work to do to keep your app looking like it belongs.
Usually you can write an application targeting android 1.6 and deploy it to every device which supports a higher API level. You can compile an application which targets android 4.0 and it will still run on 1.6 as long as you're writing code which doesn't depend on API which isn't present in 1.6.
Since there are a lot of changes since 1.6 there is a compatibility library which you can use. This library doesn't include the actionbar. Therefore you could use Actionbar Sherlock.
With these two libraries you should be able to write applications for 1.6 without having the pain to pass on new techniques.
If you still depend on leatest API features, you could request the API level on runtime and implement features for new devices only. You should avoid to ever use this API on old devices. You can compile it but it would crash on runtime if you do.
I plan on creating an application for users to view their stats of a game I am currently in the process of making but my question is like the title. I am not sure if phones with Android 3.0, Android 2.0 or lower can use the apps? If not, how would I work around this? Would I just not be able to use the new API features such as NFC etc? All in all, if I start developing with Android 4.0 SDK, will all android phones be able to use my app?
My understanding of android development, is that you can build against a lowest common denominator if you build a single package, and it will run on that version, and most likely any newer version. But not the other way around.
The compatibility library (which we're now just calling the support library) doesn't use any special magic to pull this off. You can check Build.VERSION.SDK_INT at runtime and use classloader guarantees to access newer functionality when it's available. Some examples are here: http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
We recommend taking a graduated approach to supporting different platform versions. Provide a simpler version of your UI on older versions and layer features on top as they become available. The link above gives some examples of how to do this, and we're going to continue expanding the support library with more *Compat classes that do the version checking for you when using newer features that may or may not be available on all devices you want to support.
Chris is right. However this can be limiting. What if you want to be flexible and use features of the 3.0 and 4.0 android in you app if the device you're running on has them and then gracefully fallback if they don't? Enter the android compatibility package. You can do development using really old api's (all the way back to 1.6) and still have access to new api features.