Debugging method, electronic device and storage medium

Abstract

An embodiment of the present application provides a debugging method, an electronic device, and a storage medium, wherein the above-mentioned test configuration method is applied to an electronic device, including: after the first user space init process of the operating system of the electronic device completes the log redirection configuration, it jumps to create a child process, wherein the init process stagnates as a parent process after creating the child process; a temporary system environment is established through the child process, and the temporary system environment can read and write the native system environment file of the electronic device; the child process uses the temporary system environment to view or modify the native system environment file; in response to the signal of the termination of the child process, the init process is notified to end the stagnation and continue execution. The present application realizes debugging by interacting with the debugging device as soon as possible during the initial stage of the startup of the init process of the electronic device, that is, after the Linux system completes the basic system environment configuration, thereby advancing the debugging timing and improving the debugging efficiency.

Description

Technical field

[0001] The embodiments of the present application relate to the technical field of operating system debugging, and in particular to a debugging method, electronic device, and storage medium. [Background Technology]

[0002] During the startup of a Linux kernel-based operating system, you may encounter various problems that may cause the operating system to fail to start. During the operating system startup debugging process, you can obtain the system environment information just before the operating system failed to start based on the error information output in the log. Then, you can modify the native system environment file based on the system environment information and recompile the operating system kernel.

[0003] However, the startup debugging method of the above operating system requires recompiling and restarting the operating system each time an error is reported and the system environment configuration is modified, resulting in low debugging efficiency. [Summary of the invention]

[0004] The embodiments of the present application provide a debugging method, an electronic device, and a storage medium. In the initial stage of starting the init process of the electronic device, that is, after the Linux system completes the basic system environment configuration, the debugging is immediately interacted with the debugging device to implement debugging, thereby advancing the debugging timing and improving debugging efficiency.

[0005] In a first aspect, an embodiment of the present application provides a debugging method applied to an electronic device, comprising:

[0006] When the first user space init process of the operating system of the electronic device completes the log redirection configuration, it jumps to create a child process, wherein the init process stops as a parent process after creating the child process;

[0007] Establishing a temporary system environment through the sub-process, wherein the temporary system environment can read and write native system environment files of the electronic device;

[0008] Viewing or modifying the native system environment file using the temporary system environment through the subprocess;

[0009] In response to the signal of termination of the child process, the init process is notified to end the stagnation and continue execution.

[0010] The above debugging method builds a temporary system environment after the init process completes the log redirection configuration. The native system environment files are viewed or modified based on the temporary system environment. This can advance the debugging time, expand the debugging scope, quickly resolve configuration errors in the native system environment files, and improve debugging efficiency.

[0011] In one possible implementation, viewing or modifying the native system environment file by using the temporary system environment through the child process includes:

[0012] Obtaining, through the subprocess, an operation instruction for viewing or modifying the native system environment file;

[0013] Viewing or modifying the native system environment file using the temporary system environment in response to the operation instruction by the subprocess;

[0014] Save the modified native system environment file.

[0015] In one possible implementation, establishing a temporary system environment through the sub-process includes:

[0016] Creating a temporary virtual memory disk ramdisk through the child process, wherein the child process accesses the native system environment file of the electronic device through the temporary ramdisk;

[0017] A console is initialized through the child process, and the console is used to obtain an operation instruction for viewing or modifying the native system environment file.

[0018] In one possible implementation, obtaining, through the child process, an operation instruction to view or modify the native system environment file includes:

[0019] Running the console through the subprocess;

[0020] The subprocess utilizes the console to obtain an operation instruction for viewing or modifying the native system environment file.

[0021] In one possible implementation, before running the console through the subprocess, the method further includes:

[0022] The permission of the subprocess to access the native system environment file through the temporary ramdisk is modified so that the subprocess can read and write the native system environment file through the temporary ramdisk.

[0023] In a second aspect, an embodiment of the present application provides an electronic device, including:

[0024] a child process creation module, configured to jump to create a child process after the first user space init process of the operating system of the electronic device completes log redirection configuration, wherein the init process stops as a parent process after creating the child process;

[0025] A temporary system environment establishment module, configured to establish a temporary system environment through the sub-process, wherein the temporary system environment can read and write native system environment files of the electronic device;

[0026] A system environment configuration module, configured to view or modify the native system environment file using the temporary system environment through the subprocess;

[0027] The execution module is used to notify the init process to end the stagnation and continue execution in response to the signal of termination of the sub-process.

[0028] In one possible implementation, the system environment configuration module includes:

[0029] an acquiring unit, configured to acquire, through the subprocess, an operation instruction for viewing or modifying the native system environment file;

[0030] A response unit, configured to view or modify the native system environment file by using the temporary system environment through the sub-process in response to the operation instruction;

[0031] The saving unit is used to save the modified native system environment file.

[0032] In one possible implementation, the temporary system environment establishment module includes:

[0033] an establishing unit, configured to establish a temporary virtual memory disk ramdisk through the child process, wherein the child process accesses the native system environment file of the electronic device through the temporary ramdisk;

[0034] An initialization unit is used to initialize a console through the sub-process, and the console is used to obtain an operation instruction for viewing or modifying the native system environment file.

[0035] In one possible implementation, the acquiring unit includes:

[0036] A running subunit, configured to run the console through the subprocess;

[0037] The acquisition subunit is used to obtain an operation instruction for viewing or modifying the native system environment file using the console through the subprocess.

[0038] In one possible implementation, the electronic device further includes:

[0039] The permission modification module is used to modify the permission of the subprocess to access the native system environment file through the temporary ramdisk before the subprocess runs the control so that the subprocess can read and write the native system environment file through the temporary ramdisk.

[0040] In a third aspect, an embodiment of the present application provides a chip system, including:

[0041] a communication interface for inputting and / or outputting information;

[0042] The processor is used to execute a computer executable program so that a device equipped with the chip system executes the method provided in the first aspect.

[0043] In a fourth aspect, an embodiment of the present application provides an electronic device, including:

[0044] At least one processor; and at least one memory communicatively connected to the processor, wherein: the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the method provided by the first aspect.

[0045] In a fifth aspect, an embodiment of the present application provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions enable the computer to execute the method provided in the first aspect.

[0046] It should be understood that the second to fifth aspects of the embodiments of the present application are consistent with the technical solutions of the first aspect of the embodiments of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here.

Brief Description of the Drawings

[0047] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0048] Figure 1 This is a schematic diagram of the architecture of a Linux operating system provided in an embodiment of the present application;

[0049] Figure 2 This is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0050] Figure 3 This is a flowchart of the operating system startup of the electronic device according to an embodiment of the present application;

[0051] Figure 4 This is a flowchart of a debugging method provided by an embodiment of the present application;

[0052] Figure 5 This is a flowchart of a debugging method provided by another embodiment of the present application;

[0053] Figure 6 This is a flowchart of a debugging method provided by another embodiment of the present application;

[0054] Figure 7 A schematic diagram of the structure of an electronic device provided in accordance with one embodiment of the present invention;

[0055] Figure 8 A schematic diagram of the structure of a device provided in one embodiment of this specification. [Specific implementation method]

[0056] In order to better understand the technical solutions of this specification, the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0057] It should be clear that the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this specification.

[0058] The terms used in the examples of this application are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a," "an," "the," and "the" used in the examples of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0059] Figure 1 This is a schematic diagram of the architecture of a Linux operating system provided in an embodiment of the present application. Figure 1 , the operating system and related terms involved in the embodiments of this application are explained.

[0060] Linux: is a free and open source operating system (OS). Linux can refer to an operating system based on the Linux kernel.

[0061] Kernel: The kernel is the core of the operating system and manages system resources, such as providing software-level abstractions and hardware access abstractions. Software-level abstractions include operations and permission control for objects such as processes, file systems, synchronization, memory, and network protocols. Hardware access abstractions include access to hardware such as disks, displays, and network interface controllers (NICs).

[0062] An operating system based on the Linux kernel: It can be an extension of the Linux kernel, including system components that provide basic services. System components that provide basic services can be software development tools, databases, web servers, desktop environments, office suites, etc. A web server can be, for example, Apache HTTP Server. The desktop environment can be GNOME (The GNU Network Object Model Environment) or KDE (K Desktop Environment). GNOME is a set of computer software that can run on an operating system and provide a graphical desktop environment. KDE is a free graphical desktop environment that runs on operating systems such as Linux, Unix, and FreeBSD.

[0063] Hardware resources (Computer Resources): may include processors, storage media, displays, network interface cards, etc.

[0064] Shell: This refers to software that provides an operating interface for users. A shell can be the user interface of an operating system, providing an interface for users to interact with the kernel. A shell can also be a command interpreter that receives user input and sends it to the kernel for execution.

[0065] User Applications: A standard Linux operating system has a set of programs called applications. User applications can include text editors, programming languages, office suites, Internet tools, databases, etc.

[0066] For example, the Shell can manage the interaction between the outside world and the operating system, such as waiting for input, interpreting input to the operating system, and processing output results of the operating system.

[0067] It can be understood that the interaction with the operating system can be achieved through the Shell console (Console).

[0068] A process is a single execution activity of a program with independent functionality on a specific data set. A process is the basic unit of dynamic execution in the Linux operating system. A program is a description of instructions, data, and their organization. A process is an executing program and the basic execution entity of a program. Each process has its own address space. A process can include a text region, a data region, and a stack region. The text region is used to store code executed by the processor. The data region is used to store variables and dynamically allocated memory used during process execution. The stack is used to store instructions and local variables called during the active process.

[0069] Thread: Typically, a process can include multiple threads. A thread is the smallest unit that the operating system can use to schedule operations and is the actual operating unit within a process. A thread can refer to a single, sequential flow of control within a process. A process can have multiple threads running concurrently, each executing different tasks in parallel. Multiple threads within the same process share all resources within the process, such as virtual address space, file descriptors, and signal processing. However, multiple threads within the same process each have their own call stack, register context, and thread-local storage.

[0070] Kernel space: The Linux operating system divides itself into several parts. Some core software is independent of ordinary applications and runs at a higher privilege level. They reside in protected memory areas and have full access to hardware devices. Linux calls this kernel space.

[0071] User space: In contrast, user applications run in user space. Applications running in user space can only see the system resources they are allowed to use, and cannot use certain specific system functions, nor can they directly access kernel space and hardware resources.

[0072] It can be understood that the user space can be the memory area where the process of the user program is located.

[0073] Kernel state: When a process runs in kernel space, it is in kernel state. When a process is in kernel state, it has the highest permissions and can access hardware resources.

[0074] User state: When a process runs in user space, it is in user state.

[0075] It's important to understand that kernel mode and user mode are the two operating levels of the Linux operating system. Kernel mode is the highest operating level, while user mode is a lower level than kernel mode. User mode cannot access kernel mode's address space, functions, or data.

[0076] System Call Interface (SCI): A standard interface provided by the kernel for user-space interaction with kernel space. User-space programs can access kernel-space address spaces, functions, and data through the SCI. It should be noted that the SCI is implemented by the Linux kernel and runs in kernel mode.

[0077] Debugging: This refers to troubleshooting in the computer field. The debugging involved in the embodiments of the present application may refer to troubleshooting a Linux kernel boot failure, such as reading the logs before the Linux kernel boot failure to check for errors in the system environment configuration and then modifying the system environment configuration to address the errors.

[0078] Linux kernel-based operating systems can run on a variety of chip or chip module platforms, such as x86, 680x0, SPARC, Alpha, and ARM processor platforms, and are primarily used in electronic devices such as personal computers, laptops, and servers. Furthermore, electronic devices can also be terminal devices or user equipment (UE), such as smartphones, tablets, smart wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, and in-vehicle devices.

[0079] like Figure 1 As shown in Figure 1, the Linux operating system consists of four parts: kernel, shell, file system, and user applications. The kernel, shell, and file system form the basic operating system structure, allowing users to manage files, run programs, and use the operating system.

[0080] File systems: A file system is a way of organizing files on storage media such as disks.

[0081] It is important to understand that an operating system based on the Linux kernel treats all resources as files, integrating the resources of the entire electronic device into a large file directory.

[0082] For the sake of convenience, Linux is used to represent an operating system based on the Linux kernel.

[0083] For example, Linux's file organization can be called a hierarchical file system standard, which uses a hierarchical tree-like directory structure. The top level of the directory structure is the root directory " / ," and below this root directory are other directories and subdirectories. Linux uses a "path" to represent the hierarchy of a file or directory in the file system. A path consists of multiple directory name strings separated by " / ."

[0084] For example, “ / ” is the top-level directory of the Linux file system, and all other directories are subdirectories of this directory.

[0085] The / bin directory stores user executable programs. These programs can be command programs, such as copying files or directories (cp), moving files or directories (mv), or changing the current working directory (cd). The / bin directory can also store shell programs, such as bash and csh.

[0086] The / boot directory stores kernel files and system environment files. These files can be image files stored in ROM (Read-Only Memory). ROM is a non-volatile memory that maintains its information even during a power outage. It is suitable for storing persistent programs and data. After decompression, the image file can be mounted in a Linux file directory to view its contents.

[0087] The " / dev" directory is the device file directory. For example, / dev / sda represents the first SCSI device, and / dev / hda represents the first IDE device. A SCSI device might be a hard disk using SCSI (Small Computer System Interface) technology. An IDE device might be a hard disk using IDE (Integrated Drive Electronics) technology.

[0088] The " / home" directory is the home directory of an ordinary user or a File Transfer Protocol (FTP) site directory.

[0089] Partition: A section of a physical disk that behaves like a separate, physically separate disk. A partition can function as a physical separation unit. In Linux, the partitioning system creates partitions for / , / boot, / dev, / home, / bin, and swap. If other partitions or storage devices exist, they can be mounted in subdirectories within the trunk.

[0090] Mounting refers to the process by which the operating system makes files and directories on a device accessible to the operating system. In Linux, mounting refers to attaching a device to an existing directory. This directory may be present, but the previous contents of the directory will be unavailable after mounting. For example, to access a file on a storage device, you need to mount the partition containing the file to an existing directory and then access the storage device by accessing that directory.

[0091] It can be understood that in Linux, the Linux file directory can be the logical structure relationship of data between partitions, that is, the partition is the place where data is physically stored, and the directory is the logical mapping of the data stored in the partition. The partition needs to be mounted to a directory before it can be accessed by Linux.

[0092] Ramdisk: This refers to a virtual memory disk. A ramdisk uses software to simulate a portion of RAM as a hard drive. Compared to direct hard drive file access, a ramdisk can significantly improve file access speed. In Linux, a portion of RAM can be mounted as a partition.

[0093] It should be noted that the volatility of RAM will cause some data to be lost after the power is turned off. However, in general, the data transferred to RAM is a copy of the file permanently stored on the hard disk or elsewhere.

[0094] It is understood that the kernel file and the system environment file can be stored in the ROM in the form of an image file. The image file can be mounted in the " / boot" directory after being decompressed.

[0095] Exemplarily, the boot.img image file stored in the ROM may include a kernel file and a system environment file. The kernel file may be a vmlinuz file, which may be used for process management, memory management, file management, driver management, network management, and the like.

[0096] The system environment file can be a ramdisk file. The system environment file stores the files required for Linux kernel startup. The system environment file is decompressed and stored in the ramdisk.

[0097] In some possible implementations, the system environment file may be an image file named ramdisk.img.

[0098] For example, the system environment file may include an initrd (Bootloader initialized ramdisk) image file. Before the Linux kernel boots, the bootloader mounts the initrd image file from the storage medium to the memory. When the Linux kernel boots, it accesses the initrd.img file in the ramdisk before accessing the actual root file, and then loads the device driver module.

[0099] Understandably, when the kernel file or system environment file is not mounted successfully, the Linux kernel will fail to start.

[0100] Bootloader: A program that runs before the Linux kernel boots up, also known as a boot program. The bootloader completes the entire Linux system startup process. It initializes hardware devices, establishes memory space mapping, and guides the Linux hardware and software environment to the proper state, preparing the correct system environment for the final call to the Linux kernel.

[0101] It should be noted that the Bootloader can be stored in ROM.

[0102] After the Linux operating system boots, the bootloader moves the code from the storage medium to the memory for execution, then loads the kernel image file into the memory. After the kernel image file is decompressed, it starts the kernel, activates kernel space, abstracts hardware resources, initializes hardware parameters, and runs and maintains virtual memory, the scheduler, signals, and inter-process communication (IPC).

[0103] After the kernel boots, it loads the shell and user applications. User applications can be written in C or C++, which are compiled into machine code by the processor to form a process, which communicates with the kernel through the system call interface.

[0104] When the Linux operating system is started, it may encounter various problems that cause the operating system to fail to start, such as incorrect Linux kernel startup parameter settings, missing system environment files, etc. Therefore, it is necessary to obtain the system environment information just before the operating system failed to start according to the error information output by the log (Log), and then modify the system environment file according to the system environment information, and then recompile the kernel and restart the Linux operating system to complete the startup debugging of the Linux operating system.

[0105] It should be understood that a log can refer to a time-ordered collection of certain operations and their results on objects specified by the Linux system. For example, if an unsuccessful mount of a system environment file causes a Linux kernel boot failure, a log can record the failure. Printing the log can reveal detailed information such as the file name, link type, and starting address of the RAM disk, thereby identifying the cause of the failure. For example, the Linux kernel defines functions such as printascii, printch, and printhex for printing log information to facilitate debugging.

[0106] Figure 2 This is a schematic diagram of the application scenario provided by the embodiment of this application. Figure 2 As shown, when the electronic device 201 running the Linux operating system is being debugged, the debugging device 202 needs to communicate with the electronic device 201, and the interaction between the debugging device 202 and the electronic device 201 is completed through the Shell console (Console), and then according to the error information in the log, the system environment file of the electronic device 201 is modified through the debugging device 202 to complete the startup debugging of the Linux operating system.

[0107] It can be understood that the debugging device 202 can be a computer device, such as a personal computer (PC).

[0108] In a possible implementation, the debugging device 202 may communicate with the electronic device 201 via Android Debug Bridge (ADB).

[0109] However, the more complex Linux operating system has more system environment files and requires a longer debugging time. For example, the first user space process (init process) started by the Android system is relatively complex and the startup process is long. There may be many file mounting failures, resulting in startup failures. On the one hand, when the Android system fails to start, passively checking the log information can only obtain the error message of the current startup failure problem, which can only solve the current startup failure problem. The subsequent second startup failure problem will also cause the Android system to fail to start, and it is necessary to check the log information, modify the system environment files and restart the system, resulting in low debugging efficiency.

[0110] In order to better understand the above technical issues, the startup process of the operating system involved in the embodiment of the present application is introduced below.

[0111] Figure 3 1 is a flowchart of the operating system startup of the electronic device 201 according to an embodiment of the present application. Figure 3 As shown, the operating system is an Android system as an example for illustration, and this example does not constitute a limitation on the embodiments of the present application.

[0112] First, let's introduce the layered structure of the Android system. The Android system is a free and open source operating system based on the Linux kernel. Figure 3 The Android system structure, from top to bottom, consists of the Applications layer, the Java API Framework layer, the Runtime layer, the Hardware Abstraction Layer (HAL), and the Linux kernel layer. The Runtime layer includes the Android Runtime and the system's native C / C++ libraries.

[0113] The application layer includes a series of applications, such as browsers, desktop launchers, and cameras.

[0114] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions for providing system services. Predefined functions may include the phone manager, power manager, window manager, etc.

[0115] The runtime layer includes the Android runtime and native system libraries. The Android runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one for Java language functions and the other for the Android core library. The application layer and application framework layer run in the virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine is responsible for performing functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0116] The system local library can include multiple functional modules, such as the Surface Manager, Media Libraries, and Service Manager.

[0117] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0118] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0119] The service manager is used to manage system services, such as the phone manager, power manager, and window manager.

[0120] The Hardware Abstraction Layer (HAL) stores some hardware drivers. Operating in user space, the HAL can load dynamic libraries provided by hardware manufacturers, thereby moving some hardware driver functionality from kernel space to user space. This layer can include Bluetooth drivers, USB drivers, Wi-Fi drivers, and more.

[0121] The Linux kernel layer is the layer between hardware and software. It includes at least the display driver, camera driver, audio driver, and sensor driver. The core services of the Android system are implemented based on the Linux kernel. The Android system's security management, memory management, process management, and network protocols all rely on the Linux kernel.

[0122] The following describes the startup process of the Android system.

[0123] See also Figure 3 The Android system starts from the ROM of the electronic device 201, and starts the Linux kernel and the programs in the Android system user space in sequence. The startup process of the Android system can be divided into three stages, namely, boot boot, kernel startup and Android startup.

[0124] Booting: When the electronic device 201 is powered on, the boot code (ROM code) in the electronic device 201 starts to execute from a predefined location to load the boot loader into the memory and then execute it. The predefined location can be fixed in ROM (Read-Only Memory).

[0125] The bootloader is responsible for loading and starting the entire system. It initializes hardware devices, creates a memory map, and guides the system's hardware and software environments to the proper state, preparing the correct system environment for the final call to the Linux kernel.

[0126] It should be noted that during the boot phase, the operation of initializing the Universal Asynchronous Receiver / Transmitter (UART) port is completed.

[0127] Kernel startup: During the boot phase, the bootloader loads the Linux kernel image file into memory. The Linux kernel image file may include the kernel file (vmlinuz.img) and the system environment file (ramdisk.img). During the kernel startup phase, hardware device drivers, such as camera drivers, audio drivers, and display drivers, are primarily loaded. Hardware device drivers interact with the hardware abstraction layer through the system call interface.

[0128] During kernel startup, the swapper is started, which initializes process management, memory management, and driver loading. Then, the kernel thread is started. After kernel space is initialized, the init program is loaded, and the kernel thread creates the init process.

[0129] As you can understand, the process identifier (PID) of the swap process is 0. The process identifier of the first user space process is 1.

[0130] Android startup: At the running layer, after the init process completes startup, the init process parses the init.c file, starts the adbd process, the Service manager process, and hatches the Zygote process.

[0131] The Zygote process will load the virtual machine and start the system service process (system service). The system service process is the first process incubated by the Zygote process and is responsible for starting and managing the entire application framework layer. The Zygote process will also start related application processes. Exemplarily, the first application process started by the Zygote process is the desktop launcher (Launcher), which then starts the mailbox (Emails) process. It can be understood that all application processes are incubated by the Zygote process.

[0132] During the aforementioned startup process, all userspace processes in the Android system are started by the init process. This means that the Android system can only complete its startup after the init process has successfully started. However, the Android system's init process startup process is long and complex, and involves numerous nodes where system environment files are mounted.

[0133] Exemplarily, the init process startup process includes a first stage init and a second stage init.

[0134] Phase 1 includes:

[0135] 1. Determine and add environment variables;

[0136] 2. Create and mount a virtual file system;

[0137] 3. Log redirection configuration;

[0138] 4. Mount the partition device (do first stage mount);

[0139] 5. Complete SELinux related work;

[0140] 6. is the end of the first stage;

[0141] After the first phase is finished, some information will be reset and some environment variables will be set, and then the second phase will be started.

[0142] Phase II includes:

[0143] 1. Initialize the attribute domain;

[0144] 2. Clear environment variables;

[0145] 3. Complete SELinux related work. The first stage mainly loads SELinux related policies, while the second stage calls selinux_initialize to only register some processors;

[0146] 4. Create an epoll handle;

[0147] 5. Load the child process signal handler;

[0148] 6. Start the attribute service;

[0149] 7. Match the correspondence between commands and functions;

[0150] At the end of the second stage the init.rc file is parsed.

[0151] It is understandable that the startup process of the above init process is complicated and involves many system environment file mounting nodes. However, the existing related technologies do not consider advancing the debugging time and ignore debugging the init process, resulting in long debugging time and low debugging efficiency.

[0152] Based on the above problems, the embodiments of the present application provide a debugging method that can interact with the debugging device 202 to implement debugging at the initial stage of the init process startup of the electronic device 201, that is, after the Linux system completes the basic system environment configuration, thereby advancing the debugging time. When the init process is not fully started, the native system environment file is proactively checked in advance, so that startup failure problems can be discovered in advance and the native system environment file can be modified. The Linux operating system can then be started based on the modified system environment file, without the need to recompile and restart the Linux system, thereby improving debugging efficiency.

[0153] The following specific embodiments are used to describe the technical solution of the present application in detail. The following multiple embodiments can be implemented independently or in combination with each other, and the same or similar technical terms or processes may not be repeated in some embodiments.

[0154] Figure 4 This is a flowchart of a debugging method provided by an embodiment of the present application. Figure 4 As shown, the above debugging method can be applied to the electronic device 201, including:

[0155] Step 401: After the first user space init process of the operating system of the electronic device 201 completes the log redirection configuration, it jumps to create a child process. After the init process creates the child process, it stops as a parent process.

[0156] It is understood that electronic device 201 executes the jump action after the init process completes the log redirection configuration. In the first stage, the init process completes the creation and mounting of the virtual file system, successfully mounting the ramdisk of electronic device 201, that is, successfully mounting the native system environment files of electronic device 201. After the init process completes the log redirection configuration, the native system environment files of electronic device 201 can be accessed.

[0157] It can be understood that the electronic device 201 creates a sub-process by executing a jump after the init process completes the log redirection configuration, and then the electronic device 201 can build a temporary system environment through the sub-process.

[0158] Optionally, an interface function may be inserted into the init source code of the electronic device 201 to enable the electronic device 201 to execute a jump action. The interface function may point the electronic device 201 to a function for executing a sub-process creation.

[0159] Exemplarily, the operating system of the electronic device 201 is Android as an example for explanation, and this example does not constitute a limitation of the embodiments of the present application. The electronic device 201 can be implemented by adding a header file (.h) and an implementation file (.cpp) to jump to create a subprocess. For example, the interface function android::mboot::mc(" / msystem / bin / date") can be inserted into the first_stage_init.cpp file in the init source code through the header file to implement the electronic device 201 to execute the jump. For example, a function for creating a subprocess can be defined in the implementation file to implement the electronic device 201 to execute the creation of the subprocess.

[0160] Optionally, the electronic device 201 pre-stores a storage file for execution of the created sub-process. The storage file can be used to build a temporary system environment. The storage file can be a file in .pac format.

[0161] Exemplarily, the storage file may include an inittab file for building a temporary system environment.

[0162] Optionally, in step 401, after the first user space init process of the operating system of the electronic device 201 completes the log redirection configuration, the process jumps to create a child process, including:

[0163] Step 4011, determine whether there is a storage file.

[0164] Step 4012: When the storage file exists, create a child process.

[0165] Step 4013: When the storage file does not exist, notify the init process to return to the jump location and continue execution.

[0166] It can be understood that the storage file stores the files that the child process needs to execute later. If the storage file is not mounted successfully, the child process cannot perform subsequent actions.

[0167] Optionally, the determination of whether the storage file exists in step 4011 can be performed by checking the file path to confirm whether the storage file exists.

[0168] For example, the storage file may be named Mboot.pac. The storage file is mounted in the msystem partition of the electronic device 201. The electronic device 201 may confirm whether the storage file exists by checking whether the Mboot.pac file exists in the directory of the msystem partition through a subprocess.

[0169] Optionally, the electronic device 201 creates the child process by executing a fork function through an init process to hatch the child process.

[0170] As you can understand, a process in memory consists of three parts: a code segment, a data segment, and a stack segment. A child process shares the code segment with the parent process and copies the parent's data and stack segments. After a child process is successfully created, the init process becomes the parent process. The fork function returns values ​​to both the parent and child processes. The value returned by the parent process is the child process's PID, which is greater than zero. The value returned by the child process is 0.

[0171] Optionally, after the electronic device 201 creates a child process through the init process, the init process can execute a wait function to achieve stagnation.

[0172] Step 402 : A temporary system environment is established through a child process. The temporary system environment can read and write the native system environment file of the electronic device 201 .

[0173] Optionally, the child process can execute the executable program in the storage file. The inittab file in the storage file can be used to build a temporary system environment. Building the temporary system environment can be done by creating a temporary virtual memory disk ramdisk. The temporary ramdisk can share a file system with the native ramdisk of the electronic device 201. At the same time, the permission of the temporary randisk to access the native system environment file can be modified, so that the temporary system environment can read and write the native system environment file of the electronic device 201.

[0174] Step 403: View or modify the native system environment file using the temporary system environment through the child process.

[0175] Optionally, the inittab file of the storage file can also be used to initialize an interactive tool for the electronic device 201 and the debugging device 202 to interact with each other. The interactive tool for the electronic device 201 and the debugging device 202 to interact with each other can be a console or an Android debugging bridge.

[0176] It is understood that electronic device 201 can obtain debugging instructions input by debugging device 202 through an interactive tool. The debugging instructions can be to view or modify the native system environment file. Electronic device 201 can view or modify the native system environment file in response to the debugging instructions. When electronic device 201 modifies the native system environment file through a subprocess in response to the debugging instructions, the subprocess can save the modified native system environment file, thereby completing the debugging.

[0177] Step 404: In response to the child process termination signal, notify the init process to end the stagnation and continue execution.

[0178] Optionally, after completing debugging, the debugging device 202 may send an end instruction to the electronic device 201 to terminate the sub-process.

[0179] Optionally, after the child process ends and returns to kernel state, the process control block (PCB) of the kernel of the electronic device 201 can send a SIGCHILD signal to the parent process, that is, the init process. After receiving the SIGCHILD signal, the wait function of the init process returns the PID of the child process.

[0180] Optionally, when the PID returned by the wait function is the PID of the child process, the init process ends and continues to execute.

[0181] The debugging method provided in the embodiment of the present application builds a temporary system environment after the init process completes the log redirection configuration, and checks or modifies the native system environment file according to the temporary system environment. This can advance the debugging timing, expand the debugging scope, and quickly handle configuration errors of the native system environment file, thereby improving debugging efficiency.

[0182] It should be noted that the debugging method provided in the embodiments of the present application can advance the debugging timing in the application scenario of viewing the native system environment files for debugging, compared to the native debugging tools or Android Debug Bridge of the Android system. For example, debugging using the Android Debug Bridge requires the init process to complete the startup phase and start the adbd process before calling the Android Debug Bridge. For another example, if you want to call the console for debugging earlier, you need to perform the native system environment configuration work, that is, modify the native system environment files. The debugging method provided in the embodiments of the present application is for debugging unmodified native system environment files.

[0183] Figure 5 This is a flowchart of a debugging method provided by another embodiment of the present application. Figure 5 As shown, this application Figure 4 In the illustrated embodiment, step 403 uses a temporary system environment to view or modify the native system environment file through a subprocess, including:

[0184] Step 501: Obtain an operation instruction for viewing or modifying a native system environment file through a child process.

[0185] Optionally, the child process may open an interactive tool and use the interactive tool to obtain an operation instruction input by the debugging device 202 .

[0186] Step 502: The child process uses the temporary system environment to view or modify the native system environment file in response to the operation instruction.

[0187] Optionally, since the temporary system environment and the native system environment files share a file system, the native system environment files can be viewed or modified through the temporary system environment.

[0188] Step 503: Save the modified native system environment file.

[0189] The debugging method provided in the embodiment of the present application saves the modified native system environment file, so that when the init process ends its stagnation and continues to execute, it can continue to execute based on the modified native system environment file, without the need to recompile the kernel and restart the Linux operating system, thereby saving debugging time and improving debugging efficiency.

[0190] Figure 6 This is a flowchart of a debugging method provided by another embodiment of the present application. As shown in Figure 6, in the above embodiment, step 402 establishes a temporary system environment through a sub-process. The temporary system environment can read and write the native system environment file of the electronic device 201, including:

[0191] Step 601 : A temporary virtual memory disk ramdisk is created through a child process, and the child process accesses the native system environment file of the electronic device 201 through the temporary ramdisk.

[0192] Step 602: Initialize the console through the child process. The console is used to obtain operation instructions for viewing or modifying the native system environment file.

[0193] It can be understood that the debugging method provided in the embodiment of the present application does not modify the native system environment file of the electronic device 201 before jumping to create a sub-process. Therefore, the electronic device 201 establishes a temporary system environment through the sub-process by only establishing a temporary ramdisk and initializing the interactive tool, and then automatically mounts the initialization interactive tool.

[0194] Optionally, the interactive tool can be a console or Android Debug Bridge.

[0195] For example, the interactive tool is a console, and the inittab file design instructions for storing files are described. The inittab file design is as follows:

[0196] ::sysinit: / msystem / metc / init.d / rcS;

[0197] ::respawn:- / msystem / bin / sh;

[0198] ::ctrlaltdel: / msystem / bin / umount-a–r.

[0199] rcS is the system initialization file, which is initialized by action:sysinit. Sh is the shell console calling tool, which is opened by action:respawn. Action:ctrlaltdel is a key combination setting, which can reset the operating system of electronic device 201 by entering the ctrl+alt+del key combination.

[0200] The above debugging method provided in the embodiment of the present application can access the native ramdisk of the electronic device 201 through a temporary ramdisk. The native ramdisk can store native system environment files, and then the electronic device 201 can use the ramdisk to access the native system environment files through a sub-process.

[0201] Optionally, step 501 obtains an operation instruction for viewing or modifying a native system environment file through a subprocess, including:

[0202] Step 603: Run the console through a child process.

[0203] Step 604: Obtain an operation instruction for viewing or modifying the native system environment file through the console via the child process.

[0204] Optionally, before running the console through the subprocess in step 603, the following steps may be further included:

[0205] Step 6031: Modify the permission of the child process to access the native system environment file through the temporary ramdisk so that the child process can read and write the native system environment file through the temporary ramdisk.

[0206] Optionally, the storage file also includes a profile file. The profile file can be used to configure the console's environment variables and modify the permissions for the temporary ramdisk to access native system environment files.

[0207] Optionally, the profile file can also be used to save the modified native system environment file. Exemplarily, the profile file can include the android.start tool, which is a tool used to save the current native system file when the console exits.

[0208] It is understandable that the temporary ramdisk has only readable permissions to access the native system environment files. You can configure the permissions of the mounted files through the profile file and modify the temporary ramdisk's permissions to access the native system environment files to be readable and writable.

[0209] Exemplarily, after the electronic device 201 executes the ::respawn:- / msystem / bin / sh command, it calls the sh tool and automatically executes the profile script file.

[0210] Optionally, before running the console through the subprocess in step 603, the following steps may be further included:

[0211] Step 6031, determining whether the instruction is obtained within the preset time;

[0212] Step 6032: When the command is received within the preset time, the console is opened through the child process;

[0213] Step 6033: When no instruction is obtained within the preset time, the sub-process terminates.

[0214] Optionally, the preset time may be 10s, 15s, 20s or other time values, and this application does not specifically limit the value of the preset time.

[0215] The debugging method provided in the embodiment of the present application can provide an exit mechanism when the debugger wants to skip the current debugging node by setting a preset time. Exemplarily, the profile file of the storage file also includes a countdown input detection tool mboot-auto. When the sub-process of the electronic device 201 automatically executes the profile file by calling the sh tool. When the electronic device 201 executes the profile file through the sub-process, it will call the mboot-auto tool to detect whether there is a key input within the preset time. If there is a key input within the preset time, the sub-process interrupts the execution of the mboot-auto tool and enters the console. If there is no key input within the preset time, the sub-process calls the android.start tool, saves the current native system environment file, and terminates the sub-process.

[0216] It should be understood that the debugging method provided in the above embodiment of the present application can be implemented once or multiple times at any node after the init process completes the log redirection configuration. Exemplarily, the debugging method provided in the above embodiment of the present application can be implemented by setting an interface function at a node between the log redirection configuration of the first stage of init process startup and the mount partition device (do first stage mount) to execute the debugging method provided in the above embodiment of the present application, and can also be implemented by setting an interface function at the mount partition device (do first stage mount) node to execute the method provided in the above embodiment of the present application.

[0217] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0218] Figure 7 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Figure 7 As shown, the electronic device 201 includes: a sub-process creation module 701, a temporary system environment establishment module 702, a system environment configuration module 703 and an execution module 704.

[0219] The child process creation module 701 is used to jump to create a child process after the first user space init process of the operating system of the electronic device 201 completes the log redirection configuration, wherein the init process stops as a parent process after creating the child process.

[0220] The temporary system environment establishing module 702 is used to establish a temporary system environment through a sub-process. The temporary system environment can read and write the native system environment file of the electronic device 201.

[0221] The system environment configuration module 703 is used to view or modify the native system environment file by using the temporary system environment through a child process.

[0222] The execution module 704 is used to notify the init process to end the stagnation and continue execution in response to the signal of the child process termination.

[0223] Optionally, the system environment configuration module 703 includes an acquisition unit, a response unit, and a storage unit.

[0224] The acquisition unit is used to obtain operation instructions for viewing or modifying native system environment files through a child process.

[0225] The response unit is used to view or modify the native system environment file by using the temporary system environment through the child process in response to the operation instruction.

[0226] The saving unit is used to save the modified native system environment file.

[0227] Optionally, the temporary system environment establishing module 702 includes an establishing unit and an initializing unit.

[0228] The establishing unit is used to establish a temporary virtual memory disk ramdisk through a child process, wherein the child process accesses the native system environment file of the electronic device 201 through the temporary ramdisk.

[0229] The initialization unit is used to initialize the console through a subprocess. The console is used to obtain operation instructions for viewing or modifying native system environment files.

[0230] Optionally, the acquisition unit includes an operation subunit and an acquisition subunit.

[0231] Run subunit, used to run the console through a subprocess.

[0232] The acquisition subunit is used to obtain operation instructions for viewing or modifying native system environment files through the console through a child process.

[0233] Optionally, the electronic device 201 further includes a permission modification module.

[0234] The permission modification module is used to modify the permission of the subprocess to access the native system environment file through the temporary ramdisk before running the console through the subprocess so that the subprocess can read and write the native system environment file through the temporary ramdisk.

[0235] Optionally, the sub-process creation module 701 includes a first determining unit and a first executing unit.

[0236] The first determining unit is configured to determine whether a storage file exists.

[0237] The first execution unit is used to create a child process when the storage file exists, and is also used to notify the init process to return to the jump location to continue execution when the storage file does not exist.

[0238] Optionally, the electronic device 201 further includes a second determining unit and a second executing unit.

[0239] The second determining unit is configured to determine whether to obtain an instruction within a preset time before running the console through a sub-process.

[0240] The second execution unit is used to keep the console in a running state when an instruction is obtained within a preset time, and is also used to terminate the sub-process when no instruction is obtained within the preset time.

[0241] Figure 7 The electronic device 201 provided in the embodiment shown can be used to execute the present invention. Figures 4 to 6 The technical solution of the method embodiment shown, its implementation principle and technical effects can be further referred to the relevant description in the method embodiment.

[0242] The embodiment of the present application also provides a chip system, including: a communication interface for inputting and / or outputting information; a processor for executing a computer executable program so that a device equipped with the chip system executes the following Figures 4 to 6 The processor may be a chip or a chip module.

[0243] The debugging method provided in the embodiment of the present application can be executed by the following devices: a chip or a chip module. The above-mentioned sub-process creation module 701, temporary system environment establishment module 702, system environment configuration module 703 and execution module 704 can be, for example, a chip or a chip module.

[0244] The modules / units included in the various devices and products described in the above embodiments may be software modules / units, hardware modules / units, or partially software modules / units and partially hardware modules / units. For example, for various devices and products applied to or integrated into a chip, the modules / units included therein may all be implemented using hardware such as circuits, or at least some of the modules / units may be implemented using software programs that run on a processor integrated within the chip. Different modules / units may be located in the same component (e.g., chip, circuit module, etc.) or in different components of the chip module, or at least some of the modules / units may be implemented in the form of a software program that runs on a processor integrated inside the chip module, and the remaining (if any) modules / units may be implemented in the form of hardware such as circuits; for various devices and products applied to or integrated in a terminal, the various modules / units contained therein may all be implemented in the form of hardware such as circuits, and different modules / units may be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal, or at least some of the modules / units may be implemented in the form of a software program that runs on a processor integrated inside the terminal, and the remaining (if any) modules / units may be implemented in the form of hardware such as circuits.

[0245] Figure 8 This is a schematic diagram of the structure of the device provided in one embodiment of this specification. Figure 8 As shown, the electronic device 201 may include at least one processor; and at least one memory in communication with the processor, wherein: the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the instructions of this specification. Figures 4 to 6 The debugging method provided by the illustrated embodiment.

[0246] The electronic device 201 may be a smart phone, a tablet computer, a laptop computer, etc. This embodiment does not limit the form of the electronic device 201.

[0247] For example, Figure 8 The structure diagram of the electronic device 201 is shown by taking a smart phone as an example. Figure 8 As shown, the electronic device 201 may include a processor 110, an internal memory 121, a universal serial bus (USB) interface 130, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, a sensor module 180, a display screen 194, and a subscriber identification module (SIM) card interface 195. The sensor module 180 may include a pressure sensor 180A, an air pressure sensor 180C, a magnetic sensor 180D, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

[0248] It should be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 201. In other embodiments of the present application, the electronic device 201 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0249] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0250] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0251] The processor 110 may also include a memory for storing instructions and data.

[0252] The wireless communication function of the electronic device 201 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0253] Wireless communication module 160 can be one or more devices that integrate at least one communication processing module. Wireless communication module 160 receives electromagnetic waves via antenna 2, frequency-modulates and filters the electromagnetic wave signals, and transmits the processed signals to processor 110. Wireless communication module 160 can also receive signals to be transmitted from processor 110, frequency-modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0254] In some embodiments, antenna 1 of electronic device 201 is coupled to mobile communication module 150 , and antenna 2 is coupled to wireless communication module 160 , so that electronic device 201 can communicate with the network and other devices through wireless communication technology.

[0255] Electronic device 201 implements display functionality through a GPU, display screen 194, and an application processor. A GPU is a microprocessor for image processing that connects display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0256] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 201 by running the instructions stored in the internal memory 121 and / or the instructions stored in the memory provided in the processor.

[0257] The present invention provides a non-transitory computer-readable storage medium that stores computer instructions that enable a computer to execute the instructions in this specification. Figures 4 to 6 The debugging method provided by the illustrated embodiment.

[0258] The above-mentioned non-transitory computer-readable storage medium can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by an instruction execution system, device or device or used in combination with it.

[0259] Computer program code for carrying out the operations of this specification may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server.

[0260] In the description of the embodiments of the present invention, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0261] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout this specification, "plurality" means at least two, such as two or three, unless otherwise specifically defined.

[0262] The above are only preferred embodiments of this specification and are not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A debugging method, characterized in that: Used in electronic equipment, including: After the first user space init process of the operating system of the electronic device completes log redirection configuration and before the init process completes parsing of the init.rc file, jump to create a child process, wherein the init process stagnates as a parent process after creating the child process; Establishing a temporary system environment through the sub-process, wherein the temporary system environment can read and write native system environment files of the electronic device; Viewing or modifying the native system environment file using the temporary system environment through the subprocess; In response to the signal of termination of the child process, the init process is notified to end the stagnation and continue execution.

2. The method according to claim 1, characterized in that The viewing or modifying the native system environment file by using the temporary system environment through the subprocess includes: Obtaining, through the subprocess, an operation instruction for viewing or modifying the native system environment file; Viewing or modifying the native system environment file using the temporary system environment in response to the operation instruction by the subprocess; Save the modified native system environment file.

3. The method according to claim 1 or 2, characterized in that The establishing of a temporary system environment through the sub-process includes: Creating a temporary virtual memory disk ramdisk through the child process, wherein the child process accesses the native system environment file of the electronic device through the temporary ramdisk; A console is initialized through the child process, and the console is used to obtain an operation instruction for viewing or modifying the native system environment file.

4. The method according to claim 3, characterized in that The obtaining, through the sub-process, an operation instruction to view or modify the native system environment file includes: Running the console through the subprocess; The subprocess utilizes the console to obtain an operation instruction for viewing or modifying the native system environment file.

5. The method according to claim 4, characterized in that Before running the console through the sub-process, the method further includes: The permission of the subprocess to access the native system environment file through the temporary ramdisk is modified so that the subprocess can read and write the native system environment file through the temporary ramdisk.

6. An electronic device, characterized in that: include: A child process creation module, configured to jump to create a child process after the first user space init process of the operating system of the electronic device completes log redirection configuration and before the init process completes parsing of the init.rc file, wherein the init process stagnates as a parent process after creating the child process; A temporary system environment establishment module, configured to establish a temporary system environment through the sub-process, wherein the temporary system environment can read and write native system environment files of the electronic device; A system environment configuration module, configured to view or modify the native system environment file using the temporary system environment through the subprocess; The execution module is used to notify the init process to end the stagnation and continue execution in response to the signal of termination of the sub-process.

7. The electronic device according to claim 6, wherein: The system environment configuration module includes: an acquiring unit, configured to acquire, through the subprocess, an operation instruction for viewing or modifying the native system environment file; A response unit, configured to view or modify the native system environment file by using the temporary system environment through the sub-process in response to the operation instruction; The saving unit is used to save the modified native system environment file.

8. The electronic device according to claim 7, wherein: The temporary system environment establishment module includes: an establishing unit, configured to establish a temporary virtual memory disk ramdisk through the child process, wherein the child process accesses the native system environment file of the electronic device through the temporary ramdisk; An initialization unit is used to initialize a console through the sub-process, and the console is used to obtain an operation instruction for viewing or modifying the native system environment file.

9. The electronic device according to claim 8, wherein: The acquisition unit includes: A running subunit, configured to run the console through the subprocess; The acquisition subunit is used to obtain an operation instruction for viewing or modifying the native system environment file using the console through the subprocess.

10. The electronic device according to claim 8, wherein The electronic device further comprises: The permission modification module is used to modify the permission of the subprocess to access the native system environment file through the temporary ramdisk before running the console through the subprocess so that the subprocess can read and write the native system environment file through the temporary ramdisk.

11. A chip system, characterized in that: include: a communication interface for inputting and / or outputting information; A processor, configured to execute a computer executable program so that a device equipped with the chip system executes the method according to any one of claims 1 to 5.

12. An electronic device, characterized in that: include: at least one processor; as well as at least one memory in communication with the processor, wherein: The memory stores program instructions that can be executed by the processor, and the processor can execute the method according to any one of claims 1 to 5 by calling the program instructions.

13. A non-transitory computer-readable storage medium, characterized in that The non-transitory computer-readable storage medium stores computer instructions, which cause the computer to execute the method according to any one of claims 1 to 5.

Images