GPX import is offered for too many actions in OS

[jakedot]

Describe the bug:
As far as I am aware, c:geo can only import gpx files and ZIP-files containing GPX (PQ). But my Android offers to open almost any file or content I'm downloading with c:geo, also clearly irrelevant stuff like gwc.

IMO this behaviour is a bug, I hope it is also fixable but I'm not an Android developer unfortunately.

To Reproduce:
Steps to reproduce the behavior:

1. try to open an irrelevant file, c:geo is offered as possible app

Actual behavior/state after performing these steps:
Nothing, because I don't take an actual action.

Expected behavior/state after performing these steps:
Only files conforming to GPX/PQ (or other handleable formats I'm not aware of) should be offered to be opened with c:geo

Version of c:geo used:
Current Beta / Release 2019.05.20,

Is the problem reproducible:
Yes, always

Screenshots:
You may attach screenshots if applicable and helpful to explain your problem

System information:

--- System information ---
Device: P6000 (P6000, Blackview)
Android version: 7.1.1
Android build: P6000-Blackview-V0.1-20171021
c:geo version: 2019.05.20
Google Play services: disabled - 17.4.55 (040408-248795830)
Low power mode: inactive
Compass capabilities: yes
Rotation vector sensor: present
Orientation sensor: present
Magnetometer & Accelerometer sensor: present
Direction sensor used: rotation vector
Hide own/found: true
HW acceleration: enabled (default state)
System language: en_AT
System date format: dd/MM/y
Debug mode active: no
System internal c:geo dir: /data/user/0/cgeo.geocaching (28,5 GB free) internal
User storage c:geo dir: /storage/emulated/0/cgeo (28,5 GB free) external non-removable
Geocache data: /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData (28,5 GB free) external non-removable
Database: /data/user/0/cgeo.geocaching/databases/data (60,5 MB) on system internal storage
Fine location permission: granted
Write external storage permission: granted
Geocaching sites enabled:
   geocaching.com: Logged in (Login OK) / PREMIUM
Geocaching.com date format: dd/MM/yyyy
Installed c:geo plugins: contacts
--- End of system information ---

[Lineflyer]

I am no expert for file handling on Android as well, but I learned somewhen in the past, that it is not a plain definition by file extension but also consideres other things (like MIME-type).
However from the practical testing:
When I see c:geo offered for a file (and indeed it might be unsupported files) I do also see other apps with similar file support (e.g. Locus) also offered for those files. So I up to now just assumed, that this cannot be made more precise, but I might be wrong though.

[jakedot]

Maybe related bug report from FB

[Lineflyer]

Maybe related bug report from FB

May I suggest to post relevant information (if any are contained in this case...) directly into this issue instead of or additional to linking to an information, which might change or be deleted at some time in future?

IMHO this helps to get an overview without the need to analyze several sources.

[jakedot]

Yes you're right of course, probably was still on the go with broken phone, so not possible to do much more then, I wanted to do it when I came back home. Which is now. So nice timing and thanks for remembering! 🥇

[jonas-koeritz]

Related code is in AndroidManifest.xml:

cgeo/main/AndroidManifest.xml

Line 317 in e79866d

<data android:pathPattern=".*\\.zip" />

Android does not know about any MIME types or additional details on the .zip file. Removing the handler for .zip would break some scenarios for users that import GPX data from .zip files.
As far as i am aware we can not filter this any further with the current way Android handles sharing. I will have a look what Android Qs implementation looks like, they changed a lot in this regard.

[jonas-koeritz]

I had a quick look and I do not think that Android Q gives any more options to filter based on the content or structure of the shared data.

[jakedot]

The issue was not that there is a handler for any .zip, but that also other files are offered to be opened in c:geo, which are neither gpx nor zips. I'm aware it's not possible to detect PQ content of a specific zip file.

Your XML snippet shows that the file extension is used for detecting... but why are there so many other file types detected?

[jonas-koeritz]

Can you give an example for a file that triggers this behavior?

[jakedot]

Any .gwc file seems to trigger opening it with c:geo or displaying an app choice if e.g. Whereyougo is installed. It might be caused by the line <data android:mimeType="application/octet-stream" /> as afaik this is used for "any other type"? I just observed this on a different device as well:

…

--- System information --- Device: SM-J415FN (j4primeltecis, samsung) Android version: 9 Android build: PPR1.180610.011.J415FNXXU4BSF6 c:geo version: 2019.08.18 Google Play services: enabled - 18.3.85 (100300-262677519) Low power mode: inactive Compass capabilities: no Rotation vector sensor: absent Orientation sensor: absent Magnetometer & Accelerometer sensor: absent Direction sensor used: magnetometer & accelerometer Hide own/found: true HW acceleration: enabled (default state) System language: de_AT System date format: dd.MM.yy Debug mode active: no System internal c:geo dir: /data/user/0/cgeo.geocaching (20,0 GB free) internal User storage c:geo dir: /storage/emulated/0/cgeo (20,0 GB free) external non-removable Geocache data: /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData (20,0 GB free) external non-removable Database: /data/user/0/cgeo.geocaching/databases/data (5,9 MB) on system internal storage Fine location permission: granted Write external storage permission: granted Geocaching sites enabled: geocaching.com: Logged in (Anmeldung OK) / PREMIUM Geocaching.com date format: dd/MM/yyyy Installed c:geo plugins: none --- End of system information ---

[jonas-koeritz]

@Bananeweizen can you elaborate on why application/octet-stream is part of that list? You seem to be the author of that line ;)

[jakedot]

Any updates here? As the cgeo team now also edits the whereyougo app, could we resolve this and also add opening cartridges from the file system there?

The problem still persists as of version 2020.01.26-RC.

See WhereYouGo/39

[moving-bits]

Currently we have five intent-filter sections regarding downloads and opening local files:

element	local gpx	gpx links	local ggz	ggz links	zip files
mimeType	*/*		*/*		text/html, application/xml, application/zip, application/x-compressed, application/x-zip-compressed, application/x-zip, application/octet-stream
scheme	file	http, https	file	http, https
host	*	*	*	*
pathPattern	.*\\.gpx	(same)	.\\.ggz	(same)	.*\\.gpx
	.*\\..*\\.gpx		.*\\..*\\.ggz		.*\\.zip
	...		...		.*\\.ggz

A couple of questions arise:

• What are the ggz entries for?
• Why are .gpx and .ggz extensions also listed for zip files?
• Why does the zip entry not have a scheme and host entry?
• Why does the zip entry have so many mime types unrelated to zip files?

If someone can provide me with a test scenario (with links) I can dive into testing variations of the above entries.

[Narrat]

Doesn't have Garmin introduced the .ggz format? It reminds me of .tgz (.tar.gz), so could be gzipped gpx files? But that is speculation from my side.
And maybe .zip got added, because of zipped gpx, which can be found as .gpx.zip?

Edit: https://www.opencaching.de/okapi/services/caches/formatters/ggz.html

[moving-bits]

Thanks for clarifying on ggz format - didn't know that before.

zip format itself is used for pocket queries from gc.com at least. But that does not explain why gpx and ggz extensions are listed in the zip entry (last column) as well.

[moving-bits]

Ok, after some debugging and reading docs etc., there seems to be no easy solution: Android simply does not support opening local files filtered by file extension. pathExt in AndroidManifest.xml (which could have been partially useful in this case) is ignored for local files, at least on Android 10 (which is what I tested on), but seems to be confirmed for other versions as well, according to several SO articles.
The only filtering working is by MIMEType, but some servers simply set application/octet-stream for every "unknown" (= non-standard) file type, thus making this approach useless for user-specific file types like gpx, map etc. (but explaining the usage of application/octet-stream in one of our intent-filters).

Probably a workaround could be to accept all local files, and filter by file extension on our own, either forwarding the intent internally (for matching file types) or displaying an error message (for non-matching).

[moving-bits]

Closing this issue as "non fixable"/"won't fix", but there will be some improvements coming as a side effect from #8180, as I need to parse the file's header anyway for that, and by this will be able to drop a message to the user if c:geo cannot handle the file.

[hughcoleman]

My issue with dismissing this issue so naively is that this "feature" is confusing the end user(s).

Specifically, people expect that tapping on a .gwc in the file explorer will open WhereYouGo, rather than c:geo. This is partially addressed by @jakedot in cgeo/WhereYouGo#39 and the associated pull—it modifies WhereYouGo so that it declares intent to open .gwc files—however, that still doesn't change the fact that this is confusing.

Perhaps c:geo's Intent "handler" could be configured to redirect intents to open a .gwc to the WhereYouGo app, or to the Play Store if WhereYouGo is not installed?