Detailed Description
The following description of the technical solutions in the embodiments of the present disclosure will be made clearly and completely with reference to the accompanying drawings in the embodiments of the present disclosure, and it is apparent that the described embodiments are only some embodiments of the present disclosure, not all embodiments. Based on the embodiments in this disclosure, all other embodiments that a person of ordinary skill in the art would obtain without making any inventive effort are within the scope of protection of this disclosure.
Fig. 1 is a schematic flow chart diagram illustrating a module processing method according to an embodiment of the present disclosure. The module processing method shown in the embodiment may be executed by a cloud server.
As shown in fig. 1, the module processing method may include the steps of:
in step S101, when a first target module is loaded into a kernel, determining whether the loaded system is a container android;
in step S102, if the loaded system is a container android, loading the first target module into the kernel is ignored;
the first target module is a module which can be initialized only once in the android system.
In step S101, when the system is about to load the first target module into the kernel, if it is determined that the system is a container android, the loading logic is ignored, that is, the first target module is not loaded into the kernel; and if the system is judged to be a host system, loading the first target module into a kernel.
The above procedure may be implemented based on the following code:
if [ -e /.dockerenv ];then
exit 0
Fi
in one embodiment, the first target module is a module that needs to be loaded into the kernel, and may include at least one of the following:
system_dlkm_modprobe.sh;
vendor_modprobe.sh。
both modules are loading kernel modules, and as the android system is containerized, the kernel and the modules are shared, logic judgment is added for the two parts, and only a host system (such as the android system) can be loaded, and the loading logic is ignored by the android container.
Before loading the first target module, the first target module needs to be initialized, and then hardware corresponding to the first target module is initialized, so that the host system and the android operation of each container need to initialize the hardware corresponding to the target module, and therefore multiple times of initialization of the hardware is needed.
However, for a Gao Tongan android system (for example, an android system running based on high-pass hardware), many hardware cannot be initialized multiple times due to hardware limitations, and then in the case that the host system is a Gao Tongan android system, at least one container android cannot be run in the host system by a docker technology.
Because the host system and the container android share the kernel and the modules loaded into the kernel, only the host system can load the first target module into the kernel in the scheme, and the container android ignores the loading logic when loading the first target module into the kernel, so that the host system is only required to initialize the first target module, the container android does not need to initialize the first target module, and therefore hardware corresponding to the first target module is guaranteed to be initialized only once, and the container android can still use the first target module to realize corresponding functions on the basis that the host system has loaded the first target module into the kernel.
It can be seen that, according to the embodiment of the present disclosure, for the first target module that can be initialized only once in the android system, only the host system can load the first target module into the kernel, and the container android ignores the loading logic, so that the initialization of the first target module is not triggered by the container android, and the hardware corresponding to the first target module is initialized only once, thereby avoiding the problem of initializing the hardware multiple times, and being beneficial to ensuring that the hardware supports at least one container android to run on the host system, that is, running multiple operating systems simultaneously.
In some embodiments, a user may enter an operational instruction on a terminal running a cloud application on multiple containers An Zhuoshang of an example system. For example, cloud applications can be run on each container android separately, thereby realizing multiple cloud applications.
For the cloud application in running, the instance system may collect a cloud application picture rendered by the cloud application and push the obtained video stream to the terminal, the terminal may watch the video picture of the cloud application on the browser or the installed APP (application), and input an operation instruction for the cloud application, where the operation instruction may be sent to the instance system to control running of the cloud application.
On the basis of the foregoing method embodiment, the module processing method may further include:
the function of the second target module is simulated by software.
In the related art, if the second target module is executed in each container android, there are a plurality of service processes accessing the hardware corresponding to the second target module, but for the Gao Tongan android system, the kernel does not support the existence of a plurality of service processes accessing the hardware, which results in that at least one container android cannot be executed in the host system.
The user is actually at the side of the remote equipment, and runs the cloud application on the instance system under the operation instruction of the remote equipment, so that the second target module in the instance system can be realized only by software simulation in the android container without multiple instantiations.
Specifically, the second target module includes at least one of:
a sound processing module;
a key library providing module;
logging in a password storage module.
For example, the sound processing module is audio. In the cloud application scenario, because the user does not need to play the application sound through hardware at the far-end device side, but pushes the application sound to the far-end device through a push flow mode, the audio-primary-default-so module can be replaced by the audio-primary-kalama-so module by using software simulation, so that the function of sound processing is realized by using the software simulation, and the audio data is pushed to the far-end device through the push flow mode, and the sound is not actually played through the hardware by using the sound processing module.
For example, the key library providing module is android, hardware, keymaster@4.0-strongbox-service-qti, and the module is responsible for providing a key library function, storing keys in high-pass proprietary hardware, in a cloud application scenario, the keys are not required to be stored by the proprietary hardware, and only need to be implemented by software simulation, so that the function of key processing is realized by using software to replace android, hardware, keymaster@3.0-service with the android, hardware, keymaster@4.0-strongbox-service-qti module to store keys.
For example, the login password storage module is android.hardware.gateway@1.0-service-qti, and the module is responsible for storing the user login password, and storing the user password in high-pass proprietary hardware. However, in the cloud application scenario, the user is password-free to log in, so that the login password does not need to be stored. Therefore, the software simulation is used for realizing the function of storing the login passwords by replacing the android.hardware.gatekeeper@1.0-service.software with the android.hardware.gatekeeper@1.0-service-qti module, and the login passwords are stored in a mode of storing the login passwords in hardware special for a non-high-pass android system.
It can be seen that, according to the embodiments of the present disclosure, for the second target module, the existing implementation is replaced in the container android through software simulation, so that there can be avoided a plurality of service processes accessing hardware corresponding to the second target module.
According to the scheme, through modifying the high-pass android system, for logic which cannot be initialized for multiple times, only one initialization is guaranteed, for the problem that multiple hardware access processes cannot coexist, a related module is replaced by using a software simulation mode, and the aim of coexistence of multiple android systems is fulfilled. The high-pass android system can be containerized, and multi-instance coexistence is realized.
Corresponding to the embodiments of the module processing module described above, the present disclosure also proposes embodiments of a module processing device.
Fig. 2 is a schematic block diagram of a modular processing apparatus shown in accordance with an embodiment of the present disclosure.
As shown in fig. 2, in some embodiments, the modular processing apparatus comprises:
the module processing module 201 is configured to determine, when a first target module needs to be loaded into the kernel, whether the first target module is a preset module;
the loading processing module 202 is configured to ignore recording the first target module into the kernel when the target is a preset module;
the container android runs in a host android, and the container android system and the host android system share a kernel.
In some embodiments, the first target module may include at least one of:
system_dlkm_modprobe.sh;
vendor_modprobe.sh。
in some embodiments, the apparatus may further comprise:
and the simulation module is used for simulating the function of the second target module through software.
In some embodiments, the second target module may include at least one of:
a sound processing module;
a key library providing module;
logging in a password storage module.
The implementation process of the module processing device provided by the embodiment of the application is consistent with the module processing method provided by the embodiment of the application, and the achieved effect is the same as that of the module processing method provided by the embodiment of the application, and is not described herein again.
Implementations of the present disclosure also propose a communication device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the method of any of the embodiments described above.
Implementations of the present disclosure also provide a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any of the embodiments described above.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.
It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.