JAVA安卓4.4.4_Android 4.4.4: java.lang.SecurityException: Package com.android.settings does not belong...

How to check:

When enable flight mode, it will update one attribute in the setting’s DB. When updating the value, security error occurs, saying “Package com.android.settings does not belong to 1001”. From the error information, We understand that the user id which is accessing the DB is 1001(phone) while the package which it belonged to is 1000(the package is com.android.settings and in the manifest it is declared that it is the “system” group, the value is 1000).From Android4.3, there is the permission management module called Appops, it will check if the process id and the id which the package belongs to are identical in case of the application is hacked. In this case, it detected that they are different, so the FC occurred.

Tracing the code to AppOpsManager.java, it call checkPackage(), and then the AppOpsSevice.checkpackage is called. In this function,

pkgUid = mContext.getPackageManager().getPackageUid(packageName, UserHandle.getUserId(uid));

The returned packageUid is 1001, not same as the 1000 which is the uid of com.android.settings.

But as a process in system group, the operation which an activity in “phone” process should be valid, since in the ContextImpl.java

if (ainfo.uid == Process.SYSTEM_UID && ainfo.uid != Process.myUid()) {

// Special case: system components allow themselves to be loaded in to other

// processes. For purposes of app ops, we must then consider the context as

// belonging to the package of this process, not the system itself, otherwise

// the package+uid verifications in app ops will fail.

mOpPackageName = ActivityThread.currentPackageName();

} else {

mOpPackageName = mBasePackageName;

}

So it’s really strange that

this case has been considered in the code, but it doesn’t work After

checking the code carefully, We found that the init of the

contentResolver is before the code sniff mentioned above.

At that time, the mOpPackageName is not set at all. So the solution for

this is moving the code of initiating the contentResolve after

initiating mopPackageName.

….

} else {

mOpPackageName = mBasePackageName;

}

}

mContentResolver = new ApplicationContentResolver(this, mainThread, user);

After changing this, we are

wondering why this error is found till now since it is from AOSP4.4.

After checking the settings of AOSP4.4, it won’t access DB when

enable/disable flight mode. Accessing DB when enable/disable

flight mode is QUALCOMM specified. That’s why the issue happened on

Nokia phone but not AOSP.