How inDrive Detects Silent Android Resource Overrides Before Merge

0:00This 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,

1:01as 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,

2:06nothing 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.

3:07If 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.

4:13Filtered 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,

5:16this 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

6:17relevant 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.