Better Android support

[gotson]

Closes #1378

• uses the Animal Sniffer plugin with Android signatures to detect signatures not compatible with Android
• updates documentation around Android usage and restrictions, some methods are not supported (i couldn't find a way to add support)
• bumps the stated API level supported from 24 to 26. Supporting everything in 24 would require many changes, 26 is probably fine for now.

[pavel-yazev-km]

@gotson looks great! Thank you very much.

I've tried to run animal-sniffer with 24, 25, and 26 Android SDK versions and see the difference.

Although I understand that dropping Android SDK 24-25 support helps to greatly reduce the incompatible surface, I'd take some time to try to make it possible to solve incompatibilities, to make it possible to keep the min API level at 24.

It looks quite doable because:

1. All java.time related issues (20% of all cases) can be solved by just adding a requirement to use Core Library Desugaring or another java.time backport in the app. java.time checks then can be ignored by animal-sniffer.
2. Some other calls can be replaced by matching overloads, like in case of [Android] BatchUpdateException constructor is not available #1378 (to replace long[] back to int[], without functional changes).
3. The rest of the cases will probably need a compatibility layer (a function that does the same but with available underlaying calls), which is a nuisance of course. But that's up to you to decide whether it is acceptable. Even if these substitutions are not accepted - we still will use the library with Android SDK 25 for several more years. So the less incompatibilities there are - the better for us.

What do you think? Would such a contribution make sense?

[gotson]

Hi,

i am not versed at all in Android dev, please bear with me.

1. • All java.time related issues (20% of all cases) can be solved by just adding a requirement to use Core Library Desugaring or another java.time backport in the app. java.time checks then can be ignored by animal-sniffer.

I don't quite understand what work would be required. Is that some work needed in the Android app, or in sqlite-jdbc ?

Would this prevent what i did when inlining functions like here ?

• Some other calls can be replaced by matching overloads, like in case of [Android] BatchUpdateException constructor is not available #1378 (to replace long[] back to int[], without functional changes).

I have already replaced those BatchUpdateException constructors, but you may be referring to other places in the code when lowering the API level ?

---

How would you feel about this:

1. merge this PR first
2. work on a separate PR to lower the API level for Android

We could get something out of the door for API level 26 quickly, and keep working in the background to lower the API level.

[pavel-yazev-km]

I don't quite understand what work would be required. Is that some work needed in the Android app, or in sqlite-jdbc ?

Desugaring is a way to backport features from newer Android JDK to an older JDK version (like java.time).
It is added as a library (almost) to an Android Project, but it is not present in headers used by animal-sniffer.

So if you add a line that states: works with API 26+ or 24+ with Core Library Desugaring - it will be enough to make sure that java.time is available and therefore <ignore> it in animal-sniffer config.

Nothing else is required from sqlite-jdbc.

Would this prevent what i did when inlining functions like here ?

Should be fine.

How would you feel about this:

merge this PR first
work on a separate PR to lower the API level for Android
We could get something out of the door for API level 26 quickly, and keep working in the background to lower the API level.

Sure, we can do that.

[gotson]

Would you have some more information on those desugaring libraries, or some links we could add in the documentation for Android users ?

I also found this: https://github.com/open-toast/gummy-bears#core-library-desugaring which seems to indicate we should be able to use the desugared core libs signatures, which should be more accurate than just ignoring things.

I will try to test other signatures and see where i get in regards to java.time functions.

[gotson]

Ok, while the gummy-bears project publishes the signatures for coreLib1/2, there is a limitation in the Maven plugin that forces the classifier to signature.

I managed to use a workaround by installing the file locally, it works but it's a bit ugly. However there are much less warnings even with API 24, so i think it's a good idea.

Will need some time to work on a solution to use those signatures, but i think we could achieve API 24 compat in one go.

[pavel-yazev-km]

Would you have some more information on those desugaring libraries, or some links we could add in the documentation for Android users ?

No, the link I've provided is a sufficient entry point for those who want to use it.
I also believe that it is a default to use desugaring if older Android support is needed.

I also found this: https://github.com/open-toast/gummy-bears#core-library-desugaring which seems to indicate we should be able to use the desugared core libs signatures, which should be more accurate than just ignoring things.

Yep, if it works properly (doubts since it is experimental) - it is a times better way to manage false detections on java.time (and other) classes available through desugaring.

[gotson]

@pavel-yazev-km one more question, is there anything that would prevent an Android project to use corelib2 instead of corelib1 ?

[gotson]

@pavel-yazev-km i have updated the PR:

• added mandatory comment on the AndroidSignatureIgnore annotation
• added comments where code was inlined/changed
• use the coreLib2 (default) signatures. Unfortunately the nio flavor is not available to use.
• updated documentation saying that desugared core lib 2 is required

Would appreciate if you can review again.