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)
Related
I would like to use AndroidX if I can (instead of the support library). I read that it is backwards compatible, and people have been using it with API 21. Due to some limitations with one of our vendors... our app is built to only work on Android SDK 5, API 21. When I search for AndroidX packages in the Nuget Package Manager in Visual Studio.. the Dependencies listed are MonoAndroid.Version=v9.0. Does this mean I cannot migrate to AndroidX for my project?
AndroidX can work on API 21. MonoAndroid.Version=v9.0 is not indication of the API level, this is Microsoft's version number that has nothing to do with Google SDK version numbers.
So yes, you can migrate, I have migrated one project that targets API 21.
If I have a published android application that uses the android support libraries, and I then migrate my app to use androidx (making as few changes as possible), does this impact the needed OS on a device in order to run my app?
The AndroidX overview (https://developer.android.com/jetpack/androidx/) states that "AndroidX ships separately from the Android OS and provides backwards-compatibility across Android releases. AndroidX fully replaces the Support Library by providing feature parity and new libraries." but I'm not sure that this answers my question.
AndroidX is designed as replacement for current support libraries. So it has same minimum api level, since version of support library 26.0.0 minimum api level is 14 (Android 4.0).
So if you had support library below 26 version in your project, AndroidX will impact on needed OS, in other case not.
I recently started with android development. I don't understand what is the point of specifying minSDK, when I use appcompat?
In my project I've set minSDK to api 19, targetSDK to 19, compileSDK to 19, buildTools to 23.0. And Bam, Android studio automatically linked the appcompat v7-23.0.1. What is the point of setting minSDK to 19 if I can run the app even on api 7 because of the appcompat?
There are still a lot of features in Android introduced on higher versions. For example, API 14 introduced a lot of new features that weren't available before (you can see this page for a list of what's new in API 14), but this is just an example. You can read further about development considerations when deciding minimum and maximum SDK versions here.
Using a higher minSDK also means you are reducing your audience (i.e. how many people can buy that app). You can see a chart showing distribution for versions of Android here.
To answer your question, unless there are specific features from API 19 onwards that aren't in any support libraries, there is no point in keeping it at that - I would lower it to API 14, which means that you have access to most features in Android, as well as any support libraries for any other features you want to add in your app.
What is the point of setting minSDK to 19 if I can run the app even on
api 7 because of the appcompat?
you can not all the time.
where appcomapt fills gap for only a lot of APIs, there are still a lot of APIs which are not supported on lower versions even by appcompat or any other support library.
check documentation for more details.
Is it possible to Support all Android Versions, that exists? How does that work in Eclipse?
You could do that, but you will probably eventually choose not to. Because in the older versions, you don't have all possibilities you now have in the latest version of Android. The API in older versions is very limited.
If you want to do that, you could just use the minSdkVersion in your manifest, that will set the minimal Android version you need to have to run the app.
I suggest you have a look at the following site http://developer.android.com/guide/practices/compatibility.html
Edit: You only need to download the Android version you are locally building against. For example if you say your minSdkVersion is 11, but you're locally building with version 15, that's perfectly okay. You don't need to do anything else for supporting the previous versions. Of course you will need the support libraries too.
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.