CN107861827B - Card screen detection method, mobile terminal and computer readable storage medium - Google Patents

Card screen detection method, mobile terminal and computer readable storage medium Download PDF

Info

Publication number
CN107861827B
CN107861827B CN201711060999.9A CN201711060999A CN107861827B CN 107861827 B CN107861827 B CN 107861827B CN 201711060999 A CN201711060999 A CN 201711060999A CN 107861827 B CN107861827 B CN 107861827B
Authority
CN
China
Prior art keywords
mobile terminal
card screen
preset
result information
monitoring
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201711060999.9A
Other languages
Chinese (zh)
Other versions
CN107861827A (en
Inventor
周龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nubia Technology Co Ltd
Original Assignee
Nubia Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nubia Technology Co Ltd filed Critical Nubia Technology Co Ltd
Priority to CN201711060999.9A priority Critical patent/CN107861827B/en
Publication of CN107861827A publication Critical patent/CN107861827A/en
Application granted granted Critical
Publication of CN107861827B publication Critical patent/CN107861827B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0778Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/825Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking

Abstract

The invention discloses a card screen detection method, a mobile terminal and a computer readable storage medium, wherein the card screen detection method comprises the following steps: acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process; monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information; and judging whether the mobile terminal has a card screen fault or not according to the monitoring result information. According to the scheme, the core process in the preset core process of the Native framework layer is monitored when the mobile terminal system is started through presetting the monitoring rule. When the core process is abnormal and causes the card screen, the reason causing the card screen can be found in time according to the monitored result information. After-sales personnel or developers can conveniently and quickly and accurately locate the reason of the card screen of the mobile terminal when monitoring the reason of the card screen of the mobile terminal, and the labor cost and the time cost are greatly reduced.

Description

Card screen detection method, mobile terminal and computer readable storage medium
Technical Field
The invention relates to the technical field of mobile terminals, in particular to a card screen detection method, a mobile terminal and a computer readable storage medium.
Background
With the development of mobile terminal technology, more and more Applications (APPs) are integrated in the mobile terminal, and at present, tens of thousands of applications are installed on the mobile terminal based on different scenes of the mobile terminal, and with more and more third-party applications and service software installed on the mobile terminal by a user, when people use the mobile terminal daily, certain key points in the starting and starting process of the mobile terminal are easily affected, so that the mobile terminal is blocked at certain key points, and a screen blocking phenomenon occurs.
At present, when the screen of the mobile terminal is blocked, a user needs to manually force the mobile terminal to be restarted to enable the mobile terminal to be recovered to be normal, and the user experience is not good. In addition, the reasons for the screen clamping phenomenon of the mobile terminal are various, the mobile terminal cannot be recovered to be normal by restarting the mobile terminal, and the mobile terminal needs to be returned to the after-sale or returned to a manufacturer for maintenance. After taking the mobile terminal, after the after-sales personnel or developers need to reproduce the card screen phenomenon, more time is consumed for monitoring and positioning the card screen reason of the mobile terminal. Therefore, how to quickly position the screen clamping reason and reduce the labor cost and the time cost are problems to be solved urgently at present.
The above is only for the purpose of assisting understanding of the technical aspects of the present invention, and does not represent an admission that the above is prior art.
Disclosure of Invention
The invention mainly aims to provide a card screen detection method, a mobile terminal and a computer readable storage medium, and aims to solve the technical problems of how to quickly locate the reason for the card screen and reduce the labor cost and the time cost.
In order to achieve the above object, the present invention provides a card screen detection method, which is applied to a mobile terminal, and comprises the following steps:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information;
and judging whether the mobile terminal has a card screen fault or not according to the monitoring result information.
Optionally, the core process includes creating a path, registering information, and preloading data, and reading a synchronization lock in the process of creating the path, registering information, and preloading data;
the step of monitoring the core process for starting the system in the preset core process according to the preset monitoring rule comprises the following steps:
judging whether the path is successfully created by the preset core process, whether the registration information is successful, whether the data is preloaded, and whether the synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data to obtain a judgment result, and generating monitoring result information according to the judgment result.
Optionally, the step of determining whether the card screen fault occurs in the mobile terminal according to the monitoring result information includes:
judging whether the monitoring result information is consistent with preset reference information or not;
when the monitoring result information is consistent with preset reference information, judging that the mobile terminal has no card screen fault;
and when the monitoring result information is inconsistent with the preset reference information, judging that the mobile terminal has a card screen fault.
Optionally, the step of determining that the card screen failure occurs in the mobile terminal includes:
and collecting monitoring result information in real time, and storing the collected monitoring result information after carrying out redundancy removal processing within preset time.
Optionally, the step of performing redundancy removal and post-processing on the collected monitoring result information within a preset time and then storing the collected monitoring result information includes:
judging whether the size of the stored data volume exceeds the size of the preset data volume, selecting information to be deleted from the stored monitoring result information when the size of the stored data volume exceeds the size of the preset data volume, and deleting the information to be deleted.
Optionally, after the step of determining whether the card screen fault occurs in the mobile terminal according to the monitoring result information, the method includes:
and when the mobile terminal has a card screen fault, outputting the monitoring result information to a feature log file.
In addition, to achieve the above object, the present invention also provides a mobile terminal, a memory, a processor, a communication bus, and a card screen detection program stored on the memory:
the communication bus is used for realizing connection communication between the processor and the memory;
the processor is used for executing the card screen detection program to realize the following steps:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information;
and judging whether the mobile terminal has a card screen fault or not according to the monitoring result information.
The present invention also provides a computer-readable storage medium having stored thereon a card screen detection program for execution by a processor to:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information;
and judging whether the mobile terminal has a card screen fault or not according to the monitoring result information.
The invention provides a card screen detection method, a mobile terminal and a computer readable storage medium, which are implemented by acquiring a preset core of a Native framework layer of the mobile terminal in the system starting process, and monitoring a core flow for starting a system in the acquired preset core process according to a preset monitoring rule to obtain monitoring result information; and judging whether the mobile terminal has a card screen fault according to the monitoring result information. According to the scheme, the core process in the preset core process of the Native framework layer is monitored when the mobile terminal system is started through presetting the monitoring rule. When the core process is abnormal and causes the card screen, the reason causing the card screen can be found in time according to the monitored result information. After-sales personnel or developers can conveniently and quickly and accurately locate the reason of the card screen of the mobile terminal when monitoring the reason of the card screen of the mobile terminal, and the labor cost and the time cost are greatly reduced.
Drawings
Fig. 1 is a schematic diagram of a hardware structure of a mobile terminal implementing various embodiments of the present invention;
FIG. 2 is a level diagram of an operating system of the mobile terminal according to the present invention;
FIG. 3 is a schematic flow chart illustrating a card screen detection method according to a first embodiment of the present invention;
FIG. 4 is a flowchart illustrating a card screen detection method according to a second embodiment of the present invention;
fig. 5 is a schematic structural diagram of a hardware operating environment related to the method according to the embodiment of the present invention.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
In the following description, suffixes such as "module", "component", or "unit" used to denote elements are used only for facilitating the explanation of the present invention, and have no specific meaning in itself. Thus, "module", "component" or "unit" may be used mixedly.
The terminal may be implemented in various forms. For example, the terminal described in the present invention may include a mobile terminal such as a mobile phone, a tablet computer, a notebook computer, a palmtop computer, a Personal Digital Assistant (PDA), a Portable Media Player (PMP), a navigation device, a wearable device, a smart band, a pedometer, and the like, and a fixed terminal such as a Digital TV, a desktop computer, and the like.
The following description will be given by way of example of a mobile terminal, and it will be understood by those skilled in the art that the construction according to the embodiment of the present invention can be applied to a fixed type terminal, in addition to elements particularly used for mobile purposes.
Referring to fig. 1, which is a schematic diagram of a hardware structure of a mobile terminal for implementing various embodiments of the present invention, the mobile terminal 100 may include: RF (Radio Frequency) unit 101, WiFi module 102, audio output unit 103, a/V (audio/video) input unit 104, sensor 105, display unit 106, user input unit 107, interface unit 108, memory 109, processor 110, and power supply 111. Those skilled in the art will appreciate that the mobile terminal architecture shown in fig. 1 is not intended to be limiting of mobile terminals, which may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
The following describes each component of the mobile terminal in detail with reference to fig. 1:
the radio frequency unit 101 may be configured to receive and transmit signals during information transmission and reception or during a call, and specifically, receive downlink information of a base station and then process the downlink information to the processor 110; in addition, the uplink data is transmitted to the base station. Typically, radio frequency unit 101 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like. In addition, the radio frequency unit 101 can also communicate with a network and other devices through wireless communication. The wireless communication may use any communication standard or protocol, including but not limited to GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), CDMA2000(Code Division Multiple Access 2000), WCDMA (Wideband Code Division Multiple Access), TD-SCDMA (Time Division-Synchronous Code Division Multiple Access), FDD-LTE (Frequency Division duplex Long Term Evolution), and TDD-LTE (Time Division duplex Long Term Evolution).
WiFi belongs to short-distance wireless transmission technology, and the mobile terminal can help a user to receive and send e-mails, browse webpages, access streaming media and the like through the WiFi module 102, and provides wireless broadband internet access for the user. Although fig. 1 shows the WiFi module 102, it is understood that it does not belong to the essential constitution of the mobile terminal, and may be omitted entirely as needed within the scope not changing the essence of the invention.
The audio output unit 103 may convert audio data received by the radio frequency unit 101 or the WiFi module 102 or stored in the memory 109 into an audio signal and output as sound when the mobile terminal 100 is in a call signal reception mode, a call mode, a recording mode, a voice recognition mode, a broadcast reception mode, or the like. Also, the audio output unit 103 may also provide audio output related to a specific function performed by the mobile terminal 100 (e.g., a call signal reception sound, a message reception sound, etc.). The audio output unit 103 may include a speaker, a buzzer, and the like.
The a/V input unit 104 is used to receive audio or video signals. The a/V input Unit 104 may include a Graphics Processing Unit (GPU) 1041 and a microphone 1042, the Graphics processor 1041 Processing image data of still pictures or video obtained by an image capturing device (e.g., a camera) in a video capturing mode or an image capturing mode. The processed image frames may be displayed on the display unit 106. The image frames processed by the graphic processor 1041 may be stored in the memory 109 (or other storage medium) or transmitted via the radio frequency unit 101 or the WiFi module 102. The microphone 1042 may receive sounds (audio data) via the microphone 1042 in a phone call mode, a recording mode, a voice recognition mode, or the like, and may be capable of processing such sounds into audio data. The processed audio (voice) data may be converted into a format output transmittable to a mobile communication base station via the radio frequency unit 101 in case of a phone call mode. The microphone 1042 may implement various types of noise cancellation (or suppression) algorithms to cancel (or suppress) noise or interference generated in the course of receiving and transmitting audio signals.
The mobile terminal 100 also includes at least one sensor 105, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor that can adjust the brightness of the display panel 1061 according to the brightness of ambient light, and a proximity sensor that can turn off the display panel 1061 and/or a backlight when the mobile terminal 100 is moved to the ear. As one of the motion sensors, the accelerometer sensor can monitor the magnitude of acceleration in each direction (generally three axes), can monitor the magnitude and direction of gravity when stationary, and can be used for applications of recognizing the posture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping) and the like; as for other sensors such as a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.
The display unit 106 is used to display information input by a user or information provided to the user. The Display unit 106 may include a Display panel 1061, and the Display panel 1061 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like.
The user input unit 107 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the mobile terminal. Specifically, the user input unit 107 may include a touch panel 1071 and other input devices 1072. The touch panel 1071, also referred to as a touch screen, may collect a touch operation performed by a user on or near the touch panel 1071 (e.g., an operation performed by the user on or near the touch panel 1071 using a finger, a stylus, or any other suitable object or accessory), and drive a corresponding connection device according to a predetermined program. The touch panel 1071 may include two parts of a touch monitoring device and a touch controller. The touch monitoring device monitors the touch direction of a user, monitors signals brought by touch operation and transmits the signals to the touch controller; the touch controller receives touch information from the touch monitoring device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 110, and can receive and execute commands sent by the processor 110. In addition, the touch panel 1071 may be implemented in various types, such as a resistive type, a capacitive type, an infrared ray, and a surface acoustic wave. In addition to the touch panel 1071, the user input unit 107 may include other input devices 1072. In particular, other input devices 1072 may include, but are not limited to, one or more of a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like, and are not limited to these specific examples.
Further, the touch panel 1071 may cover the display panel 1061, and when the touch panel 1071 detects a touch operation thereon or nearby, the touch panel may transmit the touch operation to the processor 110 to determine the type of the touch event, and then the processor 110 may provide a corresponding visual output on the display panel 1061 according to the type of the touch event. Although the touch panel 1071 and the display panel 1061 are shown in fig. 1 as two separate components to implement the input and output functions of the mobile terminal, in some embodiments, the touch panel 1071 and the display panel 1061 may be integrated to implement the input and output functions of the mobile terminal, and is not limited herein.
The interface unit 108 serves as an interface through which at least one external device is connected to the mobile terminal 100. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having an identification module, an audio input/output (I/O) port, a video I/O port, an earphone port, and the like. The interface unit 108 may be used to receive input (e.g., data information, power, etc.) from external devices and transmit the received input to one or more elements within the mobile terminal 100 or may be used to transmit data between the mobile terminal 100 and external devices.
The memory 109 may be used to store software programs as well as various data. The memory 109 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 109 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.
Referring to fig. 2, which is a schematic hierarchical diagram of an operating system stored in a storage program area, as shown in fig. 2, the operating system includes a Loader layer, a Kernel layer, a Native layer, a Framework layer (including a C + + Framework layer and a Java Framework layer), and an App layer, where an HAL layer (hardware abstraction layer) also exists between the Kernel layer and the Native layer, a JNI layer also exists between the C + + Framework layer and the Java Framework layer, and a SysCall layer also exists between the HAL layer and the Kernel layer.
The Loader layer comprises a Boot ROM (Boot service) and a Boot Loader (Boot initialization program), wherein the Boot ROM is mainly used for booting by pressing a Power (Boot) key for a long time when the mobile terminal is in a Power-off state, and a Boot chip starts to execute from a preset code solidified in the ROM. The Boot Loader is a Boot program before starting the operating system, and mainly has the functions of checking the RAM, initializing hardware parameters and the like.
The Kernel layer is mainly used for performing related work such as initialization process management, memory management, Display loading, Camera Driver (Camera Driver), Binder Driver (Binder Driver) and the like, and is used for creating Kernel daemon processes such as Kernel worker threads kworkder, soft interrupt threads ksofirqd and soft interrupt threads thermal.
The Native layer mainly comprises a daemon process of a user space hatched by init, a HAL layer, startup animation and the like. User daemon processes, User Daemons, such as ueven, logd, health, installd, adbd, and lmkd, can hatch out from the Init process (a User-level process started by a kernel); the init process also starts important services such as servicemanager and bootanim; the init process hatches a Zygote process, the Zygote process is the first Java process of the operating system, the Zygote process is the parent process of all the Java processes, and the Zygote process is hatched from the init process.
The Framework layer comprises a Zygote process, a System Server (System service) process and a Media Server (multimedia service) process, wherein the Zygote process is generated by an init process through analysis of an init.rc file and then fork, and mainly comprises loading Zygote init classes, registering Zygote Socket service end sockets, loading virtual machines, preloadClasses, preloadResouces and the like; the System Server process is derived from a Zygote process fork, the System Server is the first process of Zygote incubation, and the System Server is responsible for starting and managing the whole Java Framework and comprises services such as an ActivitiManager (application program component), a PowerManager (power supply management component) and a WindowManagerServer (window management component); the Media Server process, which is derived from the init process fork, is responsible for starting and managing the whole C + + frame, and includes services such as audio pointer (afofinger), Camera Service (Camera Service), and MediaPlayServer (multimedia Service).
The APP layer comprises APP processes, each APP process is generated by a Zygote process fork, the first APP process hatched by the Zygote process is a Launcher (desktop Launcher), desktop APPs seen by a user are created by the Zygote process, the App processes such as a Browser, a Phone and an Email are also created by the Zygote process, and each App runs on at least one process.
The processor 110 is a control center of the mobile terminal, connects various parts of the entire mobile terminal using various interfaces and lines, and performs various functions of the mobile terminal and processes data by operating or executing software programs and/or modules stored in the memory 109 and calling data stored in the memory 109, thereby performing overall monitoring of the mobile terminal. Processor 110 may include one or more processing units; preferably, the processor 110 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 110.
The mobile terminal 100 may further include a power supply 111 (e.g., a battery) for supplying power to various components, and preferably, the power supply 111 may be logically connected to the processor 110 via a power management system, so as to manage charging, discharging, and power consumption management functions via the power management system.
Although not shown in fig. 1, the mobile terminal 100 may further include a bluetooth module or the like, which is not described in detail herein.
Based on the above mobile terminal hardware structure, various embodiments of the mobile terminal of the present invention are provided.
The present invention provides a card screen detection method applied to a mobile terminal shown in fig. 1, and referring to fig. 3, in a first embodiment of the card screen detection method of the present invention, in this embodiment, the card screen detection method includes:
step S10, acquiring a preset core process of a Native framework layer of the mobile terminal in the system starting process;
the card screen detection method is applied to the mobile terminal shown in fig. 1, and the mobile terminal can comprise a smart phone or a tablet computer with an Android (Android) system. At present, functions of a mobile terminal are more and more powerful, the increase of the functions can lead to the increase of hardware, and the increase of the hardware can increase software driving, resource loading or initialization processes, so that a starting-up starting process is long, a previous process in the starting process can influence a later process, and the slow starting condition occurs. The embodiment is provided with a starting standardized mechanism, and the starting process of the Android system is combed, so that the starting process of the system is divided into five stages, namely a minimum system power-on and starting stage, a kernel layer power-on and starting stage, a Native layer starting stage, a framework layer starting stage and an application layer starting stage, and each starting stage is divided into an inherent part and a self-defined part of the Native system. After the starting process of the system is standardized, the processes are classified according to the process creation related to the execution of each stage flow after standardization. In the system starting process, data related to hardware and resources are mainly loaded and initialized, and processes related to the system starting process are divided into a core process and a non-core process according to the influence of the hardware and the resources on the system after the starting process is completed. The core process comprises a Camera driver, a Binder driver, a display driver and an all-in-one device driver (Wifi, Bluetooth, GPS, radio and NFC) of a Kernel layer; a daemon of the kernel; the method comprises the following steps of starting up animation of a Native layer, a ServiceManager process, an audioFlinger thread in a multimedia process, a media playing service thread, a Camera service thread, a zygate process of a Native framework layer and the like.
The card screen detection of the embodiment is mainly applied to a core process which is divided in advance, and is specifically applied to a zygate process in the core process, and obtains a preset core process of a Native framework layer, namely the zygate process, in a starting process of the mobile terminal. The executable program corresponding to Zygote is App _ process, the corresponding source file is App _ main. The Zygote process is monitored and judged by acquiring the Zygote process, whether the Zygote process is successfully created normally or not is determined, and whether the Zygote process is abnormally locked or blocked in a system starting execution flow or not during creation is determined, so that whether the screen clamping fault occurs in the mobile terminal or not is judged.
Step S20, monitoring a core process for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information;
further, after a preset core process of the Native framework layer is obtained, a core process for starting the system in the preset core process is monitored according to a preset monitoring rule. The preset monitoring rule is a rule scheme preset for monitoring the correctness of a core flow in the zygate process, and the core flow in the zygate process is a flow having a critical influence on system starting when the system is started. The Android (Android) comprises a C part and a Java part, the former is established on the basis of Linux, the latter is established on the basis of JVM, and the two parts are connected through Zygote. The Zygote process performs operations such as initialization of a virtual machine, loading of a library, loading of a prefabricated library and the like in the starting process of the system, and meanwhile, when the system needs a new virtual machine, the Zygote creates the virtual machine by copying the Zygote process. If the operation flow having a critical influence on the system starting in the process is found to have a large influence on the card screen of the mobile terminal in the using process, the flow A can be added as the core flow to monitor the core flow. And after the core flow is determined, setting monitoring points of the core flow according to a preset monitoring rule. If the core flow is a loading library, presetting the flow of the loading library in the monitoring rule, monitoring whether the loading path of the loading library is correct, and monitoring the size of the memory required by the loading library. Therefore, according to the preset monitoring rule, monitoring points are set, and the size of the loaded loading path and the loaded library is monitored. And acquiring monitoring result information obtained by monitoring so as to judge whether the mobile terminal has a card screen fault or not according to the monitoring result information.
And step S30, judging whether the mobile terminal has card screen fault according to the monitoring result information.
Furthermore, after the monitoring result information of the core process is obtained, whether the card screen fault occurs in the mobile terminal can be judged according to the monitoring result information. The preset monitoring rule comprises a monitoring point related to a monitoring position, a reference result used for judging whether the monitoring result information represents the card screen fault of the mobile terminal or not, and the monitoring result information obtained by monitoring is compared with the reference result to judge whether the monitoring result information and the reference result are consistent or not; when the judgment result is consistent, the monitoring result information shows that the mobile terminal has no card screen fault; and when the judgment result is inconsistent, the monitoring result information shows that the mobile terminal has a card screen fault. If the loading path of the monitoring loading library is from A to B, namely the monitoring result information is from A to B, and the reference result in the preset monitoring rule is from A to C, the monitoring result information is judged to be inconsistent with the reference result, and the monitoring result information shows that the card screen fault occurs in the mobile terminal. After the card screen fault of the mobile terminal is monitored, the reason of the card screen fault, namely the monitoring result information and the time of the card screen fault is stored, so that the reason of the card screen can be known by reading the stored information when the mobile terminal is monitored subsequently.
The invention provides a card screen detection method, a mobile terminal and a computer readable storage medium, which are implemented by acquiring a preset core of a Native framework layer of the mobile terminal in the system starting process, and monitoring a core flow for starting a system in the acquired preset core process according to a preset monitoring rule to obtain monitoring result information; and judging whether the mobile terminal has a card screen fault according to the monitoring result information. According to the scheme, the core process in the preset core process of the Native framework layer is monitored when the mobile terminal system is started through presetting the monitoring rule. When the core process is abnormal and causes the card screen, the reason causing the card screen can be found in time according to the monitored result information. After-sales personnel or developers can conveniently and quickly and accurately locate the reason of the card screen of the mobile terminal when monitoring the reason of the card screen of the mobile terminal, and the labor cost and the time cost are greatly reduced.
Further, based on the first embodiment, a second embodiment of the card screen detection method of the present invention is provided, in the second embodiment, the core process includes creating a path, registering information, preloading data, and reading a synchronization lock in the process of creating the path, registering information, and preloading data;
the step of monitoring the core process for starting the system in the preset core process according to the preset monitoring rule comprises the following steps:
judging whether the path is successfully created by the preset core process, whether the registration information is successful, whether the data is preloaded, and whether the synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data to obtain a judgment result, and generating monitoring result information according to the judgment result.
Further, the core flow of this embodiment includes creating a path, registering information, preloading data, and a synchronization lock read during creating the path, registering information, and preloading data, that is, a flow having a critical influence on system startup in such a zygate process is used as the core flow. Specifically, the creation path is a main execution function creation/data/dalvik-cache path of the Zygote process; the main execution function of the Zygote process as the registration information registers the socket for Zygote; the data in the preloaded data includes classes and resources, which are preloaded for the main execution function of the zygate process. The synchronization lock is used to ensure that resources are used by a single thread at the same time. Because multiple threads share the same resource, when multiple threads use the resource at the same time, the execution result of the thread is wrong. Therefore, if the current thread uses the resource, the current thread and the resource are synchronously locked, so that the resource cannot be used by other threads, and other threads cannot use the resource until the current thread finishes executing. In the embodiment, the operation of reading the synchronous lock in the process of establishing a/data/dalvik-cache path, registering a socket for Zygote and preloading data is taken as a core flow, so that the phenomenon that the synchronous lock is read wrongly in the process, the execution result of a thread is wrongly executed and a screen is blocked by the mobile terminal is avoided. Considering that the classes and resources preloaded by the Zygote process are numerous, the preloaded classes of the present implementation include: classes located in/system/etc/preloaded-classes files; the preloaded resources include: dracable and color resources; in addition, preloading data can further comprise: the method comprises the steps of preloading OpenGL, loading classes through a System, loadLibrary () method, preloading 3 shared libraries such as 'android', 'builder _ rt' and 'jnigraphics', and preloading text connector resources.
When core process monitoring is performed according to preset monitoring rules, the monitoring rules set in the preset monitoring rules are different according to different types of the core processes. Specifically, when the core flow is a path creation, whether the creation of the main execution function/data/dalvik-cache path of the Zygote process is successful is monitored; when the core flow is the registration information, monitoring whether a main execution function of the Zygote process is successful in registering the socket for the Zygote; when the core flow is the preloading data, monitoring whether the class and the resource are preloaded successfully by the main execution function of the Zygote process; when the core process is reading the synchronous lock in the process of creating the path, registering the information and preloading the data, monitoring whether the read synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data; the synchronous lock blocking is the condition that when a thread uses a resource, the thread occupies the resource for too long time due to some reasons, other threads needing to use the resource wait for time, and cause blocking, and the synchronous lock deadlock is the condition that two threads respectively need the resource held by the other thread and wait for each other. When the synchronous lock is blocked and deadlocked, the execution result of the thread is influenced, the starting of the system is influenced, and the screen of the mobile terminal is blocked. Therefore, according to the detection rules, the core processes are judged to obtain judgment results, and the judgment results are used for generating monitoring result information.
Further, based on the first or second embodiment, a third embodiment of the card screen detection method of the present invention is provided, in the third embodiment, the step of determining whether the card screen fault occurs in the mobile terminal according to the monitoring result information includes:
step S31, judging whether the monitoring result information is consistent with preset reference information;
step S32, when the monitoring result information is consistent with preset reference information, judging that no card screen fault occurs in the mobile terminal;
and step S33, when the monitoring result information is consistent with preset reference information, judging that the mobile terminal has a card screen fault.
Furthermore, in order to determine whether the monitoring result information includes information that causes the mobile terminal to have a card screen fault, the present embodiment is preset with reference information, that is, preset reference information. After the monitoring result information is acquired, whether the monitoring result information is consistent with preset reference information or not is judged, if the monitoring result information is consistent with the preset reference information, the core flow for starting the system is represented as a normal starting flow, the mobile terminal can be judged not to have a card screen fault, if the monitoring result information is inconsistent with the preset reference information, the core flow for starting the system is represented as an abnormal state, and the mobile terminal is judged to have the card screen fault. The preset reference information is different for different core flows, and when the core flow is a path creation, the preset reference information is a path creation success identifier; when the main execution function of the Zygote process successfully establishes the/data/dalvik-cache path, returning monitoring result information as a successful establishing identifier; when the creation is failed, the identifier is the creation failure identifier; therefore, when the monitoring result information is the identifier which is successfully created, the monitoring result information is consistent with the preset reference information, and the core flow of the created path is judged to be normal. Correspondingly, when the core flow is registration information, presetting reference information as a successful registration identifier; when the core flow is the preloaded data, the core flow is a loading success identifier; and when the core flow is to read the synchronous lock in the processes of creating the path, registering information and preloading data, the core flow is to read the successful identifier. Understandably, the system is started as a result of all core processes, so that the mobile terminal can be judged to be normally started only when the monitoring result information of each core process is consistent with the preset reference information; and when any item is inconsistent with the preset reference information, the screen clamping phenomenon of the mobile terminal can be judged. In addition, the determination of successful loading of the preloaded data is also determined by multiple factors, which can be specifically classified into a name, a path, a required memory size, whether the required memory exceeds the available memory, whether a mapping table established after the memory application is successful is correct, and the like. And judging that the loading is successful only if all the factors are normally monitored, otherwise, an error can be caused by any error. If the preloaded resource is a color resource, monitoring a path error during loading, judging that the preloaded resource is wrong, returning a loading error identifier, and judging that the card screen fault occurs in the mobile terminal if the preloaded resource is inconsistent with the preset reference information.
Further, based on the first, second, or third embodiment, a fourth embodiment of the card screen detection method of the present invention is provided, where in the fourth embodiment, the step of determining that the card screen fault occurs in the mobile terminal includes:
and step S34, collecting monitoring result information in real time, and storing the collected monitoring result information after carrying out redundancy removal processing within preset time.
Furthermore, when the mobile terminal is judged to have the card screen fault, the monitoring result information is collected in real time so as to reflect the reason of the card screen of the mobile terminal in real time, and the collected monitoring result information is subjected to redundancy removal processing and then stored in the preset time. The preset time is a reasonable redundancy removing interval time determined through experiments, and in the interval time, data needing redundancy removing are not too much or too little, so that too long time is spent or redundancy removing is too frequent. The redundancy removing process is to integrate the monitoring result information collected in the preset time into an information output and storage, wherein the information comprises the reason type of the card screen, the time point of occurrence and the frequency of occurrence of various types. If the preset time is one hour, 100 pieces of monitoring result information are received within the preset time between 9 points and 10 points, wherein the number of card screens caused by path creation failure is 30, the number of card screens caused by registration information failure is 50, and the number of card screens caused by color resource preloading failure is 20, the 100 pieces of monitoring result information are integrated into one piece of information including type, number and time point to be output and stored, and the type and time point of the 100 pieces of information are prevented from being output and stored respectively, so that the storage space is saved.
Further, based on the fourth embodiment, a fifth embodiment of the card screen detection method of the present invention is provided, in the fifth embodiment, after the step of performing redundancy removal and post-processing on the collected monitoring result information within a preset time and storing the collected monitoring result information, the method includes:
step S35, judging whether the size of the stored data volume exceeds the size of the preset data volume, when the size of the stored data volume exceeds the size of the preset data volume, selecting information to be deleted from the stored monitoring result information, and deleting the information to be deleted.
Understandably, the storage unit in the mobile terminal is divided into a plurality of storage sections, each storage section is used for storing different data, and the capacity of each storage section is constant, that is, the amount of data which can be stored is constant. Accordingly, the capacity of the storage interval for storing the monitoring result information is also constant, and when the monitoring result information is stored in the storage interval within the preset time, the amount of data stored in the storage interval is increased continuously and may exceed the capacity. Therefore, after the monitoring result information is subjected to redundancy removal processing and stored, whether the size of the stored data volume exceeds the size of the preset data volume is judged, and the size of the preset data volume is the capacity of the storage area for storing the monitoring result information. When the size of the stored data amount exceeds the preset data amount, it is described that the capacity of the storage interval is used up, data storage can no longer be performed, and the stored data needs to be deleted. And selecting information to be deleted from the stored monitoring result information, and deleting the information to be deleted. The selection principle can be based on the time sequence, and the earlier the time sequence is, the longer the current time of the monitoring result information is, the less the referential significance is, so that the monitoring result information is selected as the information to be deleted for deletion.
Further, referring to fig. 4, based on the first, second, third, fourth, or fifth embodiments, a sixth embodiment of the card screen detection method of the present invention is provided, in the sixth embodiment, after the step of determining whether the card screen fault occurs in the mobile terminal according to the monitoring result information, the method includes:
and step S40, when the mobile terminal has a card screen fault, outputting the monitoring result information to a feature log file.
Furthermore, when the mobile terminal is judged to have the card screen fault according to the monitoring result information, the monitoring result information is output to the feature log file. Specifically, a thread can be independently created to output monitoring result information to a debug process, the debug process is a diagnosis process for abnormal exit of a program of the Android system, and the debug process can detect program crash and output process state information during the crash to a file and a serial port for a developer to analyze and debug. The implementation outputs the monitoring result information to the Debugerd process, and the Debugerd process directionally outputs the monitoring result information to the characteristic log file with the Debugerd authority processing. Therefore, when monitoring and positioning of the card screen reasons are carried out on the mobile terminal by developers, the card screen reasons can be quickly and accurately positioned by inquiring the characteristic log file, and the labor cost and the time cost are reduced.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a hardware operating environment related to a method according to an embodiment of the present invention.
The mobile terminal of the embodiment of the invention can be a mobile terminal device with a display function, such as a smart phone, a tablet computer, an electronic book reader, a portable computer and the like.
As shown in fig. 5, the mobile terminal may include: a processor 110, such as a CPU, a memory 109, and a communication bus 1002. Wherein the communication bus 1002 is used for implementing connection communication between the processor 110 and the memory 109. The memory 109 may be a high-speed RAM memory or a non-volatile memory (e.g., a disk memory). The memory 109 may alternatively be a storage device separate from the processor 110 described above.
Optionally, the mobile terminal may further include a user interface, a network interface, a camera, RF (Radio Frequency) circuitry, a sensor, audio circuitry, a WiFi module, and so on. The user interface may comprise a Display screen (Display), an input unit such as a Keyboard (Keyboard), and the optional user interface may also comprise a standard wired interface, a wireless interface. The network interface may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface).
Those skilled in the art will appreciate that the mobile terminal architecture shown in fig. 5 is not intended to be limiting of mobile terminals and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
As shown in fig. 5, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, and a card screen detection program of the mobile terminal. The operating system is a program that manages and controls the hardware and software resources of the mobile terminal, supporting the operation of the mobile terminal as well as other software and/or programs. The network communication module is used for communicating between the various components within the memory 1005, as well as with other hardware and software within the mobile terminal.
In the mobile terminal shown in fig. 5, the processor 1001 is configured to execute a card screen detection program of the mobile terminal stored in the memory 1005, and implement the following steps:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information;
and judging whether the mobile terminal has a card screen fault or not according to the monitoring result information.
Further, the core process comprises creating a path, registering information, preloading data, and reading a synchronization lock in the process of creating the path, registering information, and preloading data;
the step of monitoring the core process for starting the system in the preset core process according to the preset monitoring rule comprises the following steps:
judging whether the path is successfully created by the preset core process, whether the registration information is successful, whether the data is preloaded, and whether the synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data to obtain a judgment result, and generating monitoring result information according to the judgment result.
Further, the step of judging whether the mobile terminal has a card screen fault according to the monitoring result information includes:
judging whether the monitoring result information is consistent with preset reference information or not;
when the monitoring result information is consistent with preset reference information, judging that the mobile terminal has no card screen fault;
and when the monitoring result information is inconsistent with the preset reference information, judging that the mobile terminal has a card screen fault.
Further, after the step of determining that the card screen failure occurs in the mobile terminal, the processor 1001 is configured to execute a card screen detection program of the mobile terminal stored in the memory 1005, and implement the following steps:
and collecting monitoring result information in real time, and storing the collected monitoring result information after carrying out redundancy removal processing within preset time.
Further, after the step of performing redundancy removal and post-processing on the collected monitoring result information within the preset time and then storing the collected monitoring result information, the processor 1001 is configured to execute a card screen detection program of the mobile terminal stored in the memory 1005, and implement the following steps:
judging whether the size of the stored data volume exceeds the size of the preset data volume, selecting information to be deleted from the stored monitoring result information when the size of the stored data volume exceeds the size of the preset data volume, and deleting the information to be deleted.
Further, after the step of determining whether the card screen failure occurs in the mobile terminal according to the monitoring result information, the processor 1001 is configured to execute a card screen detection program of the mobile terminal stored in the memory 1005, so as to implement the following steps:
and when the mobile terminal has a card screen fault, outputting the monitoring result information to a feature log file.
The specific implementation of the mobile terminal of the present invention is substantially the same as the embodiments of the card screen detection method, and is not described herein again.
The present invention provides a computer-readable storage medium storing one or more card screen detection programs, the one or more card screen detection programs further executable by one or more processors for:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information;
and judging whether the mobile terminal has a card screen fault or not according to the monitoring result information.
Further, the core process comprises creating a path, registering information, preloading data, and reading a synchronization lock in the process of creating the path, registering information, and preloading data;
the step of monitoring the core process for starting the system in the preset core process according to the preset monitoring rule comprises the following steps:
judging whether the path is successfully created by the preset core process, whether the registration information is successful, whether the data is preloaded, and whether the synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data to obtain a judgment result, and generating monitoring result information according to the judgment result.
Further, the step of judging whether the mobile terminal has a card screen fault according to the monitoring result information includes:
judging whether the monitoring result information is consistent with preset reference information or not;
when the monitoring result information is consistent with preset reference information, judging that the mobile terminal has no card screen fault;
and when the monitoring result information is consistent with preset reference information, judging that the mobile terminal has a card screen fault.
Further, after the step of determining that the card screen failure occurs in the mobile terminal, the one or more card screen detection programs may be further executable by one or more processors to:
and collecting monitoring result information in real time, and storing the collected monitoring result information after carrying out redundancy removal processing within preset time.
Further, after the step of performing redundancy removal and post-processing on the collected monitoring result information within the preset time and storing the collected monitoring result information, the one or more card screen detection programs may be further executed by one or more processors to:
judging whether the size of the stored data volume exceeds the size of the preset data volume, selecting information to be deleted from the stored monitoring result information when the size of the stored data volume exceeds the size of the preset data volume, and deleting the information to be deleted.
Further, after the step of determining whether the mobile terminal has a card screen failure according to the monitoring result information, the one or more card screen detection programs may be further executed by one or more processors to:
and when the mobile terminal has a card screen fault, outputting the monitoring result information to a feature log file.
The specific embodiment of the computer-readable storage medium of the present invention is substantially the same as the specific embodiments of the card screen detection method described above, and details thereof are not repeated herein.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a computer storage medium (e.g., ROM/RAM, magnetic disk, optical disk) as described above and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims (10)

1. A card screen detection method is applied to a mobile terminal, and is characterized by comprising the following steps:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information, wherein the core process comprises a path creation process, registration information and pre-loading data, and a synchronous lock is read in the path creation process, the registration information process and the pre-loading data process;
and judging whether the mobile terminal has a card screen fault according to the monitoring result information of the core flow.
2. The card screen detection method according to claim 1, wherein the step of monitoring a core process for starting a system in the preset core process according to a preset monitoring rule comprises:
judging whether the path is successfully created by the preset core process, whether the registration information is successful, whether the data is preloaded, and whether the synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data to obtain a judgment result, and generating monitoring result information according to the judgment result.
3. The card screen detection method of claim 1, wherein the step of determining whether the card screen failure occurs in the mobile terminal according to the monitoring result information comprises:
judging whether the monitoring result information is consistent with preset reference information or not;
when the monitoring result information is consistent with preset reference information, judging that the mobile terminal has no card screen fault;
and when the monitoring result information is inconsistent with the preset reference information, judging that the mobile terminal has a card screen fault.
4. The card screen detection method of claim 3, wherein the step of determining that the mobile terminal has a card screen failure is followed by:
and collecting monitoring result information in real time, and storing the collected monitoring result information after carrying out redundancy removal processing within preset time.
5. The card screen detection method of claim 4, wherein the step of performing redundancy removal and post-processing on the collected monitoring result information within a preset time and then storing the collected monitoring result information comprises the following steps:
judging whether the size of the stored data volume exceeds the size of the preset data volume, selecting information to be deleted from the stored monitoring result information when the size of the stored data volume exceeds the size of the preset data volume, and deleting the information to be deleted.
6. The card screen detection method according to any one of claims 1 to 5, wherein the step of determining whether the card screen failure occurs in the mobile terminal according to the monitoring result information comprises:
and when the mobile terminal has a card screen fault, outputting the monitoring result information to a feature log file.
7. A mobile terminal, characterized in that the mobile terminal comprises: memory, processor, communication bus and card screen detection program stored on the memory:
the communication bus is used for realizing connection communication between the processor and the memory;
the processor is used for executing the card screen detection program to realize the following steps:
acquiring a preset core process of a Native framework layer of a mobile terminal in a system starting process;
monitoring a core process used for starting a system in the preset core process according to a preset monitoring rule, and acquiring monitoring result information, wherein the core process comprises a path creation process, registration information and pre-loading data, and a synchronous lock is read in the path creation process, the registration information process and the pre-loading data process;
and judging whether the mobile terminal has a card screen fault according to the monitoring result information of the core flow.
8. The mobile terminal according to claim 7, wherein the step of monitoring the core process for starting the system in the preset core process according to a preset monitoring rule comprises:
judging whether the path is successfully created by the preset core process, whether the registration information is successful, whether the data is preloaded, and whether the synchronous lock is blocked or deadlocked in the process of creating the path, registering the information and preloading the data to obtain a judgment result, and generating monitoring result information according to the judgment result.
9. The mobile terminal according to claim 7, wherein the card screen detection program implements the steps of the card screen detection method according to any one of claims 3 to 6 when executed by the processor.
10. A computer-readable storage medium, having stored thereon a card screen detection program which, when executed by a processor, implements the steps of the card screen detection method according to any one of claims 1 to 6.
CN201711060999.9A 2017-10-31 2017-10-31 Card screen detection method, mobile terminal and computer readable storage medium Active CN107861827B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711060999.9A CN107861827B (en) 2017-10-31 2017-10-31 Card screen detection method, mobile terminal and computer readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711060999.9A CN107861827B (en) 2017-10-31 2017-10-31 Card screen detection method, mobile terminal and computer readable storage medium

Publications (2)

Publication Number Publication Date
CN107861827A CN107861827A (en) 2018-03-30
CN107861827B true CN107861827B (en) 2021-05-21

Family

ID=61697172

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711060999.9A Active CN107861827B (en) 2017-10-31 2017-10-31 Card screen detection method, mobile terminal and computer readable storage medium

Country Status (1)

Country Link
CN (1) CN107861827B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108920195B (en) * 2018-06-19 2021-05-18 Oppo(重庆)智能科技有限公司 Boot processing method and related product
CN111179369B (en) * 2019-12-27 2023-07-25 珠海全志科技股份有限公司 GPU rendering method and device based on android system
CN113867879B (en) * 2021-10-15 2023-09-22 数源科技股份有限公司 Android-based system style depth customization method

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101221585A (en) * 2008-02-03 2008-07-16 华为技术有限公司 Data storage method and device
CN103514007A (en) * 2012-08-31 2014-01-15 Tcl集团股份有限公司 Method for warm start of mobile terminal based on Android system
CN106484555A (en) * 2016-09-29 2017-03-08 广东欧珀移动通信有限公司 Abnormality detection and the method recovered and mobile terminal
CN106547598A (en) * 2016-11-22 2017-03-29 四川长虹电器股份有限公司 The method for lifting Android application program launching speed
CN106649017A (en) * 2016-12-30 2017-05-10 珠海市魅族科技有限公司 On screen display abnormality processing method and mobile terminal
CN106792185A (en) * 2016-11-15 2017-05-31 深圳Tcl数字技术有限公司 Starting-up method, opening device and Android smart machines
CN106897197A (en) * 2015-12-17 2017-06-27 阿里巴巴集团控股有限公司 The De-weight method and device of error log
CN107133143A (en) * 2017-04-25 2017-09-05 努比亚技术有限公司 Restart daily record merging method, method for uploading, system and readable storage medium storing program for executing

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9143530B2 (en) * 2011-10-11 2015-09-22 Citrix Systems, Inc. Secure container for protecting enterprise data on a mobile device
KR101588295B1 (en) * 2014-01-28 2016-01-25 현대모비스 주식회사 The System and Method for Booting the Application of the Terminal

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101221585A (en) * 2008-02-03 2008-07-16 华为技术有限公司 Data storage method and device
CN103514007A (en) * 2012-08-31 2014-01-15 Tcl集团股份有限公司 Method for warm start of mobile terminal based on Android system
CN106897197A (en) * 2015-12-17 2017-06-27 阿里巴巴集团控股有限公司 The De-weight method and device of error log
CN106484555A (en) * 2016-09-29 2017-03-08 广东欧珀移动通信有限公司 Abnormality detection and the method recovered and mobile terminal
CN106792185A (en) * 2016-11-15 2017-05-31 深圳Tcl数字技术有限公司 Starting-up method, opening device and Android smart machines
CN106547598A (en) * 2016-11-22 2017-03-29 四川长虹电器股份有限公司 The method for lifting Android application program launching speed
CN106649017A (en) * 2016-12-30 2017-05-10 珠海市魅族科技有限公司 On screen display abnormality processing method and mobile terminal
CN107133143A (en) * 2017-04-25 2017-09-05 努比亚技术有限公司 Restart daily record merging method, method for uploading, system and readable storage medium storing program for executing

Also Published As

Publication number Publication date
CN107861827A (en) 2018-03-30

Similar Documents

Publication Publication Date Title
CN107276789B (en) Log uploading method and device and computer readable storage medium
EP3402160B1 (en) Service processing method and apparatus
CN107885635B (en) Black screen detection method, mobile terminal and computer readable storage medium
CN107678876B (en) Screen freezing monitoring and solving method, mobile terminal and computer readable storage medium
US10824449B2 (en) Application running method and device
CN108040159B (en) Restart positioning method based on hardware drive, mobile terminal and readable storage medium
CN107590057B (en) Screen freezing monitoring and solving method, mobile terminal and computer readable storage medium
CN107704133B (en) Screen freezing monitoring and solving method, mobile terminal and computer readable storage medium
CN107807861B (en) Screen freezing solution method, mobile terminal and computer readable storage medium
CN107765922B (en) Card screen detection and solution method, mobile terminal and computer readable storage medium
CN107908491B (en) Card screen detection and solution method, mobile terminal and computer readable storage medium
CN107704363B (en) Screen freezing monitoring method, mobile terminal and computer readable storage medium
CN107861827B (en) Card screen detection method, mobile terminal and computer readable storage medium
CN107766222B (en) Black screen detection method, mobile terminal and computer readable storage medium
CN107704332B (en) Screen freezing solution method, mobile terminal and computer readable storage medium
CN108052430B (en) Mobile terminal restart positioning method, mobile terminal and computer readable storage medium
CN108012031B (en) Mobile terminal restart positioning method, mobile terminal and computer readable storage medium
CN107832191B (en) Black screen detection method, mobile terminal and computer readable storage medium
CN107908492B (en) Black screen detection method, mobile terminal and computer readable storage medium
CN107818036B (en) Black screen detection method, mobile terminal and computer readable storage medium
CN108089937B (en) Direct memory allocation-based restart positioning method, mobile terminal and storage medium
CN107748633B (en) Solution for terminal screen freezing, terminal and computer readable storage medium
CN107861826B (en) Screen freezing monitoring and solving method, mobile terminal and computer readable storage medium
CN105278942B (en) Component management method and device
CN107872367B (en) Black screen detection method, mobile terminal and computer readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant