Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect resource merging logic when handling conflicts #272

Open
oliviernotteghem opened this issue Nov 4, 2024 · 0 comments · May be fixed by #273
Open

Incorrect resource merging logic when handling conflicts #272

oliviernotteghem opened this issue Nov 4, 2024 · 0 comments · May be fixed by #273

Comments

@oliviernotteghem
Copy link

Description :
Our large project include duplicated android resources. We recently hit a bug when our developers introduced a dependency to a new third party library, which contains an android resource with the same name as one used in our top-level target. This is due to the fact the old APPT1 behavior is currently preserved, and the defined resources in the list provided to Aapt2ResourcePackagingAction 'wins'. The expectation is that the closest value defined from the app wins.

The project below exemplify this (bogus) behavior : app defines resource app_name and app_name2 (with same value), depends directly (or transitively) on library lib, which defines also app_name. In the final APK, app_name has the value from lib.

This is problematic for projects tolerating duplicated resource, as, even with warnings, breaks can easily be introduced as any code change or third party library bump could possibly overwrite the value defined in top level target.

The workaround we're using is to reverse the input order in Aapt2ResourcePackagingAction.

Repro :

  1. clone https://github.com/oliviernotteghem/rules_android/tree/repro_merge_issue branch (or simply cherry-pick oliviernotteghem@0f36bf1)
  2. bazel build java/com/basicapp:basic_app
  3. visualize output APK in android studio :
Screenshot 2024-11-04 at 11 25 03 AM
@oliviernotteghem oliviernotteghem linked a pull request Nov 4, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant