How to use Android Support Libraries in my own Android Library

Question

My company has an android library (an SDK) which we distribute to third parties. It uses some features of the Android Support libraries - specifically (but not limited to) android.support.annotation and android.support.v4.content.LocalBroadcastManager

The problem is, if we compile our library against (say) com.android.support:appcompat-v7:27.1.1 and the third party compiles against (say) com.android.support:appcompat-v7:28.0.0 then the third party app receives the All com.android.support libraries must use the exact same version specification warning.

If we were developing a single self-contained app, then the fix is clear; just update everything to use the latest (28) version of the support libraries. Same deal if we were to move to androidX.

However, for a redistributable library which may be out of date (a third party could use our SDK 18 months after it's release) we can't do this.

As far as I can see, there is no guidance on what to do here. Options I can think of:

1. Do nothing. The third parties can ignore the warning. This is what we've been doing in the past and it does seem to be fine, however I don't like the idea of shipping something which is going to throw warnings at our customers.

2. Remove all references to com.android.support from our SDK. This is very painful, because LocalBroadcastmanager only exists in the support libraries, it's not part of Android itself, and also we use @NonNull and @Nullable extensively. They are great at preventing bugs, and important for Kotlin support and I wouldn't like to lose them.

3. Remove all references to com.android.support from our SDK but make an exemption for com.android.support:support-annotations for @Nullable. Perhaps that will make the warnings go away? Losing LocalBroadcastManager would not be great though. Is this even OK?

4. Always ship our SDK compiled against the latest support libraries and aggressively push third parties to update as well. Pushing third parties like this doesn't feel good, and also it means if we don't have a release for say 9-months we'll have to make interim releases just to keep up with Android support library updates.

5. Ship different versions in parallel of our SDK compiled against different support libraries, where the third party can pick the one they want. This is a lot of work (how many versions back do we go?) and would be quite confusing I imagine.

6. Give up and support iOS only (lol)

Anyway - As mentioned I've been unable to find any guidance on how to handle this kind of thing. Any feedback would be much appreciated

Answer 1

How about an option 7?

It's just a fact of life (?) that your implementations won't always match the user's implementations.

I've run into libraries that are somewhat outdated (using support 25.1.3 or something), and I've hit this error. But there's a pretty simple fix. You just modify the implementation a little bit:

implementation ("com.my:project:project-name:1.0.0") {
    exclude group: "com.android.support"
}

It should be pretty self-explanatory, but that just tells Gradle to ignore the library's support implementations and use the app's instead.

This has a potential issue, where if the user doesn't implement one of the support libraries you use, they can't build until they implement it themselves. But that's also pretty easy to work around:

implementation ("com.my:project:project-name:1.0.0") {
    exclude group: "com.android.support" module: "support-annotations"
}

That way, only support-annotations is excluded in the implementation, and the rest are left alone.

I think a good way to approach this is to do two things:

1. Modify your README to say which support libraries you use.
2. Guide the user on how to exclude the ones they currently use in their app from the implementation of your library (just copy that "exclude" line from above for each one).

---

PS, I don't think I've ever had an issue if a library I implement is using support library versions above my own. That might just be a mistake in lint.