Infinite loop if Dialog Option is choosen and the app crashes on onResmue Method of a Activity about acra HOT 12 CLOSED

This is not specific to the Dialog option of ACRA, or ACRA for that matter.

On application crash the Android framework will attempt to restart your app and the Activity last shown. So if your Activity throws an Exception in onResume then it will get into an unbounded restart loop.

William

from acra.

It is specific to the ACRA lib and not to the Android System. If I don't use ACRA I get the normal force close Dialog of the Android System.

Android also did not restart the Activity which has crashed. It tries to start the last working Activity.

For example:

1. App is launched, MainActivity is shown
2. Click on a link, second Activity is started by an Intent
3. In onResume() of the second Activity an exception is raised

Without ACRA, the force close Dialog is shown and the User comes back to the MainActivity. With ACRA, it comes to an infinite loop. onResume of the second Activity is called in a loop.

from acra.

So if you comment out ACRA#init in your Application#onCreate you get totally different behaviour that when ACRA#init has been invoked?

from acra.

Exactly. Without the ACRA.init(); call the application "crashes" like expected. With the ACRA.init() line it comes to the infinite loop.

    Gesendet: Donnerstag, 10. Januar 2013 um 22:44 UhrVon: william-ferguson-au <[email protected]>An: ACRA/acra <[email protected]>Cc: snakevalley <[email protected]>Betreff: Re: [acra] Infinite loop if Dialog Option is choosen and the app crashes on onResmue Method of a Activity (#42)


    So if you comment out ACRA#init in your Application#onCreate you get totally different behaviour that when ACRA#init has been invoked?


          —
          Reply to this email directly or view it on GitHub.

from acra.

OK, I have managed to replicate and have sent Kevin a pull request with changes that will work for Android 4.0+ (earlier versions will continue to get the current behavior unless someone can solve X).

The solution essentially listens for Activity lifecycle events and keeps track of the last Activity that was created. And on crash explicitly finishes that Activity before killing the Process (which will attempt to recreate the entire Task stack).

X: To be available on versions < 4.0 we need some way of working out which Activity was last created.

from acra.

I merged the PR today on the master branch.
Tested on Nexus One (2.3.7) Galaxy Tab 10.1 (4.0.4) and SDK (4.1.2).

from acra.

I'm integrating some code from https://github.com/BoD/android-activitylifecyclecallbacks-compat to allow the use of the new API without losing the compatibility with the oldest android versions.

from acra.

I'm not sure this is going to work.
It requires all of your Actvities to extend from the one in the
org.jraf.android.util.activitylifecyclecallbackscompat.app
package.

If that isn't done then you won't get the Application life cycle callbacks
occurring.

William

On Wed, Jan 30, 2013 at 8:44 AM, KevinGaudin [email protected]:

I'm integrating some code from
https://github.com/BoD/android-activitylifecyclecallbacks-compat to allow
the use of the new API without losing the compatibility with the oldest
android versions.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-12863034.

from acra.

Absolutely, my idea was to integrate the abstraction layer to allow ACRA to still be compatible with older android versions without benefiting from the activity lifecycle tracking.

For apps before ICS, ACRA will behave like it always has. Starting with ICS, the latest activity will be destroyed.

from acra.

But we get that without adding a dependency on this library.

On Wed, Jan 30, 2013 at 8:56 AM, KevinGaudin [email protected]:

Absolutely, my idea was to integrate the abstraction layer to allow ACRA
to still be compatible with older android versions without benefiting from
the activity lifecycle tracking.

For apps before ICS, ACRA will behave like it always has. Starting with
ICS, the latest activity will be destroyed.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-12863680.

from acra.

I was concerned about having to raise the minimum API level to 7 for integrating ACRA (remember #41 ).

Before API level 7, ACRA.init() crashes with a verify error.

I know there are now less than 1% of devices running cupcake or donut... but... well... that was itching. :-)

Anyway, this is not really a dependency with another lib. It's the inclusion of 5 abstraction/wrapping classes which mimic the new API so that it does not crash on those old android versions.

There is now a dev branch, I just committed these changes in that branch if you want to have a look.

from acra.

Ahhh, I missed "since Android API 7 or such, dalvik doesn't complain about
uknown class at load time, until it tries to execute it.". I didn't realise
it was an API 7 and up thing.

Fair enough then.

On Wed, Jan 30, 2013 at 9:12 AM, KevinGaudin [email protected]:

I was concerned about having to raise the minimum API level to 7 for
integrating ACRA (remember #41 https://github.com/ACRA/acra/issues/41 ).

Before API level 7, ACRA.init() crashes with a verify error.

I know there are now less than 1% of devices running cupcake or donut...
but... well... that was itching. :-)

Anyway, this is not really a dependency with another lib. It's the
inclusion of 5 abstraction/wrapping classes which mimic the new API so that
it does not crashes on those old android versions.

There is now a dev branch, I just committed these changes in that branch
if you want to have a look.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-12864345.

from acra.