Android uses the Root permission to simulate global buttons and touch-screen events in the background (similar to the press-key wizard). Android root

Android uses the Root permission to simulate global buttons and touch-screen events in the background (similar to the press-key wizard). Android root
Android uses the Root permission to simulate global buttons and touch screen events in the background (similar to the button pushing wizard)

Sometimes we need to use android to simulate system buttons in the background, such as adjusting the volume (simulating the volume Key), closing the App running on the foreground (simulating the return key), or simulating a touch screen event. However, for a native Android system, background processes do not comply with the system security principles when they shut down foreground processes or even simulate user events to manipulate the entire system, if such a vulnerability is exploited by viruses or malware, it is very dangerous.
For some special reasons, I happen to need to implement this function, but I don't have the conditions to compile the Android system on my own (but I can use the Root permission because it is much easier to obtain the Root permission, in addition, many Android devices have Root users ). Many people have asked similar questions on the Internet. Many people have discussed the issue for a long time and the results are unsolvable. So I spent a lot of energy and finally found a solution.
I found a lot of information on the Internet, mainly in two ways: Instrumentation and IWindowManager.

Using the Instrumentation interface: for Android systems that are not self-compiled, you cannot obtain the system signature. You can only simulate the buttons on the foreground, not the background simulation.

One is to use the Instrumentation interface, which was originally used to test the software. After trying, it is found that this interface can simulate the button, but the premise is that when the application is on the frontend. When the application is on the frontend, the simulated button basically does not play much role (the simulated button operation application does not seem to be of great significance ).
When the application is in the background, this Instrumentation interface becomes invalid. The explanation on the internet is that using this interface in the background requires system permissions, that is, adding android: sharedUserId = "android. uid. system" to Manifest ". What problems will this cause? An APK with system permissions declared can be installed on Android devices only when it has a system signature. For example, the phone number and text message provided by the system are essentially the APK program, however, these applications have system permissions.
Android has a signature mechanism. APK can be installed only when it has a digital signature. Usually, Eclipse automatically signs it by default during debugging, and uses the Debug signature. When releasing an application, the developer uses his/her own digital signature file to sign the APK (this file can be generated using Eclipse, and the signature can be completed by Eclipse ). When a new version of APK is installed, if the signature is detected to be inconsistent, the system will prompt that the signature is inconsistent. Only the old version can be installed after it is uninstalled. To a certain extent, this mechanism avoids third parties from modifying or even illegally embedding viruses on officially published APK (of course, if users take the initiative to uninstall the official applications of the old version and install the new version of unofficial APK ). Different apps with the same signature can share some data.
How can we obtain the system signature? When compiling the Android system, a digital signature file signed by the system is put together for compilation. For a compiled system or to adapt to different systems, the digital signature file cannot be obtained, and the APK cannot be signed by the system. Finally, the APK with the uid. system attribute cannot be installed. Therefore, the Instrumentation interface can only be used when the system is compiled.

Call using the Reflection MethodSystem IWindowManager hidden APIs: poor compatibility, poor stability, and error-prone. In addition, an error occurs during actual compilation. the cause is unknown.
There is also a method on the Internet. There are some hidden APIs in Android, which are usually restricted by Java permissions, so that these Apis cannot be called. However, through reflection, you can break through Java's permission restrictions. In IWindowManager, APIs that can simulate buttons and touch-screen events are hidden. Try the method on the internet, download it to a jar file compiled by Android source code, add it to the project, write some code using the launch, and try to call the hidden API. The result is that Eclipse does not respond directly during compilation, probably because the computer configuration is insufficient and the jar file is too large. I tried this method several times but failed. Considering that this method has many drawbacks, and it is very likely that system permissions are still needed (many articles on the Internet are not very clear ), so I gave up this method.
Android simulated button problem summary [using IWindowManager. injectKeyEvent method]
Http://blog.csdn.net/xudongdong99/article/details/8857173
Using hidden APIs in Android (a large number of illustrations)
Http://163liufuliang.blog.163.com/blog/static/331651862013119114431760/

JNI calls the C program simulated button: it is still a permission issue.
Based on the possible ideas put forward by some materials on the Internet, we found that the remaining method we can think of is to use JNI to simulate buttons by calling the C/C ++ program. I am not familiar with the underlying programming of Linux. I have referenced some code on the Internet and compiled a key simulation program under Ubuntu, which is successfully compiled and run. Then I began to learn how to compile JNI. I first wrote a simple addition operation on the C program layer, compiled and run the test, and then pasted the code of the simulation button. Android Java-layer code compilation, downloading, and execution are very promising, but no effect is found.
I want to see which step is wrong. I changed it in the C program and printed the return value of the C program using LogCat. I found that an error occurred when I opened the key device, it seems that it is a permission issue again.
Even though the system has Root and APK permission, the Root permission cannot be passed to the C program, and the program cannot be executed due to insufficient permissions. I found a piece of information about Linux and Android permissions on the internet, and I didn't find any idea. In fact, I was confused that in Linux, the Root permission is the highest permission, and Android is no exception. Some Articles have pointed out that the Root permission> system permission> User permission. Although the Root permission can be obtained, the tasks that the system permission can do are not possible.

Android press-key genie: it is feasible to simulate buttons, touch screens, and other events in the background using Root permissions without system signatures.
At that time, I felt very desperate. It was estimated that only the self-compiled system could solve the problem. At that time, I suddenly remembered the key-pushing genie software. I used a computer version before. I found it in the Android Market and it actually has an Android version. Download and usage discovery: The click-On Wizard can simulate button operations in the background and requires Root permissions. However, it is unclear what the principle is. I tried to decompile the source code, but some problems occurred at the time and the decompilation was not successful. In addition to the previous two types of APIs that can be used only by the source code environment, you cannot find the results of searching for the android shortcut. However, it should at least be explained that it is feasible to use the Root permission without the system signature, to simulate keys, and to be compatible with a large number of Android devices.

Final Solution: use Shell to call the ADB command.
Continue searching for Android key simulation on the Internet (in fact, I didn't know what keywords to use at that time, and all the keywords I could think of were used, but the search results were, these are the solutions that depend on the source code environment and system permissions mentioned earlier ). I found many articles about ADB debugging and sending button events to mobile phones. I used Java to call the underlying Linux Shell of Android with the Root permission, and then run the pm command to install and uninstall the APK. In this case, I was wondering if I could use Shell to call the ADB command?
Therefore, I tried to use Java to execute runtime.getruntime(cmd.exe c ("su "). getOutputStream (), which obtains the output stream object of a Process with Root permissions. Writing strings to it can be executed by Shell with Root permission, the ADB analog key command is "input keyevent keyCode", and the keyCode is the key value of the key, for example, KeyEvent. KEYCODE_VOLUME_UP indicates that the volume is increased.
After compiling the program and installing and executing the program, we finally achieved the expected results. At that time, we were very happy. For touch screen or mouse events, you only need to call the corresponding ADB command. However, one problem is that the response speed is very slow, especially when simulating multiple buttons consecutively, and even crashes. The key-pushing wizard is quite smooth, and I began to wonder how the key-pushing Wizard was implemented.
Later, the original cause is also found. During the simulation of the press Key, runtime.getruntime(cmd.exe c ("su") is used for every call, because every time this code is called, The Runtime instance will be obtained and the Root permission will be executed for the "su" request, the response will be slow (my understanding is that it is equivalent to opening a new command line window every time); instead, it should be executed only once at the beginning and get an OutputStream instance, later, every time you run a Shell command, you only need to write the corresponding string to it, which is much faster.
The following shows the available code. The device must be Root and no other special permissions or signatures are required. Because the ADB command is used, the compatibility will not be too high. When runtime.exe c ("su") is executed, the Root permission is requested.

/*** Use root permission to execute Shell commands in Linux *  * @author jzj * @since 2014-09-09 */public class RootShellCmd {private OutputStream os;/*** Execute shell commands *  * @param cmd* Command */public final void exec(String cmd) {try {if (os == null) {os = Runtime.getRuntime().exec("su").getOutputStream();}os.write(cmd.getBytes());os.flush();} catch (Exception e) {e.printStackTrace();}}/*** Simulate global buttons in the background *  * @param keyCode* Key value */public final void simulateKey(int keyCode) {exec("input keyevent " + keyCode + "\n");}}

The main purpose of writing this article is not to emphasize the difficulty of this issue, nor to propose a solution to the problem (so there is no need to write so many processes above ). I want to write the complete process of solving the problem. It is a record for me. For readers, I may find something from it.
After solving this problem, I accidentally discovered that someone had actually solved the problem and posted a blog. Unfortunately, the blog was buried by a lot of blogs that used the first two ideas. At that time, I could not find it. This blog address is here:
Http://blog.csdn.net/aminfo/article/details/7785975
By the way, the author mentioned in this blog is slow in response. As mentioned above, I have encountered the same problem and provided a solution.
This article by PurpleSword (jzj1993) original, reproduced please indicate the original web site http://blog.csdn.net/jzj1993
Android platform, recording operations, and timed playback tools, similar to buttons

Are you using a mobile phone press? It's not a mobile phone version of the key genie, right? The mobile phone version of the press Key genie is also programmed with a computer, to connect the mobile phone to the computer, like a mobile assistant. Write scripts on the computer and then run them on the mobile phone. The name is the mobile phone button. And now in the beta phase, of course, because of relatively new software, will not be game harmony. You need to use it. You can go to the internal test group of the mobile phone buttons officially found by the click-Button wizard, which contains.

Meizu MX does not use ROOT software similar to the push key genie

Hello,
The key control software must be ROOT. The firmware of meizu MX in flyme1.1.7 cannot be root. You can update the latest MX system (with the built-in ROOT option) Metadata.

Meizu enterprise Platform [Official Certification]