Android applications hijack^Wclaim MIME type associations

nephros · 1 June 2022 15:24

REPRODUCIBILITY: 100%
OS VERSION: 4.4.0.64
HARDWARE: X10III
UI LANGUAGE: en_GB
REGRESSION: unknonwn

DESCRIPTION:

Desktop files derived from Android packages can include a MimeType= tag.

Depending on the associations that package specifies, this can lead to an app “hijacking” a whole class of file mime types, or certain mimetypes which may not be wanted by the user.

See below for an example, in which the .apk claims to support the mime type text/*, which leads to an entry in the mimecache, which apparently overrides any other MimeType that is registered from other apps.

It would seem there are in fact two issues with wildcard use in types:

Mime Type foo/* leads to the app hijacking all file associations, overriding more specific assignments by other apps, so only one app appears in the chooser.
Mime handler type x-scheme-handler/* leads to the app appearing on any and all “open URL” type events. See comment below for an app that does this.

PRECONDITIONS:

Example: Install the application “Nextcloud Notes” (https://f-droid.org/is/packages/it.niedermann.owncloud.notes/)

STEPS TO REPRODUCE:

stop Android Support
create a text file called ‘text.log’ containg some ascii text. depending on the tool you use, the mime type might be text/x-log or text/plain
tap on the file using a file manager

→ SFOS opens the file in nextcloud notes, starts Android Support to do it

EXPECTED RESULT:

A prompt to select the text editing/viewing application from a list of text-supporting apps, e.g. Sailfish Office

ACTUAL RESULT:

File is opened automatically without prompt (just the popup that the application may start in the backfround)

MODIFICATIONS:

Lots, but probably none which affect this:

defaultuser → nemo
patchmanager and mostly Silica patches

WRT applications and MIME types, I have a couple of custom files in ~/.local/share/applications, but nothing modified in /usr/share/applications

ADDITIONAL INFORMATION:

Query the file association:

$ lca-tool --file --print file:///home/nemo/test.log
apkd_handler_it_niedermann_owncloud_notes-it_niedermann_owncloud_notes_edit_EditNoteActivity

look in /usr/share/applications/apkd_handler_it_niedermann_owncloud_notes-it_niedermann_owncloud_notes_edit_EditNoteActivity.desktop

find that it has:

MimeType=text/*

look in /usr/share/applications/mimeinfo.cache and find the corresponding

text/*=apkd_handler_it_niedermann_owncloud_notes-it_niedermann_owncloud_notes_edit_EditNoteActivity.desktop

The text/* assiciation comes from the Android Manifest directive here:

github.com

stefan-niedermann/nextcloud-notes/blob/master/app/src/main/AndroidManifest.xml#L111

    
      
                  <action android:name="android.intent.action.SEND" />
                  <category android:name="android.intent.category.DEFAULT" />
                  <data android:mimeType="text/plain" />
              </intent-filter>
              <!-- Voice command "note to self" in google search -->
              <intent-filter android:label="@string/action_create">
                  <action android:name="com.google.android.gm.action.AUTO_SEND" />
                  <category android:name="android.intent.category.DEFAULT" />
                  <data android:mimeType="text/plain" />
              </intent-filter>
              <intent-filter android:label="@string/app_name">
                  <action android:name="android.intent.action.VIEW" />
                  <category android:name="android.intent.category.DEFAULT" />
          
          
        <data android:scheme="content" />
                  <data android:host="*" />
                  <data android:mimeType="text/*" />
              </intent-filter>
          </activity>
          
          
<activity

nephros · 24 June 2022 07:22

Another example is the app ‘Lite Uptodown App Store’ which claims to handle application/* and x-scheme-handler/*.

nephros · 24 June 2022 07:26

Question: is there any use case where associating foo/* makes sense?

I can’t think of any.See below for an example, in which the .apk claims to support the mime type text/*, which leads to an entry in the mimecache, which apparently overrides any other MimeType that is registered from other apps.

If there is not probably the easiest fix would be for either apkd or update-desktop-database to ignore wildcard assignments.

Or, allow them for things where they might be lazy but somewhat reasonable, like text, image, audio, video, but not for general things like application and scheme-handler. where a wild card assignment is obviously lazy and wrong.

In any case, wildcard-claiming apps should be added to the chooser (and if possible ordered last), not replace all others, properly configured applications.

flypig · 6 July 2022 18:29

Thanks for reporting this @nephros. I’ve created an internal bug report about it and tagged it as tracked.

nephros · 15 July 2022 14:45

Additional info:

If you remove the wildcard entry from the .desktop file and update the app/mime cache, the issue goes away.

However either starting/stopping Android Support, upr updating an Android app (not the affected one!) makes it reappear.

nephros · 17 November 2022 06:54

Another handling clain that may cause unwanted apps opening things: application/octet-stream.

Being a generic fallback type, claiming to deal with it will almost always be wrong.

pvuorela · 21 March 2024 07:13

Granted that it can be unlikely that an app can really really handle text/* but just registering video/* or image/* might not be that far fetched as shortcut to handle very wide range of types, and definitely apps doing those registrations should be able to handle a lot of file types on the category. Also conceptually it’s a valid registration on the .desktop file level.

I suppose on Android the app really gets to be offered on all text files too?

I tried creating such an artificial text/* handler but it doesn’t hijack the whole file category. It just gets itself shown as option when opening a text file. So to me this works as expected. Not impossible that there has been some bug here that’s been since fixed.

Eventually we should also offer to save the selection as default handler for a type so the user shouldn’t be bothered every time. That probably helps here too.