CN113342422A - Linux-compatible Android multi-application camera access method and device - Google Patents
Linux-compatible Android multi-application camera access method and device Download PDFInfo
- Publication number
- CN113342422A CN113342422A CN202110726449.6A CN202110726449A CN113342422A CN 113342422 A CN113342422 A CN 113342422A CN 202110726449 A CN202110726449 A CN 202110726449A CN 113342422 A CN113342422 A CN 113342422A
- Authority
- CN
- China
- Prior art keywords
- camera
- application
- linux
- android
- list
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/7243—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
- H04M1/72439—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for image or video messaging
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Human Computer Interaction (AREA)
- Business, Economics & Management (AREA)
- Multimedia (AREA)
- Studio Devices (AREA)
Abstract
The invention discloses a Linux-compatible Android multi-application camera access method and device, wherein a container is established on Linux, and a camera on the Linux side is mounted in the container; starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process; when the camera is monitored to be inserted, a camera frame service process of the Android system virtualizes a single camera into a front camera and a rear camera; when the Android application accesses the camera, the HAL layer adapts to use an idle camera for the Android application; the priority of the process of the application which is using the camera is compared with the priority of the process of the application which requests to use the camera, and the use of the camera is determined. The function that multiple apps access different cameras simultaneously is realized.
Description
Technical Field
The invention relates to the field of computer operating systems, in particular to a Linux-compatible Android-compatible multi-application camera access method and device.
Background
Since the Android application ecology becomes the largest application ecology in the world today, cross-platform operation of Android applications has become an industry trend. As is known, the problem of the Linux desktop operating system is that the application ecology is lacking, which also causes that the Linux desktop system cannot become the mainstream desktop operating system, so that the Android application is more and more accepted by the public to run on the Linux desktop system.
The Linux compatible Android environment is a technology for running Android applications (apps) on a Linux operating system, and has important significance for enriching the application ecology of the Linux operating system. The Linux compatible Android environment generally comprises a Host end and a Guest end, wherein the Host end runs on a Linux system and mainly comprises an Android container and a user interaction window, the Android container is used for isolating part of kernel resources from the Linux system to support the Guest end to run, the Guest end mainly comprises a specially customized Android application frame, an Android running library and the like, and Android applications run on the Guest end.
Unlike PC devices, mobile devices have only two cameras: the front camera of the same way, the rear camera of the same way, do not support USB port to expand more cameras moreover. The PC machine with the Linux operating system compatible with the Android environment is provided with the built-in camera, and can support more USB cameras through USB port external equipment. The existing Android technical framework does not support an external USB camera, so that the external USB camera of the PC cannot be fully utilized.
In the existing Android technology framework, after a camera is opened by one App, the camera framework service caches the camera ID (1 represents a front camera, 0 represents a rear camera) and the process PID, when a new camera opening request is accepted, the requested camera ID (1 represents a front camera and 0 represents a rear camera) is searched in a cache, if the camera ID (1 for front camera, 0 for rear camera) has been found in the cache, then proving that the camera has been opened, the previously opened camera will be closed, and a new request for opening the camera will be accepted, in the case of multiple front cameras and multiple rear cameras, the logic that the existing camera frame service judges whether to be opened or not only through the camera ID (1 represents the front camera and 0 represents the rear camera) results in that the multiple cameras cannot be opened at the same time.
In practice, a plurality of things are often done by using one camera, but the prior art is that: one camera can only be occupied by one application program, and when one application program uses the camera, all other application programs cannot use the camera.
Disclosure of Invention
In order to solve the problem that multiple Android applications can access multiple cameras at the same time in a Linux-compatible Android environment, the invention provides a Linux-compatible Android-compatible multi-application camera access method and device.
On one hand, the invention provides a Linux-compatible Android multi-application camera access method, which is applied to an operation environment compatible with an Android system in Linux, and comprises the following steps:
step S1: creating a container on Linux, and mounting a camera on the Linux side into the container; starting a container on Linux, and starting an Android system in the container;
step S2: starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process;
when the camera is monitored to be inserted, virtualizing a single camera into a front camera and a rear camera by a camera frame service process of the Android system, and informing the HAL layer of the information of the virtual front camera and the virtual rear camera through an interface by the camera frame service process so as to add the camera of the Linux system into a front camera information list and a rear camera information list of the HAL layer; the camera information list comprises a camera type id, a process priority of an application for opening the camera, a process number of the application for opening the camera and a camera name;
step S3: when the Android application accesses the camera, firstly analyzing and judging the type id of the camera accessed by the Android application as a front camera id or a rear camera id; judging whether an idle camera exists in a front camera information list or a rear camera information list of the HAL layer according to the name of the camera; if the idle camera exists, the HAL layer adapts to the use of the idle camera for the Android application; if no idle camera exists, comparing the priority of the process of the application using the camera with the priority of the process of the application requesting to use the camera, if the priority of the process of the application using the camera is high, the opening is failed this time, if the priority of the process of the application requesting to use the camera is high, closing the camera being opened, opening the camera for the application requesting to use the camera, and updating the opened camera information cache queue list.
Further, in step S2, the event that the camera framework service process monitors that the device under the/dev directory is plugged in or unplugged includes: when the equipment under the camera framework service process monitoring/dev directory is pulled out, the name of the pulled-out camera is notified to the HAL layer, and the HAL layer deletes the name of the pulled-out camera from the front camera list and the rear camera list.
Further, the event that the device under the camera framework service process monitoring/dev directory is plugged in or unplugged in step S2 is specifically: the insertion or extraction action of the camera is sensed by the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), IN _ CREATE represents that the camera is inserted, and IN _ DELETE represents that the camera is extracted.
Further, in step S2, when the camera is monitored to be inserted, the camera framework service of the Android system virtualizes a single camera into a front camera and a rear camera, and the camera framework service process notifies the HAL layer of information of the virtualized front camera and rear camera through an interface, including: when a camera is newly added, a camera framework service process notifies the HAL layer twice: and the HAL layer adds the camera information to a corresponding front camera list or a rear camera list according to the camera type.
Further, in step S3, if there is an idle camera, the adapting, by the HAL layer, the idle camera for the Android application includes: the HAL layer selects an idle camera from a front camera list or a rear camera list according to the type of the camera required by the Android application as a front camera or a rear camera; and marking the state of the selected camera in the front camera list or the rear camera list as being used, opening the camera, and storing the process number and the camera name of the application for opening the camera.
On the other hand, the invention provides a Linux-compatible Android multi-application access camera device, which is applied to an operation environment compatible with an Android system on Linux, and comprises the following components:
a container creation initiating unit for: creating a container on Linux, and mounting a camera on the Linux side into the container; starting a container on Linux, and starting an Android system in the container;
a virtual camera unit to: starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process;
when the camera is monitored to be inserted, virtualizing a single camera into a front camera and a rear camera by a camera frame service process of the Android system, and informing the HAL layer of the information of the virtual front camera and the virtual rear camera through an interface by the camera frame service process so as to add the camera of the Linux system into a front camera information list and a rear camera information list of the HAL layer; the camera information list comprises a camera type id, a process priority of an application for opening the camera, a process number of the application for opening the camera and a camera name;
an access camera unit to: when the Android application accesses the camera, firstly analyzing and judging the type id of the camera accessed by the Android application as a front camera id or a rear camera id; judging whether an idle camera exists in a front camera information list or a rear camera information list of the HAL layer according to the name of the camera; if the idle camera exists, the HAL layer adapts to the use of the idle camera for the Android application; if no idle camera exists, comparing the priority of the process of the application using the camera with the priority of the process of the application requesting to use the camera, if the priority of the process of the application using the camera is high, the opening is failed this time, if the priority of the process of the application requesting to use the camera is high, closing the camera being opened, opening the camera for the application requesting to use the camera, and updating the opened camera information cache queue list.
Further, the virtual camera unit is configured to: when the equipment under the camera framework service process monitoring/dev directory is pulled out, the name of the pulled-out camera is notified to the HAL layer, and the HAL layer deletes the name of the pulled-out camera from the front camera list and the rear camera list.
Further, the virtual camera unit is configured to: the insertion or extraction action of the camera is sensed by the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), IN _ CREATE represents that the camera is inserted, and IN _ DELETE represents that the camera is extracted.
Further, the virtual camera unit is configured to: when a camera is newly added, a camera framework service process notifies the HAL layer twice: and the HAL layer adds the camera information to a corresponding front camera list or a rear camera list according to the camera type.
Further, the access camera unit is configured to: the HAL layer selects an idle camera from a front camera list or a rear camera list according to the type of the camera required by the Android application as a front camera or a rear camera; and marking the state of the selected camera in the front camera list or the rear camera list as being used, opening the camera, and storing the process number and the camera name of the application for opening the camera.
Compared with the prior art, the invention has the following advantages:
according to the technical scheme provided by the invention, after the plurality of USB cameras are inserted into the PC host, each camera can be ensured to be operated by different applications, the function that the plurality of apps access different cameras simultaneously is realized, and the method and the device can be widely applied to scenes such as monitoring and split-screen conferences.
Drawings
Fig. 1 is a schematic diagram of a Linux-compatible Android multi-application camera access method provided by an embodiment of the present invention;
fig. 2 is a schematic diagram illustrating a Linux-compatible Android multi-application access camera device according to an embodiment of the present invention;
fig. 3 is a schematic diagram of a network architecture of a Linux-compatible Android virtual front camera and a Linux-compatible Android virtual rear camera provided in an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
For the operating environment compatible with Android running on the Linux operating system, the Android operating environment runs in a container.
Containers are a lightweight virtualization technology supported by the Linux kernel in recent years. A new Linux system (including other systems customized based on the Linux system, such as Android) can be operated in the Linux system through a container technology, and a client system and a host system are isolated from each other through the container. Different from the traditional scheme based on the virtual machine technology, in the container technology, the client system and the host system share resources such as a CPU (central processing unit), a memory, storage and the like, and the resource overhead is low. In addition, through proper configuration, the client system can directly access the hardware resource of the host, and the performance of the client system is further improved.
Due to the isolation effect of the container docker, Linux cannot access the internal storage directory of Android, and Android applications on Linux cannot directly access Linux-side files.
Fig. 1 is a schematic diagram of a Linux-Android-compatible multi-application access camera method provided by an embodiment of the present invention, and the method is applied in an operating environment where an Android system is compatibly operated on Linux, and includes the following steps:
step S1: creating a container on Linux, and mounting a camera on the Linux side into the container; starting a container on Linux, and starting an Android system in the container;
step S2: starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process;
when the camera is monitored to be inserted, virtualizing a single camera into a front camera and a rear camera by a camera frame service process of the Android system, and informing an HAL layer application abstraction layer of the information of the virtual front camera and the virtual rear camera through an interface by the camera frame service process so as to add the camera of the Linux system into a front camera information list and a rear camera information list of the HAL layer; the camera information list comprises a camera type id, a process priority of an application for opening the camera, a process number of the application for opening the camera and a camera name;
each node in the/dev directory of the Linux system describes an external device, when the external device is accessed, an external device descriptor is created in the directory, and when the device is removed, the node is deleted. Therefore, the USB camera plug-in and plug-out actions can be sensed by monitoring/dev directory through the inotify mechanism of Linux. inotify is a mechanism for notifying a user space program of a file system change by a next kernel of the Linux system.
IN the scheme, the insertion and extraction actions of the USB camera are mainly sensed through the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), the IN _ CREATE event indicates that the camera is inserted, and the IN _ DELETE indicates that the camera is extracted.
S201, monitoring the insertion and the extraction of a USB camera;
after the camera framework services the monitoring/dev directory, when a device is pulled out or deleted, the camera framework services can receive an event response, acquire a device name (a multimedia device, including a camera, and the front part of the device name is video) from an event structure inotify _ event, and combine the device name with the monitoring directory to form a complete device name (for example: dev/video 1).
S202, the Android system virtualizes each newly added USB device into a front camera and a rear camera;
in an Android system, an App can only operate a camera through an ID 0 (rear camera) or 1 (front camera), specifically, whether the front camera or the rear camera is opened is determined by the service of the App, only one or a plurality of USB cameras are inserted into a PC, and in order to meet the requirement that all apps can normally operate the cameras under various conditions, each external camera device needs to be split into one front camera and one rear camera, and it is guaranteed that the device can be operated by opening both the front camera and the rear camera after one USB camera is accessed.
When the USB camera is pulled out, the virtual process is not needed any more, and the name of the pulled USB camera is only needed to be notified to the HAL layer, so that the HAL layer deletes the given camera from the front camera list and the rear camera list.
S203, the HAL layer processes the newly added or deleted USB camera;
in order to realize multi-camera access, the HAL layer has two lists, a front camera list and a rear camera list, and each piece of information in the lists is a camera.
The camera service framework will transmit the camera information to the HAL layer, and the specific information includes:
newly adding information of the camera:
camera type (0: rear, 1: front), camera name (dev/video0, etc.), rotation angle (rear 90 degrees, front 270 degrees);
deleting the information of the camera:
camera name (dev/video0, etc.).
When a new camera is added, the HAL layer needs to add camera information to corresponding camera lists (a front camera list and a rear camera list) according to the type of the camera, and when the camera is added, the HAL layer is informed by the camera framework service twice, wherein the new rear camera is added once, and the new front camera is added once. When a camera is deleted, the camera framework service only needs to notify the HAL layer once, and the HAL layer retrieves and deletes the camera name (dev/video0, etc.) from the front camera list and the rear camera list while closing the camera that is being opened. And whether the camera information is deleted or added, the HAL layer informs the camera framework service to update the camera information after the camera information is updated.
Step S3: when the Android application accesses the camera, firstly analyzing and judging the type id of the camera accessed by the Android application as a front camera id or a rear camera id; judging whether an idle camera exists in a front camera information list or a rear camera information list of the HAL layer according to the name of the camera; if the idle camera exists, the HAL layer adapts to the use of the idle camera for the Android application; if no idle camera exists, comparing the priority of the process of the application using the camera with the priority of the process of the application requesting to use the camera, if the priority of the process of the application using the camera is high, the opening is failed this time, if the priority of the process of the application requesting to use the camera is high, closing the camera being opened, opening the camera for the application requesting to use the camera, and updating the opened camera information cache queue list.
The scheme of the prior art is as follows: an App opens a camera by transmitting a camera ID (0: rear camera, 1: front camera) to a camera service, and in the camera service, there is an opened camera equipment information cache queue list, and each piece of information in the queue includes: camera ID, App process ID (pid) to open the camera, and App process priority to open the camera (dynamically refreshable). And the front camera and the rear camera are limited to be opened by only one App at the same time through the camera ID. The Android system is mainly oriented to mobile equipment at present, and a front camera and a rear camera are only provided with one or more pieces of equipment. According to the technical scheme, the front camera and the rear camera are respectively provided with the plurality of devices, and in the prior art, whether the cameras are opened or not is judged through the camera ID, so that one of the plurality of cameras can be opened, and other cameras cannot be opened.
Further, in step S2, the event that the camera framework service process monitors that the device under the/dev directory is plugged in or unplugged includes: when the equipment under the camera framework service process monitoring/dev directory is pulled out, the name of the pulled-out camera is notified to the HAL layer, and the HAL layer deletes the name of the pulled-out camera from the front camera list and the rear camera list.
Further, the event that the device under the camera framework service process monitoring/dev directory is plugged in or unplugged in step S2 is specifically: the insertion or extraction action of the camera is sensed by the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), IN _ CREATE represents that the camera is inserted, and IN _ DELETE represents that the camera is extracted.
Further, in step S2, when the camera is monitored to be inserted, the camera framework service of the Android system virtualizes a single camera into a front camera and a rear camera, and the camera framework service process notifies the HAL layer of information of the virtualized front camera and rear camera through an interface, including: when a camera is newly added, a camera framework service process notifies the HAL layer twice: and the HAL layer adds the camera information to a corresponding front camera list or a rear camera list according to the camera type.
Further, in step S3, if there is an idle camera, the adapting, by the HAL layer, the idle camera for the Android application includes: the HAL layer selects an idle camera from a front camera list or a rear camera list according to the type of the camera required by the Android application as a front camera or a rear camera; and marking the state of the selected camera in the front camera list or the rear camera list as being used, opening the camera, and storing the process number and the camera name of the application for opening the camera.
The technical scheme of the invention can simultaneously process simultaneous access of a plurality of front-mounted and rear-mounted cameras, such as: the A application turns on the rear camera (camera ID: 0, App PID: 2001, device name:/dev/video 0), and the B application turns on the rear camera (camera ID: 0, App PID: 2002, device name:/dev/video 1).
The information of the front camera and the information of the rear camera are different from the single information of Android default, but are stored in a list form, the capacity of the list is not limited, and the information can be completely added into a front camera information list and a rear camera information list if a PC host is externally connected with a plurality of USB cameras, wherein each piece of information in the list comprises: device name (/ dev/video0, etc.), rotation angle (270 degrees front and 90 degrees rear), and usage status (1: 0 in use: idle). When the App operates the camera, the system can automatically select one idle device for the App to operate.
And after the HAL layer opens the camera, a cache list is used for recording the process number and the equipment name of the application for opening the camera, the equipment is set to be in a busy state, other applications cannot operate the equipment when opening the camera again, the equipment can be found according to the process number when the camera is closed after the service of the application camera is finished, the equipment is closed, and the equipment state in the front-end equipment list and the rear-end equipment list is set to be idle. The most central thing in this process is that when different apps operate the cameras, they search for the idle device in the front-facing camera information list or the rear-facing camera information list in a round-robin manner, and when the idle device is found, the idle device is directly opened, and the application process number and the device name of the device are recorded, so that the idle device is used for switching the front-facing camera and the rear-facing camera of the subsequent application and closing the camera.
It should be noted that the application needs to open a front camera or a rear camera, the application does not know which one of the lists needs to be opened, and the application only needs to know which one of the front camera or the rear camera needs to be opened, and cannot select which one of the front camera or the rear camera. Which device is turned on is adapted by the HAL layer.
Fig. 2 is a schematic view of a Linux-Android-compatible multi-application access camera device composition provided in an embodiment of the present invention, where the device is applied in an operating environment where an Android system is compatible to run on Linux, and the device includes:
a container creation initiating unit for: creating a container on Linux, and mounting a camera on the Linux side into the container; starting a container on Linux, and starting an Android system in the container;
a virtual camera unit to: starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process;
when the camera is monitored to be inserted, virtualizing a single camera into a front camera and a rear camera by a camera frame service process of the Android system, and informing the HAL layer of the information of the virtual front camera and the virtual rear camera through an interface by the camera frame service process so as to add the camera of the Linux system into a front camera information list and a rear camera information list of the HAL layer; the camera information list comprises a camera type id, a process priority of an application for opening the camera, a process number of the application for opening the camera and a camera name;
an access camera unit to: when the Android application accesses the camera, firstly analyzing and judging the type id of the camera accessed by the Android application as a front camera id or a rear camera id; judging whether an idle camera exists in a front camera information list or a rear camera information list of the HAL layer according to the name of the camera; if the idle camera exists, the HAL layer adapts to the use of the idle camera for the Android application; if no idle camera exists, comparing the priority of the process of the application using the camera with the priority of the process of the application requesting to use the camera, if the priority of the process of the application using the camera is high, the opening is failed this time, if the priority of the process of the application requesting to use the camera is high, closing the camera being opened, opening the camera for the application requesting to use the camera, and updating the opened camera information cache queue list.
Further, the virtual camera unit is configured to: when the equipment under the camera framework service process monitoring/dev directory is pulled out, the name of the pulled-out camera is notified to the HAL layer, and the HAL layer deletes the name of the pulled-out camera from the front camera list and the rear camera list.
Further, the virtual camera unit is configured to: the insertion or extraction action of the camera is sensed by the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), IN _ CREATE represents that the camera is inserted, and IN _ DELETE represents that the camera is extracted.
Further, the virtual camera unit is configured to: when a camera is newly added, a camera framework service process notifies the HAL layer twice: and the HAL layer adds the camera information to a corresponding front camera list or a rear camera list according to the camera type.
Further, the access camera unit is configured to: the HAL layer selects an idle camera from a front camera list or a rear camera list according to the type of the camera required by the Android application as a front camera or a rear camera; and marking the state of the selected camera in the front camera list or the rear camera list as being used, opening the camera, and storing the process number and the camera name of the application for opening the camera.
Fig. 3 is a schematic diagram of a network architecture of a Linux-compatible Android virtual front camera and a Linux-compatible Android virtual rear camera provided in an embodiment of the present invention. In the figure, each camera (including a built-in camera and a USB camera) on the Linux system is added to a front camera information list and a rear camera information list, that is, the Linux camera is virtualized into a camera that can be supported by the Android system, and the Android application can be selected from the lists when the front camera or the rear camera is opened, so that multiple options are available.
Finally, it should be noted that: although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that changes may be made in the embodiments and/or equivalents thereof without departing from the spirit and scope of the invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A Linux-compatible Android multi-application camera access method is applied to an operation environment compatible with an Android system on Linux, and comprises the following steps:
step S1: creating a container on Linux, and mounting a camera on the Linux side into the container; starting a container on Linux, and starting an Android system in the container;
step S2: starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process;
when the camera is monitored to be inserted, virtualizing a single camera into a front camera and a rear camera by a camera frame service process of the Android system, and informing the HAL layer of the information of the virtual front camera and the virtual rear camera through an interface by the camera frame service process so as to add the camera of the Linux system into a front camera information list and a rear camera information list of the HAL layer; the camera information list comprises a camera type id, a process priority of an application for opening the camera, a process number of the application for opening the camera and a camera name;
step S3: when the Android application accesses the camera, firstly analyzing and judging the type id of the camera accessed by the Android application as a front camera id or a rear camera id; judging whether an idle camera exists in a front camera information list or a rear camera information list of the HAL layer according to the name of the camera; if the idle camera exists, the HAL layer adapts to the use of the idle camera for the Android application; if no idle camera exists, comparing the priority of the process of the application using the camera with the priority of the process of the application requesting to use the camera, if the priority of the process of the application using the camera is high, the opening is failed this time, if the priority of the process of the application requesting to use the camera is high, closing the camera being opened, opening the camera for the application requesting to use the camera, and updating the opened camera information cache queue list.
2. The Linux-compatible Android multi-application access camera method of claim 1, wherein in the step S2, the event that the camera framework service process monitors the insertion or extraction of the device under the/dev directory comprises: when the equipment under the camera framework service process monitoring/dev directory is pulled out, the name of the pulled-out camera is notified to the HAL layer, and the HAL layer deletes the name of the pulled-out camera from the front camera list and the rear camera list.
3. The Linux-compatible Android multi-application access camera method of claim 1, wherein in the step S2, the event that the camera framework service process monitors the insertion or extraction of the device under the dev directory is specifically: the insertion or extraction action of the camera is sensed by the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), IN _ CREATE represents that the camera is inserted, and IN _ DELETE represents that the camera is extracted.
4. The Linux-compatible Android multi-application access camera method of claim 1, wherein in the step S2, when it is monitored that a camera is plugged in, a camera framework service of the Android system virtualizes a single camera into a front camera and a rear camera, and the camera framework service process notifies the HAL layer of information of the virtualized front camera and rear camera through an interface, including: when a camera is newly added, a camera framework service process notifies the HAL layer twice: and the HAL layer adds the camera information to a corresponding front camera list or a rear camera list according to the camera type.
5. The Linux-compatible Android multi-application access camera method of claim 1, wherein in the step S3, if there is a free camera, the HAL layer adapts to use the free camera for the Android application, including: the HAL layer selects an idle camera from a front camera list or a rear camera list according to the type of the camera required by the Android application as a front camera or a rear camera; and marking the state of the selected camera in the front camera list or the rear camera list as being used, opening the camera, and storing the process number and the camera name of the application for opening the camera.
6. A Linux-compatible Android multi-application access camera device is applied to an operating environment compatible with an Android system on Linux, and the device comprises:
a container creation initiating unit for: creating a container on Linux, and mounting a camera on the Linux side into the container; starting a container on Linux, and starting an Android system in the container;
a virtual camera unit to: starting a camera frame service process in an Android system, and monitoring an event that equipment under a dev directory is inserted or pulled out by the camera frame service process;
when the camera is monitored to be inserted, virtualizing a single camera into a front camera and a rear camera by a camera frame service process of the Android system, and informing the HAL layer of the information of the virtual front camera and the virtual rear camera through an interface by the camera frame service process so as to add the camera of the Linux system into a front camera information list and a rear camera information list of the HAL layer; the camera information list comprises a camera type id, a process priority of an application for opening the camera, a process number of the application for opening the camera and a camera name;
an access camera unit to: when the Android application accesses the camera, firstly analyzing and judging the type id of the camera accessed by the Android application as a front camera id or a rear camera id; judging whether an idle camera exists in a front camera information list or a rear camera information list of the HAL layer according to the name of the camera; if the idle camera exists, the HAL layer adapts to the use of the idle camera for the Android application; if no idle camera exists, comparing the priority of the process of the application using the camera with the priority of the process of the application requesting to use the camera, if the priority of the process of the application using the camera is high, the opening is failed this time, if the priority of the process of the application requesting to use the camera is high, closing the camera being opened, opening the camera for the application requesting to use the camera, and updating the opened camera information cache queue list.
7. The Linux-compatible Android multi-application access camera device of claim 6, wherein the virtual camera unit is to: when the equipment under the camera framework service process monitoring/dev directory is pulled out, the name of the pulled-out camera is notified to the HAL layer, and the HAL layer deletes the name of the pulled-out camera from the front camera list and the rear camera list.
8. The Linux-compatible Android multi-application access camera device of claim 6, wherein the virtual camera unit is to: the insertion or extraction action of the camera is sensed by the inertia _ add _ watch (fd, "/dev", "IN _ CREATE | IN _ DELETE"), IN _ CREATE represents that the camera is inserted, and IN _ DELETE represents that the camera is extracted.
9. The Linux-compatible Android multi-application access camera device of claim 6, wherein the virtual camera unit is to: when a camera is newly added, a camera framework service process notifies the HAL layer twice: and the HAL layer adds the camera information to a corresponding front camera list or a rear camera list according to the camera type.
10. The Linux-compatible Android multi-application access camera device of claim 6, wherein the access camera unit is to: the HAL layer selects an idle camera from a front camera list or a rear camera list according to the type of the camera required by the Android application as a front camera or a rear camera; and marking the state of the selected camera in the front camera list or the rear camera list as being used, opening the camera, and storing the process number and the camera name of the application for opening the camera.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110726449.6A CN113342422A (en) | 2021-06-29 | 2021-06-29 | Linux-compatible Android multi-application camera access method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110726449.6A CN113342422A (en) | 2021-06-29 | 2021-06-29 | Linux-compatible Android multi-application camera access method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113342422A true CN113342422A (en) | 2021-09-03 |
Family
ID=77481471
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110726449.6A Pending CN113342422A (en) | 2021-06-29 | 2021-06-29 | Linux-compatible Android multi-application camera access method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113342422A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113824888A (en) * | 2021-11-23 | 2021-12-21 | 北京鲸鲮信息系统技术有限公司 | Linux-compatible Android camera control method, system, device and medium |
| CN114047964A (en) * | 2022-01-13 | 2022-02-15 | 麒麟软件有限公司 | Method for enabling Android-supported camera to be hot-plugged when Linux is compatible with Android system |
| CN114185851A (en) * | 2022-02-14 | 2022-03-15 | 麒麟软件有限公司 | Method and system for android to access Linux local directory and file |
| CN114185508A (en) * | 2022-02-15 | 2022-03-15 | 麒麟软件有限公司 | Method for left-right screen splitting on Linux compatible android system |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101833520A (en) * | 2009-03-11 | 2010-09-15 | 凹凸电子（武汉）有限公司 | Method for simultaneously utilizing one camera by computer system and a plurality of application programs |
| CN112612536A (en) * | 2020-12-15 | 2021-04-06 | 麒麟软件有限公司 | Method and device for controlling camera shooting based on Android application program in Linux system |
| CN112749022A (en) * | 2019-10-29 | 2021-05-04 | 阿里巴巴集团控股有限公司 | Camera resource access method, operating system, terminal and virtual camera |
-
2021
- 2021-06-29 CN CN202110726449.6A patent/CN113342422A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101833520A (en) * | 2009-03-11 | 2010-09-15 | 凹凸电子（武汉）有限公司 | Method for simultaneously utilizing one camera by computer system and a plurality of application programs |
| CN112749022A (en) * | 2019-10-29 | 2021-05-04 | 阿里巴巴集团控股有限公司 | Camera resource access method, operating system, terminal and virtual camera |
| CN112612536A (en) * | 2020-12-15 | 2021-04-06 | 麒麟软件有限公司 | Method and device for controlling camera shooting based on Android application program in Linux system |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113824888A (en) * | 2021-11-23 | 2021-12-21 | 北京鲸鲮信息系统技术有限公司 | Linux-compatible Android camera control method, system, device and medium |
| CN113824888B (en) * | 2021-11-23 | 2022-06-17 | 北京鲸鲮信息系统技术有限公司 | Linux-compatible Android camera control method, system, device and medium |
| WO2023093715A1 (en) * | 2021-11-23 | 2023-06-01 | 北京字节跳动网络技术有限公司 | Camera control method, system and apparatus for achieving compatibility between linux and android, and medium |
| CN114047964A (en) * | 2022-01-13 | 2022-02-15 | 麒麟软件有限公司 | Method for enabling Android-supported camera to be hot-plugged when Linux is compatible with Android system |
| CN114185851A (en) * | 2022-02-14 | 2022-03-15 | 麒麟软件有限公司 | Method and system for android to access Linux local directory and file |
| CN114185508A (en) * | 2022-02-15 | 2022-03-15 | 麒麟软件有限公司 | Method for left-right screen splitting on Linux compatible android system |
| CN114185508B (en) * | 2022-02-15 | 2022-04-26 | 麒麟软件有限公司 | Method for left-right screen splitting on Linux compatible android system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113342422A (en) | Linux-compatible Android multi-application camera access method and device | |
| US11500670B2 (en) | Computing service with configurable virtualization control levels and accelerated launches | |
| US9990232B2 (en) | Quality of service tagging for computing jobs | |
| US7934220B2 (en) | Method and system for optimizing file table usage | |
| RU2629448C2 (en) | System and method of controlling and organizing web-browser cash | |
| US11755356B2 (en) | Asynchronous queries on secondary data cores in a distributed computing system | |
| CN109522029A (en) | A kind of method and device for disposing cloud platform technology component | |
| CN113596128B (en) | Resource synchronization method and system of multi-cloud platform and electronic equipment | |
| US11550713B1 (en) | Garbage collection in distributed systems using life cycled storage roots | |
| US20200364063A1 (en) | Distributed job manager for stateful microservices | |
| US11422698B2 (en) | Method, electronic device, and computer program product for storage management | |
| US20020174265A1 (en) | Method and apparatus for caching active computing environments | |
| US11593270B1 (en) | Fast distributed caching using erasure coded object parts | |
| US7979867B2 (en) | Managing a device in a distributed file system, using plug and play | |
| CN113448648A (en) | Linux-compatible Android camera access method and device | |
| US11029932B2 (en) | Hydration of applications | |
| EP3598310B1 (en) | Network interface device and host processing device | |
| US20140082275A1 (en) | Server, host and method for reading base image through storage area network | |
| CN112306669A (en) | Task processing method and device based on multi-core system | |
| US20220291975A1 (en) | Techniques for managing access to file systems | |
| Paiker et al. | Design and implementation of an overlay file system for cloud-assisted mobile apps | |
| US20230054696A1 (en) | User-level services for multitenant isolation | |
| CN110018782B (en) | Data reading/writing method and related device | |
| Ivanovic et al. | OpenStack cloud tuning for high performance computing | |
| CN110750221A (en) | Volume cloning method, volume cloning device, electronic equipment and machine-readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |