Cross-domain data acquisition method and device, computer device, chip and chip module

Abstract

The application relates to a cross-domain data acquisition method and device, computer equipment, a chip and a chip module, which can be used in the technical field of data acquisition. The method comprises the following steps: creating a data acquisition service in a first permission domain of an operating system; a client and a server of the data acquisition service are located in the first permission domain; in the case that the server receives a data acquisition instruction, the data acquisition instruction is analyzed and processed to obtain a target data type corresponding to the data acquisition instruction; a target data processing thread corresponding to the target data type in the server is determined, and a target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read-write permissions of the first permission domain and a second permission domain; target measurement data from the second permission domain is read from the target pipeline device through the target data processing thread, and the target measurement data is stored in a target storage position in the first permission domain. The method can improve the efficiency of data acquisition.

Description

Technical Field

[0001] This application relates to the field of data acquisition technology, and in particular to a cross-domain data acquisition method, apparatus, computer equipment, chip, and chip module. Background Technology

[0002] With the development of operating system security architecture, permission domain isolation has become an important means of ensuring system security. However, in practical application scenarios, it is often necessary to exchange data between different permission domains to meet business function requirements.

[0003] In related technologies, traditional inter-process communication mechanisms are mainly used for data retrieval across permission domains. However, in environments with strictly isolated permission domains, these methods are prone to problems such as low transmission efficiency, resulting in low data retrieval efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a cross-domain data acquisition method, apparatus, computer equipment, chip, chip module, computer-readable storage medium, and computer program product that can improve the efficiency of data acquisition in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for cross-domain data acquisition. The method includes:

[0006] A data acquisition service is created in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0007] When the server receives the data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction;

[0008] The target data processing thread corresponding to the target data type in the server is determined, and the target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0009] The target data processing thread reads target dimension measurement data from the second permission domain from the target pipeline device and stores the target dimension measurement data in the target storage location in the first permission domain.

[0010] In one embodiment, the target data type includes at least one of an audio data type and a log data type;

[0011] The step of determining the target pipeline equipment corresponding to the target data type includes:

[0012] If the target data type is the audio data type, the target pipeline device is determined to be the audio data pipeline device in the pre-created pipeline device;

[0013] If the target data type is the log data type, the target pipeline device is determined to be the log data pipeline device in the pre-created pipeline device.

[0014] In one embodiment, before reading the target maintenance data from the second permission domain from the target pipeline device via the target data processing thread, the method further includes:

[0015] The instruction sending pipeline device corresponding to the target data type sends the data acquisition enable instruction corresponding to the data acquisition instruction to the second permission domain;

[0016] The instruction receiving pipeline device corresponding to the target data type receives the instruction response information fed back by the second permission domain for the data acquisition enable instruction;

[0017] The step of reading target maintenance data from the second permission domain from the target pipeline device through the target data processing thread includes:

[0018] If the instruction response information indicates that the data acquisition enable instruction was successfully executed, the target dimension measurement data from the second permission domain is read from the target pipeline device through the target data processing thread.

[0019] In one embodiment, reading target maintenance data from the second permission domain from the target pipeline device via the target data processing thread includes:

[0020] The target data processing thread reads the data description information corresponding to the target maintenance data from the target pipeline equipment.

[0021] Based on the data description information, target maintenance data from the second permission domain is read from the target pipeline equipment.

[0022] In one embodiment, before storing the target dimension measurement data in the target storage location in the first permission domain, the method further includes:

[0023] If the target dimension measurement data and the historical dimension measurement data already stored in the first permission domain belong to the same data source, the target storage location is determined to be the storage file corresponding to the historical dimension measurement data;

[0024] If the target dimension measurement data and the historical dimension measurement data do not belong to the same data source, a new storage file is created in the first permission domain, and the target storage location is determined as the new storage file.

[0025] In one embodiment, the method further includes:

[0026] The target data processing thread performs storage capacity detection processing on the data in the target storage location to obtain the storage capacity detection result of the target storage location.

[0027] If the storage capacity detection result indicates that the storage capacity of the target storage location has reached a preset capacity threshold, data cleaning or data migration processing is performed on the data in the target storage location.

[0028] Secondly, this application also provides a cross-domain data acquisition device. The device includes:

[0029] A service creation module is used to create a data acquisition service in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0030] The instruction processing module is used to parse and process the data acquisition instruction when the server receives the data acquisition instruction, so as to obtain the target data type corresponding to the data acquisition instruction;

[0031] A thread determination module is used to determine the target data processing thread in the server corresponding to the target data type, and to determine the target pipeline device corresponding to the target data type; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0032] The data storage module is used to read target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread, and store the target dimension measurement data in the target storage location in the first permission domain.

[0033] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0034] A data acquisition service is created in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0035] When the server receives the data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction;

[0036] The target data processing thread corresponding to the target data type in the server is determined, and the target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0037] The target data processing thread reads target dimension measurement data from the second permission domain from the target pipeline device and stores the target dimension measurement data in the target storage location in the first permission domain.

[0038] Fourthly, this application also provides a chip, including a processor and a communication interface, wherein the processor is configured to cause the chip to perform:

[0039] A data acquisition service is created in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0040] When the server receives the data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction;

[0041] The target data processing thread corresponding to the target data type in the server is determined, and the target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0042] The target data processing thread reads target dimension measurement data from the second permission domain from the target pipeline device and stores the target dimension measurement data in the target storage location in the first permission domain.

[0043] Fifthly, this application also provides a chip module, including a communication module, a power module, a storage module, and a chip, wherein:

[0044] The power module is used to provide power to the chip module;

[0045] The storage module is used to store data and instructions;

[0046] The communication module is used for internal communication within the chip module, or for communication between the chip module and external devices.

[0047] The chip is used to perform the steps of the method provided in the first aspect above.

[0048] Sixthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0049] A data acquisition service is created in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0050] When the server receives the data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction;

[0051] The target data processing thread corresponding to the target data type in the server is determined, and the target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0052] The target data processing thread reads target dimension measurement data from the second permission domain from the target pipeline device and stores the target dimension measurement data in the target storage location in the first permission domain.

[0053] Seventhly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0054] A data acquisition service is created in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0055] When the server receives the data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction;

[0056] The target data processing thread corresponding to the target data type in the server is determined, and the target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0057] The target data processing thread reads target dimension measurement data from the second permission domain from the target pipeline device and stores the target dimension measurement data in the target storage location in the first permission domain.

[0058] The aforementioned cross-domain data acquisition methods, devices, computer equipment, chips, chip modules, computer-readable storage media, and computer program products, by creating a data acquisition service in the first permission domain of the operating system and configuring both the client and server corresponding to the data acquisition service in the first permission domain, facilitate the reception and transmission of data acquisition instructions within the first permission domain, avoiding the permission verification overhead caused by cross-domain instruction transmission. By parsing and processing the data acquisition instructions on the server side to obtain the target data type and determining the target data processing thread and target pipeline device corresponding to the target data type, it is beneficial to use dedicated data processing threads to process different types of maintenance data, realizing parallel processing of data acquisition tasks. By configuring the target pipeline device to have data read and write permissions in both the first and second permission domains, it is beneficial to establish a data transmission channel between the first and second permission domains while taking into account the security of the operating system. By reading the target maintenance data from the second permission domain from the target pipeline device through the target data processing thread and storing it in the target storage location in the first permission domain, it is beneficial to obtain maintenance data originally located in the second permission domain from the first permission domain, thereby improving the efficiency of data acquisition. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying 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.

[0060] Figure 1 This is a flowchart illustrating a cross-domain data acquisition method in one embodiment;

[0061] Figure 2 This is a flowchart illustrating the steps for obtaining vendor domain audio data in one embodiment;

[0062] Figure 3 This is a structural block diagram of a cross-domain data acquisition device in one embodiment;

[0063] Figure 4 This is an internal structural diagram of a computer device in one embodiment;

[0064] Figure 5 This is an internal structure diagram of a chip module in one embodiment. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0067] In one exemplary embodiment, such as Figure 1 As shown, a cross-domain data acquisition method is provided. This embodiment illustrates the method by applying it to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc.; the server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In this embodiment, the method includes the following steps:

[0068] Step S101: Create a data acquisition service in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server.

[0069] Step S102: When the server receives a data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction.

[0070] Step S103: Determine the target data processing thread corresponding to the target data type in the server, and determine the target pipeline device corresponding to the target data type; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system;

[0071] Step S104: Through the target data processing thread, read the target dimension measurement data from the second permission domain from the target pipeline device, and store the target dimension measurement data in the target storage location in the first permission domain.

[0072] The operating system can divide different functional modules into different logical partitions, and different security mechanisms exist between different logical partitions.

[0073] The first permission domain can be a logical partition in the operating system used to host system-level services. The first permission domain can be the System domain. The first permission domain has higher system access permissions, can directly interact with the user interface, and supports local data storage.

[0074] The data acquisition service can be a service module created in the first permission domain for acquiring and storing cross-domain data. The data acquisition service is created through an inter-process communication mechanism and includes a client and a server.

[0075] Inter-process communication (IPC) mechanisms can be mechanisms in the operating system used to enable data exchange and communication between different processes. IPC mechanisms support instruction transmission and information feedback between clients and servers.

[0076] The client can be a component in the data acquisition service used to receive user instructions. The client can receive data acquisition instructions input by the user through a user interface or command-line tool and transmit the data acquisition instructions to the server.

[0077] The server can be a component in the data acquisition service that processes data acquisition instructions and executes specific data acquisition operations. After receiving the data acquisition instructions transmitted by the client, the server parses the data acquisition instructions and calls the corresponding data processing thread to complete the data acquisition task based on the parsing results.

[0078] The data acquisition instruction can be a command sent by the user through the client to indicate the type of measurement data to be acquired. The data acquisition instruction contains keyword information to identify the target data type.

[0079] Parsing can be the process by which the server analyzes and identifies data acquisition commands, and the target data type corresponding to the command can be extracted from the data acquisition command through parsing.

[0080] The target data type can be the type of measurement data to be acquired as indicated by the data acquisition command. Target data types include raw audio sample data types and string log data types from an audio digital signal processor (ADSP). The raw audio sample data type can refer to uncompressed audio waveform data. The ADSP can be a dedicated processor for processing audio signals, and it generates string log data for debugging and analysis during operation.

[0081] The target data processing thread can be a dedicated data processing thread in the server that corresponds to the target data type. Different target data types correspond to different target data processing threads. The target data processing thread is used to read maintenance data from the target pipeline device and store the maintenance data in the specified location.

[0082] The target pipeline device can be a pipeline device used to realize data transmission between the first permission domain and the second permission domain. The target pipeline device is configured to have data read and write permissions for both the first permission domain and the second permission domain, thereby supporting cross-domain data read and write operations.

[0083] Data read and write permissions can be the access permissions in the operating system to read and write data to a specific device or path. By configuring the data read and write permissions of the target pipeline device, the target pipeline device can support data access in both the first permission domain and the second permission domain.

[0084] The second permission domain can be another logical partition in the operating system that is isolated from the first permission domain. The second permission domain can be a vendor domain (the system or service of the vendor). The second permission domain is used to carry hardware-related functional modules and stores maintenance data.

[0085] Among them, the target dimension measurement data can be data generated in the second permission domain for system debugging and problem analysis. The target dimension measurement data includes persistent data such as raw audio sampling data and string log data of audio digital signal processor, as well as status information such as log status information and log size information.

[0086] The target storage location can be a file directory path in the first permission domain used to store the target dimension measurement data, and the target storage location can be a directory path that can be directly accessed and read by the user.

[0087] Optionally, the terminal creates a data acquisition service within the first permission domain of the operating system via an inter-process communication mechanism. Both the client and server for this service reside within the first permission domain. The client receives data acquisition commands input by the user through a user interface or command-line tool and transmits these commands to the server via a parameter interface. Upon receiving a data acquisition command, the terminal parses and processes the command, extracting keyword information and determining the target data type. Based on the target data type, the terminal identifies the corresponding target data processing thread on the server and the corresponding target pipeline device. This target pipeline device is configured to have read and write permissions in both the first and second permission domains, which are isolated permission domains within the operating system. The terminal opens the target pipeline device via the target data processing thread, reads target dimension measurement data from the second permission domain, and stores the target dimension measurement data in the target storage location within the first permission domain, thus achieving cross-domain data acquisition and storage.

[0088] In the aforementioned cross-domain data acquisition method, by creating a data acquisition service in the first permission domain of the operating system and configuring both the client and server corresponding to the data acquisition service in the first permission domain, it is beneficial to complete the reception and transmission of data acquisition instructions within the first permission domain, avoiding the permission verification overhead caused by cross-domain instruction transmission. By parsing and processing the data acquisition instructions on the server side to obtain the target data type and determining the target data processing thread and target pipeline device corresponding to the target data type, it is beneficial to use dedicated data processing threads to process different types of maintenance data, realizing parallel processing of data acquisition tasks. By configuring the target pipeline device to have data read and write permissions in both the first and second permission domains, it is beneficial to establish a data transmission channel between the first and second permission domains while taking into account the operating system security. By using the target data processing thread to read the target maintenance data from the second permission domain from the target pipeline device and store it in the target storage location in the first permission domain, it is beneficial to obtain maintenance data originally located in the second permission domain from the first permission domain, thereby improving the efficiency of data acquisition.

[0089] In an exemplary embodiment, the target data type includes at least one of an audio data type and a log data type; determining the target pipeline device corresponding to the target data type specifically includes the following: if the target data type is an audio data type, the target pipeline device is determined to be an audio data pipeline device in a pre-created pipeline device; if the target data type is a log data type, the target pipeline device is determined to be a log data pipeline device in a pre-created pipeline device.

[0090] The audio data type can refer to the type of raw audio sample data, including uncompressed audio waveform data, used for audio signal debugging and analysis.

[0091] The log data type can refer to the type of string log data generated by the audio digital signal processor, including debugging information and status information output during processor operation.

[0092] The pre-created pipeline devices can be multiple pipeline devices pre-configured according to different data types before the data acquisition service starts, with each pipeline device assigned to transmit a specific type of data.

[0093] The audio data pipeline device can be a pre-created pipeline device used to transmit audio data, and the audio data pipeline device is configured to have data read and write permissions for both the first permission domain and the second permission domain.

[0094] The log data pipeline device can be a pre-created pipeline device used to transmit log data, and the log data pipeline device is configured to have data read and write permissions for both the first permission domain and the second permission domain.

[0095] Optionally, after parsing the data acquisition instruction, the terminal obtains the target data type corresponding to the data acquisition instruction. The target data type includes at least one of audio data type and log data type. Based on the different target data types, the terminal determines the target pipeline device corresponding to the target data type from the pre-created pipeline devices. If the target data type is audio data type, the terminal determines the target pipeline device to be the audio data pipeline device in the pre-created pipeline devices. If the target data type is log data type, the terminal determines the target pipeline device to be the log data pipeline device in the pre-created pipeline devices.

[0096] The technical solution provided in this embodiment divides the target data type into audio data type and log data type, and configures corresponding target pipeline devices for different target data types. This facilitates the separate transmission of different types of maintenance data, thereby helping to avoid mutual interference between different types of data during transmission and improving the stability of data transmission.

[0097] In an exemplary embodiment, before reading the target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread, the method further includes: sending a data acquisition enable instruction corresponding to a data acquisition instruction to the second permission domain through an instruction sending pipeline device corresponding to the target data type; receiving instruction response information from the second permission domain in response to the data acquisition enable instruction through an instruction receiving pipeline device corresponding to the target data type; and reading the target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread, specifically including: if the instruction response information indicates that the data acquisition enable instruction has been successfully executed, reading the target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread.

[0098] The instruction sending pipeline device can be a pipeline device used to send control instructions from the first authority domain to the second authority domain.

[0099] Among them, the data acquisition enable instruction can be a control instruction used to instruct the second permission domain to start the acquisition and transmission function of target dimension measurement data.

[0100] The instruction receiving pipeline device can be a pipeline device used to receive feedback information from the second authority domain.

[0101] The instruction response information can be the response information fed back by the second permission domain after receiving the data acquisition enable instruction, based on the execution status of the instruction. The instruction response information is used to characterize whether the data acquisition enable instruction was executed successfully.

[0102] Optionally, the terminal sends a data acquisition enable instruction corresponding to the data acquisition instruction to the second permission domain via the instruction sending pipeline device corresponding to the target data type. The data acquisition enable instruction contains data acquisition configuration information corresponding to the target data type. The terminal receives the instruction response information from the second permission domain in response to the data acquisition enable instruction via the instruction receiving pipeline device corresponding to the target data type. The terminal judges the instruction response information. If the instruction response information indicates that the data acquisition enable instruction has been successfully executed, the terminal reads the target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread.

[0103] For example, when the target data type is audio, the terminal opens the instruction sending pipeline for sending control commands, encapsulates the data acquisition point information and enable flag parsed from the data acquisition command into a data acquisition enable command, and sends it to the second permission domain through the instruction sending pipeline. Simultaneously, the terminal opens the instruction receiving pipeline for receiving feedback information, waiting to receive the instruction response information from the second permission domain regarding the data acquisition enable command. If the return value of the instruction response information indicates that the data acquisition enable command was executed successfully, the terminal creates a target data processing thread. Through the target data processing thread, it reads the target dimension measurement data from the second permission domain from the audio data pipeline. When the target data type is log data, the terminal similarly first sends a log function switch command as a data acquisition enable command to the second permission domain through the corresponding instruction sending pipeline. After receiving the instruction response information indicating successful execution, it reads the target dimension measurement data from the log data pipeline through the target data processing thread.

[0104] The technical solution provided in this embodiment sends a data acquisition enable command to the second permission domain through a command sending pipeline device, and receives the command response information through a command receiving pipeline device. This helps to avoid data acquisition failure caused by data reading when the second permission domain is not ready, thereby improving the success rate of data acquisition.

[0105] In an exemplary embodiment, the target dimension measurement data from the second permission domain is read from the target pipeline device through the target data processing thread, specifically including: reading the data description information corresponding to the target dimension measurement data from the target pipeline device through the target data processing thread; and reading the target dimension measurement data from the second permission domain from the target pipeline device according to the data description information.

[0106] The data description information can be attribute information describing the target dimension measurement data. The data description information includes at least one of the following: data size information, sampling rate information, and data source identification information of the target dimension measurement data. The data description information is used to indicate the method of reading and storing the target dimension measurement data in the future.

[0107] Optionally, when the terminal reads target maintenance data from the target pipeline device through the target data processing thread, it also reads the data description information corresponding to the target maintenance data from the target pipeline device through the target data processing thread. The terminal determines the amount of data and storage method of the target maintenance data to be read subsequently based on the data description information, and reads the target maintenance data of the corresponding size from the second permission domain from the target pipeline device based on the data size information in the data description information.

[0108] The technical solution provided in this embodiment first reads the data description information corresponding to the target maintenance data from the target pipeline equipment, and then reads the target maintenance data according to the data description information. This helps to accurately obtain complete target maintenance data, thereby improving the accuracy and completeness of data reading.

[0109] In an exemplary embodiment, before storing the target dimension measurement data in the target storage location in the first permission domain, the method further includes the following: if the target dimension measurement data and the historical dimension measurement data already stored in the first permission domain belong to the same data source, the target storage location is determined to be the storage file corresponding to the historical dimension measurement data; if the target dimension measurement data and the historical dimension measurement data do not belong to the same data source, a new storage file is created in the first permission domain, and the target storage location is determined to be the new storage file.

[0110] Among them, historical dimension measurement data can be dimension measurement data that has been obtained from the second permission domain and stored in the first permission domain before the current data acquisition operation.

[0111] Among them, the same data source can refer to the target dimension measurement data and the historical dimension measurement data coming from the same data collection point or the same functional module, which can be determined by the data source identification information in the data description information.

[0112] The storage file can be a file in the first permission domain used to store maintenance data, and the storage file is located in a directory path that can be directly accessed by the user.

[0113] The new storage file can be a newly created file in the first permission domain for storing target dimension measurement data from different data sources.

[0114] Optionally, the terminal determines whether the target dimension measurement data and the historical dimension measurement data already stored in the first permission domain belong to the same data source. If the target dimension measurement data and the historical dimension measurement data belong to the same data source, the terminal determines the target storage location as the storage file corresponding to the historical dimension measurement data and appends the target dimension measurement data to the storage file corresponding to the historical dimension measurement data. If the target dimension measurement data and the historical dimension measurement data do not belong to the same data source, the terminal creates a new storage file in the first permission domain, determines the target storage location as the new storage file, and stores the target dimension measurement data in the new storage file.

[0115] The technical solution provided in this embodiment determines whether the target dimension measurement data and historical dimension measurement data belong to the same data source, and determines the target storage location based on the determination result. This is beneficial for storing dimension measurement data from the same data source in the same storage file, and storing dimension measurement data from different data sources in different storage files, thereby improving the storage management efficiency of dimension measurement data and the efficiency of subsequent data analysis.

[0116] In an exemplary embodiment, the method further includes: performing storage capacity detection processing on the data in the target storage location through a target data processing thread to obtain a storage capacity detection result for the target storage location; and performing data cleaning or data migration processing on the data in the target storage location when the storage capacity detection result indicates that the storage capacity of the target storage location has reached a preset capacity threshold.

[0117] Among them, the storage capacity detection process can be a process of detecting the size of the data already stored in the target storage location.

[0118] Among them, the storage capacity detection result can be the detection result obtained from the storage capacity detection process, and the storage capacity detection result is used to characterize the current storage space occupancy of the target storage location.

[0119] The preset capacity threshold can be a pre-set upper limit of storage capacity. When the storage capacity of the target storage location reaches the preset capacity threshold, data cleaning or data migration is triggered.

[0120] Optionally, the terminal performs storage capacity detection processing on the data in the target storage location through the target data processing thread to obtain the storage capacity detection result of the target storage location. If the storage capacity detection result indicates that the storage capacity of the target storage location has reached a preset capacity threshold, the terminal performs data cleaning processing or data migration processing on the data in the target storage location. Specifically, data cleaning processing involves deleting some data in the target storage location to release storage space, while data migration processing involves migrating the data in the target storage location to other storage locations to release the current storage space.

[0121] The technical solution provided in this embodiment detects the storage capacity of the data in the target storage location and performs data cleaning or migration when the storage capacity reaches a preset capacity threshold. This helps to prevent subsequent maintenance data from being unable to be stored, thereby ensuring the continuous and stable operation of cross-domain data acquisition.

[0122] The following example illustrates the cross-domain data acquisition method provided in this application. This example demonstrates the application of this method to a terminal.

[0123] Terminology Explanation:

[0124] Binder: A cross-process communication mechanism in the Android system.

[0125] pipe: A conduit device used for cross-domain data transmission.

[0126] aidl: Android Interface Definition Language.

[0127] SELinux: Security-Enhanced Linux, a security subsystem in Android that restricts permissions between different domains.

[0128] ylog: The directory used in the Android system to store logs and data.

[0129] This embodiment addresses the technical challenge of enabling the Android system's user version system domain to access audio data from the vendor domain and store it in a specified directory. Currently, the Android system divides the system and vendor domains into two distinct logical partitions with different security mechanisms. The user version has stricter user permissions, preventing the vendor domain from directly accessing the system domain's file directory and thus hindering the transfer of maintenance information from the vendor domain to the system domain. To ensure system security while allowing the system domain to access audio maintenance data, this embodiment designs and implements a service for creating, acquiring, and storing data in the system domain, using a pipe mechanism for cross-domain data transmission. This embodiment supports the system domain acquiring various types of maintenance data from the vendor domain, such as raw PCM (Pulse Code Modulation) data, persistent data like audio DSP (Audio Digital Signal Processor) string log data, and status information like string log status and log size. It also supports setting status parameters for some maintenance functions in the vendor domain, such as the location of PCM data acquisition, audio DSP string log on / off, and storage path selection. This embodiment greatly facilitates developers in obtaining and setting vendor-related information when debugging the Android system. The implementation of this embodiment is independent of the original Android framework and is not affected by Android version upgrades or interface iterations.

[0130] This embodiment addresses the issue of limited debugging information on the vendor side by implementing cross-Android domain data acquisition and information settings. A service is created in the system domain using the Binder mechanism, with both the client and service sides residing on the system side. A pipe device is used to implement the specific method of data transmission between the system and vendor domains. Four threads are created on the service side of the system domain: one for reading and writing PCM data and storing it at a specified path; another for checking the size of PCM data and deleting it; and the third for reading and writing string logs, storing them at a specified path, and selecting the path; and the fourth for deleting and moving string logs. Permission settings for information access and data transfer from the system domain to the vendor domain are also included.

[0131] This embodiment achieves efficient data transmission between the system domain and vendor domain in the Android version through a cross-domain communication mechanism, and completes the data reading and storage functions in the system domain.

[0132] Related Technology: In the Android system, permission restrictions exist between the system domain and vendor domain in the user version, preventing direct communication. Audio data debugging and analysis require cross-domain data acquisition. However, among related technologies, only the Userdebug version (test version) supports direct audio maintenance data dumping and related operations in the vendor domain. Due to Android permission restrictions, the user version cannot directly store vendor domain maintenance data in relevant files. Therefore, a system is needed that can share maintenance data from the vendor domain to the system domain without violating Android and SELinux security mechanisms, facilitating developers to quickly locate problems.

[0133] Related technical solutions:

[0134] 1) Solution 1: Cross-process communication based on the AIDL framework: The AIDL framework depends on Android's fixed framework template, which requires the generation of complex interface definition files and configuration files. It also depends on the interface functions of the Android AIDL framework. If the functionality of the AIDL function or the interface file is upgraded, it is necessary to spend manpower to upgrade the interface file again.

[0135] 2) Solution 2: Cross-domain communication based on Sockets: While this method is feasible, Android emphasizes permission isolation and security, requiring strict permission verification for cross-domain communication. Socket communication lacks a built-in permission control mechanism, potentially leading to security vulnerabilities. Furthermore, using Socket communication requires handling low-level details such as connection establishment, data transmission, and error handling, increasing development complexity.

[0136] Disadvantages of Option 1: Cross-process communication based on the AIDL framework requires significant time to study the AIDL architecture specification, necessitates complex configuration files and interface definition files, and its version iteration and functionality are limited by the AIDL architecture mechanism. This presents considerable inconvenience for maintenance and testing technologies that require stable operation.

[0137] Disadvantages of Option 2: Cross-domain communication based on Socket is implemented on Android. In particular, it may lead to security vulnerabilities when implemented on Android versions with lower permissions, such as the user version. In addition, the development compatibility is low, which increases the complexity of the function implementation.

[0138] To address the aforementioned shortcomings, this embodiment proposes a method to create a service located in the system domain using a simplified Binder mechanism. Both the client and server of this service reside in the system domain. The client is used for setting instructions and collecting information; the server receives instruction information from the client and completes data read / write operations from the vendor domain to the system domain via cross-domain transmission through a pipe. By configuring permissions on the pipe, it gains read / write permissions for both the vendor and system domains. The service in the system domain can then complete the reading and storage of maintenance data, thereby resolving the issue of acquiring maintenance data on the vendor side in Android user versions.

[0139] This embodiment, based on the userdebug Android version, allows storage of audio data in the vendor domain. The storage path is located in the vendor domain, and services in the vendor domain can be directly configured with read / write permissions, allowing users to directly access the content within that path. However, access to the vendor domain from the system domain in the user version is restricted, preventing direct access to its content. Therefore, a solution is needed to store vendor domain data in a path within the system domain, enabling direct user access. Thus, a service is created in the system domain, with both the client and service sides residing there. The client is invoked via the UI (user interface) or adb shell (Android debugging command line). The client transmits specific instructions for obtaining maintenance information to the service side through a parameter interface. Upon receiving the instructions, the service side parses them and uses different threads based on the specific instructions, completing the acquisition and storage of audio maintenance data from the vendor domain within each thread. Data transfer between the thread and the vendor domain can be accomplished through different dev (device path) / pipes. The implementation flowchart is available below. Figure 2 .

[0140] Figure 2 A flowchart illustrating the overall process of obtaining audio data from the vendor domain. Figure 2 Includes the following:

[0141] Within the system domain, there is a Binder service module that receives input from the UI (user interface) and shell commands. This module includes a Binder service interface implementation. It also includes a client side, which has interface interfaces for setting parameters and for retrieving parameters (for information feedback). Finally, the Binder service module includes a Service side, which includes interface interfaces for setting and retrieving parameters, as well as four thread modules: a PCM data acquisition thread, a PCM data status acquisition thread, a LOG acquisition thread, and a LOG status acquisition thread.

[0142] The vendor domain includes multiple functional modules and data transmission channels. The vendor domain includes modules for PCM data dumping and transmission, and modules for obtaining the pcmdump status (dump status) set by the system domain. The PCM data dumping and transmission module communicates with the Service side of the System domain via pipe 1, while the module for obtaining the pcm dump status (dump status) set by the system domain communicates via pipe 2. The vendor domain also includes a module for obtaining the log status (log status) set by the system domain. This module communicates with the Service side of the System domain via pipe 4, and pipe 3 is used for log data dumping and transmission. The vendor domain also includes modules for providing PCM status (Pulse Code Modulation status) and Log status (log status). These modules communicate with the Service side of the System domain via pipe 5 and pipe 6, respectively.

[0143] according to Figure 2 We can see the service creation on the system side. The service is created directly using the Binder mechanism, by manually writing BBinder (basic binder), BpInterface (binder proxy interface), and BnInterface (binder local interface) classes to implement the service's functional interfaces. The interfaces mainly need to implement parameter setting and parameter retrieval functions, namely getparameter (get parameter) and setparameter (set parameter). After the interfaces are implemented, the client and service sides are created based on these interfaces.

[0144] The process of creating and using the service is as follows: First, the service needs to be named when the system starts. Define the service name as unisocaudioutils (audio tool service) and add it to the processes. Before using the UI tool to call the client to set parameters, it will first confirm whether the unisocaudioutils service has been created normally. This information can also be viewed by indexing the name of the created service, unisocaudioutils, after booting up.

[0145] After successful service creation, the client will receive content in the UI, distinguishing between the `setparameter` and `getparameter` interfaces based on keywords. If the keyword sets a PCM dump point or log switch, the client will use `setparameter`, and the service will also have a corresponding parameter interface to receive the parameter information. If the received information is PCM dump point information, three pipe devices will be opened when the dump point is non-zero: `pipe_out` (output pipe), `pipe_in` (input pipe), and `pipe_pcm` (pulse code modulation pipe), used for sending and receiving commands in the system domain, and receiving PCM data, respectively. The service will send the parsed dump value and `enable` command to the vendor side using `pipe_out`, and use `pipe_in` to receive the return value from the vendor side to check if the requirements are met. Simultaneously, a thread `pcmDumpThread` (pulse code modulation dump thread) will be created to read data from the vendor side and write it to the corresponding directory. The data reading method is somewhat unique because the size and sampling rate of the data are unknown before it is obtained. Therefore, the reading is performed in two steps. The first step retrieves the data information to determine if it is a dump from the same point and whether a new storage file needs to be created. The second step reads the corresponding size of the dump data based on the bytes size. After both readings are completed, the data is stored in the corresponding file at the ylog path.

[0146] Similarly, if DSP log (Digital Signal Processor Log) information is received, and the information indicates that logging is enabled, the service will first check the current state of the log in the configuration file to determine if an update is needed. To retrieve the stored string log from the DSP, a `char_log_pipe` (character log pipe) needs to be created, along with a `saveLogThread` (log saving thread). When logs are needed, they can be read directly from the pipe and stored in a specified path; this reading method is consistent with PCM dumps. The difference is that this thread, in addition to reading logs, includes features for convenient string log storage such as path setting, size detection, and saving to a file with a fixed size.

[0147] If the UI is set to retrieve dump points or the current status of the string log, the client will call the `getparameter` interface function. The service will then synchronize the relevant thread status and send the corresponding information back to the return parameter of `getparameter`, ultimately feeding that value back to the UI. This can also be achieved using an AIDL or HIDL (Hardware Interface Definition Language) architecture combined with pipe data transfer.

[0148] This embodiment completes the service creation process using a relatively simple service creation method within the relevant inter-process communication services. Leveraging its convenience and extensibility, it develops two highly convenient interfaces for setting and retrieving parameters. New interfaces can be quickly derived for more complex requirements. Furthermore, the client-side of the binder communication method can easily run directly in the adb shell or be called through a UI interface, offering significant convenience. The cross-domain data transfer in this embodiment also employs a pipe method, which facilitates reading, writing, and control, perfectly resolving the permission and communication issues between the two domains. This embodiment does not depend on a specific Android version framework; that is, Android version upgrades will not affect the stability of this solution within a certain period, meeting the stability requirements of audio maintenance and testing.

[0149] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0150] Based on the same inventive concept, this application also provides a cross-domain data acquisition device for implementing the cross-domain data acquisition method described above. This device can be applied to or integrated into a chip or chip module, for example. The solution provided by this device is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more cross-domain data acquisition device embodiments provided below can be found in the limitations of the cross-domain data acquisition method described above, and will not be repeated here.

[0151] In one exemplary embodiment, such as Figure 3 As shown, a cross-domain data acquisition device 300 is provided, which may include:

[0152] Service creation module 301 is used to create a data acquisition service in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server;

[0153] The instruction processing module 302 is used to parse and process the data acquisition instruction when the server receives the data acquisition instruction, so as to obtain the target data type corresponding to the data acquisition instruction;

[0154] The thread determination module 303 is used to determine the target data processing thread in the server that corresponds to the target data type, and to determine the target pipeline device that corresponds to the target data type; the target pipeline device is configured to have data read and write permissions of a first permission domain and a second permission domain; the first permission domain and the second permission domain are different permission domains that are isolated from each other in the operating system;

[0155] The data storage module 304 is used to read target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread, and store the target dimension measurement data in the target storage location in the first permission domain.

[0156] In an exemplary embodiment, the target data type includes at least one of an audio data type and a log data type; the thread determination module 303 is further configured to determine, when the target data type is an audio data type, that the target pipeline device is an audio data pipeline device in a pre-created pipeline device; and when the target data type is a log data type, that the target pipeline device is a log data pipeline device in a pre-created pipeline device.

[0157] In an exemplary embodiment, the device 300 further includes: an information receiving module, configured to send a data acquisition enable instruction corresponding to a data acquisition instruction to a second permission domain via an instruction sending pipeline device corresponding to the target data type; and to receive instruction response information from the second permission domain in response to the data acquisition enable instruction via an instruction receiving pipeline device corresponding to the target data type; and a data storage module 304, configured to, when the instruction response information indicates that the data acquisition enable instruction has been successfully executed, read target dimension measurement data from the second permission domain from the target pipeline device via a target data processing thread.

[0158] In an exemplary embodiment, the data storage module 304 is further configured to read data description information corresponding to the target maintenance data from the target pipeline device through the target data processing thread; and read the target maintenance data from the second permission domain from the target pipeline device according to the data description information.

[0159] In an exemplary embodiment, the device 300 further includes: a file determination module, configured to determine the target storage location as the storage file corresponding to the historical dimension measurement data when the target dimension measurement data and the historical dimension measurement data already stored in the first permission domain belong to the same data source; and to create a new storage file in the first permission domain and determine the target storage location as the new storage file when the target dimension measurement data and the historical dimension measurement data do not belong to the same data source.

[0160] In an exemplary embodiment, the device 300 further includes: a data processing module, configured to perform storage capacity detection processing on the data in the target storage location through a target data processing thread to obtain a storage capacity detection result of the target storage location; and to perform data cleaning processing or data migration processing on the data in the target storage location when the storage capacity detection result indicates that the storage capacity of the target storage location has reached a preset capacity threshold.

[0161] Each module in the aforementioned cross-domain data acquisition device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0162] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0163] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a cross-domain data acquisition method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0164] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0165] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0166] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above-described method embodiments.

[0167] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0168] Based on the same inventive concept, this application also provides a chip, including a processor coupled to a memory, for executing a computer program or instructions stored in the memory, and implementing the steps in the above method embodiments when the processor executes the computer program or instructions.

[0169] It is understood that the chip involved in the embodiments of this application may be a field-programmable gate array (FPGA), may be an application-specific integrated circuit (ASIC), may be a system on chip (SoC), may be a central processor unit (CPU), may be a network processor (NP), may be a digital signal processor (DSP), may be a microcontroller unit (MCU), may be a programmable logic device (PLD) or other integrated chips, etc.

[0170] Based on the same inventive concept, this application also provides a chip module, such as... Figure 5 As shown, the chip module includes a communication module, a power module, a storage module, and a chip. Among them:

[0171] The power module is used to provide power to the chip module; the storage module is used to store data and instructions; the communication module is used for internal communication within the chip module, or for communication between the chip module and external devices; this chip corresponds to the chip in the above chip embodiment.

[0172] The implementation method of this chip module can be found in the relevant content of the above chip embodiment, and will not be repeated here.

[0173] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0174] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0175] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for cross-domain data acquisition, characterized in that, The method includes: A data acquisition service is created in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server. When the server receives the data acquisition instruction, it parses and processes the data acquisition instruction to obtain the target data type corresponding to the data acquisition instruction; The target data processing thread corresponding to the target data type in the server is determined, and the target pipeline device corresponding to the target data type is determined; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system; The target data processing thread reads target dimension measurement data from the second permission domain from the target pipeline device and stores the target dimension measurement data in the target storage location in the first permission domain.

2. The method according to claim 1, characterized in that, The target data type includes at least one of audio data type and log data type; The step of determining the target pipeline equipment corresponding to the target data type includes: If the target data type is the audio data type, the target pipeline device is determined to be the audio data pipeline device in the pre-created pipeline device; If the target data type is the log data type, the target pipeline device is determined to be the log data pipeline device in the pre-created pipeline device.

3. The method according to claim 1, characterized in that, Before reading the target maintenance data from the second permission domain from the target pipeline device through the target data processing thread, the process further includes: The instruction sending pipeline device corresponding to the target data type sends the data acquisition enable instruction corresponding to the data acquisition instruction to the second permission domain; The instruction receiving pipeline device corresponding to the target data type receives the instruction response information fed back by the second permission domain for the data acquisition enable instruction; The step of reading target maintenance data from the second permission domain from the target pipeline device through the target data processing thread includes: If the instruction response information indicates that the data acquisition enable instruction was successfully executed, the target dimension measurement data from the second permission domain is read from the target pipeline device through the target data processing thread.

4. The method according to claim 1, characterized in that, The step of reading target maintenance data from the second permission domain from the target pipeline device through the target data processing thread includes: The target data processing thread reads the data description information corresponding to the target maintenance data from the target pipeline equipment. Based on the data description information, target maintenance data from the second permission domain is read from the target pipeline equipment.

5. The method according to claim 1, characterized in that, Before storing the target dimension measurement data in the target storage location in the first permission domain, the method further includes: If the target dimension measurement data and the historical dimension measurement data already stored in the first permission domain belong to the same data source, the target storage location is determined to be the storage file corresponding to the historical dimension measurement data; If the target dimension measurement data and the historical dimension measurement data do not belong to the same data source, a new storage file is created in the first permission domain, and the target storage location is determined as the new storage file.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The target data processing thread performs storage capacity detection processing on the data in the target storage location to obtain the storage capacity detection result of the target storage location. If the storage capacity detection result indicates that the storage capacity of the target storage location has reached a preset capacity threshold, data cleaning or data migration processing is performed on the data in the target storage location.

7. A cross-domain data acquisition device, characterized in that, The device includes: A service creation module is used to create a data acquisition service in the first permission domain of the operating system; the client and server corresponding to the data acquisition service are located in the first permission domain; the client is used to receive data acquisition instructions and transmit the data acquisition instructions to the server. The instruction processing module is used to parse and process the data acquisition instruction when the server receives the data acquisition instruction, so as to obtain the target data type corresponding to the data acquisition instruction; A thread determination module is used to determine the target data processing thread in the server corresponding to the target data type, and to determine the target pipeline device corresponding to the target data type; the target pipeline device is configured to have data read and write permissions of the first permission domain and the second permission domain; the first permission domain and the second permission domain are different permission domains isolated from each other in the operating system; The data storage module is used to read target dimension measurement data from the second permission domain from the target pipeline device through the target data processing thread, and store the target dimension measurement data in the target storage location in the first permission domain.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A chip, characterized in that, The device includes a processor and a communication interface, wherein the processor is configured to cause the chip to perform the steps of the method described in any one of claims 1 to 6.

10. A chip module, characterized in that, This includes communication modules, power modules, storage modules, and chips, among which: The power module is used to provide power to the chip module; The storage module is used to store data and instructions; The communication module is used for internal communication within the chip module, or for communication between the chip module and external devices. The chip is used to perform the steps of the method according to any one of claims 1 to 6.

Images