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.
| Affects | Does not affect |
|---|---|
| Which resource wins a merge | Which version Gradle selects |
| Manifest element merging | Whether 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
- After adding or reordering a dependency, build a release and open the merged manifest report in your IDE.
- Compare permissions and exported components against the previous build.
- Place the dependency you want to win a conflict above the one it should override.
- 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.
- 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.