Log system applied to android pos machine terminal

Abstract

The application provides a log system applied to an Android POS terminal. The log system comprises a double-process daemon protection module, a system process application resident memory, a first monitoring unit and a second monitoring unit for monitoring a log recording process, the first monitoring unit and the second monitoring unit monitor each other through a first interface, and when the other process is monitored to end, the process starts the other process according to the current process, so as to continuously record the log; and a system log daemon process, which is used to start the system process application resident memory when the memory state is lower than a preset threshold, so as to avoid that the log recording process of the system process application is closed by a security mechanism. The above technical scheme can guarantee the persistence and integrity of the recording process, and can guarantee that more useful information can be obtained when the log is used.

Description

Technical Field

[0001] This application relates to the field of operating systems, and more particularly to a log system for Android POS terminals. Background Technology

[0002] Mobile phone hardware manufacturers are concerned with hardware logs, application developers are concerned with application logs, and hardware manufacturers of unattended devices are concerned not only with the hardware's operating status but also with the software and system's operating status. Currently, the logging mechanisms they have built mainly address the logging functions in their respective areas of interest. The native Android system provides a simple way to record and upload logs.

[0003] However, Android POS terminals encounter the following problems when deployed in different environments: 1) Various temporary and unreproducible anomalies due to abnormal operating environments; 2) Anomalies caused by customers leaving or forgetting how to operate the terminal; 3) Occasional software and hardware anomalies after prolonged operation (e.g., a loose or incomplete interface); 4) Software and hardware anomalies caused by bugs in the terminal application. Furthermore, because the operating environment of the terminal is difficult to reproduce, these anomalies are hard to reproduce, making it impossible for developers to locate the cause and thus unable to fix or avoid the problems caused by the anomalies.

[0004] Therefore, providing a stable log system for Android POS terminals that can be configured with different functional focuses according to customer needs and application scenarios is an urgent technical problem to be solved. Summary of the Invention

[0005] The technical problem to be solved by this application is to provide a log system for Android POS terminals that has high stability and can be configured with different functional focuses according to different customer needs and application scenarios.

[0006] To address the aforementioned issues, this application provides a logging system for Android POS terminals, comprising: a dual-process protection module, including a system process application resident in memory, a first monitoring unit and a second monitoring unit for monitoring the logging process, wherein the first and second monitoring units monitor each other's processes through a first interface, and upon detecting the termination of the other process, start the other process according to their own current process to continuously perform log recording; and a system log daemon process, used to enable the system process application to reside in memory when the memory status is below a preset threshold, so as to prevent the logging process of the system process application from being closed by security mechanisms.

[0007] In some embodiments, the logging system further includes a dynamic detection module, used to periodically detect the logging process using dynamic programming, and determine whether the currently detected logging process is running correctly based on the detection results.

[0008] In some embodiments, determining whether the currently detected logging process is running correctly based on the detection result includes: determining whether the currently detected logging process is running correctly based on the growth of the recorded log file; if the log file grows correctly, determining that the logging process is running correctly; otherwise, determining that the logging process is running abnormally and restarting the logging process.

[0009] In some embodiments, the dynamic detection module further uses a hardware clock to set a timer alarm via baseband processor communication, so as to perform timed detection of the logging process using dynamic programming.

[0010] In some embodiments, the log system further includes: a log storage module for storing uncompressed log files and compressed log files; and a dynamic expansion module for enabling dynamic expansion based on the maximum limit number of uncompressed log files to improve the storage capacity of the log storage module.

[0011] In some embodiments, the maximum number of uncompressed log files is equal to the total log capacity limit / (size of each file * (1 + compression ratio)), where the total log capacity limit is set according to the log storage module, and the compression ratio is the compression percentage of the compressed log files.

[0012] In some embodiments, the logging system further includes a secure storage module for recording all log files in a private storage area, wherein the private storage area is read and written only by the logging process.

[0013] In some embodiments, the logging system further includes a secure delivery module, configured to receive a log file of type zip format output by the logging process, and provide the log file to a third-party application via a second interface using encrypted delivery and certificate verification.

[0014] In some embodiments, the second interface includes: a log packaging interface, used to package the log file according to a first parameter representing the password of the compressed file, a second parameter representing the log output level, and a third parameter representing the output path of the compressed file to be output externally; and a parameter setting interface, used to set the parameter type using JSON.

[0015] In some embodiments, the log system further includes a log processing module, configured to perform rolling recording of logs and, when the number of recorded log files exceeds a threshold, delete the earliest recorded log file.

[0016] The above technical solution ensures the persistence and integrity of the recording process by setting up a dual-process protection module that includes a system process application resident memory, a first listening unit and a second listening unit for monitoring the log recording process, and a system log guardian process for enabling the system process application resident memory when the memory status is lower than a preset threshold. This maximizes the availability of more useful information when using the logs.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus should be considered part of the specification. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the specific implementation of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a framework diagram of a log system applied to an Android POS terminal in one embodiment of this application; Figure 2 This is a lifecycle diagram of the log recording process and the dual-process protection module in one embodiment of this application; Figure 3 This is a flowchart of dynamic log expansion in one embodiment of this application; Figure 4 This is a flowchart illustrating the process of a USB storage device acquiring log information in one embodiment of this application; Figure 5 This is a schematic diagram of the log types recorded by the log system in one embodiment of this application; Figure 6 This is a flowchart of an exception handling method in one embodiment of this application. Detailed Implementation

[0020] The technical solutions of the specific embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described specific embodiments are only a part of the specific embodiments of this application, and not all of the specific embodiments. Based on the specific embodiments of this application, all other specific embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It should be noted that the abnormal issues mentioned in this article refer to phenomena on the terminal that are inconsistent with actual operation or environment, such as application crashes, abnormal screen display, unresponsive clicks, and intermittent signal. The key information of these abnormal issues refers to the crucial software and hardware information that caused the abnormal phenomenon. For example, if the abnormal issue is intermittent network connectivity, the key information is the terminal's network status at that time. The causes of these abnormal issues refer to the reasons that caused the abnormal phenomenon, such as software vulnerabilities, hardware defects, or misoperation. The solutions to these abnormal issues refer to the methods used to resolve the abnormal phenomenon. For example, software vulnerabilities can be resolved by updating the application with the bug fixed. The logs mentioned refer to the recorded terminal status information, including operating system output, application output, and driver output, all stored in text files. The AIDL interface mentioned refers to the Android Interface Definition Language, used for direct communication and interaction between multi-process applications. The compression ratio mentioned refers to the compression ratio of the current log file, calculated as: Compression Ratio = Compressed File Size / Original File Size.

[0022] To address the problems encountered by existing Android POS terminals when deployed in different environments, such as: various temporary and unreproducible anomalies caused by abnormal operating environments; anomalies caused by customers leaving or forgetting how to operate the terminal; occasional software and hardware anomalies after long-term operation (e.g., a loose or incomplete interface); and software and hardware anomalies caused by bugs in the terminal application, this application provides a log system for Android POS terminals that is highly stable and allows for setting functional priorities according to different customer needs and application scenarios.

[0023] The following describes the log system for Android POS terminals provided in the specific embodiments of this application. Figure 1 This is a framework diagram of a log system applied to an Android POS terminal in one embodiment of this application. Please refer to the following: Figure 1The logging system applied to the Android POS terminal includes a dual-process protection module 1 and a system log guardian process 2. The dual-process protection module 1 includes a system process application resident in memory 11, a first listening unit 12 and a second listening unit 13 for monitoring the log recording process. The first listening unit 12 and the second listening unit 13 monitor each other's processes through a first interface 31, and upon detecting the termination of the other process, start the other process according to their own current process to continuously record logs. The second interface 32 is used to expose the log recording process. The system log guardian process 2 is used to enable the system process application resident in memory 11 when the memory status is below a preset threshold, to prevent the log recording process of the system process application from being closed by security mechanisms. By continuously recording various types of logs from the terminal and querying the terminal status logs at the time of the anomaly, the system can prove and confirm the events that occurred on the terminal at that time, facilitating operational confirmation and resolution of related issues.

[0024] Figure 2 This is a lifecycle diagram of the logging process and the dual-process protection module in one embodiment of this application. Please refer to the following: Figure 2 Upon power-on, the operating system and the dual-process protection module are activated. The dual-process protection module binds a first monitoring unit and a second monitoring unit to the logging process, respectively, to monitor for the logging process's termination. Upon detecting the termination of the other process, it restarts the other process based on its own current process. Normally, when the operating system's memory is below a preset threshold, the operating system closes the logging process and forcibly saves the recorded files. At this time, the dual-process protection module detects the logging process being closed and immediately restarts it to ensure that the logging process is not closed by the system's security mechanism under low memory conditions. Furthermore, the logging system applied to the Android POS terminal does not prevent the reduction of other resident system processes, ensuring that other applications do not consume excessive system resources.

[0025] Please continue reading below. Figure 1In this embodiment, the log system applied to the Android POS terminal further includes a dynamic detection module 4, used to periodically detect the log recording process using dynamic programming, and determine whether the currently detected log recording process is running correctly based on the detection results. For example, when the dynamic detection module 4 detects that the screen is on, it will generate random intervals of 15 to 50 minutes to dynamically detect whether the recording task is normal; when the dynamic detection module 4 detects that the screen is off and the local time is between 24:00 and 6:00, it will generate random intervals of 60 to 180 minutes to dynamically detect whether the recording task is normal; when the dynamic detection module 4 detects that the screen is off and the local time is between 6:00 and 24:00, it will generate random intervals of 30 to 90 minutes to dynamically detect whether the recording task is normal.

[0026] In this implementation, determining whether the currently detected log recording process is running correctly based on the detection results includes: determining whether the currently detected log recording process is running correctly based on the growth of the recorded log file; if the log file grows correctly, the log recording process is determined to be running correctly; otherwise, the log recording process is determined to be running abnormally and the log recording process is restarted.

[0027] In this embodiment, the dynamic detection module 4 further uses a hardware clock to set a timer alarm via baseband processor communication, employing dynamic programming to periodically detect the logging process, ensuring continuous logging under various extreme operating conditions. For example, to prevent the logging process from being interrupted by the Android sleep mechanism, an alarm is set at random intervals of 180-210 minutes from the start of the logging task, to check whether the logging process is functioning normally at the scheduled time.

[0028] Please continue reading below. Figure 1 In this embodiment, the log system applied to the Android POS terminal further includes: a log storage module 5 for storing uncompressed log files and compressed log files; and a dynamic expansion module 6 for enabling dynamic expansion based on the maximum number of uncompressed log files to improve the storage capacity of the log storage module 5.

[0029] The maximum number of uncompressed log files = total log capacity limit / (size of each file * (1 + compression ratio)), where the total log capacity limit is set according to the log storage module, and the compression ratio is the compression percentage of the compressed log files.

[0030] The specific derivation process is as follows: Given: Total log capacity limit = Size of each file * Maximum number of files + Size of each file * Maximum number of files * Compression ratio; Therefore: Maximum number of logs = Total log limit / (size of each file * (1 + compression ratio)).

[0031] The following example illustrates the process using a maximum capacity limit of 180MB and a file size of 4MB. Actual test data is as follows: Without enabling the dynamic expansion module, the maximum capacity limit can store a maximum of 45 files. A normal terminal can typically record information from approximately two files per day, totaling about 22 days of data. With the dynamic expansion module enabled, the log system applied to the Android POS terminal records approximately 42 log files and a compressed file containing those 42 files, totaling about 42 days of data. Compared to the original recording method, the log system applied to the Android POS terminal described in this application improves storage capacity by 90%.

[0032] Figure 3 This is a flowchart illustrating dynamic log expansion in one embodiment of this application. Please refer to the following: Figure 3 The dynamic expansion module 6 performs the following steps for dynamically expanding the log storage capacity: after power-on, it executes step S31 to calculate the maximum number of storage files; and simultaneously executes step S32 to start the log recording process, dynamically expanding the capacity through compression ratio to ensure greater log storage capacity within the same storage space. Step S31, calculating the maximum number of storage files, further includes: calculating the compression ratio of the log files, calculating the maximum number of files to be stored based on the storage capacity and compression ratio, and comparing the maximum number of storage files with the compression ratio. If the maximum number of storage files is the same, the calculation task ends; if the maximum number of storage files is different, the member variable parameters of the files and the corresponding log recording process are updated. Step S32, starting the log recording process, further includes: reading the current maximum storage number and other relevant parameters from the files, and starting the log recording process based on the relevant parameters. In this embodiment, when the log recording process restarts, the dynamic expansion module 6 re-executes step S32 to read the current maximum storage number and other relevant parameters from the files.

[0033] Please continue reading below. Figure 1 In this embodiment, the log system applied to the Android POS terminal further includes a secure storage module 7, which is used to record all log files in a private storage area, wherein the private storage area is only read and written by the log recording process to ensure data security.

[0034] Please continue reading below. Figure 1In this embodiment, the log system applied to the Android POS terminal further includes a secure transmission module 8, used to receive log files in zip format output by the log recording process, and to provide the log files to the third-party application 10 via a second interface 32 using encrypted transmission and certificate verification. The second interface 32 is used to expose the log recording process. Specifically, by placing a trusted encryption certificate on an external storage device, when the secure transmission module 8 receives an external storage device mounting broadcast, it checks whether the specified certificate file exists, pops up a certificate password input box, and then verifies whether the other party's certificate is a legitimate user by accessing the certificate and using the verification certificate embedded in the terminal firmware of Shanghai Huiyin. Only then can the encrypted compressed file be transmitted to the third-party external storage device to maximize the protection of data from being obtained by third parties.

[0035] Figure 4 This is a flowchart illustrating the acquisition of log information by a USB storage device in one embodiment of this application. Please refer to the following: Figure 4 The steps for obtaining log information using the USB storage device include: simultaneously executing step S41, verifying the user certificate, and step S42, security verification, when the USB storage device is inserted. Step S41, verifying the user certificate, further includes: checking if an encrypted storage certificate exists in the USB storage device; if no encrypted storage certificate exists, the task ends; if an encrypted storage certificate exists, a user certificate password input box pops up, and the user password is confirmed. If the user password and certificate verification are successful, the log file is encrypted and compressed, and the encrypted file is copied to the USB storage device, prompting the user to remove the storage device; if the user password and certificate verification fail, an incorrect password message is displayed, and a new input box pops up for the user to enter the user certificate password before proceeding to the next round of verification; if the user cancels the input, the task ends. Step S42, security verification, includes using an Android Root certificate for security verification.

[0036] In some embodiments, the second interface includes: a log packaging interface, used to package the log file according to a first parameter representing the password of the compressed file, a second parameter representing the log output level, and a third parameter representing the output path of the compressed file to be output externally; and a parameter setting interface, used to set the parameter type using JSON to ensure that operators can quickly understand the configuration content.

[0037] Please continue reading below. Figure 1 In this embodiment, the log system applied to the Android POS terminal further includes: a log processing module 9, which is used to record logs in a rolling manner and to delete the earliest recorded log file when the number of recorded log files exceeds a threshold.

[0038] Figure 5 This is a schematic diagram of the log types recorded by the log system in one embodiment of this application. Please refer to the following: Figure 5 In this embodiment, the log system applied to the Android POS terminal covers more types of terminal status logs. When dealing with occasional and low-probability problems, it can locate problems more accurately and quickly through the correlation between log information and status information. While taking into account the integrity, flexibility and data security of terminal status recording, it also meets the requirement of recording abnormal problems that are unknown or have not occurred. It stores as many logs as possible in the same storage environment to meet the requirement of outdated traceability.

[0039] Figure 6 This is a flowchart of an exception handling method in one embodiment of this application. Please refer to the following: Figure 6 When a terminal malfunctions, the operator reports it to the operations staff, who then retrieve the terminal logs and communicate to understand the basic information about the problem, such as the specific phenomenon, the time of occurrence, and how it occurred. Based on this basic information, key details about the malfunction are extracted from the terminal logs, and the cause is further analyzed and deduced. If the cause of the malfunction is successfully identified, a solution is derived and implemented. If the cause cannot be determined due to insufficient key information, the relevant malfunction is added to the logs, awaiting its recurrence.

[0040] The following explanation, based on the application effects of the log system for Android POS terminals described in this application in common scenarios, further illustrates this application.

[0041] Scenario 1: When encountering reproducible hardware or software issues while operating the terminal, such as application crashes, incorrect data display, unresponsive buttons, and abnormal screen display, the maintenance personnel can quickly obtain key information about the anomaly based on the relevant logs submitted by the terminal, given the time points provided by the customer. They can then quickly deduce the cause of the anomaly based on the customer's description and provide the best solution.

[0042] Scenario 2: When encountering occasional hardware or software anomalies while operating the terminal, such as interface anomalies caused by loose internal interfaces, anomalies due to special environmental conditions, or low-probability anomalies caused by incomplete consideration during software development, the logs recorded by this invention are comprehensive enough. Even if the anomaly cannot be reproduced, maintenance personnel can perform multi-faceted analysis of the terminal logs from various perspectives based on continuous log records and different types of records, i.e., analyze logs related to more different types of anomalies. As long as there is enough key information about the anomaly, maintenance personnel can determine the approximate cause of the anomaly and thus provide a solution to resolve the problem, reducing the process of repeated communication and testing.

[0043] Scenario 3: When a terminal malfunctions, but due to delays caused by holidays or other reasons, the problem is only exposed to maintenance personnel late, several days have passed. However, because the logging process can record at least 42 days' worth of logs (180MB) by default, and due to rolling recording and dynamic expansion mechanisms, the terminal's log records are preserved to the greatest extent. Therefore, key information about the malfunction can still be obtained from the currently submitted log information, ultimately leading to the analysis of the cause and the provision of a solution. Additionally, for unattended devices, the maximum capacity limit can be modified by adjusting parameters to obtain more timely log recordings.

[0044] Scenario 4: When improving software quality, such as reducing power consumption and performance, the fix process may contain low-probability vulnerabilities that occur only on a limited number of devices due to incomplete planning. In this case, operations and maintenance personnel can periodically check logs to understand the device status, optimize the application, and identify and fix low-probability vulnerabilities by checking logs for anomalies. Optimization using this method can significantly improve code quality and software performance.

[0045] The above technical solution, by setting up a dual-process protection module including a system process application resident memory, a first listening unit and a second listening unit for monitoring the log recording process, and a system log daemon process for activating the system process application resident memory when the memory status is below a preset threshold, ensures the persistence and integrity of the recording process, maximizes the availability of more useful information when using logs, and verifies and confirms the events that occurred on the terminal at the time of the anomaly by querying the terminal status log at the time the anomaly occurred, facilitating operation to confirm and resolve related issues.

[0046] It should be noted that, in this document, relational terms such as "second" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "also includes a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0047] All specific embodiments in this application are described in a related manner. For the same or similar parts between the various specific embodiments, refer to each other. Each specific embodiment focuses on describing the differences from other specific embodiments.

[0048] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A log system for Android POS terminals, characterized in that, include: The dual-process protection module includes a system process application resident in memory, a first listening unit and a second listening unit for monitoring the log recording process. The first listening unit and the second listening unit monitor each other's processes through a first interface, and when they detect that the other process has ended, they start the other process according to their own current process to continue logging. The system log daemon is used to enable the system process application to reside in memory when the memory status is lower than a preset threshold, so as to prevent the logging process of the system process application from being closed by the security mechanism. The log storage module is used to store both uncompressed and compressed log files. A dynamic expansion module is used to enable dynamic expansion based on the maximum limit number of uncompressed log files, so as to improve the storage capacity of the log storage module. The maximum number of uncompressed log files = total log capacity limit / (size of each file * (1 + compression ratio)), where the total log capacity limit is set according to the log storage module, and the compression ratio is the compression percentage of the compressed log files.

2. The log system according to claim 1, characterized in that, Also includes: The dynamic detection module is used to periodically detect the logging process using dynamic programming, and to determine whether the currently detected logging process is running correctly based on the detection results.

3. The log system according to claim 2, characterized in that, The step of determining whether the currently detected log recording process is running correctly based on the detection results includes: determining whether the currently detected log recording process is running correctly based on the growth of the recorded log file; when the log file grows correctly, the log recording process is determined to be running correctly; otherwise, the log recording process is determined to be running abnormally and the log recording process is restarted.

4. The log system according to claim 2, characterized in that, The dynamic detection module further uses a hardware clock to set a timer alarm via baseband processor communication, and uses dynamic programming to perform timed detection on the logging process.

5. The log system according to claim 1, characterized in that, Also includes: A secure storage module is used to record all log files in a private storage area, which can only be read and written by the logging process.

6. The log system according to claim 1, characterized in that, Also includes: The secure delivery module is used to receive log files in zip format output by the logging process and provide the log files to third-party applications through a second interface using encrypted delivery and certificate verification.

7. The log system according to claim 6, characterized in that, The second interface includes: The log packaging interface is used to package the log file according to the first parameter representing the password of the compressed file, the second parameter representing the log output level, and the third parameter representing the output path of the compressed file to be output externally; The parameter setting interface is used to set parameter types using JSON.

8. The log system according to claim 1, characterized in that, Also includes: The log processing module is used to record logs in a rolling manner and delete the earliest recorded log file when the number of recorded log files exceeds a threshold.

Images