Should library depend on androidx or android.support

Question

I am writing android library that depends on lifecylce artifacts, and the question is: should my library depend on AndroidX version or legacy android.suport version of that artifacts?

I'm asking with target audience in mind.
As far as I'm concerned, there is Jetifier that allows apps on AndroidX use libraries on android.support, with some build-time cost.
But what about apps using legacy support libraries? Is it possible for them to depend on AndroidX-based library using some... anti-jetier tool?

According to expanding target api level requirements article, targeting api 28 will be required at the end of 2019, and probably (I justs extrapolating) targeting api 29 will be required at the end of 2020. So, technically, it is possible for apps with legacy dependencies to survive till the end of 2020.
I did not find any statistics about apps migration to AndroidX, can your share it if you have some?

Answer 1

I too am building a library. Unfortunately, I have yet to find an acceptable solution for the issue of releasing a library that depends on AndroidX and implementing it into a project that still depends on android.support.

I am in the process of ripping out AndroidX and reverting to android.support in the library being built because of the issues it causes the consumers of the library. I wish this wasn't the case, but there does not seem to be another way as of today.

Answer 2

you could use jetifier manually to reverse jetify. I was able to manually take an aar, reverse jetify it using the source code at https://dl.google.com/dl/android/studio/jetifier-zips/1.0.0-beta04/jetifier-standalone.zip . Although, i dont think this can be integrated into the CI servers, this is a temporary workaround until google adds support for reverse jetify.

---

./bin/jetifier-standalone -r -i ~/Downloads/jetified.aar -o reversejetified.aar

---

thanks to https://ncorti.com/blog/jetifier-reverse