Summary:
Since a rather long time, ACRA seems to not attach logs to the crash report email.
For instance, I just got a crash and after the ACRA screen, Gmail opens on this screen:

As you can see, the email is empty, so there is no point sending it.
Fortunately I had logcat running this time, here it is, hopefully it can explain why the crash info is not included in the email:
empty_acra.txt
HI, I am an Outreachy applicant and would like to contribute,
Kindly assign this issue to me
Also, I know just the basics of Android dev. It would be really helpful if you could help me get started with setting up the project.
@vvijayalakshmi21 It is yours :-)
Here is how I would do:
Thanks!
FWIW, I _recently_ tried to send the crash email from ACRA using K-9 mail and I was able to see the crash information in the mail body. I've even sent it to the crash Google group where people with access to it can find it for reference.
To clarify my previous comment, I'm just saying crash reporting works fine with K-9 mail. So, there's a chance this _might be_ a Gmail specific thing that needs to be handled.
Thank you so much for the direction sir.
Kindly help me get started. How do I set up the project in my local machine? (Windows 10 Home)
Is there a way to replicate the issue in the live website?
@sivaraam Interesting! So it seems to be specific to the crash found in the empty_acra.txt above. I modify the instructions.
@vvijayalakshmi21 See https://github.com/commons-app/documentation/blob/master/android/Volunteers-welcome!.md
Hi Nicolas, I have cloned the repo as mentioned in the guidelines. On reading about the exception from the above log file, it seems like it is more likely to occur in the cases when 1) Order of read and write in Parcelable is different, 2) the CREATOR is not mentioned as static in proguard. I checked the source code and upon checking I see that in our code both of them are rightly done.
I also read in one of the posts that such issue could happen when the app is kept open for a long time in the background and when a memory-consuming app is opened then this app will be cleared of the memory which leads to a crash when accessed again. Would it be possible to let me know how you reproduced this issue?
Do you think I can just change the order in one of the Parcelable codes to reproduce the crash and see what happens? Will this be a good start to approach? Kindly let me know your thoughts about this.
So it seems to be specific to the crash found in the empty_acra.txt above.
I just checked now and came to know that this really isn't specific to the crash observed by @nicolas-raoul. In my observation, for a crash that's different from the one observed by Nicolas:
So, I really think the actual problem is the interaction with Gmail.
@vvijayalakshmi21 Can you verify this?
@sivaraam Just want to clear my understanding on this issue. The problem is that we are not seeing the attachment file (in the case of a crash in the app) in the composed mail when we use Gmail whereas other mail providers like K-9 works just fine. So I have to check if this could be replicated for any crash. Is that right? Kindly confirm
@vvijayalakshmi21 I'm not sure about whether an attachment is added when you report crash but when I report a crash (read 'send a crash report email') using K-9 mail I see the To, Subject and Body fields of the e-mail filled correctly. Here's a screenshot of K-9 mail:

When I do the same reporting with Gmail only the To field gets filled. The Subject and Body are empty:

I know crash reporting works fine with K-9 mail but haven't tested other e-mail clients. Hope this helps. Let me know if need any other clarifications. 馃檪
Thanks so much for this. I read a couple of S.Overflow posts related to this:
https://stackoverflow.com/questions/59314608/android-studio-mailto-intent-doesnt-show-subject-and-mail-body
https://stackoverflow.com/questions/59237274/email-intent-subject-is-ignored-in-gmail-but-works-with-other-mail-clients
I have been trying to replicate the issue and try out the above solutions using my emulator on Android studio but I have been having issues. Could you please help me out?
I have been trying to replicate the issue and try out the above solutions using my emulator on Android studio but I have been having issues. Could you please help me out?
Sure. Share the details about the issues you are facing. 馃檪
The target device for the app is set as Pixel 3a API 28.

I have been trying to run the emulator. The process is running in the background but I am not able to view the Emulator.

I also tried to run the app on my device (Pixel 3a - same as the emulator I have configured) but I could not get it installed.

I noticed that the apk is by default generated in the debug folder (../apps-android-commons\app\build\outputs\apk\beta\debug). Should I add a release config?
Requesting your help to get this fixed
You can't install on your device? have you enabled usb debugging in developer settings?
You could also try a much lower spec emulator, I go for much smaller screens because even though the emulator has improved greatly over the years it is still awful.
There is no need to add a release config in order to test the app, debug should work. You may want to experiment with different kinds of virtual devices, and also make sure they are up to date.
What exactly happens when you try with your real device?
The Android emulator does not show up even though the process is running in the background. I missed to enable the developer options and now I can install and run the app in my device but the debug points are not hit despite having USB debugging set to true
... run the app in my device but the debug points are not hit despite having USB debugging set to true
The breakpoints work only if you run the debug variant of the app. You can do that by hitting the debug icon instead of the run icon in Android studio. This is how the debug icon would look like:

Refer the following page for more information: https://developer.android.com/studio/debug/
I can confirm that this problem still happens for me on current master (I use Gmail).
@vvijayalakshmi21 , how are things going?
Hey @vvijayalakshmi21 , since this issue is a blocker for v2.13 release (urgent), 谋 may need to claim this one. By looking the comments above the last one sent 2 days ago, I feel like you are not around anymore and this should be okay for you. I hope this is ok for you :)
Hi, My sincere apologies for not responding here. I had been on quarantine with no access to my laptop. I totally understand the urgency of the issue. Please go ahead.
@misaochan or @nicolas-raoul Please could you assign me another issue to work on? I am available from today.
@vvijayalakshmi21 Sure, no problem, thanks for letting us know. How about #3117? :-)
Hi @neslihanturan Not sure if this has been already fixed. But just noticed that the logs DO get attached to Gmail when we click ''Send Log file" from Settings.

@vvijayalakshmi21 Those are not the logs we're concerned about in this issue. We're concerned about the crash logs not getting attached from (ACRA) crash dialog. After you face an app crash you are shown a dialog (by ACRA) that suggests you to send the logs via e-mail for further debugging. It looks something like the following:

When you use Gmail to complete that action the logs are not attached. That's the issue.
Hi @sivaraam, I think we're both highlighting the same point. It's from the acra dialog where the logs aren't attached to Gmail and not that the logs aren't attached to Gmail at all. Just wanted to drop this note if that'd be helpful in any way.
Thanks @vvijayalakshmi21 , it's interesting to see that Send Log File works but not ACRA. That does help us narrow the potential causes indeed.
I found a very similar issue is mentioned here, and it is told that fixed from Gmail side: https://github.com/ACRA/acra/issues/744
Well an interesting detail,if I change ACRA configuration to send the stacktrace as file, instead of text as:
@AcraMailSender(
mailTo = "[email protected]",
reportAsFile = true,
reportFileName = "test"
)
It works with gmail too. But if I set it to false as
@AcraMailSender(
mailTo = "[email protected]",
reportAsFile = false
)
It does not work this time.
As I discussed with Neslihan, my main concern with switching to files is that it will be difficult to search the google groups forum for a particular crash or version number. Currently in a forum thread we can see everything directly without needing to download them one by one.
But on the other hand, we already have access to crashes on the Dev Console so we would only be using ACRA to get user comments for the most part (or for users who did not consent to google collecting crash info from them). So it may be a "good enough" fix if we can't find a better one. @nicolas-raoul what do you think?
(or for users who did not consent to google collecting crash info from them).
Just curious, how do users do that? I don't see an option in the app's settings that says it to use ACRA instead of Google's crash reporting 馃
Also, I only remember seeing the ACRA dialog during a crash. I don't remember seeing the Google's crash reporting dialog when the app crashes. Do we show that only for the stable versions released to play store? I ask this because I mostly just use alpha play store version (or) beta versions and don't remember denying any consent to use Google's crash reporting.
Just curious, how do users do that?
I believe there is an Android system setting for users to say "automatically share diagnostics and crash data" or not.
I don't see an option in the app's settings that says it to use ACRA instead of Google's crash reporting
It doesn't really work as a binary choice. Basically, if the user allows the above Android setting, Google will automatically collect crash stats from their phone for us (and all other apps) in the dev console. You can see more about that here: https://support.google.com/googleplay/android-developer/answer/6083203?hl=en
Additionally, an ACRA dialog pops up when a crash happens in OUR app, and the user can make an additional choice to email us their stack trace or not.
Also, I only remember seeing the ACRA dialog during a crash. I don't remember seeing the Google's crash reporting dialog when the app crashes.
Google does not have a dialog. :)
I believe there is an Android system setting for users to say "automatically share diagnoscs and crash data" or not.
Thanks for the tip. There does seem to be a setting for the diagnostics.
It doesn't really work as a binary choice. Basically, if the user allows the above Android setting, Google will automatically collect crash stats from their phone for us (and all other apps) in the dev console. You can see more about that here: support.google.com/googleplay/android-developer/answer/6083203?hl=en
Additionally, an ACRA dialog pops up when a crash happens in OUR app, and the user can make an additional choice to email us their stack trace or not.
Ah. Now I see what you're saying. Thanks for the clarification.
Also, I only remember seeing the ACRA dialog during a crash. I don't remember seeing the Google's crash reporting dialog when the app crashes.
Google does not have a dialog. :)
I'm not sure about this part though. When I said Google's crash report dialog the following is what I had in mind.

This is what I see when I tap on "Report":

I thought you were speaking of the crash reporting done via this method and was curious to know how a user can prevent this dialog from happening. FYI: I have 'Usage & Diagnostics' turned off and still see this dialog. So, I think it's unrelated to that.
In case anyone is curious, the app for which I saw the above crash dialog is opensource and can it's source code can be found at https://github.com/TeamAmaze/AmazeFileManager
Anyways, thanks for the clarification @misaochan.
Ok. Coming back to the topic of the issue. I actually noticed an interesting thing. When the size of the crash log is small the crash logs are filled in the the mail body just fine even when I use Gmail.

I observed this in the emulator (Nexus 5 API 24; Gmail 2020.02.16.297705979.release) but am _unable to_ observe the same behaviour in my Samsung SM-J111F i.e., the logs are _not filled in_ the mail body even when they are relatively small. cc @neslihanturan
It is very unexpected to get different results based on devices. My suggestion is merging #3605 before release if we don't find a better approach to be able to get crash logs in a way. Meanwhile I will continue to look for root cause. Thanks @sivaraam your findings seems really helpful.
I am in favor of merging and have approved the pr.
Most helpful comment
Hi @sivaraam, I think we're both highlighting the same point. It's from the acra dialog where the logs aren't attached to Gmail and not that the logs aren't attached to Gmail at all. Just wanted to drop this note if that'd be helpful in any way.