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.

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.

Causes the current thread to wait until another thread invokes the
notify() method or the
notifyAll() method for this object, or
some other thread interrupts the current thread, or a certain
amount of real time has elapsed.

setThreadPolicy

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.