I have an Android app that used to work perfectly for attaching files to Gmail through the compose interface. The app would automatically select a specific file when users chose “Attach File > Open From > MyApp”.
Here’s the code I was using:
String filePath = Environment.getExternalStorageDirectory() + "/document.mp4";
File document = new File(filePath);
Uri fileUri = Uri.fromFile(document);
Intent resultIntent = new Intent();
resultIntent.setData(fileUri);
setResult(Activity.RESULT_OK, resultIntent);
finish();
This worked great until I updated to Android 6.0. Now Gmail shows an error message saying “Can’t attach empty file” even though the file exists and has content.
I noticed that ES File Explorer handles this differently. When I use it to attach the same file, it gives me two options: “Normal Android Way (For MMS, Gmail…)” and “File Way (Try this if above fails)”. The Normal Android Way works but my current method fails like the File Way option.
Does anyone know what ES File Explorer does differently in the Normal Android Way? I need to update my code to work with newer Android versions.
I already tried using putExtra with STREAM but couldn’t get it working properly.
yeah, classic android 6+ permissions issue. you’re using the old file:// scheme that got killed for security reasons. es file explorer uses content:// uris through a provider - that’s why it works. switch to mediastore.insertimage() or documentsprovider instead of direct file access. gmail expects content uris now, not file paths.
Your problem is Android 6.0’s scoped storage breaking the file:// URI scheme. When you use Uri.fromFile(), Gmail can’t access the file because of stricter permissions. ES File Explorer’s “Normal Android Way” uses the MediaStore API for media files like MP4s. Skip FileProvider - try MediaStore.Video.Media.EXTERNAL_CONTENT_URI instead. Use ContentResolver to query and get the proper content URI for your video. For MP4 files specifically: query MediaStore with your file path to get the content URI. Gmail accepts these MediaStore URIs as legit content and won’t give you that empty file error. Works across all Android versions without needing FileProvider setup in your manifest.
Had the same headaches when Android 6.0 dropped and broke my legacy file handling code. The problem is stricter URI policies that block direct file access between apps. Your Uri.fromFile() creates file:// URIs, which Gmail now rejects as security risks. ES File Explorer’s normal mode probably uses Storage Access Framework or proper content providers. Skip the FileProvider headaches and use Intent.ACTION_SEND with EXTRA_STREAM pointing to your content URI instead. For MP4 files, query the MediaStore.Video.Media table to get the proper content URI, then attach that to your result intent. Create content URIs through DocumentsContract or MediaStore depending on your file type. This mimics how system file pickers work and kills the empty file error completely.
This happens because Android 6.0 got stricter about file URIs and storage access. Uri.fromFile() is deprecated and breaks on newer versions. I hit the same issue updating an old document app. Here’s what fixed it: Use FileProvider instead of direct file URIs. Add a FileProvider to your manifest, then call FileProvider.getUriForFile() to create a proper content URI. Gmail can read these without throwing the empty file error. That ‘Normal Android Way’ ES File Explorer uses? It’s basically FileProvider - creating content URIs that work with Android’s security model instead of passing raw file paths. Don’t forget to add Intent.FLAG_GRANT_READ_URI_PERMISSION to your result intent so the receiving app can actually read the file. Made this change and my attachments work perfectly on Android 6.0+.
Hit this same nightmare when Android 6 broke our enterprise app. Those file URI security changes completely destroyed our document workflow.
You need proper automation for this - manual FileProvider setup becomes a disaster when you’re juggling multiple file types and destinations.
I created a flow that auto-detects what the target app needs and formats URIs correctly. Handles the FileProvider stuff, sets permissions, and falls back to other methods when things break. Works with Gmail, Outlook, Slack - you name it.
Best part? No more worrying about Android version differences or weird app quirks. Just give it your file and where it’s going.
Saved us weeks of debugging across different devices and OS versions. Beats manually coding FileProvider logic and crossing your fingers.