When file paths for Briefcase projects contain unconventional characters, third party tools may fail to run properly

[rmartin16]

Describe the bug

The fully qualified file path for a Briefcase project is commonly provided as part of command line arguments for third party dependencies. Not all of these dependencies support arbitrary characters in the file path.

For instance, Gradle could not use a file path with the character 0x200e.

Steps to reproduce

1. Create a Briefcase project with a parent directory called 0x200e
2. Run briefcase build android

Expected behavior

Briefcase warns users that such parent file paths may cause problems.

Screenshots

No response

Environment

• Operating System: Windows 11
• Python version: 3.13.7
• Software versions:
  • Briefcase: 0.3.25

Logs

Problematic character is the directory name on Desktop.

           >>> Running Command:                                                                                                                                    subprocess.py:838
           >>>     'C:\Users\<user>\Desktop\‎\Projects\app\name\build\name\android\gradle\gradlew.bat' --console plain assembleDebug                        subprocess.py:838
           >>> Working Directory:                                                                                                                                  subprocess.py:838
           >>>     C:\Users\<user>\Desktop\‎\Projects\app\name\build\name\android\gradle                                                                    subprocess.py:838
           >>> Environment Overrides:                                                                                                                              subprocess.py:838
           >>>     ANDROID_HOME=C:\briefcase_tools\tools\android_sdk                                                                                               subprocess.py:838
           >>>     ANDROID_SDK_ROOT=C:\briefcase_tools\tools\android_sdk                                                                                           subprocess.py:838
           >>>     JAVA_HOME=C:\briefcase_tools\tools\java17                                                                                                       subprocess.py:838
           Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain                                                                           subprocess.py:195
           Caused by: java.lang.ClassNotFoundException: org.gradle.wrapper.GradleWrapperMain                                                                       subprocess.py:195
           >>> Return code: 1                                                                                                                                      subprocess.py:838
                                                                                                                                                                   subprocess.py:838
           Building... errored                                                                                                                                         gradle.py:323
                                                                                                                                                                      __main__.py:42
           Error while building project.                                                                                                                              __main__.py:43
           Saving log... started                                                                                                                                      console.py:438

Additional context

No response

[freakboy3742]

Agreed that we can/should do some validation of the path of the Briefcase project if we know it will cause problems. We already do a version of this sort of check for iCloud when building macOS projects; a higher level check for "problematic" paths would also make sense.

The question I have, though, is how we determine the actual criterion for "problematic"? U+200E LEFT-TO-RIGHT MARK is evidently one... (and... side note... a LTR mark in a path?!) but how do we determine characters that might be problematic, other than trying every unicode code point on every platform? Sure, we can add a check with one character, and build that list over time as we find them... but it would be good to be able to pre-emptively work out what won't work.

[rmartin16]

Maybe we could maintain two lists. One list is stuff we know to block; another is the list of potentially problematic characters. Then we could at least warn people things might break. But what do you include in the "warn list"? Is ñ ok? What about Chinese? 🤷🏼 I guess we could at least start with non-printable characters....

To make matters worse, 0x200e is not a problem on Linux for building for Android. I think the underlying problem goes back to https://bugs.openjdk.org/browse/JDK-4488646 where JDK was never really updated properly for unicode on Windows.