This article was reproduced from: http://blog.csdn.net/LoongEmbedded/article/details/71477203
In the recent Qualcomm platform Android5.1 Project, there is a need to set up an Ethernet MAC, the approximate process is that Windows writes to a flash patch to save the serial number and Ethernet MAC address, and then the Android client through the interface to read the string and display it, need to sync their MAC address to Android The MAC address in the OID system.
First I added a device information display serial number and Ethernet application, through the local_java_libraries load the relevant interface library to be loaded, and then manifest through the <uses-library></ Uses-library> Load related declarations (note: This declaration is under the application node). This allows our application layer to read the contents of the relevant flash extents properly.
So back to the question, how do we synchronize the MAC address of the saved Ethernet within the Android system? We can get the results by executing the relevant Linux commands by searching the relevant documents on the Internet. Execution of the command through the serial port found that the following command is valid to modify the address stored in the Android5.1/sys/class/net/eth0/address:
Netcfg (ifconfig) eth0 down
Netcfg eth0 hwaddr 10:10:10:10:10:10
Netcfg (ifconfig) eth0 up
So by adding Java code to execute these three commands:
private void Executecmd (String cmd) {
try {
LOG.W (TAG, "cmd=" +cmd);
Runtime runtime = Runtime.getruntime ();
Process proc = runtime.exec (cmd);
} catch (IOException e) {
LOG.W (TAG, "EXE fail!!!!");
E.printstacktrace ();
}
}
We should execute the above three Linux commands in turn to meet our needs. Okay, the basic logic has been completed, the following into the commissioning phase, the author is debugging the project is a product MSM8909 Android5.1 a tablet computer. When we compile, we view the log by running the application and find that our app has actually read the saved serial number and MAC address, but set the system MAC address times back to permission denied! In this way, it enters the stage of the grant and debugging of Android permissions. First of all, we need to give our apk is System apk, so I put it into the system/system/app, behind the run found still reported ioexeption:permission denied! Then I joined the android:shareduserid= "Android.uid.system" in manifest to run the process UID to system, and then need to sign platform certificate for it, and I signed the relevant signature. Back with a full of information to debug when found there are new permissions anomalies, followed by the Adnroid5.1 introduced SELinux related permissions debugging, filtering the effective log as follows:
avc:denied {net_admin} for capability=12 Scontext=u:r:system_app:s0 tcontext=u:r:system_app:s0
Tclass=capability permissive=0
So AVC permissions issues are generally related to selinux problems, selinux in our solution is the lack of what permissions we have to add what permissions, so at least will not lead to the chaos of permissions. About SELinux's empowerment are in the source directory/external/sepolicy/file for code editing, the following we follow the clues to find our System_app permission profile (System_app.te), Plus an understanding of the log we're trying to add a statement that empowers our APK:
Allow System_app system_app:capability {net_admin};
For the syntax of this statement we can online Baidu or reference to the original content to understand, allow the following parameters are Scontext (for a group), followed by the need to add the permissions for this group, Are the names of Tcontext and Tclass and permissions (for a classification of permissions we can refer to out/target/product/msm8909/obj/etc/sepolicy_intermediates/ Policy.conf can be related. Well, after this step we need to recompile the kernel bootimage to write the burn. With full confidence to compile, the results found that God actually compiled however, look at the server reported error information found, that is, in app.tc do not allow the addition of similar capability related class permissions, we entered the APP.TC found the following statement:
Neverallow {Appdomain-bluetooth} self:capability *;
The initial understanding is that the AppDomain must not be allowed except for the Bluetooth group, and our system_app.tc exactly defines the AppDomain, so we boldly understand that we can add our group in APP.TC. Then there are the following modifications:
Neverallow {Appdomain-bluetooth-system_app} self:capability *;
Okay, you are done, compile the kernel again. Haha, actually compiled through, this time feel more confident than before each debugging. Copy out bootimage after burning, reboot, run, view log, Netcfg view Ethernet MAC address. Haha, the MAC address of the Android system has been changed to the MAC address that I read out, this demand completes successfully!
With this change in demand, I have a deeper understanding of Android5.1 's selinux. Encounter problems, leisurely, we slowly analyze the problem, locate the problem, solve the problem (inseparable from the log of important information extraction and understanding).
Android5.1 Modifying the Ethernet MAC address (SElinux) "Go"