Safeguard
Developer Tools•

Does the order of dependencies in build.gradle matter on Android?

On Android, dependency order sets priority when resources and manifests merge. Learn how the order works and why it matters for permissions and components.

Safeguard Security Team
3 min read

Yes, in one specific way. The Android documentation says the order in which you list dependencies sets their priority, and earlier entries take precedence when resources or manifest elements are merged. It does not change which versions resolve, but it can change which resource or manifest entry wins.

What the order controls

Take a project that depends on LIB_A, then LIB_B. LIB_A depends on LIB_C then LIB_D, and LIB_B depends on LIB_C. The flattened order is LIB_A, LIB_D, LIB_B, LIB_C. This lets LIB_A and LIB_B both override LIB_C, and LIB_D ranks above LIB_B because LIB_A has higher priority than LIB_B.

AffectsDoes not affect
Which resource wins a mergeWhich version Gradle selects
Manifest element mergingWhether a library is included

Why that matters for security

Every library can contribute manifest entries such as permissions, services and exported components. When two sources conflict, priority decides the result. A new library listed above an existing one can quietly override settings you assumed were stable.

This is separate from version resolution, but it changes the app you ship. It is also a reason to look at the merged manifest after adding a library. Why does my Android app ask for permissions I never added covers what to do with surprises there.

Steps

  1. After adding or reordering a dependency, build a release and open the merged manifest report in your IDE.
  2. Compare permissions and exported components against the previous build.
  3. Place the dependency you want to win a conflict above the one it should override.
  4. Do not rely on order for security decisions. State required manifest values in your app's own manifest, and use explicit removal markers for entries you do not want.
  5. Record the change in the pull request.

What this does not replace

Order is a conflict rule, not a control. Treat the merged manifest as an output you review, the same way you review the lock file for versions.

Try it yourself

Click through it at your own pace, or open it full screen. See a pull request check on dependency changes, then imagine adding a manifest diff review to it.

Safeguard builds an SBOM and scans your dependencies for known vulnerabilities, and you can run a free scan at gold.safeguard.sh/scan to see what your own project pulls in.

Quick check

Does reordering change which library version I get?

No. Version selection follows Gradle's resolution rules. Order affects merging of resources and manifest elements.

Where do I see the final manifest?

In Android Studio's merged manifest view, or in the merged manifest file in the build output.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.