fix(android): stop mangling the file name for extensions Android doesn't recognize in saveFile

[vicajilau]

Fixes #2199.

The bug

Saving a file with an extension unregistered in the device's MimeTypeMap (e.g. .gpx, a niche XML based format) produces a mangled name. The report's example: saving trace.gpx produced trace.gpx.xml.gpx.

Root cause, traced through the actual save flow

1. getMimeTypeForBytes (FileUtils.kt) doesn't find gpx in the device's MimeTypeMap, so it falls back to sniffing the file's byte content. A GPX file is valid XML, so the sniff correctly detects text/xml, a real but wrong answer for what the caller asked for.
2. That mime type is set on the ACTION_CREATE_DOCUMENT intent alongside the suggested title trace.gpx. The system's document picker honors the declared type and "corrects" the suggested name by appending its own default extension for text/xml, .xml, producing the actual created document trace.gpx.xml.
3. maybeRenameGenericMimeDuplicate runs afterward to append the extension when the picker didn't add one (the case it was written for, generic mime types like application/octet-stream). It only checks whether the current name already ends with the extension we asked for, gpx, never whether it ends with a different one. trace.gpx.xml doesn't end in .gpx, so the whole string is treated as the base name and .gpx gets appended on top, producing trace.gpx.xml.gpx.

Not specific to .gpx, any extension unknown to the device whose content happens to sniff as a recognizable generic format (XML, in this case, likely others too) can hit the same chain.

The fix

• getMimeTypeForBytes: when the extension is present but unknown to MimeTypeMap, use a wildcard mime type (*/*) instead of falling through to content sniffing. A wildcard has no default extension of its own, so the picker has nothing to "correct" the name with.
• extractBaseNameAndSuffix (used by maybeRenameGenericMimeDuplicate): added a case that recognizes our extension immediately followed by exactly one more extension, e.g. trace.gpx.xml, and strips both, recovering the true base name (trace) instead of only handling the case where no extension is present at all.

Verified the new regex's matching behavior directly (a Kotlin Regex and Python's re share the same backtracking semantics for this pattern) against the exact reported name plus a few edge cases (a base name containing a literal dot, the existing Android collision suffix style, a name that already has the right extension), all resolve to the expected base name.

What I could not verify myself

There's no existing Kotlin unit test setup in this module (only Dart tests), and reproducing this needs an actual Android device/emulator plus a real "create document" system picker interaction, which isn't something I can drive from here. @nicolaspernoud if you're able to test this branch against your actual repro (saving with fileName: 'trace.gpx', allowedExtensions: ["gpx"]), that would be the most reliable confirmation before merging. You can point at it with:

dependency_overrides:
  android_file_picker:
    git:
      url: https://github.com/vicajilau/flutter_file_picker.git
      ref: fix/android-savefile-unknown-extension-mimetype
      path: packages/file_picker_android

Test plan

• flutter analyze clean
• Bumped android_file_picker to 1.1.1 with a changelog entry
• Confirmation against the real repro (see above)

[navaronbracke]

LGTM with nit

[nicolaspernoud]

Hello,
Thanks for the quick fix.
I confirm that it solves the problem.
Best regards.