Camera control method of Android device, electronic device and storage medium

Abstract

The invention belongs to the technical field of electronic communication, and particularly relates to a camera control method of Android equipment, electronic equipment and a storage medium. The method comprises the following steps: setting a camera equipment node as a system application readable and writable permission when a system is initialized; and opening a device node file through a file operation function, setting a readable and writable file descriptor, and obtaining the file descriptor. And executing power-on initialization of the camera through the descriptor, and creating and ending a thread for initializing the image signal processor. And configuring the resolution, format and data length of the camera, requesting and registering an image buffer area, controlling a flash lamp and opening an image stream. And monitoring a scanning function key, starting continuous image reading when the scanning function key is pressed down, and reading and copying image frames through descriptors. And re-queuing the buffer area for next reading, turning off the image flow and the flash lamp after reading is finished, releasing buffer resources, and turning off the processor and the equipment node to complete power-off. According to the method, the android architecture is bypassed, the image is directly acquired from the kernel driver, delay is reduced, the frame rate is stabilized, and power consumption is reduced.

Description

Technical Field

[0001] The present invention belongs to the field of electronic communication technology, and specifically relates to a camera control method of an Android device, an electronic device and a storage medium. Background Art

[0002] In modern mobile devices, the camera has become one of the indispensable components, especially on the Android operating system platform, where the camera has a wide range of application scenarios, including but not limited to photography, video calls, and image recognition. Traditionally, camera control on Android devices mainly relies on the API interfaces provided by the Android system. These interfaces provide a relatively simple way to access and control camera hardware, but there are some shortcomings.

[0003] First, when using the standard Android API interface for camera control, you often encounter the problem of unstable frame rate. This is because the Android system may not guarantee that the camera runs at the maximum frame rate when scheduling camera access, resulting in frame drops or loss. Especially in applications with high image processing requirements, such as real-time image recognition or high-quality video recording, this instability will seriously affect the performance of the application and user experience.

[0004] Secondly, in order to ensure the camera's fast response, the application usually needs to keep the camera open for a long time, which significantly increases the power consumption of the device. In mobile devices, battery life is a problem that users are very concerned about. Therefore, how to reduce power consumption while ensuring the camera's fast response has become a technical challenge that needs to be solved urgently.

[0005] In addition, when controlling the camera through the Android API interface, the initialization and startup process of the camera involves multiple abstraction layers, which not only increases the complexity of operation, but also may cause startup delays. In some application scenarios that require fast camera startup, such as security monitoring or emergency response systems, this delay is unacceptable. Summary of the invention

[0006] 1. Technical issues to be resolved The present invention mainly aims at the above problems and proposes a camera control method, electronic device and storage medium for an Android device, which aims to solve the problems of unstable frame rate, high power consumption and response delay in the traditional camera control method of an Android device by directly acquiring images from the kernel camera driver.

[0007] (II) Technical solution To achieve the above object, the first aspect of the present invention provides a camera control method for an Android device, the method comprising the following steps: When the system is initialized, set the read and write permissions of the system application for the camera device node; Use the file operation function to open the device node file of the camera, set it to a readable and writable state, and obtain the file descriptor; Call the camera's power-on initialization through the file descriptor; Create a thread to initialize the image signal processor and terminate the thread after the initialization is completed; Configure the camera's image resolution, format, and data length parameters through file descriptors; Request and register buffer for image buffer, control flash to turn on, and open image stream to start image capture process; Monitor the scanning function button of the device. When the button is pressed, start the continuous image reading interface, read the image frame through the file descriptor and copy it to the target address; Requeue the buffer for the next image frame read; When the camera is no longer needed, turn off the image stream and flash, release all requested buffer resources, turn off the image signal processor, and close the device node to complete the camera power-off operation.

[0008] Furthermore, the setting of the camera device node includes configuring permissions through an initialization script of the operating system.

[0009] Furthermore, the file operation function is used to open the camera device node file in a readable and writable state, and initialize the camera device through this operation.

[0010] Furthermore, the initialization of the image signal processor is performed immediately after the camera device node file is opened.

[0011] Furthermore, the method also includes setting image resolution, format and data length parameters using input / output control commands after the image signal processor is initialized.

[0012] Furthermore, the image capture process of the camera includes controlling the flash to turn on using an input / output control command, and starting the image stream through the same command.

[0013] Furthermore, the method also includes in the implementation of the continuous image reading interface, when the scanning function button of the device is continuously pressed, the application continuously reads the data of each frame and returns the data to the Android application for processing.

[0014] Furthermore, the operation of closing the image stream and the flash is completed through an input / output control command, and includes releasing all requested buffer resources.

[0015] To achieve the above-mentioned purpose, the second aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the camera control method of the Android device when executing the computer program.

[0016] To achieve the above-mentioned purpose, the third aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the camera control method of the Android device is implemented.

[0017] (III) Beneficial effects Compared with the prior art, the present invention provides a camera control method, electronic device and storage medium for an Android device, which bypasses the abstract layer and framework layer of Android by directly interacting with the kernel image subsystem, thereby significantly improving the stability of the frame rate, reducing power consumption, and reducing the response time. By directly controlling the camera from the underlying hardware, the present invention can achieve fast power-on and initialization of the camera, provide continuous and stable image capture, and reduce frame loss caused by improper system scheduling. In addition, the method activates the camera and related resources only when needed, greatly reducing the energy consumption of the device when it is not in use. This fast response and low power consumption design is particularly suitable for mobile applications that require instant image processing and long-term operation, effectively improving the overall performance and user experience of the device. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a flowchart of a camera control method for an Android device disclosed in this application.

[0019] Figure 2 This is a schematic diagram of a camera control method for an Android device disclosed in this application.

[0020] Figure 3 A framework diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0021] The present invention will be described in detail below in conjunction with the accompanying drawings, and the technical solutions in the embodiments of the present invention will be clearly and completely described. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0022] like Figure 1 , Figure 2 As shown, the present invention provides a camera control method for an Android device, which includes three parts: initialization startup, continuous image reading, and shutdown. The specific steps are as follows: Step S100: When the system is initialized, the read and write permissions of the system application are set for the camera device node; The system sets read and write permissions for the camera device node during the initialization phase, mainly to ensure that system applications can successfully access and control the camera. This is achieved by modifying the system's startup script (such as the init.rc file), which contains commands to change the permissions of a specific device node (usually ` / dev / video0`). For example, you can add a command `chmod 0666 / dev / video0`, which sets the camera device node to a read and write state, allowing applications to open and operate the camera through file operations.

[0023] Step S200: Use the file operation function to open the device node file of the camera, set it to a readable and writable state, and obtain the file descriptor; Open the camera's device node file (usually ` / dev / video0`) through file operation functions such as `open()`, and set it to readable and writable state (using the flag bit `O_RDWR`). For example, calling `int fd =open(" / dev / video0", O_RDWR);` not only opens the device node file, but also ensures that the system application can access the camera in read-write mode. After successfully executing this operation, the system returns a file descriptor (`fd`), which is used for all subsequent system calls that interact with the camera hardware, such as setting the image format, controlling the image stream, etc.

[0024] Step S300, calling the power-on initialization of the camera through the file descriptor; Using the file descriptor (fd) obtained in the previous step, perform the power-on initialization process of the camera. Call specific system calls or functions, such as `ioctl()`, to interact with the camera driver and start the camera hardware. For example, you can instruct the camera to switch from the power-off state to the power-on state by executing a command such as `ioctl(fd, VIDIOC_S_POWER, ON)`. This step ensures that the camera hardware is properly activated and ready for the key links of image capture and data transmission.

[0025] Step S400, creating a thread to initialize the image signal processor, and terminating the thread after the initialization is completed; Create a new thread dedicated to initializing the image signal processor (ISP) to optimize the independent task of image processing. For example, you can create a thread programmatically and execute a command such as `pthread_create(&thread_id, NULL, initialize_ISP, NULL)` to start the thread. After starting, the thread will execute the relevant initialization code to configure and optimize the ISP settings, and once completed, it will end the thread. Doing so ensures that the main process of camera initialization is not delayed due to ISP configuration, while ensuring the efficiency and quality of image processing.

[0026] Step S500, configure the image resolution, format and data length parameters of the camera, and set them through the file descriptor; Configure the camera's image resolution, format, and data length parameters, which are set through the file descriptor obtained previously. The specific operation is implemented through the `ioctl()` function, such as executing `ioctl(fd, VIDIOC_S_FMT,&fmt)` to set the camera's image format and resolution. Here, `fmt` is a structure that contains resolution, image format (such as JPEG, YUV, etc.), image width and height, and other related parameters. This step is to ensure that the image data output by the camera meets the application requirements and the expected effect of subsequent image processing, thereby improving the overall image quality and processing speed.

[0027] Step S600, requesting and registering an image buffer, controlling the flash to turn on, and opening the image stream to start the image capture process; First, request and register the image buffer through the file descriptor (fd) to ensure that there is enough memory space to store the captured image data. This is done through `ioctl(fd, VIDIOC_REQBUFS,&req)`, where `req` is a configuration structure that specifies the number and type of buffers required. Subsequently, `mmap()` is used to map the buffer to user space so that the application can directly access the buffer. At the same time, another `ioctl()` call is used to control the opening of the flash, such as `ioctl(fd, VIDIOC_S_CTRL,&ctrl)`, where the `ctrl` control structure specifies the state of the flash. Finally, `ioctl(fd, VIDIOC_STREAMON,&type)` is used again to open the image stream and officially start the image capture process. This series of operations ensures that the data flow from the camera to the application is continuous and stable, while providing the necessary illumination through the flash to optimize image quality.

[0028] Step S700, monitoring the scanning function button of the device, when the button is pressed, starting the continuous image reading interface, reading the image frame through the file descriptor and copying it to the target address; The image capture process is triggered by listening to the scan function button on the device. When the scan function button is pressed by the user, the system starts the continuous image reading interface, which is implemented through the file descriptor (fd). The specific operation includes using the `ioctl(fd, VIDIOC_DQBUF,&buf)` call to obtain an image frame buffer from the device's queue. Once the image data is obtained, the image data is copied from the kernel space to the target address in the user space through `memcpy(des, buf, buf.length)` for subsequent processing. After that, the buffer will be re-queued and `ioctl(fd,VIDIOC_QBUF,&buf)` will be used to prepare for capturing the next frame of the image. This process will continue to be executed while the button remains pressed, ensuring continuous image capture and transmission, thereby supporting the efficient operation of the scanning device.

[0029] Step S800, requeue the buffer for the next image frame reading; Requeue the buffer to ensure that image frames can be read continuously. This operation is done through the file descriptor (fd) and the `ioctl()` call, and the specific command used is `ioctl(fd, VIDIOC_QBUF,&buf)`. Here, `buf` is a pointer to the buffer that has been processed by the application and now needs to be refilled with data by the camera. After executing this command, the buffer is returned to the queue to wait for data to be written by the camera. This is a cyclic process that ensures that the application can continue to receive new image frames while the user performs continuous scanning operations, thereby achieving smooth image capture and processing.

[0030] Step S900: When the camera is no longer needed, the image stream and the flash are turned off, all requested buffer resources are released, the image signal processor is turned off, and the device node is turned off to complete the power-off operation of the camera.

[0031] When the camera is no longer needed, a series of operations are performed to shut down and release resources. First, the image stream is closed through `ioctl(fd, VIDIOC_STREAMOFF,&type)`, which stops the camera from sending more image data. Next, the flash is turned off using `ioctl(fd, VIDIOC_S_CTRL,&ctrl)` to ensure that additional power consumption is terminated. Then, all buffer resources previously requested for image capture are released, and the buffers are unmapped and the memory associated with them is released. The image signal processor (ISP) is turned off to stop its operation, and the device node file is closed through `close(fd)`, so that the camera hardware completes the power-off operation and completely disconnects from the system. This whole set of operations ensures the safe shutdown of the camera and the proper management of system resources, avoiding energy waste and potential hardware damage when not in use.

[0032] Unlike other solutions, this solution opens the camera and reads images only when it is needed, and closes the camera when not in use, which can reduce power consumption. In addition, the startup speed is deeply optimized. While benefiting from bypassing the abstract layer and framework layer, the cold start speed of the camera is also optimized to 35 milliseconds for initialization and 5 milliseconds for reading images, while the cold start initialization of the Android interface camera is 450 milliseconds and 40 milliseconds for reading. Therefore, even if the camera is turned on during cold start and then the image is read, it is better than the response speed of reading the image when the Android interface camera is always on. This not only solves the problem of high power consumption of the always-on camera, but also solves the problem of slow image output during cold start.

[0033] In this way, the application can bypass the Android architecture layer to start the camera more quickly and obtain images directly from the kernel camera driver, which ensures extremely low latency, stable frame rate, and reduced power consumption.

[0034] In the preferred setting method, the permission configuration of the camera device node is performed through the initialization script of the operating system. This setting method enables the application to access and control the camera without hindrance when needed, ensuring the efficient and safe use of the camera.

[0035] In the preferred method, the file operation function is used to open the camera device node file in a readable and writable state, and the camera device is initialized through this operation. Specifically, the `open()` function is used in conjunction with the `O_RDWR` flag to open the device node file pointing to ` / dev / video0`, for example, by executing `int fd = open(" / dev / video0", O_RDWR);`. This operation not only allows the application to read and write device nodes, but also marks the beginning of the initialization process of the camera hardware. The file descriptor `fd` is returned as the result of the operation, and this descriptor will be used for various control and data exchange operations later.

[0036] In a preferred method, initialization of the image signal processor (ISP) is performed immediately after the camera device node file is opened. This process is handled by a separate thread to avoid delaying the execution of the main program. For example, once the device node is successfully opened through `open(" / dev / video0", O_RDWR)` and the file descriptor `fd` is obtained, the system will start a new thread, such as created by the `pthread_create()` function, which is responsible for initializing the ISP. This thread will perform all necessary setup and configuration tasks to ensure that the image signal processor is fully ready before the camera starts capturing images, thereby improving the efficiency and quality of image processing. This instant initialization method helps to maximize the responsiveness and processing performance of image capture.

[0037] In the preferred method, once the image signal processor (ISP) is initialized, the system will use input / output control commands (ioctl) to set the camera's image resolution, format, and data length parameters. In this way, the application can process image data more efficiently and achieve high-performance image capture and processing functions. This step is performed after the image signal processor is fully ready to ensure that all image capture parameters are configured in the optimal state.

[0038] In the preferred method, the image capture process of the camera includes using an input / output control command (ioctl) to control the opening of the flash, and starting the image stream through the same command. For example, by executing the command of `ioctl(fd, VIDIOC_S_CTRL,&ctrl)`, the state of the flash can be controlled, where the `ctrl` structure defines whether the flash is turned on and other possible control parameters. Next, the image stream is started using the `ioctl(fd, VIDIOC_STREAMON,&type)` command, so that the camera begins to transmit a continuous stream of image data. These two steps ensure that sufficient lighting can be provided when additional light sources are required, and the camera can capture and transmit images smoothly, thereby improving image quality and capture efficiency. This control method simplifies the operation process using a unified command interface and enhances the flexibility and responsiveness of the system.

[0039] In the preferred method, the implementation of the continuous image reading interface involves the application continuously reading each frame of image data from the camera through the file descriptor when the scanning function button of the device is continuously pressed. After each frame of data is transmitted back to the Android application, the application performs corresponding processing according to the preset image processing flow, such as splicing, correction or analysis, so as to achieve efficient and continuous image scanning and processing functions. This method ensures that when the scanning task requires continuous image capture, the application can receive and process data in a timely manner, improving the scanning efficiency and quality.

[0040] In the preferred method, the operation of closing the image stream and flash is completed through the input / output control command (ioctl), and includes releasing all previously requested buffer resources. Specifically, the image stream is stopped using the `ioctl(fd, VIDIOC_STREAMOFF,&type)` command to ensure that the camera stops sending image data. At the same time, the flash is turned off through `ioctl(fd, VIDIOC_S_CTRL,&ctrl)`, where the `ctrl` structure is used to control the flash off. In addition, releasing the buffer resources involves canceling the buffer previously mapped through `mmap()` and calling the corresponding release command, such as `ioctl(fd, VIDIOC_REQBUFS,&req)`, where `req.count = 0` is set to notify the system to release all buffers. Such operations not only ensure the proper management and recycling of resources, but also help avoid resource leaks and maintain the stability and efficiency of the system. These steps together ensure that the camera can be safely and cleanly turned off when it is no longer needed.

[0041] Release all applied buffer resources and image signal processor ISP, close the device node, power off and turn off the camera; simulate the user turning on wireless wifi, Bluetooth, high brightness and other settings, use the resolution and image format required for the scanning pen to work, and perform stress testing in an office environment by pressing once for one hour and scanning continuously for one hour. This stress test is approximately equal to 4-8 times the frequency and time of normal user use of the device. After the stress test, there is no frame loss or dropped frame, and it can run stably at full frame rate.

[0042] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned device can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0043] The present application embodiment also provides an electronic device 600, such as Figure 3 As shown, it includes a memory 601, a processor 602, and a computer program 603 stored in the memory 601 and executable on the processor 602. When the processor 602 executes the computer program 603, the steps of the monitoring method for the electro-hydraulic jet machining process provided in the first aspect are implemented.

[0044] In applications, the electronic device may include, but is not limited to, a processor and a memory.

[0045] In applications, the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0046] In applications, the memory may be an internal storage unit of an electronic device in some embodiments, such as a hard disk or memory of the electronic device. In other embodiments, the memory may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device. The memory may also include both an internal storage unit and an external storage device of the electronic device. The memory is used to store operating systems, applications, boot loaders, data, and other programs, such as program codes of computer programs. The memory may also be used to temporarily store data that has been output or is to be output.

[0047] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0048] The present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of each of the above-mentioned method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk.

[0049] Those of ordinary skill in the art will appreciate that the devices and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0050] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices, which can be electrical, mechanical or other forms.

[0051] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A camera control method for an Android device, characterized in that: The control method comprises the following steps: When the system is initialized, set the read and write permissions of the system application for the camera device node; Use the file operation function to open the device node file of the camera, set it to a readable and writable state, and obtain the file descriptor; Call the camera's power-on initialization through the file descriptor; Create a thread to initialize the image signal processor and terminate the thread after the initialization is completed; Configure the camera's image resolution, format, and data length parameters through file descriptors; Request and register buffer for image buffer, control flash to turn on, and open image stream to start image capture process; Monitor the scanning function button of the device. When the button is pressed, start the continuous image reading interface, read the image frame through the file descriptor and copy it to the target address; Requeue the buffer for the next image frame read; When the camera is no longer needed, turn off the image stream and flash, release all requested buffer resources, turn off the image signal processor, and close the device node to complete the camera power-off operation.

2. The camera control method of an Android device according to claim 1, characterized in that: The setting of the camera device node includes configuring permissions through an initialization script of the operating system.

3. The camera control method of an Android device according to claim 1, characterized in that: The file operation function is used to open the camera device node file in a readable and writable state, and initialize the camera device through this operation.

4. The camera control method of an Android device according to claim 1, characterized in that: The initialization of the image signal processor is performed immediately after the camera device node file is opened.

5. The camera control method of an Android device according to claim 1, characterized in that: The method further includes setting image resolution, format and data length parameters using input / output control commands after the image signal processor is initialized.

6. The camera control method of an Android device according to claim 1, characterized in that: The image capture process of the camera includes controlling the flash to turn on using input / output control commands and starting the image stream through the same command.

7. The camera control method of an Android device according to claim 1, characterized in that: The method also includes, in the implementation of the continuous image reading interface, when the scanning function button of the device is continuously pressed, the application program continuously reads the data of each frame and returns the data to the Android application program for processing.

8. The camera control method of an Android device according to claim 1, characterized in that: Closing the image stream and flash is done through input / output control commands and includes releasing all requested buffer resources.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the camera control method of the Android device as described in any one of claims 1 to 8 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the camera control method of an Android device as described in any one of claims 1 to 8 is implemented.

Images