Android Custom Filetype Content Intent Filter

user_1839307 0
Viewed 25

I now have two apps with custom filetypes (extensions .ffx and .tcb). When opened from an attachment within Gmail app, the Intent includes neither the filename nor the originally assigned custom mimetypes (application/freqfinder and application/timecardbuddy).

HOST=(com.google.android.gm.sapi)

SCHEME=content

PATH=/newendian@gmail.com/message_attachment_external/%23thread-f%3A1736258334946004772/%23msg-f%3A1736258334946004772/0.1

FRAGMENT=null

MIME=application/octet-stream

How can I make sure that the proper app is opened? Android doesn't even allow the user to select from multiple apps.

Is there a way to reject an Intent from within the app so that it gets directed properly? Or should I write code to send an explicit Intent from one app to the other?

intentfilter mime-types android-intent android
1 Answers

I now have two apps with custom filetypes (extensions .ffx and .tcb)

Custom file extensions have never been practical on Android IMHO. They have been very impractical since Android 7.0, six years ago.

When opened from an attachment within Gmail app, the Intent includes neither the filename nor the originally assigned custom mimetypes (application/freqfinder and application/timecardbuddy).

I don't know how Gmail would find out about those MIME types. They are not on the official roster, nor do they follow the rules for vendor-specific MIME types.

How can I make sure that the proper app is opened?

Your apps would need to have an <intent-filter> matching that Intent (content scheme and application/octet-stream MIME type). The app would need to attempt to read in the content and make one of two or three determinations:

  1. Yes, this stream has the data in the expected format, in which case the app can go ahead and use it
  2. No, this stream does not have the data in the expected format, but it happens to match the other format
  3. No, this stream does not have the data in the expected format, and it is unrecognizable

In case 3, you would show some sort of "sorry!" error message. If you elect to also add support for case 2, you could either:

  • Show a message in your app explaining that the user needs to use the other app (perhaps with a button to install that app), or
  • Forward the Uri along to it, including FLAG_GRANT_READ_URI_PERMISSION (and, if needed, FLAG_GRANT_WRITE_URI_PERMISSION) in your Intent to start an activity in the other app (and fall back to the message if you get an ActivityNotFoundException, indicating that your other app is not installed)
user_1151450
Related