Android strict mode detects multiple activity instance violation, but I have no idea why

Question

Code is probably too complex to post here in full, but here is the basic schema: I have two Activity subclasses, each of which hosts a ListView. Each ListView has an adapter of a custom class, which generates View instances also of a custom class. These lists are showing data items that are generated asynchronously in another thread; as it needs to know where to send updates to, the data objects it manipulates have WeakReference<> objects that are set to hold references to the adapters displaying their contents when they are initialised. When an object in the list of the first activity is selected, I start the second activity with an intent that instructs it to look up the item and display its contents. I then use the 'back' button to close the second activity and return to the first. For some reason when I run this with StrictMode checking enabled, it always crashes after a few iterations of switching between the two activities, complaining that there are too many instances of one of my Activity classes.

I have arranged for a heap dump to be written just prior to the crash (see Android StrictMode and heap dumps). These heap dumps always show that there is 1 instance of each of my two activities on the heap at the time of termination. First of all, is this not to be expected when I have recently switched between the two, and if that is so, why is StrictMode complaining about this? If it isn't expected, how can I arrange to avoid this? Examining the heap dump, both objects are referenced from the main thread stack, over which I don't seem to have any useful degree of control. Each also has a reference from android.app.ActivityThread$ActivityClientRecord, which I also do not seem to be able to control.

So, basically, any ideas how I avoid this situation? Does this actually represent an activity leak, or is StrictMode just being overly sensitive?

Overcareful

Possibly related, but unfortunately lacking a useful answer, is this question that appears to describe a very similar problem: #6602629 – Overcareful

Did you figure out the answer to this question? We're facing a similar issue. – Ideograph

No, I'm no further advanced on this problem than I was when I wrote the question. I'm just not using this feature of strict mode any more; it seems to be too sensitive a test to give any useful information. – Overcareful

How do you 'just not use' strict mode? – Ideograph

I removed the call to 'detectActivityLeaks()' on the StrictMode.VmPolicy.Builder my application was using to set strict mode up. – Overcareful

Not sure I understand what you mean by that. I took a heap dump, the results of which I summarised in the question. I don't know what "ban" refers to in this context, though. – Overcareful

Answer 1

I know that this is old post. Just for guys who is looking for solution and explanation to this problem.

In case there is InstanceCountViolation exception it means that there is a real problem that Activity leak. Otherwise there can problem which is related to how detectActivityLeaks check is implemented in Android SDK.

To identify if this is a problem I can recommend the following post: Detecting leaked Activities in Android. If you will see that there are objects holding a reference to this activity which don't related to Android Framework then you have a problem which should be fixed by you.

In case there are no objects holding a reference to this activity which don't related to Android Framework than it means that you encountered with the problem related to how detectActivityLeaks check is implemented. In this case to fix the problem with failed activity without turning off detectActivityLeaks you can simply run System.gc() before starting activity in debug configuration like in the following example:

 if (BuildConfig.DEBUG)
 {         
     System.gc();
 }

 Intent intent = new Intent(context, SomeActivity.class);
 this.startActivity(intent);

More information are available in this answer.

Jansenism