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

Android: Copy resource files in the correct folder #1753

Open
3 tasks
GitToTheHub opened this issue Dec 21, 2024 · 4 comments
Open
3 tasks

Android: Copy resource files in the correct folder #1753

GitToTheHub opened this issue Dec 21, 2024 · 4 comments

Comments

@GitToTheHub
Copy link

GitToTheHub commented Dec 21, 2024

Bug Report

I want to copy resources to the res directory of the android app.

Problem

I followed the documentation for the resource-file tag of the config.xml, where it shows an example to copy a resource file to res/values/ for Android:

<resource-file src="FooPluginStrings.xml" target="res/values/FooPluginStrings.xml" />

When I use this code, the resource file gets copied to platforms/android/res/values, but the correct folder would be platforms/android/app/src/main/res/values.

When I do the same for iOS with

<platform name="ios">
    <resource-file src="FooPluginStrings.xml" target="FooPluginStrings.xml" />
</platform>

It gets correctly copied to platforms/iOS/[AppName]/Resources (using cordova-ios 7.1.1).

Should there be not a similar behavior for Android? Must the documentation be updated to the correct path, or is this an issue in the Cordova-cli?

What is expected to happen?

The resource file should be put in the correct folder like the documentation says.

What does actually happen?

The resource file is copied in the wrong place.

Information

Command or Code

Environment, Platform, Device

Version information

Checklist

  • I searched for existing GitHub issues
  • I updated all Cordova tooling to most recent version
  • I included all the necessary information above
@dpogue
Copy link
Member

dpogue commented Dec 21, 2024

There's some history here that's worth knowing. The Android platform moved from being an Eclipse (ant) project to being an Android Studio (gradle) project, and the project structure changed. Previously, res was a top-level folder, but now it's nested under app/src/main.

To avoid breaking all the existing plugins, there's a remapping system in cordova-android that will take "old" paths and rewrite them to the newer paths. That remapping appears to be used unconditionally resource-file in plugins, but not for resource-file declarations in config.xml.

The workaround is to specify the full path that you want for the file, i.e. app/src/main/res/values/FooPluginStrings.xml

It's not feasible to automatically prefix all resource files with app/src/main (which is what plugins are doing) because that prevents app authors from doing something like copying a google-service.json file into the app folder.
Maybe we could add a check for target paths that start with res/ and remap those?

@GitToTheHub
Copy link
Author

I understand. On my opinion checking for res/ would be good, than it would be also backward compatible. The app developer should not care about the real res path, because the path can also change in future changes.

@dpogue dpogue transferred this issue from apache/cordova-docs Dec 21, 2024
@breautek
Copy link
Contributor

When I use this code, the resource file gets copied to platforms/android/res/values,

Android has a concept of build variants so i don't think it's a good idea to auto prefix and assume app/src/main.

app here is the module name, and main is the build type. Complex projects could make use of these.

So I think we should consider this a doc issue.

@GitToTheHub
Copy link
Author

Thank you @breautek, I didn't know about this. Could this path nevertheless automatically calculated for build variants? Is it really needed do decide in which build variant a resource file will be copied? Does cordova-android support build variants anyway?

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

No branches or pull requests

3 participants