StrictMode in Android

StrictMode is a developer tool that detects things you might be doing by accident and brings them to your attention, so you can fix them.

We can add the StrictMode with DEBUG mode.

StrictMode has various policies. Each policy has various rules. Each policy also has various methods of showing when a rule is violated. First, we will define the strictMode and then try to check with an example.

StrictMode Policies, Rules, and Penalties

1. Thread policy

The thread policy will check all the possible error or crash in:

• Disk Reads
• Disk Writes
• Network access
• Custom Slow Code

The first three items on this list are relatively self-explanatory in how they are triggered. The fourth is triggered simply by a call you can make to the class. You’d do this from your own code which is known to be slow. The detection of policy violations happens when the calls are made on the main thread. For example, you might trigger the “slow code” violation each and every time your application downloads and parses a large amount of data.

2. VM policy

• Custom Slow Code
• SQLite objects leaks
• Closable objects leaks
• Registration objects leaks
• Class instance limit
• File URL exposure

The leaked closable objects checker monitors for objects that should be closed, via a call to close() or the likes, before they are finalized.

How to use

Example code to enable from early in your Application, Activity, or other application components Application.onCreate() method:

public void onCreate() {
     StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
             .detectDiskReads()
             .detectDiskWrites()
             .detectNetwork()   
             .penaltyLog()
             .build());
     StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
             .detectLeakedSqlLiteObjects()
             .detectLeakedClosableObjects()
             .penaltyLog()
             .penaltyDeath()
             .build());
     super.onCreate();
 }

You can decide what should happen when a violation is detected. For example, using StrictMode.ThreadPolicy.Builder.penaltyLog() you can watch the output adb logcat while you use your application to see the violations as they happen.

And here is what the warning dialog looks like:

Error dialog

Ignoring Some Policy Violations

Most warnings generated by StrictMode should be followed up on, but not all of the warnings generated mean that something is wrong with your code. There are plenty of situations where, for instance, you know a quick read from disk on the main thread won’t hinder the application noticeably. Or maybe you have some other debugging code that violates the rules that won’t be enabled in a production build.

The first way to ignore the policy violations is to document them for yourself or your team and list them as known violations. The second way is to explicitly add code to stop checking for a particular rule violation just before the offending code is executed and then re-enable detection for that rule after the offending code has completed. For instance:

Conclusion

StrictMode is a useful class by using this, developers can find and fix performance issues, object leaks, and other hard-to-find runtime issues.

Thanks for reading my article. Recently I used strict mode and I found it useful if we talk about ANR or other internal issues.