Directory (?) [-]
- ADB command
- Simulator Console
- Strictmode
ADB command
We are learning about the use of SQLite, introduced some of the use of the ADB command, see Pro Android Learning Note (v): Learn about content Provider (above).
Abd –e Shell
-E is the surface connection simulator emulator,-d is the connecting device. In the simulator, we have an elevated Linux privilege, and on the real device there is no, we can process the SQLite data in the simulator, but cannot do this on the real device, even if it is our own deployment of the application.
Simulator Console
We can access the simulator via Telnet and the port is typically 5554, which is displayed in the emulator's window title. We simulate GPS events, SMS, battery status and network status changes, for reference: Http://developer.android.com/guide/developing/devices/emulator.html#console
Strictmode
Android 2.3 introduces Strictmode (in the Android.os package) to check for thread and VM policy corruption, and when the policy vialation is detected, a warning is produced that contains a stack trace. This can force a program to crash or just log records to continue execution.
The thread policy check is typically used for the main thread and also as a UI thread. Disk read-write, network access, and custom slow call (calling a code slow) are generally not recommended in the main thread if the event is found to be an alarm, depending on the contents of the alarm, we can select Logcat record, frame display, screen Flash, write dropbox log file, or directly crash the program. The relevant code examples are as follows:
Strictmode.setthreadpolicy (New StrictMode.ThreadPolicy.Builder ()
. Detectdiskreads ()
. Detectdiskwrites ()
. Detectnetwork ()//Can be used Detectall () to indicate full monitoring. If it is detected in addition to reading disk, you can. Detectall (). Permitdiskreads ()
. Penaltylog ()//with Logcat to display, you can add Penaltydeach () to crash application
. build ());
Once the Strictmode is turned on, it applies to the entire thread, which can be set in OnCreate () at the beginning of the run, once enough.
VM policy checks are used to detect memory leaks such as SQLite objects, activity objects, and objects that can be closeable, such as Call Close () to close, using the example below. is similar to thread policy detection, except that a virtual machine cannot be alerted by a bullet box.
Strictmode.setvmpolicy (New StrictMode.VmPolicy.Builder ()
. Detectleakedsqlliteobjects ()
. Penaltylog ()
. Penaltydeath ()
. build ());
Strictmode is applied to the development version and avoids being used in production builds. Simply, we can delete the relevant code directly, but this is not a good way to handle it. We can set application variables, such as static Boolean Product_mode = false; Test first. It is recommended to use the android:debuggable parameter in Androidmanifest.xml <application> if true to turn on Strictmode, otherwise it will not be turned on. When Eclipse is deployed in the emulator or device, the value is set to True, and when released as a production version, the value is set to False. The code example is as follows:
ApplicationInfo appInfo = Context.getapplicationinfo ();
int appflags = appinfo.flags;
if ((Appflags & applicationinfo.flag_debuggable)! = 0) {
Do Strictmode setup here
}
Strictmode can only be used on Android 2.3 and later if the app allows for deployment prior to version 2.3. We can make some judgments, but the 2.2 and previous versions are very few and can be considered without them. As a generic version of the API there are differences, you can use the following methods:
try {
Class Smode = Class.forName ("Android.os.StrictMode"); ///1, detect if the class exists, if not present, will throw ClassNotFoundException
Method enabledefaults = Smode.getmethod ("Enabledefaults"); ///2, get a method of this class, for example Strictmode.enabledefaults ()
Enabledefaults.invoke (NULL); ///3, call this method. This example has a static method
}
catch (Exception e) {
Strictmode not supported on this device, punt
LOG.V ("Strictmode", "... not supported". Skipping ... ");
}
But this way calls up very well, simply we can put the relevant code with Try{}catch (Throwable throwale) {...} Include them. If there is no Strictmode, the Verifyerror will be thrown out, as follows:
try {
...//related processing .....
}
catch (Throwable throwable) {
LOG.V ("Strictmode", "... is not available. Punting ... ");
}
RELATED Links: My Android development related articles
"Turn" Pro Android Learning Note (55): Debug and Analysis (3): ADB command, simulator console, and Strictmode