I believe the behavior when opening attachments has changed sometime in the past few releases (maybe starting five or six months ago?).
With a message containing an attachment (a PDF document, for example), if I touch the largest 90% of the button, I get the “Open With” selector where I can choose to view or share it using various apps installed on the phone*. If I choose one of the apps, they often complain or behave like the file doesn’t have an extension. If I use the app to save the file, it will have a long meaningless string (multipart MIME identifier?) having lost the original file’s name.
If instead I touch the right side of the button with the download icon (to download the attachment to my phone), the filename is preserved.
I believe that earlier versions of K-9 preserved the filename in both circumstances.
Maybe it’s peculiar to the kinds of files I open (mostly PDFs). Have others noticed this behavior?
That’s because the attachment is passed on as an intent, not a file. Developers are not supposed to pass files to other apps. Instead, they are supposed to use either the file API or an intent…
The dialogue asking you which app to use is the result of multiple apps having registered for the intent.
Long story short: The filename is lost due the intent mechanics.
But I think one should be able to pass the filename to the intent as secondary content…?
I feel almost certain it used to work, because I don’t remember having to mess with renaming files after (for example) sending them to Dropbox or Google Drive.
K-9 Mail has behaved this way for a long time. Whether the correct filename is used/displayed depends on the app opening the attachment.
What happens is that K-9 Mail asks the system to open the attachment by giving a special URI, e.g. content://com.fsck.k9.attachmentprovider/00000000-0000-4000-0000-000000000000/42. There exists an API that receiving apps can use to get metadata about the content using this URI (see OpenableColumns). That metadata includes a “display name”, which K-9 Mail sets to the actual file name.
Many apps, however, don’t do the right thing. They simply treat the last segment of the URI as the name (42 in the example).
