A camera control method, electronic device and storage medium for an Android device

Abstract

The present invention belongs to the field of electronic communication technologies, and specifically relates to a method for controlling a camera of an Android device, an electronic device, and a storage medium. The method includes setting the camera device node to have read-write permissions for system applications during system initialization. Opening the device node file through a file operation function, setting read-write permissions and obtaining a file descriptor. Performing power-on initialization of the camera through the descriptor, creating and ending a thread for initializing the image signal processor. Configuring the camera resolution, format, and data length, requesting and registering an image buffer, controlling the flash, and starting an image stream. Monitoring the scan function key, starting continuous image reading when pressed, reading and copying an image frame through the descriptor. Re-queuing the buffer for the next reading, closing the image stream and the flash, releasing buffer resources, and shutting down the processor and the device node to complete power-off after the process. This method bypasses the Android architecture, directly obtains images from the kernel driver, reduces latency, stabilizes the frame rate, and reduces power consumption.

Description

Technical Field

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

[0002] In modern mobile devices, the camera has become one of the indispensable components. Especially on the Android operating system platform, 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 the camera hardware, but there are some deficiencies.

[0003] First, when using the standard Android API interfaces for camera control, problems such as unstable frame rates often occur. This is because when the Android system schedules camera access, it may not be able to ensure that the camera operates at the maximum frame rate, resulting in frame drops or lost frames. 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 the user experience.

[0004] Second, in order to ensure the quick response of the camera, the application usually needs to keep the camera on for a long time, which leads to a significant increase in the power consumption of the device. In mobile devices, battery life is a major concern for users. Therefore, how to reduce power consumption while ensuring the quick response of the camera has become an urgent technical challenge.

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

[0006] (I) Technical Problems to be Solved

[0007] The present invention mainly aims at the above problems and proposes a camera control method, an electronic device, and a storage medium for an Android device. The purpose is to solve the problems of unstable frame rate, high power consumption, and response delay existing in the traditional Android device camera control method by directly obtaining images from the kernel camera driver.

[0008] (II) Technical Solutions

[0009] To achieve the above object, the first aspect of the present invention provides a camera control method for an Android device, which includes the following steps:

[0010] When the system is initialized, set the readable and writable permissions of the system application for the camera device node;

[0011] Use the file operation function to open the device node file of the camera, set it to the readable and writable state, and obtain the file descriptor;

[0012] Call the power-on initialization of the camera through the file descriptor;

[0013] Create a thread to initialize the image signal processor and end the thread after the initialization is completed;

[0014] Configure the image resolution, format, and data length parameters of the camera and set them through the file descriptor;

[0015] Request and register buffers for the image, control the flash to turn on, and open the image stream to start the image capture process;

[0016] Monitor the scan function key of the device. When the key is pressed, start the continuous image reading interface, read the image frame through the file descriptor and copy it to the target address;

[0017] Re-queue the buffer for the next image frame reading;

[0018] When the camera is no longer needed, close the image stream and the flash, release all the requested buffer resources, close the image signal processor, and close the device node to complete the power-off operation of the camera.

[0019] Further, the setting of the camera device node includes configuring permissions through the initialization script of the operating system.

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

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

[0022] Further, the method further includes setting the image resolution, format, and data length parameters using input / output control commands after the initialization of the image signal processor is completed.

[0023] Further, the image capture process of the camera includes using input / output control commands to control the flash to turn on and starting the image stream through the same command.

[0024] Further, the method further includes that in the implementation of the continuous image reading interface, when the scan function key 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.

[0025] Further, the operations of closing the image stream and the flash are completed through input / output control commands and include releasing all the buffer resources applied for.

[0026] To achieve the above object, a 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. When the processor executes the computer program, the camera control method of the Android device described above is implemented.

[0027] To achieve the above object, a third aspect of the present invention provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the camera control method of the Android device described above is implemented.

[0028] (III) Beneficial Effects

[0029] Compared with the prior art, a camera control method, an electronic device, and a storage medium for an Android device provided by the present invention directly interact with the kernel image subsystem, bypassing the Android abstraction layer and framework layer, thereby significantly improving the frame rate stability, reducing power consumption, and reducing the response time. By directly controlling the camera from the underlying hardware, the present invention can achieve rapid power-on and initialization of the camera, provide continuous and stable image capture, and reduce frame loss caused by improper system scheduling. In addition, this method only activates the camera and related resources when needed, greatly reducing the energy consumption of the device in the non-use state. This fast response and low-power design are 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

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

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

[0032] Figure 3 It is a framework diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0033] The present invention will be described in detail below with reference to the drawings. The technical solutions in the embodiments of the present invention are clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0034] As Figure 1 , Figure 2 shown, the present invention provides a camera control method for an Android device, which method includes three parts: initialization startup, continuous image reading, and shutdown. The specific steps are as follows:

[0035] Step S100: At system initialization, set the readable and writable permissions of the camera device node for system applications;

[0036] When the system sets the readable and writable permissions for the camera device node during the initialization phase, it is mainly to ensure that system applications can smoothly access and control the camera. This is achieved by modifying the system startup script (such as the init.rc file), which contains commands to change the permissions of specific device nodes (usually ` / dev / video0`). For example, a command `chmod 0666 / dev / video0` can be added, thus setting the camera device node to a readable and writable state, enabling applications to open and operate the camera through file operations.

[0037] Step S200: Use file operation functions to open the device node file of the camera, set it to a readable and writable state, and obtain a file descriptor;

[0038] Use file operation functions such as `open()` to open the device node file of the camera (usually ` / dev / video0`), and set it to a readable and writable state (using the flag `O_RDWR`). For example, calling `int fd =open(" / dev / video0", O_RDWR);` not only opens the device node file but also ensures that system applications 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 for interacting with the camera hardware, such as setting the image format and controlling the image stream.

[0039] Step S300: Call the power-on initialization of the camera through the file descriptor;

[0040] Utilize the file descriptor (fd) obtained in the previous step to execute 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, by executing a command like `ioctl(fd, VIDIOC_S_POWER, ON)`, it is indicated that the camera transitions from the power-off state to the power-on state. This step ensures that the camera hardware is correctly activated and is a crucial link for preparing for image capture and data transmission.

[0041] Step S400: Create a thread to initialize the image signal processor and end the thread after initialization is completed;

[0042] Create a new thread dedicated to initializing the Image Signal Processor (ISP) for an independent task to optimize image processing. For example, a thread can be created through programming by executing a command like `pthread_create(&thread_id, NULL, initialize_ISP, NULL)` to start the thread. After starting, the thread will execute relevant initialization code to configure and optimize the ISP settings. Once completed, the thread will end. This ensures that the main process of camera initialization is not delayed due to ISP configuration and guarantees the efficiency and quality of image processing.

[0043] Step S500: Configure the image resolution, format, and data length parameters of the camera and set them through the file descriptor;

[0044] Configure the image resolution, format, and data length parameters of the camera, which are set through the previously obtained file descriptor. The specific operation is achieved through the `ioctl()` function. For example, execute `ioctl(fd, VIDIOC_S_FMT, &fmt)` to set the image format and resolution of the camera. Here, `fmt` is a structure that contains the resolution, image format (such as JPEG, YUV, etc.), the width and height of the image, and other relevant parameters. This step ensures that the image data output by the camera meets the application requirements and the expected effects of subsequent image processing, thereby improving the overall image quality and processing speed.

[0045] Step S600: Request and register buffers for image buffering, control the flash to turn on, and open the image stream to start the image capture process;

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

[0047] Step S700: Listen for the scan function key of the device. When the key is pressed, start the continuous image reading interface, read the image frame through the file descriptor and copy it to the target address;

[0048] Trigger the image capture process by listening for the scan function key on the device. When the scan function key is pressed by the user, the system starts the continuous image reading interface, which is achieved through a file descriptor (fd). The specific operations include 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 via `memcpy(des, buf, buf.length)` for subsequent processing. After that, the buffer is re-queued using `ioctl(fd, VIDIOC_QBUF, &buf)` to prepare for capturing the next frame of the image. This process will continue to execute while the key is held down, ensuring the capture and transmission of continuous images, thus supporting the efficient operation of the scanning device.

[0049] Step S800: Re-queue the buffer for the next image frame reading;

[0050] Requeue the buffer to ensure that image frames can be continuously read. This operation is accomplished through a file descriptor (fd) and an `ioctl()` call, specifically using the command `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 returns to the queue waiting for the camera to write data. This is a cyclic process that ensures that the application can continuously receive new image frames during continuous scanning operations by the user, thus enabling smooth image capture and processing.

[0051] Step S900: When the camera is no longer needed, close the image stream and the flash, release all requested buffer resources, turn off the image signal processor, and close the device node to complete the power-down operation of the camera.

[0052] When the camera is no longer needed, a series of operations are performed to close and release resources. First, the image stream is closed via `ioctl(fd, VIDIOC_STREAMOFF, &type)`, which stops the camera from sending more image data. Then, the flash is turned off using `ioctl(fd, VIDIOC_S_CTRL, &ctrl)` to ensure that additional power consumption is terminated. Next, all buffer resources requested for image capture are released, unmapping the buffers and freeing the associated memory. The image signal processor (ISP) is turned off to stop its operation, and the device node file is closed via `close(fd)`, causing the camera hardware to complete the power-down operation and disconnect completely from the system. This entire 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.

[0053] Different from others, this solution opens the camera and reads images only when needed, and closes the camera when not in use, which can reduce power consumption; moreover, deep optimization has been done on the startup speed. Thanks to bypassing the abstraction layer and the framework layer, the cold start speed of the camera has been optimized to 35 milliseconds for initialization and 5 milliseconds for reading, while the cold start of the Android interface camera is initialized at 450 milliseconds and reads at 40 milliseconds. Therefore, even when the camera is cold-started and then the image is read, it is superior to the response speed of reading images in the state of always-on Android interface cameras, solving both the problem of high power consumption of always-on cameras and the problem of slow image output during cold start.

[0054] By this method, the application can bypass the Android architecture layer and start the camera more quickly, directly obtaining images from the kernel camera driver, which not only ensures extremely low latency but also ensures the stability of the frame rate and can reduce power consumption.

[0055] In the preferred setting method, the permission configuration of the camera device node is carried out through the initialization script of the operating system. This setting method enables the application program to access and control the camera unobstructed when needed, ensuring the efficient and secure use of the camera.

[0056] 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 initialization of the camera device is achieved 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 program to read and write the device node, but also marks the start of the initialization process of the camera hardware. The file descriptor `fd` is returned as the operation result, and this descriptor will be used for various control and data exchange operations subsequently.

[0057] In the preferred method, the initialization of the Image Signal Processor (ISP) is executed immediately after the camera device node file is opened. This process is handled by an independent thread to avoid delaying the execution of the main program. For example, once the device node is successfully opened via `open(" / dev / video0", O_RDWR)` and the file descriptor `fd` is obtained, the system will start a new thread, created through the `pthread_create()` function for instance, specifically responsible for initializing the ISP. This thread will execute all necessary setting 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 immediate start of the initialization helps to maximize the response speed and processing performance of image capture.

[0058] In the preferred method, once the initialization of the Image Signal Processor (ISP) is completed, the system will use the Input / Output Control command (ioctl) to set the image resolution, format, and data length parameters of the camera. In this way, the application program can process the image data more efficiently, achieving high-performance image capture and processing functions. This step is carried out after the Image Signal Processor is fully ready to ensure that all image capture parameters are configured in an optimal state.

[0059] In a preferred method, the image capture process of the camera includes using input / output control commands (ioctl) to control the flash to turn on and starting the image stream through the same command. For example, by executing the command `ioctl(fd, VIDIOC_S_CTRL, &ctrl)`, the state of the flash can be controlled, where the `ctrl` structure defines whether to turn on the flash and other possible control parameters. Then, the command `ioctl(fd, VIDIOC_STREAMON, &type)` is used to start the image stream, so that the camera begins to transmit a continuous image data stream. These two steps ensure that sufficient illumination can be provided in case additional light sources are needed, and the camera can smoothly capture and transmit images, thereby improving image quality and capture efficiency. This control method simplifies the operation process using a unified command interface, enhancing the flexibility and response speed of the system.

[0060] In a preferred method, the implementation of the continuous image reading interface involves continuously reading the image data of each frame from the camera through the file descriptor by the application when the scan 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 stitching, correction, or analysis, etc., so as to achieve efficient and continuous image scanning and processing functions. This method ensures that when the scan task requires continuous image capture, the application can receive and process data in a timely manner, improving the scan efficiency and quality.

[0061] In a preferred method, the operations of closing the image stream and the flash are completed through input / output control commands (ioctl) and include releasing all previously allocated buffer resources. Specifically, the command `ioctl(fd, VIDIOC_STREAMOFF, &type)` is used to stop the image stream, ensuring 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 to turn off. In addition, releasing the buffer resources involves canceling the previously mapped buffer 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.

[0062] Release all the buffer resources and image signal processor (ISP) of the application, close the device node, and power off the camera; simulate the settings of the user to turn on wireless Wi-Fi, Bluetooth, high brightness, etc., and use the resolution and image format required for the operation of the scanning pen. Conduct a stress test by pressing once for one hour and continuously scanning for one hour in an office environment. This stress test is approximately 4 to 8 times the normal usage frequency and time of the user. After the stress test, there is no frame loss, and it can run stably at full frame rate.

[0063] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, 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. Each functional unit and module in the embodiment can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of this application. The specific working process of the units and modules in the above device can refer to the corresponding process in the foregoing method embodiment and will not be elaborated here.

[0064] The embodiment of this application also provides an electronic device 600, as Figure 3 shown, including 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, it implements the steps of the monitoring method for the electro-hydraulic beam machining process provided in the first aspect.

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

[0066] In applications, the processor can be a central processing unit (CPU), and this processor can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or this processor can also be any conventional processor, etc.

[0067] In an application, 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. The memory may also be an external storage device of the electronic device in other embodiments. For example, 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 an operating system, application programs, a BootLoader, 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 will be output.

[0068] An embodiment of the present application also provides a computer-readable storage medium storing a computer program, which when executed by a processor can implement the steps in the above method embodiments.

[0069] The implementation of all or part of the processes in the above method embodiments of the present application can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps in the above method embodiments can be implemented. Among them, the computer program includes computer program codes, and the computer program codes can be in the form of source code, object code, executable files, or some intermediate forms, etc. The computer-readable medium may at least include: any entity or device capable of carrying the computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk, or an optical disc, etc.

[0070] Those of ordinary skill in the art can realize that the devices and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0071] 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 merely illustrative. Additionally, the couplings or direct couplings or communication connections shown or discussed among each other can be through some interfaces. The devices are indirectly coupled or communication-connected, which can be in electrical, mechanical, or other forms.

[0072] The above-described embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments or perform equivalent replacements for some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate 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 power-off operation of the camera; 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.

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 initialization of the image signal processor is performed immediately after the camera device node file is opened.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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 7 is implemented.

9. 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 7 is implemented.

Images