Cause Analysis and Solution for exceptions when Android 3.0 acquires Internet Resources

I believe that many users who use the latest Android system to develop network programs will encounter background exceptions when getting started. After checking the code carefully, it is found that the Code on the book or on the network is consistent and has been authorized in AndroidManifest. xml. However, the background still throws the following exception:

 

LogCat prompts that the system throws an android. OS. NetworkOnMainThreadException.
After repeated experiments, we found that when we use data streams to obtain network resources (such as the source file of a page), the system will throw this exception, for example, the following two statements:
InputStream inStream = conn. getInputStream ();
InStream. read (buffer)

This exception is thrown by the system.
After reading the relevant information, we found that the system has added a class: StrictMode since Android 2.3. This class changes the way the network is accessed.
Android official documentation provides the purpose of setting this class:
StrictMode is a development tool provided by the system. It is used to detect potential system problems caused by accidental accidents during the development process, and then prompts developers to fix them.

StrictMode is usually used to capture problems arising from interactions between disk access or network access and the main process, because in the main process, UI operations and the execution of some actions are most often used, conflicts may occur between them. Detaching disk access and network access from the main thread can make disk or network access smoother and improve response and user experience.

Obviously, most beginners choose to put the code that accesses the network directly into the main process during network development. Because it is in conflict with the primary task of the main process-UI interaction, A certain detection mechanism must be set up to ensure smooth system operation and detect all exceptions.
We recommend that you add these two commands in the Android document:
StrictMode. setThreadPolicy (newStrictMode. ThreadPolicy. Builder (). detectDiskReads (). detectDiskWrites (). detectNetwork (). penaltyLog (). build ());
StrictMode. setVmPolicy (newStrictMode. VmPolicy. Builder (). detectLeakedSqlLiteObjects (). detectLeakedClosableObjects (). penaltyLog (). penaltyDeath (). build ());

Now let's see what they do.
Public static voidsetThreadPolicy (StrictMode. ThreadPolicy policy)
This method allows us to set a set of thread running policies for the current application. The parameter is a policy group (that is, a group of policies ).
Public static finalclass StrictMode. ThreadPolicy. Builder ()
Builder is an embedded class of ThreadPolicy in StrictMode. Here we call its default constructor.
DetectDiskReads (). detectDiskWrites (). detectNetwork (). penaltyLog (). build ()

In this way, we set a set of monitoring modes. We want to detect disk read/write, network access, and Log violations.
The second statement sets a set of monitoring policies for virtual machines. The parameters are the same, so we will not repeat them here.
In this way, after the network and disk access are controlled, the main thread allows us to access network resources.
Finally, it should be said that the policy restrictions only need to be added at the beginning of the main thread running stage, that is, when onCreate was just called, all subsequent methods will follow this rule.

 
From Peking University-Google Android lab