You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 resourceapp_name
andapp_name2
(with same value), depends directly (or transitively) on librarylib
, which defines alsoapp_name
. In the final APK,app_name
has the value fromlib
.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 :
The text was updated successfully, but these errors were encountered: