45

I have a FileProvider which I use when attaching files on the SD Card to emails.

This works on Lollipop and Marshmallow in any app using an Intent.

However, in Android 4.3 when using the Email app, the attachment appears in the email when composing but when it's sent, on the recipient's end the attachment isn't there. For all other tested applications it works (Gmail, Evernote, Drive).

I am not deleting the file before the email is sent.

Here is my code.

final Intent fileShareIntent = new Intent(android.content.Intent.ACTION_SEND);
fileShareIntent.putExtra(android.content.Intent.EXTRA_SUBJECT, emailSubject);
fileShareIntent.putExtra(android.content.Intent.EXTRA_TEXT, emailText);
Uri fileUri = STFileProvider.getContentUriForProvidedFile(this,file);
fileShareIntent.putExtra(Intent.EXTRA_STREAM,fileUri);
fileShareIntent.setType(mimeType);
fileShareIntent.putExtra(android.content.Intent.EXTRA_EMAIL, new String[]{prefs.getString("default_email_preference", "")});
startActivity(Intent.createChooser(fileShareIntent,getString(R.string.share_with)));

EDIT I have found a the Exception's stack trace which is inline with @CommonsWare's suggestion

01-04 17:39:00.430 6828-6828/? W/System.err: java.lang.IllegalArgumentException: column '_data' does not exist
01-04 17:39:00.430 6828-6828/? W/System.err:     at android.database.AbstractCursor.getColumnIndexOrThrow(AbstractCursor.java:303)
01-04 17:39:00.430 6828-6828/? W/System.err:     at android.database.CursorWrapper.getColumnIndexOrThrow(CursorWrapper.java:78)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.email.activity.MessageCompose.getFilePath(MessageCompose.java:21476)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.email.activity.MessageCompose.getFilePathOfAttachment(MessageCompose.java:17710)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.email.activity.MessageCompose.addAttachment(MessageCompose.java:19140)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.email.activity.MessageCompose.access$11000(MessageCompose.java:362)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.email.activity.MessageCompose$LoadAttachmentsTaskFromIntent.onProgressUpdate(MessageCompose.java:15277)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.email.activity.MessageCompose$LoadAttachmentsTaskFromIntent.onProgressUpdate(MessageCompose.java:15101)
01-04 17:39:00.430 6828-6828/? W/System.err:     at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:647)
01-04 17:39:00.430 6828-6828/? W/System.err:     at android.os.Handler.dispatchMessage(Handler.java:99)
01-04 17:39:00.430 6828-6828/? W/System.err:     at android.os.Looper.loop(Looper.java:176)
01-04 17:39:00.430 6828-6828/? W/System.err:     at android.app.ActivityThread.main(ActivityThread.java:5419)
01-04 17:39:00.430 6828-6828/? W/System.err:     at java.lang.reflect.Method.invokeNative(Native Method)
01-04 17:39:00.430 6828-6828/? W/System.err:     at java.lang.reflect.Method.invoke(Method.java:525)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1046)
01-04 17:39:00.430 6828-6828/? W/System.err:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:862)
01-04 17:39:00.430 6828-6828/? W/System.err:     at dalvik.system.NativeStart.main(Native Method)
rds
  • 26,253
  • 19
  • 107
  • 134
StuStirling
  • 15,601
  • 23
  • 93
  • 150
  • 1
    You might try [this fix](http://stackoverflow.com/a/25020642/115145). I have a packaged version of that solution in [my CWAC-Provider library](https://github.com/commonsguy/cwac-provider#usage-legacycompatcursorwrapper). – CommonsWare Jan 04 '16 at 17:07
  • I don't think this is the same issue. It's not crashing at all, the attachment just isn't staying attached when sending. – StuStirling Jan 04 '16 at 17:19
  • I haven't used the Email app. If it is showing some details in its UI that could only be obtained from the actual stream, then you're right, this can't be the issue. If, OTOH, the only stuff you see in the UI is stuff that could be determined without actually using the `Uri` contents, then it may be they are just catching the exception with a broken `DATA`-dependent implementation. Since you already have a custom `FileProvider` subclass, adding my `LegacyCompatCursorWrapper` should only take ~6 lines or so (dependency + `query()`), so it may be worth a test. – CommonsWare Jan 04 '16 at 17:21
  • At the moment I don't do anything with the CRUD operations. In fact, after following a tutorial all they do is throw new RuntimeExceptions. I'm not sure how to use your `LegacyCompatCursorWrapper` with my subclass of `FileProvider` as I don't have a `Cursor` to begin with – StuStirling Jan 04 '16 at 17:39
  • @CommonsWare please see original question for stack trace update – StuStirling Jan 04 '16 at 17:41
  • To use `LegacyCompatCursorWrapper`, override `query()`, chain to the superclass, wrap the `Cursor` the superclass returns, and return the wrapped `Cursor`. See [this sample project](https://github.com/commonsguy/cw-omnibus/tree/master/ContentProvider/V4FileProvider) for a demonstration. – CommonsWare Jan 04 '16 at 17:45
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/99716/discussion-between-disco-s2-and-commonsware). – StuStirling Jan 04 '16 at 18:04
  • I don't believe this is a duplicate. Implemented your `LegacyCompatCursorWrapper` as described above and still doesn't work. Also I should have got a RuntimeException before when `query` was called, however I didn't so i don't believe it's my code. – StuStirling Jan 04 '16 at 18:15
  • "Implemented your LegacyCompatCursorWrapper as described above and still doesn't work" -- then you should be getting a different stack trace. "I should have got a RuntimeException before when query was called" -- your app is not the one with the problem. You are trying to work around a problem with another app. The exceptions are in the other app, in its process. You're hoping that there is enough logging to identify the problem and fix the issue. – CommonsWare Jan 04 '16 at 18:24
  • Correct in the "hoping". Can you remove the Duplicate Question status as I think we have come to the conclusion that this is a different issue. – StuStirling Jan 04 '16 at 18:28
  • Your question, as written, is a duplicate of the indicated question, as indicated by the stack trace. If you are still getting that stack trace, and therefore feel that you are having problems implementing the suggested fixes, open a separate Stack Overflow question where you provide the code you are now using, along with the current symptoms. – CommonsWare Jan 04 '16 at 18:35
  • If you are no longer seeing that stack trace, then you have a *different problem* than the one in your question, as the recommended fix *fixed the problem from your question*, and so there is no point in removing the flag, since your question has not changed. – CommonsWare Jan 04 '16 at 18:35
  • I'm afraid I have to disagree on the duplicate. It doesn't crash Facebook or Twitter. It is the Email app I am having issues with and this isn't crashing. Even with the new code as suggested by you I'm still getting exactly the same stack trace from the logcat. It hasn't change what's happening at all. Also the stack trace is completely different. – StuStirling Jan 04 '16 at 18:41
  • "It doesn't crash Facebook or Twitter" -- they fixed their bugs in the past ~18 months, apparently. By your own admission, you are having this problem with *an old app* (Email from Android 4.3). "I'm still getting exactly the same stack trace from the logcat" -- this statement does not agree with "the stack trace is completely different". – CommonsWare Jan 04 '16 at 18:46
  • I still don't see how this is a duplicate. By "exact same stack trace", I mean the same stack trace I was getting before I implemented your `LegacyCompatCursorWrapper` not the same as the other questions. You can see it above in the question. It is a completely different question and problem to the one you're saying it's a duplicate of. Different app (granted Facebook & Twitter have fixed), different stack trace and not resolved by the same fix. – StuStirling Jan 04 '16 at 18:51
  • The stack trace is from what version of Android? And what device? I've checked source code of the email app and didn't find a code corresponding to the stack trace. – Milos Fec Jan 12 '16 at 09:32
  • @MilosFec This was taken from a Samsung Galaxy S3 running Android 4.3 – StuStirling Jan 12 '16 at 09:56
  • Can you try it on another (not Samsung) Android 4.3 device? It is possible that your email app has been modified by Samsung. It looks like this specific email app looks for a field "_data" in the cursor (provided by your ContentProvider?) – Milos Fec Jan 12 '16 at 13:03

2 Answers2

1

I know, it might be too late, but I stumbled over the exact same problem and it took me a while to find my mistake:

My fault was, that I deleted the original file I like to send when my app got back from the email-app. (I tried to clean up temporary files)

Unfortunately, the email-app does not send the mail right away nor does it make a copy of the attachment. So when the file will be deleted before the mail was sent (as I did) the attachment got lost.

This behavior is different from most other apps (including Gmail-app) that take care of the file before returning back to my app.

Talha Tayyab
  • 8,111
  • 25
  • 27
  • 44
salcosand
  • 2,022
  • 4
  • 24
  • 27
0

It is about database sqlite .

there are 2 possibilities:

  1. You changed something in database or table.

or

  1. Your accessing field which is may be not correct or not present in code.

Solution:

  1. Uninstall app and test again with new changes in db.

  2. correct you database code.

Talha Tayyab
  • 8,111
  • 25
  • 27
  • 44
Mahesh Lad
  • 1,997
  • 1
  • 9
  • 8