I am getting started with Android. I am quite confused with what support library actually does . I am following a book and in the book it is mentioned that :
If an app is installed on a minimum SDK system, and our Java code
contains any calls to classes that are not present in minimum SDK ,
our app will crash
I read an article about support libraries here:
Tutorials Point
If Support libraries provide backward compatibility, doesn't it mean when they should prevent app crash?(may be by wrapping up those newer classes and making them backward compatible). What does support library actually do? Please explain.
When should I use the Android Support Library?
As new versions of Android are released, some style and behaviors may change. 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.
What does support library actually do?
There are many devices still running in Jelly bean and below versions. So you need to give the same importance for old and new devices While making an app. Otherwise, the App in old devices looks dull when compared to new ones. That may affect the app’s market. To avoid this trouble, Android introduced the Support library. These are set of code libraries provides backward compatibility
Example:
Fragment API was introduced in API 11 HONEYCOMB .android.app.Fragment is the Fragment class introduced in API 11 and android.support.v4.app.Fragment is the Fragment class in the android support library,
If you want to make your app use fragments, and want to target devices before API 11, you must use android.support.v4.app.Fragment. However, if you want only targeting devices >=API 11 ,you can use android.app.Fragment.Therefore, android.support.v4.app.FragmentManager is used to deliver newer features to older platforms.
For more info about android support library:doc
1.Suppose you want to create an app which runs on platform comes after marshmallow.
then minimum sdk of your app will be marshmallow.
2.While creating your app you call a method which is present in oreo or later version then you app will have chances to crash on marshmallow and nougat.
Related
The documentation for getting your app to work with Android auto direct users to use MediaBrowserServiceCompat. Because my app doesn't support pre-APIv21 I didn't use the compat version I used MediaBrowserService.
My main question is: can not using MediaBrowserServiceCompat (over using the MediaBrowserService) cause problems getting apps to work with Android auto?
My other question is: is there a reason to use the compat libraries other than supporting legacy devices (pre APIv21)?
No, it should not be a problem. But one thing to be noted here is Compat library is not a way to support exactly pre APIv21 devices, instead according to android documentation: "it is a standard way to provide newer features on earlier versions of Android or gracefully fall back to equivalent functionality".
To understand it, suppose after some years when android P/Q/R gets released with some new features that previous android versions didn't had, so to have support for these features on those api devices an equivalent compat class in compat library will be provided. So you can't say that compat libraries are for exactly pre APIv21.
Any way if you are not targeting older devices then you can ignore compat library.
I'm working with Xamarin.Android.
Appcompat is actually necessary for use material design because the nougat package (Android.support.design) requires it.
But why, for example, if I work only with API 27, I must add the AppCompat package? In my toolBox i've not the floatingActionButton, NavigationDrawer etc.. so I must add this packet to unlock them.
What is exactly this package? I've read on the web that this package works with backward compatibility but I only work with new APIs, so why I must install it?
Thanks.
AppCompat should add the functionality of the latest API to older APIs when needed. For instance, lollipop added the CardView class, which can be used in older Android APIs when AppCompat is used, with some minor differences (some of the Android L animations may not apply on older versions of Android for example). It is recommended to use AppCompat in most cases since more users will be able to run your app when you do (depending on your MinSdkVersion). If you want to know what classes you can access in AppCompat, you can take a look at the features here:
https://developer.android.com/topic/libraries/support-library/features.html
The Xamarin.Android.AppCompat is just what it says. Its a library for App Compatibility for backward compatibility for previous versions of Android and more specifically this version (v7) brings support for Action Bar support. Read more here :
AppCompat
They are libraries used for accessing the latest features of an Android OS version. It is backward compatible by the way.
I am building an app using Android Studio version 2.1.
I am testing it on a Lollipop device and a marshmallow one.
I was suggested to use support libraries, and I would like to make sure that it runs smoothly on Jelly Bean devices too.
I have looked it up, but can't quite understand if using v4 o v7 guarantees Jelly Bean compatibility (I am assuming it does, but not sure).
This is the first app I am developing and I just realised that I mistakenly used support versions in some activities, and native in others. I am fixing that.
Is there any tool which analyses all the code and then determines the earliest Android version that can run my app? Possibly giving suggestions on changes to make the compatibility broader?
All the answers I found so far confused me, they possibly require knowledge I don't yet have. I am a Java developer quickly trying to put together an app for a start up.
The minVersion in your manifest or gradle file determines the minimum SDK version that can use it. If you lower that number, any API call that doesn't exist on that version will cause an error or warning. Fix them.
BTW, KitKat is 19. So to have KitKat as the minimum SDK you don't need to use any support versions most likely. The best reason to do so is that it will provide a more consistent interface going forward- fewer version specific oddities when using support versions.
In Android support library docs about android.support.v4.os:
Support android.os classes to assist with development of applications for android API level 4 or later.
"Or later" means API 5,6,7 etc.? But a device running API 22(latest at the moment)
will automatically support older devices?
I don't quite understand it - it means, I should use this class to make old API 4 devices use my modern API 22 app? Or should I use it to make new phones support old devices
When should I use this numerous support.v17, support.v13 packages?
What is backward compatible?
Can you explain typical situation?
"Or later" means api5,6,7 etc?
It means that this code can be used in devices with a old version of Android (api7= Android 2.1, api=8 Android 2.2.... api14 = Android 4.0)
but a device running api22(latest at the moment) will already automatically support older devices?
A device can run only a version of Android. If it is running api22, it means that it has Android 5.1
I dont' quite understand it - it means, i should use this class to make old api 4 devices use my modern api22 app? or should I use it to make new phones support old devices
It means that you can use this library to backport some features introduced with the last api (for example 21) to old devices running a previous api level.
1.When should i use this numerous support.v17, support.v13 packages? 2. what is backward compatible?
You can use them, when you need them... If you would like to use the Google cards you can use the v7 cardview library for example.
As described in the official link:
Each Support Library is backward-compatible to a specific Android API level.
For example the
support v4 : minSdk=4
v7 appcompat library: minSdk=7
v7 recyclerview library: minSdk = 7
v7 CardView library: minSdk = 7
can you explain typical situation?
API21 introduced a new widget, the Toolbar. This widget can be used only in device with API >=21.
With the appcompat rel.21 (a v7 Support Libraries) you can use the Toolbar (pay attention to the package) to implement your Toolbar in old devices running API>=7.
SO here is my understanding of the purpose of importing fragment library(the v4.jar).
Because the developer wants to use and follow the new Fragment's way of coding, but using this will result compatibility issue on older devices that runs on android 2.xx, therefore, in the project that uses fragment, the developer has to import the v4.jar library so that the older devices know what fragment APIs and are able to call them in the app.
If this is correct, I suppose after importing the library, the android:minSdkVersion should be able to set to older version such as 8 (93% of the market), not l0, because the project had already import the library.
But When I am using the method from the fragment, for example, the instantiate method, I got this error:
Call requires API level 11 (current min is 8): android.app.Fragment#instantiate
So apparent the sdk wants me to switch my android:minSdkVersion to 11, but then what is the purpose of importing the library? And by doing so older device that running on android 2.xx will not be able to use this app.
Can someone explain this issue ?
It sounds like you're importing the wrong Fragment library.
This one requires API level 11 (Android 3.0):
http://developer.android.com/reference/android/app/Fragment.html
This one, as available in the support library, requires API level 4 (Android 1.6):
http://developer.android.com/reference/android/support/v4/app/Fragment.html
Also, you should be aware that you need to use the FragmentManager available in the support library.
There are no drawbacks to using the support Fragment APIs on Android 3.0+.