github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-16 08:33:59 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

Not all attachment formats open #274

New Issue
Closed
opened 2025-11-07 08:33:42 -06:00 by GiteaMirror · 12 comments
GiteaMirror commented 2025-11-07 08:33:42 -06:00
Owner
Copy Link

Originally created by @kzshantonu on GitHub (Sep 21, 2018).

Originally assigned to: @mpbw2 on GitHub.

PDFs and some certain file formats don't open, even when I do have the apps installed to open them

Originally created by @kzshantonu on GitHub (Sep 21, 2018). Originally assigned to: @mpbw2 on GitHub. PDFs and some certain file formats don't open, even when I do have the apps installed to open them
GiteaMirror commented 2025-11-07 08:33:43 -06:00
Author
Owner
Copy Link

@bassarf commented on GitHub (Jan 19, 2019):

Also: why am I not able to just download the attachment and then use it?
One could change the suffix of the file to hide what file it actually is. So you need to download it first to change the suffix and then use it as intended.

Or in my case the app I want to use the attachment with does not register the file type.

@bassarf commented on GitHub (Jan 19, 2019): Also: why am I not able to just download the attachment and then use it? One could change the suffix of the file to hide what file it actually is. So you need to download it first to change the suffix and then use it as intended. Or in my case the app I want to use the attachment with does not register the file type.
GiteaMirror commented 2025-11-07 08:33:43 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 21, 2019):

I'd like to be able to download my private keys and import into the Termius mobile app to manage remote servers. When attempting to download the attachments, Bitwarden gives me an error message saying: Your device cannot open this type of file.

@kspearrin Would it be possible to remove this restriction?

Similarly to what @bassarf said, some users also use custom file extensions. My private keys in Putty format end in .ppk and my private keys in OpenSSH format use .pk. A lot of times it's simply developer preference.

@ghost commented on GitHub (Sep 21, 2019): I'd like to be able to download my private keys and import into the Termius mobile app to manage remote servers. When attempting to download the attachments, Bitwarden gives me an error message saying: `Your device cannot open this type of file.` @kspearrin Would it be possible to remove this restriction? Similarly to what @bassarf said, some users also use custom file extensions. My private keys in Putty format end in `.ppk` and my private keys in OpenSSH format use `.pk`. A lot of times it's simply developer preference.
GiteaMirror commented 2025-11-07 08:33:43 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Sep 22, 2019):

Our code for creating an intent to open files is here:
ced9d33d2e/src/Android/Services/DeviceActionService.cs (L164-L198)

I am not sure why, but this code can return no intent/activities if it can't understand how to open the file. Not sure what other alternative there is?

@kspearrin commented on GitHub (Sep 22, 2019): Our code for creating an intent to open files is here: https://github.com/bitwarden/mobile/blob/ced9d33d2eccaf968e83528b6af577bf82361154/src/Android/Services/DeviceActionService.cs#L164-L198 I am not sure why, but this code can return no intent/activities if it can't understand how to open the file. Not sure what other alternative there is?
GiteaMirror commented 2025-11-07 08:33:43 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 27, 2019):

I'm not an Android Developer, so I personally don't know. In my case I prefer to download the file, not open the file. Similar to issue #192 which seems to have been closed.

Edit: I've made a Feature Request on the Bitwarden Community Forums. If anyone else is interested be sure to show your support there.

https://community.bitwarden.com/t/download-attachments-as-an-alternative-to-open-with/8226

@ghost commented on GitHub (Sep 27, 2019): I'm not an Android Developer, so I personally don't know. In my case I prefer to download the file, not open the file. Similar to issue #192 which seems to have been closed. Edit: I've made a Feature Request on the Bitwarden Community Forums. If anyone else is interested be sure to show your support there. https://community.bitwarden.com/t/download-attachments-as-an-alternative-to-open-with/8226
GiteaMirror commented 2025-11-07 08:33:44 -06:00
Author
Owner
Copy Link

@michaelkourlas commented on GitHub (Feb 18, 2020):

@kspearrin To save files, you need to use ACTION_CREATE_DOCUMENT.

I use this functionality in my own app to export a database. Here's a simplified example:

class SampleActivity : Activity() {
    val EXPORT_REQUEST_CODE = 1;

    fun export() {
        val intent = Intent(Intent.ACTION_CREATE_DOCUMENT)
        intent.type = "application/octet-stream"
        startActivityForResult(intent, EXPORT_REQUEST_CODE)
    }
    
    override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
        if (requestCode == EXPORT_REQUEST_CODE && resultCode == RESULT_OK) {
            val exportFd = it.contentResolver.openFileDescriptor(uri, "w") ?: throw Exception("Could not open file")
            val exportStream = FileOutputStream(exportFd.fileDescriptor)
            val fileStream = FileInputStream(<path to file to save>)
            exportStream.channel.truncate(0)
            val buffer = ByteArray(1024)
            do {
                val length = fileStream.read(buffer)
                if (length > 0) {
                    exportStream.write(buffer, 0, length)
                } else {
                    break
                }
            } while (true)
            exportStream.close()
            fileStream.close()
        }
    }
}
@michaelkourlas commented on GitHub (Feb 18, 2020): @kspearrin To save files, you need to use [`ACTION_CREATE_DOCUMENT`](https://developer.android.com/guide/topics/providers/document-provider). I use this functionality in my own app to export a database. Here's a simplified example: ```kotlin class SampleActivity : Activity() { val EXPORT_REQUEST_CODE = 1; fun export() { val intent = Intent(Intent.ACTION_CREATE_DOCUMENT) intent.type = "application/octet-stream" startActivityForResult(intent, EXPORT_REQUEST_CODE) } override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { if (requestCode == EXPORT_REQUEST_CODE && resultCode == RESULT_OK) { val exportFd = it.contentResolver.openFileDescriptor(uri, "w") ?: throw Exception("Could not open file") val exportStream = FileOutputStream(exportFd.fileDescriptor) val fileStream = FileInputStream(<path to file to save>) exportStream.channel.truncate(0) val buffer = ByteArray(1024) do { val length = fileStream.read(buffer) if (length > 0) { exportStream.write(buffer, 0, length) } else { break } } while (true) exportStream.close() fileStream.close() } } }
GiteaMirror commented 2025-11-07 08:33:44 -06:00
Author
Owner
Copy Link

@mpbw2 commented on GitHub (Feb 28, 2020):

I've been working on this issue and I'm curious what everyone's thoughts are regarding expected behavior. Do we:

1 - Try to open the attachment like we do now, but fall back to the option to save if that fails
2 - Always open images (based on file extension) and prompt to save everything else
3 - Always prompt to save
4 - Provide options for both actions up front
5 - Something else I haven't thought of

Option 4 seems like the best choice but has the potential to become a thing once UX changes are involved. My first thought was to add long-press support on the "open" button to prompt for saving, but discoverability of that capability can be an issue for less experienced Android users.

Thoughts?

@mpbw2 commented on GitHub (Feb 28, 2020): I've been working on this issue and I'm curious what everyone's thoughts are regarding expected behavior. Do we: 1 - Try to open the attachment like we do now, but fall back to the option to save if that fails 2 - Always open images (based on file extension) and prompt to save everything else 3 - Always prompt to save 4 - Provide options for both actions up front 5 - Something else I haven't thought of Option 4 seems like the best choice but has the potential to become a thing once UX changes are involved. My first thought was to add long-press support on the "open" button to prompt for saving, but discoverability of that capability can be an issue for less experienced Android users. Thoughts?
GiteaMirror commented 2025-11-07 08:33:44 -06:00
Author
Owner
Copy Link

@michaelkourlas commented on GitHub (Feb 28, 2020):

Another option would be to always save the file, but display a notification when this process is complete. Tapping the notification would open the file. This is the UI pattern used when downloading a file using a web browser.

@michaelkourlas commented on GitHub (Feb 28, 2020): Another option would be to always save the file, but display a notification when this process is complete. Tapping the notification would open the file. This is the UI pattern used when downloading a file using a web browser.
GiteaMirror commented 2025-11-07 08:33:44 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 28, 2020):

Option 4, in my opinion. I think adding a second icon for saving the file is best.

Users can then easily choose to open the attachment or download and save the attachment.

I think the current icon makes more sense for saving, and then an alternative icon for opening the file.

@ghost commented on GitHub (Feb 28, 2020): Option 4, in my opinion. I think adding a second icon for saving the file is best. Users can then easily choose to open the attachment or download and save the attachment. I think the current icon makes more sense for saving, and then an alternative icon for opening the file.
GiteaMirror commented 2025-11-07 08:33:45 -06:00
Author
Owner
Copy Link

@bassarf commented on GitHub (Feb 28, 2020):

If I would implement it, I think I would choose the behavior to be:
Tapping the file name would open it. And a download icon for downloading it.
I agree with @DougParker1992 that the current icon looks like a download icon

Other than that, I would rate the alternatives in the following order:

  • Having separate icons (the current icon for downloading and an eye or something for opening)
  • Always prompt to save (including the notification thing mentioned by @michaelkourlas )
  • Option 5 "Something else I haven't thought of"
  • Just give me a list of all installed apps, so I can choose which one should open the file (like the share function in Android)
  • Any other option involving: trying to open the thing first.

But that's just me. I don't use it to store pictures which I just want to open.
For me this feature makes more sense for storing sensitive stuff like 2FA backup keys or something else. Maybe some key files you need to log in or open something. Maybe your private pgp key. And maybe you want to "disguise" it as Picture. Or it's an encrypted file which you have to do some stuff with after downloading. Or I want to send the file to someone after downloading.
It would be interesting to know how the majority uses the attachments.

Anyhow.... I think opening it first is like an autocorrect fail. It's annoying when software think it's smart when it's wrong. Then it's better to don't be smart.

I personally would be satisfied if there is just one straight forward way to download the attachments.

Thank you for working on it, and thank to for asking for feedback.

@bassarf commented on GitHub (Feb 28, 2020): If I would implement it, I think I would choose the behavior to be: Tapping the file name would open it. And a download icon for downloading it. I agree with @DougParker1992 that the current icon looks like a download icon Other than that, I would rate the alternatives in the following order: * Having separate icons (the current icon for downloading and an eye or something for opening) * Always prompt to save (including the notification thing mentioned by @michaelkourlas ) * Option 5 "Something else I haven't thought of" * Just give me a list of all installed apps, so I can choose which one should open the file (like the share function in Android) * Any other option involving: trying to open the thing first. But that's just me. I don't use it to store pictures which I just want to open. For me this feature makes more sense for storing sensitive stuff like 2FA backup keys or something else. Maybe some key files you need to log in or open something. Maybe your private pgp key. And maybe you want to "disguise" it as Picture. Or it's an encrypted file which you have to do some stuff with after downloading. Or I want to send the file to someone after downloading. It would be interesting to know how the majority uses the attachments. Anyhow.... I think opening it first is like an autocorrect fail. It's annoying when software think it's smart when it's wrong. Then it's better to don't be smart. I personally would be satisfied if there is just one straight forward way to download the attachments. Thank you for working on it, and thank to for asking for feedback.
GiteaMirror commented 2025-11-07 08:33:45 -06:00
Author
Owner
Copy Link

@mpbw2 commented on GitHub (Mar 2, 2020):

Thanks everyone for the feedback. I've implemented something that I think covers the bases without introducing any technical debt on our side.

After clicking the download icon:

  • If file can be opened by system/app, present user with "open or save" prompt
  • If file can't be opened, proceed directly to save mechanism

The end result is we can save everything + optionally open when available.

Edit: Removed gigantic screenshots

@mpbw2 commented on GitHub (Mar 2, 2020): Thanks everyone for the feedback. I've implemented something that I think covers the bases without introducing any technical debt on our side. After clicking the download icon: - If file can be opened by system/app, present user with "open or save" prompt - If file can't be opened, proceed directly to save mechanism The end result is we can save everything + optionally open when available. Edit: Removed gigantic screenshots
GiteaMirror commented 2025-11-07 08:33:46 -06:00
Author
Owner
Copy Link

@bassarf commented on GitHub (Mar 2, 2020):

looks very good. Thank you.

@bassarf commented on GitHub (Mar 2, 2020): looks very good. Thank you.
GiteaMirror commented 2025-11-07 08:33:46 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 2, 2020):

This looks like an elegant solution to me. :)

Thank you very much.

@ghost commented on GitHub (Mar 2, 2020): This looks like an elegant solution to me. :) Thank you very much.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#274
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?