Question:
When should be used android.support.* packages, and when android.*?
Would love next facts considered while answering:
Not required to support old android versions
ViewPager and other features available in support-only are desired
If it can always be done in support, then why bother with native library?
Can support/native library be disabled in IDE, so that I stop accidentally importing wrong packages?
Support library is used to make your app capable to run on android lower versions also.
You should definitely read the documentation.
android.support.* is used to support older devices that does not have new Android API.
For example, Fragments were introduced from HONEYCOMB, that's why you should use support package, if you are planning to support Android 2.*.
Related
Should I select the Use legacy android.support libraries option when creating a new project? What will happen if I don't select this option?
A little context:
Up until recently, almost every Android app used the android.support libraries so that they could use features introduced on new Android versions also on older Android versions. You can read about it here: https://developer.android.com/topic/libraries/support-library
Recently, Google announced that there would be no new releases for the support library, and that instead the support library would become a new library called AndroidX. Here's their announcement:
With the release of Android 9.0 (API level 28) there is a new version
of the support library called AndroidX which is part of Jetpack. The
AndroidX library contains the existing support library and also
includes the latest Jetpack components.
You can continue to use the support library. Historical artifacts
(those versioned 27 and earlier, and packaged as android.support.*)
will remain available on Google Maven. However, all new library
development will occur in the AndroidX library.
We recommend using the AndroidX libraries in all new projects. You
should also consider migrating existing projects to AndroidX as well.
So all Android apps should now aim to use AndroidX, instead of the old support library. When you create a new project in Android Studio, it will by default use AndroidX, but you can still choose to Use legacy android.support libraries if you wish, by clicking the checkbox you found.
Most of the time, you probably want to use AndroidX
With the release of Android 9.0 (API level 28) there is a new version of the support library called AndroidX which is part of Jetpack. The AndroidX library contains the existing support library and also includes the latest Jetpack components.
Support Library
If you check this option, the android studio will use android.support library otherwise it will use androidx library.
the android.support library is deprecated, so you don't need to check this option.
The Support Library is a static library that you can add to your Android application in order to use APIs that are either not available for older platform versions or utility APIs that aren't a part of the framework APIs. Compatible on devices running API 14 or later.
Check the artifact-mappings and also check support-library
When developing apps that support multiple API versions, you may want a standard way to provide newer features on earlier versions of Android or gracefully fall back to equivalent functionality. Rather than building code to handle earlier versions of the platform, you can leverage these libraries to provide that compatibility layer. In addition, the Support Libraries provide additional convenience classes and features not available in the standard Framework API for easier development and support across more devices.
Our app uses now a min Android API 19, so we don't really need the support lib anymore, only for the ViewPager would we need an alternative. But the question I was making myself is if it is better to use e.g. DialogFragment from the support lib rather than the one from the framework itself? I was thinking in a possible advantage of doing so where for example the code in the support lib has bug fixes, so if I use it I would have the fixes also on older Android versions, if not then I may get some errors/bugs etc. on older versions, have you some thoughts about this?
IMO it's wise to continue to use the support library versions anyway regardless of your minSdk version - the support library is regularly updated and likely has various bug fixes compared to the shipped platform versions.
As you say as well, it means that you can rely on one implementation.
The only upside that I can see to dropping the support libraries and using the platform implementation is a smaller APK/lower method count, which may or may not be worth it for you.
Yes. That's one advantage of using Support library API over the SDK one - you might get bug fixes in the support library which fixes on all supported Android versions.
And we can choose the version of the support library. If there are some compatibility issues in the latest version, we can use the old version of support library as a temporary solution, even targeting the latest SDK version.
I am developing an app that work from min sdk version 19 onwards. i'm currently using AppCompatActivity, support v4 fragments and support v7 lib..
Is this actually needed for this app?
Can I avoid all support libs..?
Does that increases app performance?
No, you can't avoid all support lib.
It will not affect on your application performance. You can definitely avoid adding third party lib in your project till it is necessary to add.
Please read this link. It will give you more detail about Android support libs.
http://martiancraft.com/blog/2015/06/android-support-library/
I have a problem while building my android project due to some missing android-support-library (i.e: android-support-v7.jar) so to fix it I had to add an Android Support Library from eclipse wizard. However I was surprised that my $android_sdk_home/extras/andoird/support/v7/appcompact/libs contains android-support-v4.jar and android-support-v7-appcompat.jar. Is that normal?
If I understood you correctly, you're wondering if having both v4 and v7 support libraries is normal. It is perfectly normal as they have different purposes. Basically they provide you with widgets and APIs to be used respectively in API levels 4 and 7 and beyond. They also provide different interfaces.
You can read about it here in more detail: https://developer.android.com/topic/libraries/support-library/features.html
I am not fully certain that I am not making any mistakes when setting API level when developing under Eclipse so here are some examples which I am not 100% certain about.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
Yes this practice is correct and is done to ensure support for the latest android versions.
When you set a minSdkVersion, then that's thr lowest version of Android your app will support and compiling with ant/gradle will show errors ehen you will use methods introduced in newer api levels for an older one.
Deprecated means that another method has replaced this one and that this one will spon be removed from the Android source code, so developers are encouraged not to use them. But yes they will work until they remain in the source.
The android.jar is a dependency of the methods and stuff included in the android OS, stuff that you'd be able to call and no I don't think framework.jar plays a role in this.
All external libraries are referenced and added to the apk. BUT only some of the google ones, those that are not primary. (Take a look at the gapps packages, that'll give you some specifics. Link: http://goo.im/gapps)
I hope I got this right and helped you to understand.
When developing Android app in Eclipse I always set BuildProjectTarget under Eclipse and android:targetSdkVersion in the manifest to the latest available Android version. Is this practice correct? NOTE:I do set android:minSdkVersion according to the project (usually value is 10)
Yes. That way you ensure you're always using the latest build sdk.
I know that doing the above will trigger Eclipse warning about unsupported API when using something not available in version under android:minSdkVersion (for example using fragments without support library) are there any examples when these shouldn't be trusted and what will happen if you build the project using Gradle/Ant script or manually?
Just make sure that older devices will not get to that part of the code, using Build.Version.SDK_INT. This will give you the current SDK of the device.
What would happen if I set BuildProjectTarget and android:targetSdkVersion to for example 16 and then use some deprecated API like WebView setCertificate() (which was deprecated in API level 17). Will this method work on all devices or just those up to Android 4.1, will it crash the app or just be ignored?
Deprecated methods will continue to work, but better alternatives are available. When you have the option to use that better alternative, use it. When you're supporting devices that don't have this alternative yet due to older versions, continue using the deprecated method. You might have to do some if else branching based upon the Build.Version.SDK_INT value.
I know that Eclipse uses Java library android.jar from SDK/platforms folder and that when on the device app links to that library stored on device but what I don't get is are there multiple versions of this library on android phones or just one (the latest for that android version) ? Also does a version of framework.jar play a role in this?
The newer devices contain the code of the older devices. Therefore it is not necessary to keep references to other versions.
What happens with the libraries when you use something like google_play_services? Are these packed into the apk or reference the library that is already on the device? I know that when you use Facebook sdk the jar gets packed into apk but don't know are these google libraries different?
The class files in the jar will be packaged in the .apk. The Google Play Services on the device communicates with your app using those classes.