Detect and warn for nested resource folders. [172585862]

Fixed

Feature Request

[AOSP] duplicate

[AOSP] assigned

Migrated-Tools-Gradle

Status Update

No update yet.

Description

xa...@google.com

created issue #1

Nov 5, 2020 07:47PM

This seems to be a pattern that several users employ to organize their sourcesets.

See Issue 171155439 (and duplicates).

We should decide whether we want to actively support this in AGP or not. If we support it we should fine a way to make the Project View work for it (which may not be trivial as you have part of the content under 2 roots)

In my opinion, I think this is not the right way to organize the sources and we should detect and fail on it.

If we do decide to not support it we have to think about when to introduce the breaking change, how to migrate, etc... It would probably be safer to warn in 7.x and break in 8.0.

Chris/Jon, can you drive the decision making?

Comments

xa...@google.com <xa...@google.com> #2Nov 5, 2020 07:52PM

Same here. I have links in a local html file referencing file:///android_res/drawable/ and on all gradle build flavors using another applicationId (added suffix) the Webview only shows broken links.

This behaviour seems not to be connected solely to Android 5.0 since it occurs on Android 4.4.4 too (tested with current cyanogenmod 11 build).

jo...@google.com <jo...@google.com> #3Nov 5, 2020 08:06PM

As a hotfix I added the following code to the gradle buildscript, which generates an additional R.java with changed java package for every flavor. I don't like this solution though.

android.applicationVariants.all{ variant ->
variant.javaCompile.doFirst{
copy {
from "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/R.java"
into "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${

variant.buildType.name}/"
}
File rFile = file("${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${

variant.buildType.name}/R.java")
String content = rFile.getText('UTF-8')
String newPackageName = "com.example.application.${

variant.buildType.name}";
content = content.replaceAll(/com.example.application/, newPackageName)
rFile.write(content, 'UTF-8')
}
}

xa...@google.com <xa...@google.com> #4Nov 5, 2020 08:43PM

I've recenly encountered this issue and I must say it's quite a nuisance. Searched half of the Internet just to find out that the problem lies in Gradle's applicationIdSuffix :). I think this bug should be reported to Android SDK Build Tools devs, because only they can do something about it.

ab...@gmail.com <ab...@gmail.com> #5Nov 26, 2021 08:41PM

Comment has been deleted.

Message last modified on May 22, 2023 02:46PM

se...@gmail.com <se...@gmail.com> #6Nov 23, 2022 04:44AM

[Comment deleted]

al...@google.com <al...@google.com> #7Jun 18, 2023 09:36PM

Marked as fixed, reassigned to al...@google.com.

[Comment deleted]

li...@gmail.com <li...@gmail.com> #8Feb 24, 2025 12:18PM

The applicationIdSuffix/packageName/etc seem to be a Gradle-specific concept that applies only at build time.

At runtime, the only way WebView has to identify your app is the actual package name of the APK, and that will be the full string with the suffix included. The package that was used at compile time when generating the R class is not stored in the APK, and there's not really any way for WebView to know what it was as far as I know.