How inDrive Detects Silent Android Resource Overrides Before Merge

This audio is presented by Hacker Nune, where anyone can learn anything about any technology.

How InDrive detects silent Android resource overrides before merge? By InDrive,

tech, silent resource overriding is one of those Android problems that looks

menoruntil it affects something important. Most Android developers have encountered situations where

a resource file in the app unexpectedly overrides an existing system or library resource.

The Android build system merges everything successfully, the build stays green, and there

is no warning. At first glance, this may look like a harmless technical detail.

In practice, it can quietly change app behavior in ways that are difficult to notice during code

review. At InDrive, we wanted a practical way to make these conflicts visible earlier,

without adding unnecessary complexity to daily development. So instead of trying to redesign

the whole resource strategy, we added a lightweight C guardrail that warns engineers about

potentially dangerous duplicates right in pull requests. The problem with silent resource overriding,

as the official Android documentation explains, greater than avoid resource merge conflicts.

Greater than the build tools merge resources from a library module with those of a greater than

dependent app module. If a given resource name is defined in both modules, the greater than

resource from the app is used. If conflicts occur between multiple R greater than libraries,

then the resource from the library listed first in the dependencies greater than list,

closest to the top of the dependencies block is used. To avoid resource greater than conflicts,

consider using a prefix or other consistent naming scheme that is greater than unique to the module,

or as unique across all project modules. That behavior is well documented, but it is still

easy to underestimate the risk. If a conflict affects a minor UI detail or a low priority message,

the impact may be negligible. But if it touches something more sensitive,

authentication, authorization, navigation, or another critical flow, the consequences can be

much more serious. The most dangerous part is that the override happens silently. Nothing fails,

nothing alerts you. The issue may remain unnoticed until much later. Why the obvious solution is not

always the best one. A common recommendation is to introduce consistent prefixes for resources

and enforce them with Lint rules. That is a valid approach, and in many projects it works well.

But real-world development is usually messier than ideal guidelines suggest. Sometimes resource

overriding is intentional. Sometimes strict prefixing ADDS friction for developers. And sometimes the

bigger issue is not the existence of overrides, but the lack of visibility around them. At InDrive,

we wanted a solution that would not slow engineers down or force a new naming discipline across

every case. We wanted a simple warning mechanism. If a newly added resource duplicates an existing one,

the author should see it immediately and decide whether it is intentional. A simple idea,

detect duplicates in pull requests. The logic is straightforward. When a pull request adds new

Android resource files, compare them with resources that already exist in the project.

If duplicates are found, show a warning to the developer. This does not attempt to fix

Android resource merging globally. It simply makes hidden conflicts visible early enough to be

reviewed consciously. First implementation. Bash Plus git checkout. Our first version was based

on history. The workflow checked out the repository, detected newly added resource files,

filtered out standard XML files such as AND, and then compared those files with the existing

project tree. This version worked, but it came with an obvious drawback. It was too heavy

fourth amount of useful work it actually did. To compare new files against the existing tree,

we had to fetch history and perform a checkout. In our project, the full workflow took about three

minutes, while the actual duplicate detection logic needed only a few seconds. That made the

next step clear. Faster version. GitHub API Plus. To improve both speed and readability,

we removed the checkout step and moved the same logic to the GitHub API through.

Instead of cloning repository history locally, we listed files changed in the pull request.

Filtered added files under, excluded standard resource file names,

requested the base branch tree through the GitHub API, searched for matching resource pads there.

This kept the approach simple, but made it much more practical to run and see.

In our case, the average execution time dropped from roughly three minutes T.O. about eight seconds.

That change alone made the workflow much easier to justify in a real engineering pipeline.

What this solution improves, this approach gave us several immediate benefits. First,

it made silent conflicts visible during review. Instead of discovering issues later through manual

testing or unexpected behavior, engineers now get a signal at the pull request stage.

Second, it reduced friction. We did not need to introduce a strict naming migration or force

prefixes into cases where overriding was intentional. Third, it stayed lightweight.

For in drive, that mattered a lot. A guardrail IS useful only if it protects quality without

making the development workflow noticeably slower or more complicated. Limitations and trade-offs,

this solution is intentionally pragmatic, not universal. It checks duplicate resource files inside

project modules already present in the repository. That is enough to catch a meaningful class of

mistakes early, but it does not cover every possible merge scenario. Its main limitations are

straightforward. It does not inspect resources coming from external libraries or AAR, JAR

dependencies. It depends on the GitHub API tree response, which may be truncated in very large

repositories. It does not validate the assets folder. It warns about duplicates, but does not decide

whether a given override is correct or incorrect. A deeper Gradle or AAPT level integration could

potentially catch more cases. But it would also make the solution more complex, slower, and harder

to maintain. For us, that trade-off was not worth it. Why this was enough? We did not need a

perfect detector for every Android resource conflict across the whole dependency graph.

We needed a fast, understandable, low friction safety net that could catch the most

relevant risks before merge. This workflow does exactly that. It improves visibility.

It keeps C efficient, and it gives developers a chance at o confirm whether a duplicate resource

is intentional or accidental. Sometimes the best engineering solution is not the most comprehensive one.

It is the one that fits the team's workflow, solves the most painful part of the problem,

and remains cheap enough to use every day. At InDrive, this small GitHub workflow turned out to be a

practical way to reduce the risk of unintentional Android resource overriding, without turning a

solve-able problem into a heavyweight process. Reference, Android documentation on resource merge

conflicts, HTTPS colon slash slash developer, Android, COM, Studio, Projects, Android Library,

thank you for listening to this Hackernoun story, read by artificial intelligence.

Visit Hackernoun.com to read, write, learn, and publish.