Recently I wanted to open a markdown email attachment on my Nexus 4, but after clicking “readme.md” instead of seeing the file contents I saw this message:
I downloaded few apps from Google Play, but the message was still appearing. The same applications could open a local markdown file, so I went back to GMail app to download the attachment, but another unpleasant surprise awaited me:
There is no “overflow” menu on the attachment (see the screenshot below), which means I couldn’t access the “Save” option, so I could open it as a local file.
At this point I was:
- Pissed off, because, cmon, GMail is probably the most used app working on the mature operating system and I can’t download a fucking file with it.
- Curious, because it looked liked an interesting issue with GMail app.
The first clue was in the GMail logs in the logcat:
Note the Uri: there is no file name and no file extension, and the mime-type is a generic application/octet-stream (most likely because the “md” extension is not present in libcore.net.MimeUtils). The markdown viewers/editors I downloaded probably register intent filters for specific file extensions, so they don’t know they could handle this file. It sucks big time, because it means that the applications for viewing files with non-standard extensions would have to register for application/octet-stream mime-type, and even though they handle very specific file types they all appear in the app chooser dialog for many different file types, which defeats the whole purpose of Android Intent system and reduces the UX.
My first idea was to create an “GMail Attachment Forwarder” app which registers for any content from GMail, gets the attachment mail by querying the
DISPLAY_NAME column on the Uri supplied by GMail, save this information along with original GMail Uri in public
ContentProvider, and start the activity using Uri exposed by my
ContentProvider which does contain attachment name. This
ContentProvider should also forward any action to original GMail Uri.
Unfortunatly I was foiled by the
ContentProvider’s permissions systems: the Activity in my app was temporarily granted with the read permissions for GMail’s
ContentProvider, but this permissions did not extend to my
ContentProvider and the app I was forwarding the attachment to failed because of the insufficient permissions.
This approach didn’t work, but having a catch-all handler for GMail attachments unlocked the attachment actions. I also noticed that when the attachment is downloaded, the GMail uses a slightly different intent:
This led me to plan B: have an app which enables the attachment download and use other apps to open downloaded attachments. I renamed my app to GMail Attachment Unlocker, cleared the manifest and source folder leaving only a single, automatically closing activity:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9
The full source code is available on my Github (althought there really isn’t much more than what is posted here). In the end I also ended up writing my own markdown viewer (source code in another repo on my Github), because none of the apps I have downloaded properly rendered tags (hint: you have to use
WebView.loadDataWithBaseUrl instead of