Share to Messaging: "Assert.fail() called: Cannot send private file content://"

cloop

I used ImagePipe on my old phone for years to quickly remove metadata and compress images before sending/uploading. On GrapheneOS, when I share from ImagePipe to Messaging, the messaging app opens but is unable to read the image. At first I thought it was a problem with ImagePipe, and I even opened a bug report. However I discovered that Scrambled Exif now implements the same "pipe" functionality, and tried it only to find it can't share images to the messaging app either.

I decided to install a few more apps for testing, until I had painstakingly tried all 25 possible combinations of sharing between 5 different apps.

| From: | ImagePipe | ScrambledExif | DroidFS | SnapSafe | Messaging |
|-----------------------|---------------|---------------|---------------|---------------|---------------|
| to ImagePipe | N/A | Yes | Yes | Yes | Yes |
| to ScrambledExif | Yes | N/A | Yes | Yes | Yes |
| to DroidFS | Yes | Yes | Yes | Yes | No (Crash) |
| to SnapSafe | Yes | Yes | Yes | N/A | No |
| to Messaging | No[1] | No[2] | Yes | Yes | No[3] |

[1] E MessagingApp: Assert.fail() called: Cannot send private file content://imageprovider/cache/share/Imagepipe_0.jpg?displayName=Imagepipe_0.jpg
at com.android.messaging.ui.conversationlist.ShareIntentActivity.addSharedPartToDraft(SourceFile:244)
[2] E MessagingApp: Cannot send private file content://com.jarsilio.android.scrambledEggsif.fileprovider/shared_images/[...].jpg
at com.android.messaging.ui.conversationlist.ShareIntentActivity.addSharedPartToDraft(SourceFile:244)
[3] E MessagingApp: Cannot send private file content://mms/part/[...]
at com.android.messaging.ui.conversationlist.ShareIntentActivity.addSharedPartToDraft(SourceFile:244)

Has anyone else had this problem? Is there a bug here or is it some kind of security feature I'm not aware of? Is it even specific to GrapheneOS, or is the AOSP messaging app just broken? I don't have a stock Android 16 device to test it on.

My current workaround is to share to ImagePipe, save the modified image to storage, and either open it in Gallery and share it to Messaging, or attach it in Messaging directly.

And yes, I am well aware of the "Remove EXIF data after capture" camera option. I'll reenable it if I have to, but I was really hoping to keep metadata on local copies, and only remove it for sharing/uploading. I'm open to other workarounds too, but for now I'd like to focus on the actual problem.

Probably9857

cloop is the AOSP messaging app just broken?

Probably.

The AOSP Messaging app is outdated and likely has issues. GrapheneOS plans to eventually replace it, but AFAIK there is no public timeline for that.

I would suggest trying a different messaging app. QUIK is often recommended, but there are others.

cloop

Probably9857

The thing is, all these apps worked fine with com.android.messaging on my old phone (LineageOS). It was a much older android version, but still.

Probably9857 I would suggest trying a different messaging app. QUIK is often recommended, but there are others.

I might go that route in this case, not sure. I've used it as a secondary messaging app (just for the search feature) but never tried it as default. I've heard QUIK is kind of outdated too, though. I'm hesitant to use a third-party messaging app, but it sounds like I might not have much of a choice.

Probably9857

cloop The thing is, all these apps worked fine with com.android.messaging on my old phone (LineageOS). It was a much older android version, but still.

My guess is that there is a newer way of sharing that those apps are using, but Messaging hasn't been updated to handle it properly.

On your old phone, this new method wasn't available, so an older method was used that Messaging could handle.

If you can show that this works with another app, and create an issue, there is a decent chance GrapheneOS might fix it. Or maybe just create an issue with what you have now...seems pretty clear that the problem is with Messaging in any case.

https://github.com/GrapheneOS/Messaging/issues

cloop

Probably9857 If you can show that this works with another app

Sorry, can you clarify... if what works with what kind of other app?

Sharing from ScrambledExif/ImagePipe to another messaging app? I tried it just now and I can confirm sharing from ScrambledExif to QUIK works, but sharing from ImagePipe to QUIK does not work (interesting).

In the latter case, QUIK doesn't even prompt me to choose a thread, rather it seems to open an imaginary thread titled "//imageprovider/cache/Imagepipe_0.jpg" with no messages and the "This is the start of your conversation. Say something nice!" background.

Probably9857 there is a decent chance GrapheneOS might fix it.

For the Graphene team to fix it, we would have to show that it works on stock and not Graphene OS, right? Which I don't have the ability to test.

Probably9857

cloop For the Graphene team to fix it, we would have to show that it works on stock and not Graphene OS, right?

AOSP Messaging app isn't included in the stock OS, so that would not be reasonable.

I was just looking at the code where it fails, and there is a comment:

// Checks if the file is in /data, and don't allow any app to send personal information.
// We're told it's possible to create world readable hardlinks to other apps private data
// so we ban all /data file uris.

That's sounds like a hack. It's probably been fixed properly by now (one would hope), and this hack could be removed. It probably hasn't been because nobody maintains AOSP Messaging.

cloop

Probably9857

Probably9857 I was just looking at the code where it fails, and there is a comment:

// Checks if the file is in /data, and don't allow any app to send personal information.
// We're told it's possible to create world readable hardlinks to other apps private data
// so we ban all /data file uris.

Thanks for looking at the source. I hadn't thought of that.

The log reports provider content:// URIs in all three cases though, not paths in /data...? Or is the comment talking about something else? I don't really know all the inner workings of Android.

Probably9857 AOSP Messaging app isn't included in the stock OS

If the sharing API (or whatever) changed after stock no longer included AOSP, I guess that would explain why this bug hasn't been widely discovered. i.e. I guess I'm the only person that tried to use ImagePipe or ScrambledExif and AOSP Messaging together on recent a Android version?

Edit: The question is, what are DroidFS and SnapSafe (and Camera and Gallery) doing differently than ScrambledExif and ImagePipe? (And what is QUIK doing differently than AOSP in the case of ScrambledExif?)

cloop

Novalissoide I recommend this over Scrambledeggsif or Imagepipe:

https://github.com/potatameister/MetaPurge/releases

com.potatameister.metapurge
30:5B:F6:26:EE:9D:33:17:BF:81:B7:00:21:9E:DD:D0:6D:D5:F2:1A:9D:73:1A:84:92:AE:65:DA:4C:E3:B0:EF

It shows much more of various EXIF, and other properties of the pictures you analyse, and optionally removes them.

But can it share to AOSP Messaging? Also it may remove more metadata which is a good thing, but I'm not sure if it's necessary for camera pictures. Do the Pixel camera drivers add any metadata that isn't removed by standard EXIF sanitizers? Also it doesn't look like it supports "pipe" behavior (although I don't know for sure). Also it's doesn't appear to be available from F-Droid or seemingly anywhere but Github. Also it declares INTERNET permission even though it claims 100% offline operation (can be revoked by GrapheneOS but still, seems odd). Thanks for the recommendation though. I might give it a try, not sure yet.

JulianKaiser The "assertFail called" crash when sharing private files (like from Files app or Gallery) to Signal or other messengers is a known GrapheneOS limitation right now.

But system apps like Files, Gallery, and Camera can share to Messaging just fine (along with SnapSafe and DroidFS). It's just certain third-party apps like ScrambledExif and ImagePipe that can't share to Messaging. (One exception is that Messaging can't share to Messaging. If you open a thread, tap an image to open it full screen, tap share, and choose another thread, you get a similar "Cannot share private file content://mms/part/xxxx" error.)

Probably9857 The code that fails isn't in the OS though. It is in the Messaging app.

So there are two different things going on here? One is AOSP Messaging on any OS is incompatible with apps that share files in /data because of the hacky code Probably9857 found. The other is the strict content URI enforcement pointed out by JulianKaiser which is specific to GrapheneOS but affects various other apps, including Signal and Immich, that don't fallback to SAF properly (or something). So even if we removed the hack from AOSP Messaging, it's still unclear if it could properly handle the content URI restrictions imposed by GrapheneOS?

Eirikr70 Maybe look at this answer to an issue with another Android app (Immich).

Immich uses share_plus, which shares files via Android's
FileProvider. FileProvider grants the receiving app temporary read
permission. The problem: SMS/MMS apps don't read the file
themselves, they pass it to Android's system MMS service, a
separate process that never receives that permission. The
attachment silently fails. WhatsApp works because it reads the
file in its own process.

Makes sense, but this explanation doesn't sound like it would be specific to GrapheneOS...? It does sound like the same issue, at least based on symptoms; on a technical level, I'm not sure either.

Probably9857 It seems like the file they are attempting to share is located in external storage, where it is assumed other apps will be able to access it.

The apps that fail are trying to share a file from their internal (private) storage. That should work too, but the Messaging app has code to prevent it.

I guess that would kind of explain why Files, Gallery, and Camera can share to Messaging, because they're likely just constructing a URI that points to a file that already exists on external storage. ScrambledExif and ImagePipe are creating and modifying a temporary file located in private storage (/data). Messaging shares a content://mms/part/xxxx URI which I assume resolves to a file in the app_parts directory on private storage.

Still, if this is so, how is it that ScrambledExif can share to QUIK, even though it's sharing a private file (content URI that resolves to a file under /data)? And why is it that DroidFS and SnapSafe can share to all other apps, including Messaging, even though they use an encrypted vault? 🤔

cloop

cloop Eirikr70 Maybe look at this answer to an issue with another Android app (Immich).

Immich uses share_plus, which shares files via Android's
FileProvider. FileProvider grants the receiving app temporary read
permission. The problem: SMS/MMS apps don't read the file
themselves, they pass it to Android's system MMS service, a
separate process that never receives that permission. The
attachment silently fails. WhatsApp works because it reads the
file in its own process.

Makes sense, but this explanation doesn't sound like it would be specific to GrapheneOS...? It does sound like the same issue, at least based on symptoms; on a technical level, I'm not sure either.

Eirikr70 If might not be specific to GrapheneOS, but to the AOSP messaging app, which ends up to be equivalent since probably not many OSs/ROMs SOP with that app.

I see what you mean, but according to JulianKaiser it affects Signal on GrapheneOS too, and QUIK was semi-affected in my testing, so not just AOSP Messaging (although Probably9857 clearly found the offending code in AOSP Messaging). I just meant that the explanation given sounds like it would affect messaging apps in general across all Android flavors, but it does seem to be reported only by GrapheneOS users. Even so, I'm surprised this issue doesn't come up more often.

Anyways, I was looking at the Imagepipe code again and noticed this (https://codeberg.org/Starfish/Imagepipe/src/tag/v0.76/app/src/main/java/de/kaffeemitkoffein/imagepipe/ImageReceiver.java#L3245):

// build the intent from the FileContentProvider from cache without the media store
if (!ImagepipePreferences.autosave(this)){
...
} else {
// build the intent in the classic way from the media store

It turns out, the trick is to enable autosave. Whether it's because the file is shared from external storage (instead of the private cache), or because that code path uses MediaStore instead of FileProvider, I don't know.

So I still haven't figured out the actual problem, but at least I have a workaround for using Imagepipe with AOSP Messaging (and QUIK).

Novalissoide

cloop I recommend this over Scrambledeggsif or Imagepipe:

https://github.com/potatameister/MetaPurge/releases

com.potatameister.metapurge
30:5B:F6:26:EE:9D:33:17:BF:81:B7:00:21:9E:DD:D0:6D:D5:F2:1A:9D:73:1A:84:92:AE:65:DA:4C:E3:B0:EF

It shows much more of various EXIF, and other properties of the pictures you analyse, and optionally removes them.

Probably9857

cloop The log reports provider content:// URIs in all three cases though, not paths in /data...?

That URI apparently resolves to a file path in the /data directory.

cloop what are DroidFS and SnapSafe (and Camera and Gallery) doing differently than ScrambledExif and ImagePipe?

It seems like the file they are attempting to share is located in external storage, where it is assumed other apps will be able to access it.

The apps that fail are trying to share a file from their internal (private) storage. That should work too, but the Messaging app has code to prevent it.

I think that code was a temporary fix for a vulnerability in the app sandbox that was fixed a long time ago. I think that code just needs to be removed. (But I'm also not an Android expert, so I'm just making some educated guesses here.)

Eirikr70

Maybe look at this answer to an issue with another Android app (Immich). I'm not tech and can't decrypt if the problem might be the same but the symptom seems similar to me.

JulianKaiser

The "assertFail called" crash when sharing private files (like from Files app or Gallery) to Signal or other messengers is a known GrapheneOS limitation right now.
It happens because the OS enforces strict content URI rules for private storage, and some apps (especially Signal) don't handle the SAF fallback gracefully when they expect direct file access.
Quick workarounds that usually work:

Share from the app itself (open the photo/video in Gallery, tap Share there instead of long-press → Share).
Or copy the file to /sdcard first (public storage), then share from there – no crash, but less secure.
If it's recurring, report it on the Signal GitHub issue tracker with the exact GrapheneOS version and app version; they sometimes add workarounds for hardened OSes.

Dev team is aware of similar share crashes, so it might get patched in a future release. For now the copy-to-public step is the most reliable fix.

Probably9857

JulianKaiser The "assertFail called" crash when sharing private files (like from Files app or Gallery) to Signal or other messengers is a known GrapheneOS limitation right now.

The code that fails isn't in the OS though. It is in the Messaging app.

Maybe it would still fail later if the app didn't check preemptively. If so, it seems preferable (IMO) to let that happen instead of having this hacky logic in the app.

But maybe there is a reason. I'm not an Android dev.

Eirikr70

cloop Makes sense, but this explanation doesn't sound like it would be specific to GrapheneOS...? It does sound like the same issue, at least based on symptoms; on a technical level, I'm not sure either.

If might not be specific to GrapheneOS, but to the AOSP messaging app, which ends up to be equivalent since probably not many OSs/ROMs SOP with that app.