forceCloseDialogAfterToast not working on auto accept reports

[Scrounger]

Hi,

i use a custom reportDialogClass and give the user the option on prferences to Enable/disable auto accept reports.
If the auto accept reports is enabled, the forceCloseDialogAfterToast is not shown. So if the app crash there is no information for the user that a crash happend - the app only closing and not restarting.

Scrounger

[F43nd1r]

If autoaccept is true acra switches to toast mode, that means resDialogToast is shown

[Scrounger]

Yes this works as described.
The wiki is described that in Toast mode its possible to show the "standard android app crash dialog" by setting forceCloseDialogAfter = false.

If i use ReportingInteractionMode.TOAST the dialog is shown.

But the dialog is not shown if the user set preferences to auto accept reports enabled by using ReportingInteractionMode.DIALOG with custom reportDialogClass and also the app dont restart.

[william-ferguson-au]

@Scrounger I think you are confused about ACRA's notification methods.

• ReportingInteractionMode.TOAST
  This will display a Toast to the user when a crash occurs. If you have also set forceCloseDialogAfter == true then it will ALSO hand to crash on to the Android frameowkr which will dis;play it's crash dialog.
• ReportingInteractionMode.Dialog
  This shows the ACRA (or your custom dialog) when a crash occurs.
  You will never get the Android framework crash dialog shown.

Does this match your understanding?

You seem to be saying that if you have ReportingInteractionMode.Dialog and forceCloseDialogAfter = true and autoAcceptReports == true that the Android framework dialog is not shown and the app does not restart.

As I showed above, you would never expect to see the Android framework crash dialog when you have configured ReportingInteractionMode.Dialog.

The fact that the app does not restart is interesting and is probably caused by the use of ReportingInteractionMode.Dialog and that the ACRA dialog is finishing cleanly. Perhaps if it killed the VM with an error code, eg System.exit(-1), but that seems drastic.

[F43nd1r]

The fact that the app does not restart is interesting and is probably caused by the use of ReportingInteractionMode.Dialog and that the ACRA dialog is finishing cleanly. Perhaps if it killed the VM with an error code, eg System.exit(-1), but that seems drastic.

Maybe we can add a configuration option for an intent Uri, which is called after acra is done. (to provide a constistent restart)

[Scrounger]

@william-ferguson-au

You seem to be saying that if you have ReportingInteractionMode.Dialog and forceCloseDialogAfter = true and autoAcceptReports == true that the Android framework dialog is not shown and the app does not restart.

As I showed above, you would never expect to see the Android framework crash dialog when you have configured ReportingInteractionMode.Dialog.

Thats exactly what i mean, the user dont get an info that the app has crashed in the this configuration.
At my opinion its a bad user interaction.
Could you please implement to show optional the Android framework crash dialog? Something like forceCloseDialogAfterDialog.

[william-ferguson-au]

I don't understand. If you have configured ReportingInteractionMode.Dialog, then the user will get notified of the crash via the ACRA crash dialog.

Why do you want to them to also get notified of the crash by the Android framework dialog?

[Scrounger]

@william-ferguson-au
In configuration ReportingInteractionMode.Dialog and autoAcceptReports == true the user dont get an info that the app crashed, the app just closing.
In this configuration it would better to show an info that the app crashed e.g. the Android standard crash dialog.

[F43nd1r]

autoAcceptReports represents "I don't want to see any dialogs". Showing the default Android dialog would be contradicting. Showing a toast instead is acceptable.

[william-ferguson-au]

I want to resolve #405 first, but once that is done I think we gain some clarity on this issue by

• renaming forceCloseDialogAfter to 'alsoReportToAndroidFramework` with a default value of False,
• an explainer of what it means (AndroidFramework)
• recommendation that this always be off if ReportingInteractionMode == Dialog
• Use this to simplify https://github.com/ACRA/acra/blob/master/src/main/java/org/acra/builder/ReportExecutor.java#L117

[william-ferguson-au]

@F43nd1r want to have a go at cleaning it up as per my comments above?
Once we have this in I want to release 4.9.0

[F43nd1r]

Yes. As the versions from 4.8.0 to 4.9.0 contain breaking changes anyway (especially around KeyStore) I think it would fit to drop the setters on the configuration too. Do you agree?

[william-ferguson-au]

Good idea. Do that in a separate PR though.
The simpler and more tightly focused each PR is the easier it is to vet it.

[F43nd1r]

Maybe alsoReportToNative instad of alsoReportToAndroidFramework? it is shorter and it says the same.

[william-ferguson-au]

OK I'm closing this now we have a PR that rounds off the sharp edges.