ACRA sends reports in a new process ':acra'

[William Ferguson]

Please Note : 

As of ACRA-4.8.0, ACRA uses the `SenderService` to send crash reports. 

The `SenderService` runs in a separate process to ensure that reports can be sent even when your own VM is dying from an unhandled exception. 

This means that a new instance of your application will be started and your `Application.onCreate()` will be called again. 

If you are performing once only tasks in `Application.onCreate()` then check the name of the current process and don't do them if the process name is `:acra`.

In ACRA 4.8.6+ you can do that via ACRA.isACRASenderServiceProcess(Application), in prior versions you will need to check the name of the process yourself.

William

[Mark Murphy]

On Mon, Mar 28, 2016, at 16:22, William Ferguson wrote:
> In ACRA 4.8.6+ you can do that via
> ACRA.isACRASenderServiceProcess(Application), in prior versions you will
> need to check the name of the process yourself.

Since 4.8.6 isn't out yet, I went to look at the implementation of
isACRASenderServiceProcess(), and I see that the implementation relies
upon the process name *ending* in :acra, not *being* :acra.

I haven't fussed with multiple processes on Android much, but are you
sure that endsWith() is the right solution here, versus equality? What
you have may be the right answer, but it struck me as odd, that's all.

It might also be worth noting that if developers use manifest merging
rules to override the process name, that isACRASenderServiceProcess()
may no longer work, and such developers are on their own for determining
whether or not the process is ACRA's.

--
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy

[William Ferguson]

Hi Mark, thanks for the pick up re #equals vs #endsWith. I suspect that was a code completion error.

Fixed now and likely to have had zero impact.

With respect to overriding the SenderService process name in the Manifest, then all bets are off. Unless you know of some other way that we can definitively tell that the current process is the one started just for the SenderService.

William

--
You received this message because you are subscribed to a topic in the Google Groups "acra-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/acra-discuss/gPOpbvYhZvw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to acra-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Murphy]

On Tue, Mar 29, 2016, at 14:59, William Ferguson wrote:
> Hi Mark, thanks for the pick up re #equals vs #endsWith. I suspect that
> was a code completion error.

Ah, OK.

> With respect to overriding the SenderService process name in the
> Manifest,
> then all bets are off. Unless you know of some other way that we can
> definitively tell that the current process is the one started just for
> the SenderService.

No clue -- sorry!

[James Baster]

With this, can I just double check the order with regards to init? So it would be something like:


@Override
public void onCreate() {
    super.onCreate();

   if (!ACRA.isACRASenderServiceProcess(this)) {

       final ACRAConfiguration config = new ConfigurationBuilder(this)
             .setFormUri("http://brokenopenapp.xxxx.co.uk/incomingcrashacra?project=xxxxxxxxxxx")
             .build();

       ACRA.init(this, config);

       // Do other app tasks, maybe start a service, maybe configure Analytics, etc

   }

}

Thanks,

James

--
You received this message because you are subscribed to the Google Groups "acra-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to acra-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Tech events around town http://opentechcalendar.co.uk/
and collaborative calendars for all http://ican.hasacalendar.co.uk/ (open data & open source)

[William Ferguson]

Hi James,

ACRA already checks for this internally, so you just need to test for any services/tasks of your own.

It's more like:

@Override
public void onCreate() {
    super.onCreate();

    final ACRAConfiguration config = new ConfigurationBuilder(this)
             .setFormUri("http://brokenopenapp.xxxx.co.uk/incomingcrashacra?project=xxxxxxxxxxx")
             .build();
   ACRA.init(this, config);
 

  if (!ACRA.isACRASenderServiceProcess(this)) {

       // Do other app tasks, maybe start a service, maybe configure Analytics, etc

   }
}

And if you have any ContentResolvers then you should use 'attachBaseContext(Context ctx)' instead of 'onCreate(Context ctx)` to initialise ACRA as the ContentResolvers start BEFORE `Application.onCreate()`.

William

[James Baster]

To return to this .....

So in ACRA 4.8.6+ we can do ACRA.isACRASenderServiceProcess(Application), in previous versions we must check ourselves. However, 4.8.6 has never been released, is that right? And given you've started on 4.9 I guess it won't be?

That means for anyone starting extra processes in Application.onCreate() they basically can't use the 4.8 branch without doing extra work themselves.

I've made an helper class to do this. It's at: https://gist.github.com/jarofgreen/23a07c3b009db818a6819c7af9a7e8d2

I notice the method that ACRA 4.8.5 uses to extract the process name is not the same as the method the latest code uses. On the assumption the latest code is better, I've gone with that.

I've tested it by doing a production build, adding a deliberate crash and seeing it come through to http://www.brokenopenapp.org/ with clarity. Also putting in Log messages to make sure services start normally. That doesn't really test the process checks in some ways .... but I can get errors at least and the app works!

Any comment / checks welcome .... Hope this helps ppl!

James

[Espen Riskedal]

Why is a new instance of Application created? Is this the default behavior of Android when creating a new process or something you specifically did in ACRA?

Our application has several global static variables. They are initialized when the classes are loaded.

This means that any classes referred to by our Application subclass gets loaded and initialized in the ":acra" process as well.

We can add checks to isACRASenderServiceProcess(...) in the static { } blocks of course, but it sounds error prone and

I am unsure of how many classes are loaded.

Going from a single process to multi process app seems to complicate things a lot.

Telling people to use isACRASenderServiceProcess(..) in their Application onCreate() implementation does not seem to cover all the side-effects this introduces.

Are there any more thorough discussions or docs on all the caveats this introduces?

[F43nd1r]

Classes (or instances) cannot be (directly) shared between processes. This is the same on all common OS. As a result, each process has to get its own Application class.

Testing for isACRASenderServiceProcess is the easiest solution for your problem.

I haven't seen any other discussions on this topic. I guess this is partly because the change is relatively new, and partly because most apps don't do work in their Apllication class.

By the way - public static variables are most certainly code smell.

[Espen Riskedal]

tirsdag 31. mai 2016 20.54.09 UTC+2 skrev F43nd1r følgende:

... As a result, each process has to get its own Application class.

OK, thanks for clearing that up, was what I was wondering about.

...I haven't seen any other discussions on this topic. I guess this is partly because the change is relatively new, and partly because most apps don't do work in their Application class.

I think it's fairly common to subclass Application. It's not uncommon for 3rd party libraries (this one included) to suggest initializing themselves in onCreate(..) or attachBaseContext(..).

 

By the way - public static variables are most certainly code smell.

Well now when we're running multiple processes it definitely stinks. It's a matter of taste I guess.

espen