In the previous version of ICS40, if the program needs to set the APN, it only needs to declare this permission in the AndroidManifest file. Running on a 40 machine will throw the following exception: Java.lang.SecurityException: No permission to write APN settings: Neither user * nor current process has android.permission.WRITE_APN_SETTINGS.
The reason is that Google has blocked access to APN by third-party applications based on security considerations. Some people on the Internet say that the program can be set as a system app. It is indeed feasible to put the apk in the /system/app/ directory through the adb push command, but most apps are used as third-party applications, which is not feasible. Therefore, the system signature is used to enable the app to have APN access rights.
The first method is simpler, but you need to use make to compile in the Android system source code environment:
1. 在应用程序的AndroidManifest.xml中的manifest节点中加入android:sharedUserId="android.uid.system"这个属性。
2. 修改Android.mk文件，加入LOCAL_CERTIFICATE := platform这一行
3. 使用mm命令来编译，生成的apk就有修改系统时间的权限了。
The second method is a bit more troublesome, but you don't need to open the virtual machine and run to the source environment to compile with make:
Same as above, add the attribute android:sharedUserId=”android.uid.system”.
Use eclipse to compile the apk file, but this apk file cannot be used.
Open the apk file with compression software and delete the two files CERT.SF and CERT.RSA in the META-INF directory.
Use the platform key of the target system to re-sign the apk file. This step is more troublesome, first find the key file, the location in my Android source directory is "build\target\product\security", the following two files platform.pk8 and platform.x509.pem. Then use the Signapk tool provided by Android to sign. The source code of signapk is under "build\tools\signapk", and the usage is java-jar signapk.jar platform.x509.pem platform.pk8 * .apk ***_signed.apk Get an APK with corresponding permissions.
Tool and key download address: http://download.csdn.net/detail/bulkin/4329253
The apk obtained in this way is the same as the first method.
Finally, explain the principle, first add the attribute android:sharedUserId=”android.uid.system”. Through Shared User id, multiple APKs with the same User id can be configured to run in the same process. Then match the UID of the program to android.uid.system, that is, let the program run in the system process, so that it has the authority to modify the system time.
It is not enough to just add the UID. If the APK is installed at this time, it is found that it cannot be installed and the signature does not match. The reason is that the program wants to run in the system process and there is the platform of the target system. The key is the platform mentioned in the second method above. .pk8 and platform.x509.pem two files. After signing with these two keys, the apk can actually be put into the system process. Adding LOCAL_CERTIFICATE := platform to the first method actually uses these two keys to sign.
There is also a problem, that is, the program generated in this way can only be used in the original Android system or a system compiled by yourself, because such a system can get the two files platform.pk8 and platform.x509.pem. If the Android made by another company cannot even be installed. Try the key in the original Android to sign, the program runs on the emulator OK, but the installation on G3 directly prompts "Package… has no signatures that match those in shared user android.uid.system", which is also protected System security.
Finally, the android:sharedUserId attribute can not only put the apk in the system process, but also configure multiple APKs to run in one process, so that data can be shared, which should be very useful.
ref: http://blog.csdn.net/bulkin/article/details/7601609