My project uses support library and library which i have added as dependency uses androidx.Can i build app without replacing my project's support library APIs with androidx?
I have already seen this answer but my question is opposite of that.
Using support libraries is not a recommended practice anymore, and you should migrate to androidx as soon as possible. Migration is easy, and Android Studio takes care of the heavy lifting for you.
Related
In my mind, androidx.* is optional for an Android project, I find that androidx.* is necessary when I update to Android Studio to 3.4.2.
See the Image. So androidx.* will be standard, right?
Image
AndroidX is a major improvement to the original Android Support Library.
Like the Support Library, 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.
Here
If your app currently depends on the original Design Support Library, you can make use of the Refactor to androidX option provided by Android Studio. Doing so will update your app’s dependencies and code to use the newly packaged androidx.
New Design support library requires andriodX migration too! You should consider using androidX for your future projects! Here
Add the library to the in your build.gradle(app-level) dependencies section:
implementation 'com.google.android.material:material:version' Latest Version
you can still make app absolutely..androidx is just a extension of the android library itself...so if you completely know android libraries,you can make any app,same as what androidx can,as the name implies,its a "support library" so without using it you can still make full blown app...again its a support library to make your life not worrying of compatibility for your app,but if your really know android programming,your dont need androidx.infact making app in android(not androidx)is better because you dont need transitions in the future same to what happen to those who rely on android support libraries..
I have to set up pagination for my android project.
But I'm a little bit confused since there are two different libraries with same class names AndroidArchitectureComponents and AndroidX.
and in the documentation too I didn't found differences, methods are also the same.
What is the key difference between both of them?
androidx is a new package structure rolled out by Google. Unlike the Support Library, AndroidX packages are separately maintained and updated. All new Support Library development will occur in the AndroidX library. So the androidx paging would contain new improvements and packaging structure would be different from the normal one.For using androidX packages you will have to migrate your project to androidX. Refer : [https://developer.android.com/jetpack/androidx/migrate]
I have Android App that uses support library versions 27.1.2. I want to consume a library written using Android X (api 28).
There are few issues with name spacing of the library versions.
Example ...
The library has a Dialog that I want to use with the api
Dialog.show(androidx.fragment.app.FragmentActivity activity);
However all my activities are using
android.support.v4.app.FragmentActivity
and the compiler does not like this.
Currently it is not an option to upgrade my project to latest version, so please no upgrade answers, unless this is the only solution.
Is there a way to resolve this incompatibility issue?
Thanks in advance.
This is not possible. To use any library that depends on AndroidX, your project must migrate your whole project to AndroidX.
Note that the reverse is supported - you can use libraries built with Support Library in projects that use AndroidX (that's the purpose of the android.enableJetifier=true flag).
AndroidX[About]
Consumer support -> Producer androidX - not compatible.
You should migrate your consumer to use AndroidX. Android Studio menu -> Refactor -> Migrate to AndroidX...
Consumer androidX -> Producer support - compatible.
Consumer's gradle.properties in addition to use androidX should enable Jetifier[About] which converts support to androidX
android.useAndroidX=true
android.enableJetifier=true
[Mix AndroidX and support in a multi-module project]
There is a way
Jetifier tool migrates support-library-dependent libraries to rely on the equivalent AndroidX packages instead. But when you put -r flag, it makes him to the exactly reverse process.
From developer.android.com
If you pass the -r flag, the utility runs in reverse mode. In this
mode, the utility converts AndroidX APIs to the support library
equivalents, instead of the other way around. Reverse mode is useful,
for example, if you are developing libraries that use AndroidX APIs,
but also need to distribute versions that use the support library.
Anyway, I will suggest to use it only in a very critical needs.
I have written a library that supports AndroidX.
How can I use this library with migration if I don't want to migrate my project to AndroidX yet?
Many popular libraries that have supported AndroidX say something like "If you wish to use this library now, migrate to AndroidX or use old versions". So I don't think you can use an AndroidX library with an non-AndroidX project.
Support libraries and AndroidX have different package name space. In the future, new changes in the AndroidX libraries won't be available in the support libraries.
Migrate the project to AndroidX or downgrade the library to support library.
Update
As mlyko's comment mentioned, jetifier has a reverse mode:
https://developer.android.com/studio/command-line/jetifier#reverse_mode
In this mode, the utility converts AndroidX APIs to the support library equivalents, instead of the other way around. Reverse mode is useful, for example, if you are developing libraries that use AndroidX APIs, but also need to distribute versions that use the support library.
I haven't tried it but it seems promising.
You could try the jetifier-standalone in reverse mode, to provide build with support libraries. Therefore you'd have 2 releases of the library - androidx and support lib.
This question already has an answer here:
How do make sure there is no conflict of "v7 appcompat or support" of my library when any application uses my library?
(1 answer)
Closed 6 years ago.
I have a android library with com.android.support:appcompat-v7:23.0.1 dependency in the gradle with compliedSDK of 23
I have following doubts
case 1) Say any applicaion with different version com.android.support:appcompat-v7:23.3.0 uses my library.
which version does the android take? Lower one or Higher one? How do i see it?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
case 2) Say any applicaion with different version com.android.support:appcompat-v7:25.0.1 or com.android.support:appcompat-v7:24+ and different compiledSDk(24 or 25) uses my library.
I know that The support library should not use a different version than the compileSdkVersion.
How does the android merge the support libraries now? (Since the support library version(appcompat-v7:23.0.1) of my library is different from that of the application's compiledSDK (25) )
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
Anyone Please clear my doubts
which version does the android take? Lower one or Higher one? How do i see it?
When building library you put the dependency explicitly in build.gradle. The same is done by the creator of app, that uses your library as a dependency declared in his build.gradle. If the creator explicitly declares support library as a dependency, that version is taken (regardless the versions declared by dependencies). If he does not do that, the highest version declared by any dependency is taken (such support library is regarded as a transitive dependency).
Example: Your library uses appcompat-v7:23.3.0. The creator of app declared appcompat-v7:25.0.1. Simple case: appcompat-v7:25.0.1 is taken.
Example 2: Your library uses appcompat-v7:23.3.0. The creator of app does not use appcompat-v7. appcompat-v7:23.3.0 will be in output app.
Example 3: Your library uses appcompat-v7:23.3.0. Another library uses appcompat-v7:24.1.0. If the creator does not explicitly declare appcompat-v7:xx.x.x the version appcompat-v7:24.1.0 will be in output app.
Hope you understand.
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
You can't assure that. That is why you should always put the highest version of support libraries in the library. I can't even assure you the support libraries maintain backward compatibility. Here is the example that they don't.
I know that The support library should not use a different version than the compileSdkVersion.
That is only a suggestion. However, you should conform to it, but you don't have to.