Rather than android:path, try android:mimeType, with a value of the MIME type of this particular piece of content. Also, android:path does not accept wildcards -- use android:pathPattern for that.
The scheme of file indicates that this should happen when a local file is opened (rather than protocol like HTTP).
mimeType can be set to */* to match any mime type.
pathPattern is where you specify what extension you want to match (in this example .kdb). The .* at the beginning matches any squence of characters. These strings require double escaping, so \\\\. matches a literal period. Then, you end with your file extension. One caveat with pathPattern is that .* is not a greedy match like you would expect if this was a regular expression. This pattern will fail to match paths that contain a . before the .kdb. For a more detailed discussion of this issue and a workaround see here
Finally, according to the Android documentation, both host and scheme attributes are required for the pathPattern attribute to work, so just set that to the wildcard to match anything.
Now, if you select a .kdb file in an app like Linda File Manager, my app shows up as an option. I should note that this alone does not allow you to download this filetype in a browser, since this only registers with the file scheme. Having an app like Linda File Manager on your phone resisters itself generically allowing you to download any file type.
Brian's answer above got me 90% of the way there. To finish it off, for mime type I used
android:mimeType="*/*"
I suspect that previous posters have attempted to post the same detail, but the withough qoting the star slash star as code, stackoverflow diplays it as just a slash.
Brian's answer is very close, but here's a clean and error-free way to have your app invoked when trying to open a file with your own custom extension (no need for scheme or host):
None of the above work properly, for VIEW or SEND actions, if the suffix is not registered with a MIME type in Android's system=wide MIME database. The only settings I've found that fire for the specified suffix include android:mimeType="*/*", but then the action fires for ALL files. Clearly NOT what you want!
I can't find any proper solution without adding the mime and suffix to the Android mime database, so far, I haven't found a way to do that. If anyone knows, a pointer would be terrific.
If you want the files to be opened directly from Gmail, dropbox or any of the buildin android file tools, then use the following code (delete 'android:host="*"' that made the file unreachable for gmail) :
I've been struggling with this quite a bit for a custom file extension, myself. After a lot of searching, I found this web page where the poster discovered that Android's patternMatcher class (which is used for the pathPattern matching in Intent-Filters) has unexpected behavior when your path contains the first character of your match pattern elsewhere in the path (like if you're trying to match "*.xyz", the patternMatcher class stops if there's an "x" earlier in your path). Here's what he found for a workaround, and worked for me, although it is a bit of a hack:
PatternMatcher is used for pathPattern at IntentFilter But,
PatternMatcher's algorithm is quite strange to me. Here is algorithm
of Android PatternMatcher.
If there is 'next character' of '.*' pattern in the middle of string,
PatternMatcher stops loop at that point. (See PatternMatcher.java of
Android framework.)
Ex. string : "this is a my attachment" pattern : ".att.". Android
PatternMatcher enter loop to match '.' pattern until meet the next
character of pattern (at this example, 'a') So, '.' matching loop
stops at index 8 - 'a' between 'is' and 'my'. Therefore result of this
match returns 'false'.
Quite strange, isn't it. To workaround this - actually reduce
possibility - developer should use annoying stupid pathPattern.
Ex. Goal : Matching uri path which includes 'message'.
Using the filter as below to open from browser, gmail & file browser (Tested).
NOTE: Please do not merge two filters, that will make browser ignored your app(Tested).
I must admit that the simple task of opening attachments from emails and files from the filesystem on Android has been one of the more maddening experiences ever. It is easy to handle too many files or too few. But getting it just right is hard. Most of the solutions posted on stackoverflow didn't work correctly for me.
My requirements were:
have my app handle attachments shared by my app
have my app handle files on filestorage that were generated by my app and have a particular extension
Probably the best way to go about this task is to specify a custom MIME Type for your attachments. And you will probably also choose to have a custom file extension. So let's say that our app is called "Cool App" and we generate file attachments that have ".cool" at the end.
This is the closest I got got to my goal and it works... satisfactory.
<!-- Register to handle email attachments -->
<!-- WARNING: Do NOT use android:host="*" for these as they will not work properly -->
<intent-filter>
<!-- needed for properly formatted email messages -->
<data
android:scheme="content"
android:mimeType="application/vnd.coolapp"
android:pathPattern=".*\\.cool" />
<!-- needed for mangled email messages -->
<data
android:scheme="content"
android:mimeType="application/coolapp"
android:pathPattern=".*\\.cool" />
<!-- needed for mangled email messages -->
<data
android:scheme="content"
android:mimeType="application/octet-stream"
android:pathPattern=".*\\.cool" />
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
</intent-filter>
<!-- Register to handle file opening -->
<intent-filter>
<data android:scheme="file"
android:mimeType="*/*"
android:pathPattern=".*\\.cool"
android:host="*"/>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
</intent-filter>
Notes:
The pathPattern seems to be more or less ignored for attachments (when using android:scheme="content"). If somebody gets the pathPattern to respond only to certain patterns I would be thrilled to see how.
The Gmail app refused to list my app in the chooser if I added the android:host="*" attribute.
It probably still works if these intent-filter blocks are merged but I haven't verified this.
To handle requests from a browser when downloading a file the android:scheme="http" can be used. Note that certain browsers might mess up the android:mimeType so experiment with android:mimeType="*/*" and check in the debugger what is actually passed through and then tighten the filtering to not end up being that annoying app that handles everything.
Certain File Explorers will mess up the MIME-Types for your files as well. The above intent-filter was tested with the Samsung's "My Files" app on a Galaxy S3. The FX Explorer still refuses to properly open the file and I also noticed that the app icon is not used for the files. Again, if anyone gets that to work please comment below.
I hope you will find this useful and that you won't have to waste days going through all possible combinations. There is room for improvement so comments are welcome.
I've been trying to get this to work for ages and have tried basicly all the suggested solutions and still cannot get Android to recognise specific file extensions. I have an intent-filter with a "*/*" mimetype which is the only thing that seems to work and file-browsers now list my app as an option for opening files, however my app is now shown as an option for opening ANY KIND of file even though I've specified specific file extensions using the pathPattern tag. This goes so far that even when I try to view/edit a contact in my contacts list Android asks me if I want to use my app to view the contact, and that is just one of many situations where this occurs, VERY VERY annoying.
Eventually I found this google groups post with a similar question to which an actual Android framework engineer replied. She explains that android simply does not know anything about file-extensions, only MIME-types (https://groups.google.com/forum/#!topic/android-developers/a7qsSl3vQq0).
So from what I've seen, tried and read, Android simply cannot distinguish between file-extensions and the pathPattern tag is basicly a gigantic waste of time and energy. If you are fortunate enough to only need files of a certain mime-type (say text, video or audio), you can use an intent-filter with a mime-type. If you need a specific file-extension or a mime-type not known by Android however then you're out of luck.
If I'm wrong about any of this please tell me, so far I've read every post and tried every proposed solution I could find but none have worked.
I could write another page or two about how common these kinds of things seem to be in Android and how screwed up the developer experience is, but I'll save you my angry rantings ;). Hope I saved someone some trouble.
There's a lot of misinformation on this topic, not least from Google's own documentation. The best, and given the strange logic, possibly the only real documentation is the source code.
The following filters get pretty close to sensible behaviour. The path patterns do apply, for "file" scheme intents.
The global mime type pattern match will match all types so long as the file extension matches. This isn't perfect, but is the only way to match the behaviour of file managers like ES File Explorer, and it is limited to intents where the URI/file extension matches.
I haven't included other schemes like "http" here, but they will probably work fine on all these filters.
The odd scheme out is "content", for which the extension is not available to the filter. But so long as the provider states your MIME type (E.g. Gmail will pass on the MIME type for the attachment unimpeded), the filter will match.
Gotchas to be aware of:
Be aware that nothing behaves consistently in the filters, it's a maze of special cases, and treats violation of the principle of least surprise as a design goal. None of the pattern matching algorithms follow the same syntax or behaviour. Absence of a field sometimes is a wildcard and sometimes isn't. Attributes within a data element sometimes must go together and sometimes ignore grouping. It really could have been done better.
The scheme AND the host must be specified for path rules to match (contrary to Google's API guide, currently).
At least ES File Explorer generates intents with a MIME type of "", which is filtered very differently to null, is impossible to match explicitly, and can only be matched by the risky "*/*" filter.
The "*/*" filter will NOT match Intents with a null MIME type - that requires a separate filter for this specific case with no MIME type at all.
The "content" scheme can only be matched by MIME type, because the original file name isn't available in the intent (at least with Gmail).
The grouping of attributes in separate "data" elements is (almost) irrelevant to the interpretation, with the specific exception of host and port - which do pair together. Everything else has no specific association within a "data" element or between "data" elements.
With all this in mind, here's an example with comments:
<!--
Capture content by MIME type, which is how Gmail broadcasts
attachment open requests. pathPattern and file extensions
are ignored, so the MIME type *MUST* be explicit, otherwise
we will match absolutely every file opened.
-->
<intent-filter
android:icon="@drawable/icon"
android:label="@string/app_name"
android:priority="50" >
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="file" />
<data android:scheme="content" />
<data android:mimeType="application/vnd.my-type" />
</intent-filter>
<!--
Capture file open requests (pathPattern is honoured) where no
MIME type is provided in the Intent. An Intent with a null
MIME type will never be matched by a filter with a set MIME
type, so we need a second intent-filter if we wish to also
match files with this extension and a non-null MIME type
(even if it is non-null but zero length).
-->
<intent-filter
android:icon="@drawable/icon"
android:label="@string/app_name"
android:priority="50" >
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="file" />
<data android:host="*" />
<!--
Work around Android's ugly primitive PatternMatcher
implementation that can't cope with finding a . early in
the path unless it's explicitly matched.
-->
<data android:pathPattern=".*\\.my-ext" />
<data android:pathPattern=".*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
</intent-filter>
<!--
Capture file open requests (pathPattern is honoured) where a
(possibly blank) MIME type is provided in the Intent. This
filter may only be necessary for supporting ES File Explorer,
which has the probably buggy behaviour of using an Intent
with a MIME type that is set but zero-length. It's
impossible to match such a type except by using a global
wildcard.
-->
<intent-filter
android:icon="@drawable/icon"
android:label="@string/app_name"
android:priority="50" >
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="file" />
<data android:host="*" />
<data android:mimeType="*/*" />
<!--
Work around Android's ugly primitive PatternMatcher
implementation that can't cope with finding a . early in
the path unless it's explicitly matched.
-->
<data android:pathPattern=".*\\.my-ext" />
<data android:pathPattern=".*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
</intent-filter>
Any matching <data pathPattern/etc.> (for example .*\\.0cc)
Defining multiple <data $type=""> elements checks the $type box iff any <data $type=> matches the Intent.
Omitting mimeType breaks your intent-filter, even though it's seemingly redundant. Omitting <data scheme/host/pathPattern> causes your filter to match everything.
https://f-droid.org/en/packages/de.k3b.android.intentintercept/ is an app designed to receive all intents, and allows you to inspect the intent. I learned that unrecognized file extensions opened via Simple File Manager are delivered with MIME type application/octet-stream.
https://stackoverflow.com/a/4621284/2683842 reports that <data pathPattern=>.*xyz aborts at the first x it sees, and will fail immediately if not followed by yz. So /sdcard/.hidden/foo.0cc will not pass .*\\.0cc unless you try .*\\..*\\.0cc instead.
I did not verify whether this workaround is necessary.
Android has moved towards content URIs and MIME-Types for intent filters.
The Problem
A content URI does not necessarily have to contain the file's extension or name and it will be different between different applications that are providing the content/file.
Here are some example content URIs from different email applications for the same email attachment:
Outlook -> content://com.microsoft.office.outlook.fileprovider/outlookfile/data/data/com.microsoft.office.outlook/cache/file-download/file--2146063402/filename.customextention
As can see they are all different and are not guaranteed to contain anything related to your actual file. Thus, you cannot use the android:pathPattern like most have suggested.
A work around solution for email attachments
<intent-filter>
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.BROWSABLE"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:scheme="content"/>
<data android:host="*"/>
<!-- Required for Gmail and Samsung Email App -->
<data android:mimeType="application/octet-stream"/>
<!-- Required for Outlook -->
<data android:mimeType="application/my-custom-extension"/>
</intent-filter>
Through testing I found the MIME-Types that Gmail, Outlook, and Samsung Email used and added those to my intent-filter.
Caveats/Gotchas
I found that with my above solution, if I opened any file that was a binary type, it would automatically launch my app. I handled this in my activity by displaying a failed state if we could not parse the file. I figured this was a pretty rare event so it would acceptable.
I could not find any way to launch my app via the file browser without adding <data android:mimeType="*/*"/> to my intent-filter. I couldn't use this because it would then launch my app whenever the user clicked any file on their phone (not just the custom-file-extension ones). I would not recommend adding this to your intent-filter.
Final Thoughts
There is currently no elegant solution for associating your app with a specific extension type in Android. This was the best that I could do in my situation.