If you need to modify the Android ro. Type system properties, there are probably two methods: one is to unlock the boot loader and customize your own boot.img file; the other is to use the setpropex tool.
Both methods require root privileges. The first method is more complicated, but the advantage is that the attributes can be permanently modified. The second method is very simple, but it is only temporary, and the system restart will fail.
I use the second method here, as long as you run setpropex with root permissions to set properties, then adb root restarts the adb daemon with root permissions, and finally kills the system_server process, waiting for it to restart. This is to restart Dalvik .
The above process is theoretical, but I failed in the actual operation project. My running environment is Nexus 5, and the system is version 4.4.4.
In order to solve the problem, I read the source code of setpropex. The approximate process is to find the address range of "/ dev / __ properties__ (deleted)" in the init process space through the / proc / <pid> / maps file, and then pass / proc / <pid > / mem read the content of this part, this part of the content is actually stored system attributes, find the attribute address you want to modify, and then write the value to be modified through ptrace. In addition to a digression, there is a loophole in / proc / <pid> / mem, called memprodroid, which can be used to do many things. If you are interested, you can take a look.
But combined with my actual environment, I found that there is no "/ dev / __ properties__ (deleted)" in the map file of the init process, but "/ dev / __ properties__". Checking the meaning of the deleted flag behind is that one will be deleted. After the file is mapped to memory, the deleted flag will be added after the file. This file exists in my system. As for why it is different from the original program, I have not figured it out.
Then I changed the program to the latter, and it still failed after recompiling and running. The debugging found that something went wrong when parsing this part of the content. Comparing the code of the setpropex parsing part and the source code of the __system_property_get function in bionic, it was found that there was a big difference, and There are two more important data structures, prop_area and prop_info, which are also different. Prop_area should be the structure that stores the entire system property shared memory, and prop_info is the structure of specific properties. Moreover, the definitions of the two structures in <sys / _system_properties.h> in setpropex and ndk are the same, that is to say, these two structures are different in the ndk and the bionic source code in AOSP. ?
Let ’s talk a little bit about the concept of system properties. System properties are managed by the init process. When the init process starts, a system property service is started. All modifications and queries to system properties in Android are implemented through this service. , That is, the service is running in the init process. When the service starts, system properties are loaded from four files:
/default.prop
/system/build.prop
/system/default.prop
/data/local.prop
These files are loaded into a piece of shared memory, and then each piece of shared memory is mapped into its own process memory space when the process starts. This mapping process is implemented in the __libc_preinit function of bionic libc , It will be executed automatically when libc is loaded.
Here is only a brief description of the concept. For details, you can see another article I reprinted, click directly .
The above problem is the problem I encountered in the process of using setpropex. It has not been solved until now. Please make a record for later to solve it.
Reference link:
1. http://www.cnblogs.com/bastard/archive/2012/10/11/2720314.html
2. http://blog.csdn.net/jackyu613/article/details/6136620
3. http://blog.csdn.net/xujianqun/article/details/6363318
