Hi there :android-wave: I think the ecosystem ha...

# library-development

[Mez Pahlan]

Hi there 👋

I think the ecosystem has moved on a lot since I was last here and I'm looking for some advice on how to deal with a scenario I have with one of my libraries.

At my company I produce a small debug menu UI (Android + Compose) library for a feature flagging SDK (pure Kotlin) that I also maintain. I depend on another library that my company provides which is a design system library to provide the UI components and company styling. Both these are integrated into our main company Android app however the design system library is usually ahead in terms of versions in the main company Android app than is linked on my debug menu UI library. This frequently leads to crashes when using the part of the company Android app that my debug menu library is because the design system library regularly breaks ABI compatibility.

For example I will update my library and adopt, let's say, version 1.2.0 of the design system library and when this is also installed in the company Android app everything works fine. But by version 1.3.0 the design system library breaks ABI and is updated in the Android app but I haven't got around to updating my library. That's when my debug menu starts crashing.

What I've been doing so far is to try and keep in line with the design system updates even if nothing else in my library needs changing but that is starting to not be possible due to other work commitments. I have also spoken to the design system team many times to not break ABI but this isn't being followed.

Is there anything you'd recommend? I've looked at the Gradle Up Shadow plugin to see if I can relocate the design system library but it's an AAR so not supported. I've also gone down a rabbit hole trying to wrap my calls in try catch blocks but am finding that a lot of extra work and quite tough since I can't wrap Compose calls in try catch.

The ideal solution is for the design team to respect ABI stability within minor versions. But in the absence of that I would like to continue using the design library I've linked and tested against but not have to constantly update or face angry crash messages from colleagues.

Has anyone done something similar?

[Youssef Shoaib [MOD]]

An official Google solution exists for merging aars

Alternatively, If they tend to maintain source compatibility, you can have a CI job that uses the new version, runs tests, and if all passes, publishes a new version of your library.

[Michael Paus]

Did you have a look at this? kotlinlang.org/docs/gradle-binary-compatibility…#…
which is the successor of
github.com/kotlin/binary-compatibility-validator

[Mez Pahlan]

Thanks @Michael Paus , I have looked at that. I even integrated it into the design team's SDK repo and showed them how to use it. The problem is that new team members join and want to see their PR green, so accept the changed API file without doing any of the required backwards compatibility additions. sad panda . Hahaha, so it's like fighting the same battle over and over again.

@Youssef Shoaib [MOD] I tried using Fused but that doesn't work for two reasons. It doesn't relocate the namespaces so when integrated into the same app we will have duplicate class errors. And it also doesn't work with data binding libraries which one of the design system library dependencies uses. Maybe it can be made to work but I tried this week and it felt like I was hitting roadblocks at each turn. But then again maybe I should continue down this route?

Thanks both for the suggestions.

[jessewilson]

When I squint this looks like a monorepo / many repo problem.

Perhaps set up Renovate to automatically update your debug menu repo, and CI task to automatically release it? That way changes that are source-compatible but binary-incompatible don't require much toil.

If the Renovate task fails you know you've got a compatibility problem, which is at minimum good to have visibility into.

[jessewilson]

If you elect to have CI cut releases automatically for you, you'll need something like this: https://publicobject.com/2024/06/24/get-a-version-name-for-a-commit/

[Mez Pahlan]

Interesting. Thanks Jesse. Sounds like I've found my Friday project!

Out of interest, if the CI tasks fails after updating my debug menu repo indicating a breaking ABI... I'm informed. But isn't that too late since the library that I depend on that had broken ABI compatibility has been shipped (and depending on how quickly I read the failure report potentially also integrated elsewhere).

Or is the answer that I am notified and I can adapt to the new ABI or I am notified and I can shout at the team to restore compatibility but the point is the awareness is there?

[jessewilson]

This is an organizational question, not a technical one. If your design system team is shipping binary-incompatible changes, then all the downstream teams need to react urgently to the damage

[jessewilson]

And if you’d like your design system team to not make binary-incompatible changes, you can show ’em the tools that help you to manage that

[jessewilson]

kotlinlang.org/docs/gradle-binary-compatibility…

[Mez Pahlan]

Cheers