Android 4.4: java.lang.SecurityException: Package com.android.settings does not belong to 1001

问题描述：

在Android4.4.2上面定制的东西，今天code base改为Android4.4.4。

代码merge到新的Android 4.4.4 code base后，clean build后会报出下面错误：

 1 W/dalvikvm( 3125): threadid=1: thread exiting with uncaught exception (group=0x415e8d58)
 2 W/AppOps  ( 1053): Bad call: specified package com.android.settings under uid 1001 but it is really 1000
 3 E/AndroidRuntime( 3125): FATAL EXCEPTION: main
 4 E/AndroidRuntime( 3125): Process: com.android.phone, PID: 3125
 5 E/AndroidRuntime( 3125): java.lang.SecurityException: Package com.android.settings does not belong to 1001
 6 E/AndroidRuntime( 3125):     at android.os.Parcel.readException(Parcel.java:1465)
 7 E/AndroidRuntime( 3125):     at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:185)
 8 E/AndroidRuntime( 3125):     at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:137)
 9 E/AndroidRuntime( 3125):     at android.content.ContentProviderProxy.call(ContentProviderNative.java:636)
10 E/AndroidRuntime( 3125):     at android.provider.Settings$NameValueCache.putStringForUser(Settings.java:903)
11 E/AndroidRuntime( 3125):     at android.provider.Settings$System.putStringForUser(Settings.java:1169)
12 E/AndroidRuntime( 3125):     at android.provider.Settings$System.putIntForUser(Settings.java:1274)
13 E/AndroidRuntime( 3125):     at android.provider.Settings$System.putInt(Settings.java:1268)
14 E/AndroidRuntime( 3125):     at com.android.settings.DataRoamingSettings$3.onPreferenceChange(DataRoamingSettings.java:136)
15 。。。

定位到code中，是这行代码：

Settings.System.putInt(getContentResolver(), DATA_ROAMING_SELECTION_CODE, 0);

在网上搜索资料，只找到一个相关的介绍：

http://blog.csdn.net/eqiang8271/article/details/39576101

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.

总结一下，意思就是说Android原生应该不会有问题，但是QUALCOMM的code base会有这个问题。

修改方法如下：

修改LINUX/android/frameworks/base/core/java/android/app/ContextImpl.java

将mContentResolver初始化部分放在mOpPackageName之类的后面：

下面这句

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

放在方法的最后部分：

    if (container != null) {
            mBasePackageName = container.mBasePackageName;
            mOpPackageName = container.mOpPackageName;
        } else {
            mBasePackageName = packageInfo.mPackageName;
            ApplicationInfo ainfo = packageInfo.getApplicationInfo();
            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;
            }
        }

    //Kunkka modified
    mContentResolver = new ApplicationContentResolver(this, mainThread, user);

重新编译code，问题没有再出现。