Faced a problem with dependency locking mechanism:

Project is a multimodule android app where only app module is locked.

I expected that build will fail on simple, manual update of a regular(non dynamic) version until i rewrite locks. But it didn't.

For example i upgraded some version of my 3rd party dependency, let's call it com.dep:dep: from 1.0 to 1.2 and build finished correctly even with this particular dependency locked on 1.0 in app's gradle.lockfile

Asked in gradle community slack, but failed to describe my issue correctly (at least should mention multimodule app/): https://gradle-community.slack.com/archives/CAH4ZP3GX/p1632215556061900

Thanks to Louis Jacomet, i understood that at least my expectations are correct.

So what was the problem?

What really happened?

• app with gradle.lockfile locked with (com.dep:dep:1.0),
• app doesn't have direct dependency on com.dep:dep
• app depends on lib with implementation
• lib has direct dependency on com.dep:dep.1.0
• lib doesn't have locking enabled

I tried to update com.dep:dep:1.0 -> 1.2 Expect it to fail on app dependencies resolving. It didn't. Why?

• lib successfully resolved com.dep:dep:1.2
• app resolved transitive com.dep:dep and 1.0 wins because it's a locked version!

making 1.2 "strictly" will fail the build because two different constraints: from lockfile and libs couldn't be resolved.

Answer

So how you should lock versions in multimodule project to fullfil this expectations?

I decided to lock all modules; this way build will fail on libs resoving.

Probably it somehow should be reflected in docs?