java.lang.Object | |
↳ | android.os.StrictMode |
StrictMode is a developer tool which detects things you might be doing by accident and brings them to your attention so you can fix them.
StrictMode is most commonly used to catch accidental disk or network access on the application's main thread, where UI operations are received and animations take place. Keeping disk and network operations off the main thread makes for much smoother, more responsive applications. By keeping your application's main thread responsive, you also prevent ANR dialogs from being shown to users.
Note that even though an Android device's disk is often on flash memory, many devices run a filesystem on top of that memory with very limited concurrency. It's often the case that almost all disk accesses are fast, but may in individual cases be dramatically slower when certain I/O is happening in the background from other processes. If possible, it's best to assume that such things are not fast.
Example code to enable from early in your
Application
, Activity
, or
other application component's
onCreate()
method:
public void onCreate() { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(newStrictMode.ThreadPolicy.Builder
() .detectDiskReads() .detectDiskWrites() .detectNetwork() // or .detectAll() for all detectable problems .penaltyLog() .build()); StrictMode.setVmPolicy(newStrictMode.VmPolicy.Builder
() .detectLeakedSqlLiteObjects() .detectLeakedClosableObjects() .penaltyLog() .penaltyDeath() .build()); } super.onCreate(); }
You can decide what should happen when a violation is detected.
For example, using penaltyLog()
you can
watch the output of adb logcat
while you use your
application to see the violations as they happen.
If you find violations that you feel are problematic, there are
a variety of tools to help solve them: threads, Handler
,
AsyncTask
, IntentService
, etc.
But don't feel compelled to fix everything that StrictMode finds. In particular,
many cases of disk access are often necessary during the normal activity lifecycle. Use
StrictMode to find things you did by accident. Network requests on the UI thread
are almost always a problem, though.
StrictMode is not a security mechanism and is not
guaranteed to find all disk or network accesses. While it does
propagate its state across process boundaries when doing
Binder
calls, it's still ultimately a best
effort mechanism. Notably, disk or network access from JNI calls
won't necessarily trigger it. Future versions of Android may catch
more (or fewer) operations, so you should never leave StrictMode
enabled in applications distributed on Google Play.
Nested Classes | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
StrictMode.ThreadPolicy | StrictMode policy applied to a certain thread. |
||||||||||
StrictMode.VmPolicy | StrictMode policy applied to all threads in the virtual machine's process. |
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
A convenience wrapper that takes the current
StrictMode.ThreadPolicy from getThreadPolicy() , modifies it
to permit disk reads, and sets the new policy
with setThreadPolicy(StrictMode.ThreadPolicy) , returning the old policy so you
can restore it at the end of a block. | |||||||||||
A convenience wrapper that takes the current
StrictMode.ThreadPolicy from getThreadPolicy() , modifies it
to permit both disk reads & writes, and sets the new policy
with setThreadPolicy(StrictMode.ThreadPolicy) , returning the old policy so you
can restore it at the end of a block. | |||||||||||
Enable the recommended StrictMode defaults, with violations just being logged.
| |||||||||||
Returns the current thread's policy.
| |||||||||||
Gets the current VM policy.
| |||||||||||
For code to note that it's slow.
| |||||||||||
Sets the policy for what actions on the current thread should
be detected, as well as the penalty if such actions occur.
| |||||||||||
Sets the policy for what actions in the VM process (on any
thread) should be detected, as well as the penalty if such
actions occur.
|
[Expand]
Inherited Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
From class
java.lang.Object
|
A convenience wrapper that takes the current
StrictMode.ThreadPolicy
from getThreadPolicy()
, modifies it
to permit disk reads, and sets the new policy
with setThreadPolicy(StrictMode.ThreadPolicy)
, returning the old policy so you
can restore it at the end of a block.
A convenience wrapper that takes the current
StrictMode.ThreadPolicy
from getThreadPolicy()
, modifies it
to permit both disk reads & writes, and sets the new policy
with setThreadPolicy(StrictMode.ThreadPolicy)
, returning the old policy so you
can restore it at the end of a block.
setThreadPolicy(StrictMode.ThreadPolicy)
to
restore the policy at the end of a block
Enable the recommended StrictMode defaults, with violations just being logged.
This catches disk and network access on the main thread, as
well as leaked SQLite cursors and unclosed resources. This is
simply a wrapper around setVmPolicy(StrictMode.VmPolicy)
and setThreadPolicy(StrictMode.ThreadPolicy)
.
Returns the current thread's policy.
For code to note that it's slow. This is a no-op unless the
current thread's StrictMode.ThreadPolicy
has
detectCustomSlowCalls()
enabled.
name | a short string for the exception stack trace that's built if when this fires. |
---|
Sets the policy for what actions on the current thread should be detected, as well as the penalty if such actions occur.
Internally this sets a thread-local variable which is propagated across cross-process IPC calls, meaning you can catch violations when a system service or another process accesses the disk or network on your behalf.
policy | the policy to put into place |
---|
Sets the policy for what actions in the VM process (on any thread) should be detected, as well as the penalty if such actions occur.
policy | the policy to put into place |
---|