[#1816] Replace resourceConfigurations with androidResources.localeFilters

[ChinmayGopal931]

Closes #1816

resourceConfigurations is deprecated in AGP 8. This replaces it with androidResources.localeFilters.

-resourceConfigurations.addAll(listOf("en", "en-rUS", "en-rGB", "en-rAU", "es", "en_XA", "ar_XB"))
+localeFilters += listOf("en", "en-rUS", "en-rGB", "en-rAU", "es", "en-rXA", "ar-rXB")

Why two of the tags changed spelling

The pseudolocales went from en_XA / ar_XB to en-rXA / ar-rXB. This isn't cosmetic: localeFilters validates its entries and resourceConfigurations didn't, so the underscore form now fails the build outright.

> Task :app:processZcashtestnetFossDebugResources FAILED
  > The locale in localeFilters "en_XA" is invalid.

Warning

Please don't "modernize" these to BCP-47 (en-US, en-XA). AGP hands the list to aapt2 -c, which only takes Android resource qualifiers and rejects BCP-47 with invalid config 'en-US' for -c option. The -r region form is the only spelling that satisfies both. That's also why en-rUS / en-rGB / en-rAU are untouched.

Why library and test modules just drop the call

localeFilters only exists on ApplicationAndroidResources, so library and test variants can't set it. They don't need to: the app module's filter applies to everything merged into the APK, including resources from libraries. Library modules here aren't published as AARs and the com.android.test modules target :app, so nothing is lost.

The @Suppress("UnstableApiUsage") matches what managedDevices already does in the same file.

Verification

Built the APK twice from the same tree, once with the old API and once with the new one, then diffed aapt2 dump configurations on both. Identical, 43 configurations each: en-rAU, en-rGB, es and the en-rXA / ar-rXB pseudolocales all kept, third party locales still stripped. So this is a like-for-like swap, not just something that compiles.

:app:assembleZcashtestnetFossDebug passes, as does processZcashtestnetFossDebugResources on :ui-integration-test and :ui-screenshot-test (the modules the call was removed from).

[nesence-m]

utACK

[ChinmayGopal931]

utACK

@nesence-m Is there anything I can do to move this pr along? how can I help get this merged?

[nesence-m]

@zodl-review

[zodl-review]

🤖 Claude Review

Review

Coverage — Full diff and file contents reviewed.

Summary — Replaces the deprecated resourceConfigurations API with androidResources.localeFilters on the application module, and drops it entirely from library and com.android.test modules since the new API is only available on ApplicationAndroidResources. The application module's filter applies to merged resources at packaging time, so library-contributed locales are still stripped.

Risk Assessment — Low. Build-script-only change in a convention plugin; behavioral risk is limited to which locales survive in the final APK, which is governed solely by the application module's filter.

Key Observations

• Two extension handles for the same plugin. The application branch opens both the legacy AppExtension at line 9 (project.the<com.android.build.gradle.AppExtension>().apply {) and the modern ApplicationExtension at line 25 (project.the<com.android.build.api.dsl.ApplicationExtension>().apply {) back-to-back. Both interfaces are implemented by the same underlying object so this works, but it mixes the legacy BaseExtension/AppExtension API with the modern com.android.build.api.dsl API in one plugin block. Worth a follow-up to migrate configureBaseExtension and the application defaultConfig to the api.dsl types so this file uses a single DSL family. Non-blocking.

• UnstableApiUsage suppression is correct and consistent. Line 30 reads @Suppress("UnstableApiUsage") immediately above androidResources { ... }, mirroring the existing suppression on managedDevices.

• Locale filter only applied via +=, never reset. Line 32 reads localeFilters += listOf("en", "en-rUS", "en-rGB", "en-rAU", "es", "en_XA", "ar_XB"). If a downstream module or AGP default ever pre-populates localeFilters, this appends rather than replaces. The old resourceConfigurations.addAll(...) had the same additive semantic, so this is parity, not a regression — but if the intent is "exactly this set," localeFilters.clear(); localeFilters += ... would be more defensive. Non-blocking.

• Locale tag format worth confirming. Line 32 still uses Android resource-qualifier syntax (en-rUS, en-rGB, en-rAU) inherited verbatim from the old list. AGP's localeFilters documentation specifies BCP-47 tags (e.g. en-US); AGP is generally lenient about the legacy -rXX form, but a ./gradlew :app:assembleRelease + APK Analyzer check that values-es, values-en-rGB, values-en-rAU, values-en-rUS survive packaging (and unrelated locales like values-fr from Play Services are stripped) is worth doing before merge. The PR description mentions only compileKotlin and help, neither of which exercises resource shrinking. Non-blocking but please verify.

• Library-block comment slightly overclaims "inheritance." Lines 40–42 read // Locale stripping is configured on the application module via androidResources.localeFilters. / // The replacement API is only available on ApplicationAndroidResources, so libraries inherit / // the final filter at packaging time and don't need to declare their own. Libraries don't really "inherit" — the application module's locale filter is applied at app packaging time to all merged resources, including those contributed by libraries. The wording reads as if there's an inheritance mechanism on the library side. Nit.

• No rubric violations. None of the rubric bullets (error types, trait defaults, repr enums, missing docs, etc.) apply to a .gradle.kts convention plugin.

Suggestions

• Nit: tighten the library-block comment at lines 40–42 to something like "the application module's locale filter applies to merged resources from libraries at packaging time."
• Non-blocking: build a release APK and confirm the expected values-* resource folders are present and unrelated locales are stripped before relying on this in shipped builds.
• Non-blocking: consider migrating the application defaultConfig block at lines 9–23 to ApplicationExtension so the file no longer straddles two DSL generations.

Areas of disagreement

• Verification step. Reviewer A asks for an explicit APK-analyzer verification before merge given that compileKotlin/help don't exercise resource shrinking; Reviewer B treats local builds plus the deprecation rationale as sufficient and only suggests verification as a general "non-blocking" idea. Human reviewer to adjudicate.

---

_{Automated review by zodl-review bot · Models: us.anthropic.claude-opus-4-7 + us.meta.llama4-maverick-17b-instruct-v1:0 (synthesis) · [Silent pilot — feedback welcome]}

[ChinmayGopal931]

Hey @nesence-m, sorry about the dismissed approval. I pushed a follow-up commit because the version you approved doesn't actually build anymore (pr has been approved and open for a while)

The two pseudolocale tags came straight across as en_XA and ar_XB. It turns out localeFilters checks every entry where resourceConfigurations never did, so those two now kill resource linking:

> Task :app:processZcashtestnetFossDebugResources FAILED
  > The locale in localeFilters "en_XA" is invalid.

I'd only run compileKotlin and help before, and neither of those links resources, which is why it looked fine.

The fix is to spell them en-rXA and ar-rXB. I tried the BCP-47 spelling first (en-XA and ar-XB) and that fails too, just later on, with invalid config 'en-XA' for -c option. So the -r form is the only one that works here, and that's also why I left en-rUS, en-rGB and en-rAU as they were.

I did a bit of cleanup on the comments while I was in there. The one on the library block said libraries inherit the filter, which isn't really right. The app module's filter just applies to everything merged into the APK, libraries included.

Mind taking another look when you get a chance?