0

I have been developing an android app for a few weeks now and keep seeing this problem every now and again:

06-24 14:04:48.915    1530-1539/android.process.acore E/StrictMode﹕ A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'close' not called
        at dalvik.system.CloseGuard.open(CloseGuard.java:184)
        at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:180)
        at android.os.ParcelFileDescriptor$1.createFromParcel(ParcelFileDescriptor.java:916)
        at android.os.ParcelFileDescriptor$1.createFromParcel(ParcelFileDescriptor.java:906)
        at android.app.IBackupAgent$Stub.onTransact(IBackupAgent.java:57)
        at android.os.Binder.execTransact(Binder.java:446)

The only thing I can think of that is causing this is that I open a url in the browser using this code:

ClickableSpan clickableSpan = new ClickableSpan() {
    @Override
    public void onClick(View textView) {
        Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.practiceadmin.com/legal/"));
        browserIntent.setFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
        startActivity(browserIntent);

    }
};

The strange thing is when I open up my android.os.ParcelFileDescriptor.java file, it says that for the import statements:

import dalvik.system.CloseGuard;
import libcore.io.IoUtils;
import libcore.io.Memory;

it cannot resolve symbol 'CloseGaurd'/'libcore'. Any direction in solving this would be greatly appreciated.

Tunaki
  • 132,869
  • 46
  • 340
  • 423
drewr2012
  • 1
  • 4
  • okay, I'm going to try using MAT and the DDMS to sort this out. I'll come back if I cannot resolve it. – drewr2012 Jun 24 '15 at 18:42
  • Classes related to [BackupAgent](http://developer.android.com/reference/android/app/backup/BackupAgent.html) are shown in the stack trace. Have you subclassed BackupAgent in your app and declared it in your manifest? If so, you might want to start looking in that code for resources that were not released. – Bob Snyder Jun 25 '15 at 03:09

1 Answers1

0

This is only a report of my research on the issue--not an answer yet.

This problem has been reported recently in related posts: for example, here, here and here.

I have an app with an enabled BackupAgent. When I recently enabled StrictMode, I started seeing the same CloseGuard exception included in this and the other posts, which includes IBackupAgent in the stack trace. So I assumed I had a problem in my BackupAgent.

I saw I had neglected to close the ParcelFileDesciptors in my BackupAgent's onBackup() method, so added these statements:

// if there is no prior state, oldState is null
if (oldState != null) {
    oldState.close();
}
newState.close();

The random exceptions continued even with this change. I then noticed that in some of the other reports of the issue, the OPs were new Android developers and probably hadn't yet created BackupAgents for their app. This leads me to suspect that the resource leak is in the framework code for the BackupService, or is caused by BackupAgents in other apps. The logcat for this crash shows that the DictionaryBackupAgent was active.

I don't have a good understanding of how far StrickMode settings for an app component are propagated. The StrictMode documentation indicates that "it does propagate its state across process boundaries when doing Binder calls". This suggests that an app's StrictMode settings may be larger than expected. These crashes may be occurring anytime StrictMode is enabled and a backup occurs, and may not be caused by the code of the app in which they are reported.

Community
  • 1
  • 1
Bob Snyder
  • 37,759
  • 6
  • 111
  • 158
  • 1
    I created an [issue](http://stackoverflow.com/questions/31108503/where-is-this-parcelfiledescriptor-leak-occurring) specifically for the leak--no response yet. I'm becoming more confident that the leak is in the system Backup Service and the only way to work around it is to change your StrictMode setting to log the leak instead of crash the app. – Bob Snyder Jun 30 '15 at 16:57