WO2025232012A1 - Method for sharing input content among multiple systems, mobile terminal and storage medium - Google Patents

Abstract

Provided in the present invention are a method for sharing input content among multiple systems, a mobile terminal and a storage medium. The method comprises the steps of: pre-configuring a shell input method in an internal system, and creating an Epoll instance in an external system to monitor a shell input method invoking event and perform modification with respect to same, so as to invoke an external system API to launch an external system input method; creating an input file in the external system, storing content input by the external system input method, and, by means of an mmap method, mapping the input file into a shared memory; the internal system reading the input file in the shared memory, acquiring the input content, and transmitting same to the shell input method; and the shell input method invoking an internal system input method framework for interaction of the input content. Thus, Android virtual systems can share input methods of external systems to input content, thereby avoiding establishment of privacy information association among systems due to input methods.

Description

Methods for sharing input content between multiple systems, mobile terminals, and storage media Technical Field

This invention relates to Android virtual system technology, and more particularly to a method, mobile terminal, and storage medium for sharing the same input method input content between multiple systems inside and outside Android.

Background Technology

With the widespread adoption of smart terminals, the built-in operating systems, such as Android, can no longer meet users' increasingly complex privacy protection needs. To address this, existing technologies have proposed virtual Android systems to set up multiple operating systems within a single smart terminal, thereby catering to users' privacy protection needs in different usage scenarios.

However, existing Android multi-system solutions typically require separate installation of input methods in both the external system (main system) and the internal system (virtual system) to enable input functionality. However, some existing input method programs, for various reasons, often engage in behaviors that collect user privacy information, such as: collecting user input content, keyboard typing habits, obtaining sensitive information such as passwords, bank card information, and other information related to payment transaction security, monitoring user input behavior, and recording user input text content and search history.

In this way, this privacy information may actually lead to a connection between the external and internal systems, potentially exposing the actual users of the virtual system and rendering the privacy of the Android virtual system meaningless.

Summary of the Invention

Therefore, the main objective of this invention is to provide a method, mobile terminal, and storage medium for sharing input content among multiple systems, so that the Android virtual system can share the input method of an external system to input content, thereby avoiding the establishment of privacy information associations between different systems due to input methods.

To achieve the above objectives, according to one aspect of the present invention, a method for sharing input content among multiple systems is provided, comprising the steps of:

An empty shell input method is pre-installed in the internal system. An Epoll instance is created in the external system to listen for and modify the empty shell input method's initiation event, so as to call the external system API to launch the external system input method.

An input file is created on an external system to store the content entered by the external system's input method. The input file is then mapped to shared memory using the mmap method.

The internal system reads the input file in shared memory, obtains the input content, and passes it to the empty shell input method; the empty shell input method calls the internal system's input method framework to interact with the input content.

In a possible preferred implementation, an Epoll instance is created on an external system to listen for and modify the empty shell input method to initiate. The steps involved in triggering an external system input method by calling an external system API include:

Create an Epoll instance on an external system and create an Epoll handle using the Epoll_create function;

Files can be created and manipulated using Java's File class, and the file descriptor of the empty shell input method's initiation event can be obtained through either the FileInputStream or FileOutputStream class.

Register the file descriptor for the empty input method initiation event to Epoll;

The system listens for changes to the input method via an internal system broadcast receiver. When the input method package name obtained from the broadcast is determined to be an empty shell input method, and the current broadcast contains an input method initiation event, the current file descriptor is modified accordingly.

When the Epoll_wait function detects that the file descriptor of the empty input method that was previously registered with Epoll has undergone a signature modification, it calls the external system API to launch the external system input method.

In a possible preferred embodiment, the steps of creating an input file on an external system to store the content input by the external system's input method, and mapping the input file to shared memory using the mmap method include:

Use the FileOutputStream method to create an input file on an external system;

The input file is mapped into shared memory using the MappedByteBuffer method;

When an external system input method is invoked, the input content in its input box is directly written to the input file in shared memory using the put() method of MappedByteBuffer.

In a possible preferred embodiment, the step of the internal system reading the input file in shared memory to obtain the input content includes:

Use the FileOutputStream method to open the input file in shared memory;

Use the get() method of MappedByteBuffer to get the input content.

To achieve the above objectives, according to another aspect of the present invention, a method for sharing input content among multiple systems is also provided, comprising the steps of:

An empty shell input method is pre-installed in the internal system. An Epoll instance is created in the external system to listen for and modify the empty shell input method's initiation event, so as to call the external system API to launch the external system input method.

An input file is created on an external system to store the content input by the external system's input method after dictionary encoding. The input file is then mapped to shared memory using the mmap method.

The internal system reads the input file from shared memory, decodes the input content, and passes it to the empty shell input method; the empty shell input method calls the internal system's input method framework to interact with the input content.

In a possible preferred embodiment, an input file is created on an external system and stored according to dictionary encoding. The steps for mapping the input file from the system's input method to shared memory using the mmap method include:

Use the FileOutputStream method to create an input file on an external system;

The input file is mapped into shared memory using the MappedByteBuffer method;

When the input method of an external system is invoked, the input content in its input box is encoded according to a dictionary and then directly written to the input file in shared memory using the put() method of MappedByteBuffer.

In a possible preferred embodiment, the steps of the internal system reading the input file from shared memory and decoding the input content further include:

Use the FileOutputStream method to open the input file in shared memory;

Use the MappedByteBuffer method to read the encoded input content and decode it using a dictionary to restore the original text input content.

In a possible preferred implementation, the steps of creating an Epoll instance in the external system to listen for and modify the empty shell input method initiation event, in order to call the external system API to launch the external system input method, include:

Create an Epoll instance on an external system and create an Epoll handle using the Epoll_create function;

Files can be created and manipulated using Java's File class, and the file descriptor of the empty shell input method's initiation event can be obtained through either the FileInputStream or FileOutputStream class.

Register the file descriptor for the empty input method initiation event to Epoll;

The system listens for changes to the input method via an internal system broadcast receiver. When the input method package name obtained from the broadcast is determined to be an empty shell input method, and the current broadcast contains an input method initiation event, the current file descriptor is modified accordingly.

When the Epoll_wait function detects that the file descriptor of the empty input method that was previously registered with Epoll has undergone a signature modification, it calls the external system API to launch the external system input method.

To achieve the above objectives, corresponding to the above method examples, according to another aspect of the present invention, a mobile terminal is also provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the system implements the steps of the method for sharing input content among multiple systems as described above.

To achieve the above objectives, corresponding to the above method examples, according to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing a computer program, wherein when the computer program is executed, it implements the steps of the method for sharing input content between multiple systems as described above.

The method, mobile terminal, and storage medium for sharing input content between multiple systems provided by this invention solve the problem of transmission The Android platform addresses the issue of internal systems not being able to share input methods with external systems, thus preventing the establishment of privacy information associations between systems based on input methods and providing better privacy protection for internal systems. Furthermore, since internal systems will no longer need to install input methods independently, the possibility of loading malicious functions or monitoring user behavior through input methods is curbed, further enhancing the security of the Android virtual system.

Attached Figure Description

The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

Figure 1 is a schematic diagram of the steps of the method for sharing input content among multiple systems according to the present invention;

Figure 2 is a schematic diagram illustrating the concept of the method for sharing input content among multiple systems according to the present invention;

Figure 3 is a schematic diagram of the Epoll concept of the method for sharing input content among multiple systems according to the present invention;

Figure 4 is a schematic diagram of the implementation framework of the method for sharing input content among multiple systems according to the present invention.

Detailed Implementation

To enable those skilled in the art to better understand the technical solutions of the present invention, the specific technical solutions of the present invention will be clearly and completely described below in conjunction with embodiments, so as to help those skilled in the art further understand the present invention. Obviously, the embodiments described in this application are merely some embodiments of the present invention, and not all embodiments. It should be noted that, for those skilled in the art, the embodiments and features in the embodiments of this application can be combined with each other without departing from the concept of the present invention and without conflict. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the disclosure and protection scope of the present invention.

Furthermore, the terms "first,""second,""S100,""S200," etc., used in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such features can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those described herein. At the same time, the stages described in each step are not necessarily to be implemented in the same step; it should be understood that the implementation order of the contents of each step stage can be adjusted and interchanged without violating the inventive concept, so that embodiments of the invention described herein can be implemented in orders other than those described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. Unless otherwise expressly specified and limited, the terms "set,""arrange,""install,""connect," and "link" should be interpreted broadly, for example, referring to a fixed connection, a detachable connection, or an integral connection; a mechanical connection or an electrical connection; a direct connection or an indirect connection through an intermediate medium; or a connection within two elements. For those in the art... For a person skilled in the art, the specific meaning of the above terms in this case can be understood based on the specific circumstances and in conjunction with existing technology.

To enable Android virtual systems to share input methods from external systems and avoid establishing privacy information associations between systems based on input methods, as shown in Figure 2, this invention attempts to listen for input method initiation events in the internal system (virtual system) by creating an Epoll instance on the external Android system. When the internal system application wants to retrieve the input method for input, it invokes the empty shell input method installed on the internal system. Simultaneously, when the empty shell input method is invoked, it modifies the file containing the internal input method initiation event. Upon detecting a change in the file descriptor of the internal input method initiation event, the Epoll function is triggered to handle the input method initiation event. At this point, the system API is used to invoke its own input method. After input is completed, the input content is mapped to a specific address space of the process via mmap, achieving content sharing so that the internal system can also access the input content, thus completing the input method input loop.

As shown in Figures 1 to 4, the present invention provides a method for sharing input content among multiple systems, the example steps of which include:

Step S100: A shell input method is pre-configured in the internal system. An Epoll instance is created in the external system to listen for and modify the shell input method's initiation event, so as to call the external system API to launch the external system input method.

Specifically, the internal system's empty shell input method is an input method that does not have a specific input function. It only exists as an input method service within the system. For example, an input method can only bring up the input method interface.

In order to listen for the initiation event of the internal shell input method in the external Android system and call the corresponding external system API to launch the external system input method, the example steps include:

Step S110 creates an Epoll instance on the external system and creates an Epoll handle using the Epoll_create function.

As shown in Figure 3, Epoll is an improved version of poll in the Linux kernel for handling large numbers of file descriptors. It is an enhanced version of the select/poll multiplexed I/O interface in Linux, which can significantly improve the system CPU utilization when only a small number of connections are active amidst a large number of concurrent connections. Furthermore, when acquiring events, it does not need to traverse the entire set of monitored descriptors; it only needs to traverse the set of descriptors that have been asynchronously awakened by kernel I/O events and added to the Ready queue.

Epoll has two operating modes: LT (level triggered) and ET (edge-triggered). LT is the default mode and supports both blocking and non-blocking sockets. In this mode, the kernel notifies a file descriptor whether it is ready, and then I/O operations can be performed on that ready file descriptor. If no operation is performed, the kernel will continue to notify. ET (edge-triggered) is a high-speed mode that only supports non-blocking sockets. In this mode, when a file descriptor changes from not ready to ready, the kernel notifies it via Epoll and will not send any more ready notifications for that file descriptor until some operation causes it to no longer be ready (e.g., during transmission, reception, or...). An EWOULDBLOCK error occurs when the receiver fails to receive a request or when the amount of data sent and received is less than a certain amount. This can be simply understood as LT being level-triggered and ET being edge-triggered.

Step S120 uses Java's File class to create and manipulate files, and obtains the file descriptor of the empty input method's initiation event using either the FileInputStream or FileOutputStream class. Example code logic is as follows:

File inputMethodFile=new File("InputMethod_file.txt");

if(!customFile.exists()){customFile.createNewFile();}

//Get the file input stream and get the file descriptor

FileInputStreaminputStream=new FileInputStream(customFile);

int fileDescriptor=inputStream.getFD().getInt$().

Step S130 registers the file descriptor for the empty shell input method's initiation event with Epoll to listen for the event. Example code logic is as follows:

int inputMethodFd = ...; // File descriptor for the input method

EpollEvent event=new EpollEvent();

event.events = EPOLLIN;

event.data.fd=inputMethodFd;

Epoll_ctl(EpollFd,EPOLL_CTL_ADD,inputMethodFd,&event).

Step S140 listens for the ACTION_INPUT_METHOD_CHANGED (input method has been changed) broadcast through the internal system broadcast receiver. When the input method package name obtained from the broadcast is determined to be an empty shell input method, and the input method initiation event is heard in the current broadcast, the current file descriptor is modified for identification.

Specifically, since the internal system's input method cannot perform input functionality, after the internal system detects that the user wants to activate the input method, it modifies the file set in step S120. For example, it modifies the content class to change the input method mode, writing "inputmethodMode:open" into it. In fact, only this modification is needed. This created file is essentially just a record of an identifier and does not record the actual input content.

Because external systems cannot listen to the input method activation event of the internal system, this example uses the method described above to allow external systems to monitor the state of this file. This is equivalent to determining the state of the internal system's input method through modifications to the file, thus serving as a means of transmission of the monitoring information. The example code logic is as follows:

Step S150: When the Epoll_wait function detects that the file descriptor of the empty shell input method launch event that was previously registered in Epoll has undergone a distinctive modification, it calls the external system API to launch the external system input method.

The `Epoll_wait` function listens for a file. Internally, the system broadcasts a message indicating that the user's input method is modifying the file specified in step S120. Externally, the `Epoll` function registers the file descriptor for this file in step S130. Therefore, after step 140, when the specified file is changed, the external `Epoll_wait` function can detect the change and send a feedback. Example code logic is as follows:

Since the input method of an external system can only be invoked by the external system, when the Epoll_wait listener function detects that the system has modified the file for the input method invocation event, the Epoll handler function will be triggered, and the input method will be launched in the handler function.

For example, create an InputMethodManager object in an external system to manage input methods.

InputMethodManager imm=(InputMethodManager)

getSystemService(Context.INPUT_METHOD_SERVICE)

Then use the showSoftInput method to bring up the input method. Pass a View object as a parameter to specify the view that receives input: "imm.showSoftInput(view,0)".

Step S200 creates an input file on the external system to store the content input by the external system's input method, and maps the input file to shared memory using the mmap method.

Specifically, to achieve input transfer between internal and external systems, this example considers using shared memory, such as the mmap approach. mmap is a memory-mapped file method that maps a file or other object into the process's address space, establishing a one-to-one mapping between the file's disk address and a segment of virtual addresses in the process's virtual address space. After establishing this mapping, the process can read and write to this memory segment using pointers, and the system automatically writes dirty pages back to the corresponding file on disk, thus completing file operations without needing to call system calls like read and write. Conversely, modifications to this region in kernel space are directly reflected in user space, enabling file sharing between different processes.

In order to store the input content of the external system and share it in memory, this example includes the following steps:

Step S210 uses the FileOutputStream method to create an input file on an external system. This input file is used to store the specific input content of the input method. Example code logic is as follows:

String FILE_PATH="/data/com.example.xxx/input.txt";

FileOutputStream fileOutputStream=new FileOutputStream(FILE_PATH,true).

Step S220 maps the input file to shared memory using the MappedByteBuffer method to enable read and write operations in memory. MapMode is set to READ_WRITE. Example code logic is as follows:

int FILE_SIZE = 1024 * 1024; //File size

FileChannel channel=fileOutputStream.getChannel();

MappedByteBuffer buffer=channel.map(FileChannel.MapMode.READ_WRITE,0,FILE_SIZE).

Because the input box that actually displays the content is in the internal Android system, after the input method is invoked in the external system, an input box needs to exist in the external system to receive the input content, and then the content is stored in the created input file.

Step S230: When the external system input method is invoked, the input content in its input box is directly written to the input file in shared memory through the put() method of MappedByteBuffer.

At this point, since the file has already been mapped into memory, the content obtained by the input box of the external system input method can be directly written into memory. This step is achieved by using the put() method of MappedByteBuffer.

Furthermore, given that Chinese characters have some unique characteristics compared to the English alphabet, for example:

Chinese characters are a complex character set, and machines cannot directly recognize them because they can only recognize binary data, which can easily lead to garbled characters.

Chinese characters typically require more memory space to store because they occupy twice as many bytes as a single character. Writing large amounts of Chinese character data into memory can lead to excessive memory usage, thereby affecting system performance and stability.

Processing Chinese characters is generally more complex than processing English letters because Chinese characters may contain complex structures, polyphonic characters, and other characteristics. Therefore, when processing Chinese characters, more linguistic and cultural features need to be considered to ensure the correct processing and display of Chinese character data.

Therefore, to ensure both efficient transmission and content security, in the optional example, when dealing with Chinese character input, the input content can be encoded and stored. That is, when an external system input method is invoked, the input content in its input box is encoded according to a dictionary, and then directly written to the input file in shared memory using the `put()` method of `MappedByteBuffer`.

Specifically, in computer systems, text data is generally stored and transmitted in digital form. Character encoding maps Chinese characters and letters to numbers, making it easy to store text in computer memory for transmission.

Transmitting text and numbers directly within the system can lead to garbled characters or incorrect parsing. Directly transmitting large amounts of text data can consume significant system resources and network bandwidth, impacting system performance and response speed. This is especially true in the context of frequent reading and writing as an input method in this invention, where it is crucial to ensure that text data is accurately represented, processed, and transmitted within the computer system.

In this example, Unicode is first used to represent Chinese characters using numerical encoding. Unicode is a character encoding used on computers that assigns a unique binary code to each character in every language to meet the requirements of cross-language and cross-platform text conversion and processing.

Unicode uses the numbers 0-0x10FFFF to map these characters, and can hold a maximum of 1,114,112 characters, or 1,114,112 code points. A code point is a number that can be assigned to a character.

For example, the Unicode codes for "你好" are 20320 and 22909. After obtaining the Unicode numbers for the text, the numbers are converted by the program using the following conversion method:

Different length encodings are used for characters with different ranges. For the code point range obtained for "你好", both Chinese characters are determined to be 3 bytes. The code point of the character "你" (20320) is converted into the hexadecimal number 4F60. The four numbers are then separately decomposed into binary numbers: 0100 1111 0110 0000. The resulting sixteen numbers are placed into the format corresponding to the 3 bytes, replacing the x in the template, which will give three sixteen-bit numbers: 11100100 10111101 10100000. Converting these to hexadecimal gives E4 BD A0.

In this way, Chinese characters encoded according to Unicode will be represented as hexadecimal numbers of different lengths, and these numbers will be stored in a memory file. The storage code implementation is as follows: `buffer.put(input)`.

After writing content, you can manually refresh the memory mapping to ensure that the data is written to the file in a timely manner. This step can be achieved by using the `force()` method of `MappedByteBuffer`: `buffer.force()`. Finally, you need to close the memory mapping and the file, and release the resources using `channel.close()`.

In step S300, the internal system reads the input file in the shared memory, obtains the input content, and passes it to the empty shell input method; the empty shell input method calls the internal system input method framework to interact with the input content.

Specifically, the internal Android system's steps for obtaining input content include:

Step S310 uses the FileOutputStream method to open the input file in shared memory. Example code logic is as follows:

String FILE_PATH="/data/com.droi.xxx/input.txt";

FileOutputStream fileOutputStream=new FileOutputStream(FILE_PATH,true).

Step S320 uses the get() method of MappedByteBuffer to obtain the input content.

If the input content was previously encoded using the example above, then Chinese character decoding can be performed after reading the input content. The encoded byte sequence is converted to binary form. The first byte is read, and the binary sequence is parsed according to the encoding rules. Specifically, the number of bytes for the character is determined by the leading bit of the first byte. Then, based on the leading bit of the first byte, subsequent bytes are read sequentially. Each byte is assembled into the corresponding binary encoding value for the character. Finally, the corresponding Chinese character is found by referring to the Unicode dictionary table based on the encoding value, thus restoring the original input text content.

Afterwards, memory mapping and files are closed, resources are released, and the decoded text is passed to the empty input method and internal system. This is a shell-like input method that calls upon the internal system input method framework to display information such as input status and input content in the provided user interface, and interacts with the user. This enables an Android virtual system that can share input methods from external systems, thus avoiding the establishment of privacy information associations between different systems due to input methods.

On the other hand, corresponding to the above method examples, the present invention also provides a mobile terminal, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the system implements the steps of the method for sharing input content between multiple systems as described above.

On the other hand, corresponding to the above method examples, the present invention also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed, it implements the steps of the method for sharing input content between multiple systems as described above.

In summary, the method, mobile terminal, and storage medium for sharing input content between multiple systems provided by this invention solve the problem that internal systems on the traditional Android platform cannot share input methods from external systems. This avoids establishing privacy information associations between systems based on input methods, thereby providing better privacy protection for internal systems. Furthermore, since internal systems no longer need to install input methods independently, the possibility of loading malicious functions and monitoring user behavior through input methods is curbed, further enhancing the security of the Android virtual system.

The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The present invention is limited only by the claims and their full scope and equivalents. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Those skilled in the art will understand that, besides implementing the system, apparatus, unit, and its modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and its modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

Furthermore, all or part of the steps in the methods described in the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to... The processor executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage media include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Furthermore, various different implementations of the present invention can be combined arbitrarily, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed in the present invention.

Claims (10)

A method for sharing input content among multiple systems, comprising the following steps: An empty shell input method is pre-installed in the internal system. An Epoll instance is created in the external system to listen for and modify the empty shell input method's initiation event, so as to call the external system API to launch the external system input method. An input file is created on an external system to store the content entered by the external system's input method. The input file is then mapped to shared memory using the mmap method. The internal system reads the input file in shared memory, obtains the input content, and passes it to the empty shell input method; the empty shell input method calls the internal system's input method framework to interact with the input content. According to the method for sharing input content among multiple systems as described in claim 1, the step of creating an Epoll instance in the external system to listen to and modify the empty shell input method initiation event, so as to call the external system API to launch the external system input method, includes: Create an Epoll instance on an external system and create an Epoll handle using the Epoll_create function; Files can be created and manipulated using Java's File class, and the file descriptor of the empty shell input method's initiation event can be obtained through either the FileInputStream or FileOutputStream class. Register the file descriptor for the empty input method initiation event to Epoll; The system listens for changes to the input method via an internal system broadcast receiver. When the input method package name obtained from the broadcast is determined to be an empty shell input method, and the current broadcast contains an input method initiation event, the current file descriptor is modified accordingly. When the Epoll_wait function detects that the file descriptor of the empty input method that was previously registered with Epoll has undergone a signature modification, it calls the external system API to launch the external system input method. According to claim 1, the method for sharing input content among multiple systems, wherein the steps of creating an input file in an external system to store the content input by the external system's input method, and mapping the input file to shared memory using the mmap method, include: Use the FileOutputStream method to create an input file on an external system; The input file is mapped into shared memory using the MappedByteBuffer method; When an external system input method is invoked, the input content in its input box is directly written to the input file in shared memory using the put() method of MappedByteBuffer. According to claim 1, the method for sharing input content among multiple systems, wherein the step of the internal system reading the input file in shared memory to obtain the input content includes: Use the FileOutputStream method to open the input file in shared memory; Use the get() method of MappedByteBuffer to get the input content. A method for sharing input content among multiple systems, comprising the following steps: An empty shell input method is pre-installed in the internal system. An Epoll instance is created in the external system to listen for and modify the empty shell input method's initiation event, so as to call the external system API to launch the external system input method. An input file is created on an external system to store the content input by the external system's input method after dictionary encoding. The input file is then mapped to shared memory using the mmap method. The internal system reads the input file from shared memory, decodes the input content, and passes it to the empty shell input method; the empty shell input method calls the internal system's input method framework to interact with the input content. The method for sharing input content among multiple systems according to claim 5, wherein the steps of creating an input file in an external system to store the content input by the external system's input method after dictionary encoding, and mapping the input file to shared memory using the mmap method, include: Use the FileOutputStream method to create an input file on an external system; The input file is mapped into shared memory using the MappedByteBuffer method; When the input method of an external system is invoked, the input content in its input box is encoded according to a dictionary and then directly written to the input file in shared memory using the put() method of MappedByteBuffer. According to claim 5, the method for sharing input content among multiple systems, wherein the step of the internal system reading the input file in shared memory and decoding the input content further includes: Use the FileOutputStream method to open the input file in shared memory; Use the MappedByteBuffer method to read the encoded input content and decode it using a dictionary to restore the original text input content. According to the method for sharing input content among multiple systems as described in claim 5, the step of creating an Epoll instance in the external system to listen to and modify the empty shell input method initiation event, so as to call the external system API to launch the external system input method, includes: Create an Epoll instance on an external system and create an Epoll handle using the Epoll_create function; Files can be created and manipulated using Java's File class, and the file descriptor of the empty shell input method's initiation event can be obtained through either the FileInputStream or FileOutputStream class. Register the file descriptor for the empty input method initiation event to Epoll; The system listens for changes to the input method via an internal system broadcast receiver. When the input method package name obtained from the broadcast is determined to be an empty shell input method, and the current broadcast contains an input method initiation event, the current file descriptor is modified accordingly. When the Epoll_wait function detects that the file descriptor of the empty input method that was previously registered with Epoll has undergone a signature modification, it calls the external system API to launch the external system input method. A mobile terminal includes: a memory, a processor, and components stored in the memory and operable in the processor. A computer program running on a processor, wherein when the processor executes the computer program, the system implements the steps of the method for sharing input content between multiple systems as described in any one of claims 1 to 8. A computer-readable storage medium storing a computer program, wherein when executed, the computer program implements the steps of the method for sharing input content between multiple systems as described in any one of claims 1 to 8.