Android 权限管理 —— AppOps
Android 的安全保护源于权限，每个 App 需要申请权限才能使用特定的功能，用户在安装的时候可以浏览 App 已申请的权限再决定是否安装，不过一旦安装就相当于默认了可以使用该权限，所以这一功能基本属于鸡肋，后来便出现了权限管理这一安全防护：例如 360 手机卫士、安全管家、LBE一类第三方安全软件。除此之外，android 系统也并不是没有作为，在4.3系统以后出现了 AppOps 隐藏功能，能够针对 manifest 部分申请的权限进行一层限制，为什么说是隐藏功能呢？AppOps 本来有个可设置页面 AppOpsSummaryActivity，但是 Google 工程师一而再再而三的隐藏该界面，就是为了只让系统应用拥有后台修改 AppOps 的权限，不提供给其他用户或者第三方软件修改的机会。本文将从实例（修改短信权限）出发，分析 AppOps 的实现原理和鉴权过程。
1.短信Provider
Android 手机上，修改短信内容即是修改短信数据库，均是通过访问短信 Provider 的接口来实现的。该 Provider 是一个单独的 APK 实现的，一般来说在手机的 /system/app 目录下有一个叫做 TelephonyProvider.apk 的文件，该 Provider 实现是在 packages/providers/TelephonyProvider/src/SmsProvider.java 。
1.1 如何插入一条短信
本节简单展示一下如何在 Android 上插入一条短信:
private void insertSMS() {
final String ADDRESS = "address";
final String DATE = "date";
final String READ = "read";
final String STATUS = "status";
final String TYPE = "type";
final String BODY = "body";
int MESSAGE_TYPE_INBOX = 1;
int MESSAGE_TYPE_SENT = 2;
ContentValues values = new ContentValues();
/* 手机号 */
values.put(ADDRESS, "13800138000");
/* 时间 */
values.put(DATE, "1281403142857");
values.put(READ, 1);
values.put(STATUS, -1);
/* 类型1为收件箱，2为发件箱 */
values.put(TYPE, 2);
/* 短信体内容 */
values.put(BODY, "测试插入一条短信");
/* 插入数据库操作 */
* Uri inserted = getContentResolver().insert(Uri.parse("content://sms"),
values);
}
不瞒大家，为了节省时间，就随意摘了一段代码。。。但是效果都一样，相信大家在哪看大体都是这样，关键代码就是带*号的这一行。没错，记准了 Uri 是 content://sms 其实就够了。
1.2 插入流程
从 ContentResolver.insert 到 ContentProvider 的 Binder 调用过程在这里就不多说了，贴一小段代码足矣说明（ContentProviderNative.java）：
public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
try {
switch (code) {
......
case INSERT_TRANSACTION:
{
data.enforceInterface(IContentProvider.descriptor);
String callingPkg = data.readString();
Uri url = Uri.CREATOR.createFromParcel(data);
ContentValues values = ContentValues.CREATOR.createFromParcel(data);
* Uri out = insert(callingPkg, url, values);
reply.writeNoException();
Uri.writeToParcel(reply, out);
return true;
}
......
}
......
}
......
}
发现 Binder 调用调的是 ContentProviderNative.insert，实际上就是 ContentProvider.Transport.insert 方法：
public Uri insert(String callingPkg, Uri uri, ContentValues initialValues) {
1. if (enforceWritePermission(callingPkg, uri) != AppOpsManager.MODE_ALLOWED) {
return rejectInsert(uri, initialValues);
}
final String original = setCallingPackage(callingPkg);
try {
2. return ContentProvider.this.insert(uri, initialValues);
} finally {
setCallingPackage(original);
}
}步骤1：AppOps鉴权
步骤2：Provider实际插入操作
Provider的插入操作实现在这里就不讨论了，如果这一步里出现错误的话，返回的 Uri 将会是 null，如果顺利，将会返回 content://sms/{*}, 其中 {*} 指代插入的行数，该行数一定是大于0的，下面我们重点看鉴权过程。
1.3 鉴权过程
跟进 enforceWritePermission 方法：
private int enforceWritePermission(String callingPkg, Uri uri, IBinder callerToken)
throws SecurityException {
1. final int mode = enforceWritePermissionInner(uri, callingPkg, callerToken);
if (mode != MODE_ALLOWED) {
return mode;
}
if (mWriteOp != AppOpsManager.OP_NONE) {
2. return mAppOpsManager.noteProxyOp(mWriteOp, callingPkg);
}
return AppOpsManager.MODE_ALLOWED;
}步骤1：检查是否拥有该 Provider 声明需要的权限；
步骤2：检查通过 setAppOps 设置的 AppOps 权限；
我们直接来看第二步：
这一步既然是检查 setAppOps 设置的 AppOps 权限，那么是在哪里设置的呢？我们拿短信服务举例，即在 SmsProvider 的 onCreate 中：
@Override
public boolean onCreate() {
* setAppOps(AppOpsManager.OP_READ_SMS, AppOpsManager.OP_WRITE_SMS);
mOpenHelper = MmsSmsDatabaseHelper.getInstance(getContext());
return true;
}
public final void setAppOps(int readOp, int writeOp) {
if (!mNoPerms) {
mTransport.mReadOp = readOp;
mTransport.mWriteOp = writeOp;
}
}
这个 OP_WRITE_SMS 就是写短信对应的 AppOps 权限了：
public static final int OP_WRITE_SMS = 15;
这个 15 就是写短信权限对应的 code，我们称之为 opCode，每种权限都会有一个 opCode。
回到第二步的 AppOpsManager.noteProxyOp 方法，它实际调的是 AppOpsService.noteProxyOperation() 方法：
@Override
public int noteProxyOperation(int code, String proxyPackageName,
int proxiedUid, String proxiedPackageName) {
verifyIncomingOp(code);
1. final int proxyMode = noteOperationUnchecked(code, Binder.getCallingUid(),
proxyPackageName, -1, null);
if (proxyMode != AppOpsManager.MODE_ALLOWED || Binder.getCallingUid() == proxiedUid) {
return proxyMode;
}
2. return noteOperationUnchecked(code, proxiedUid, proxiedPackageName,
Binder.getCallingUid(), proxyPackageName);
}
其中 proxyPackageName 指的是服务提供方的包名，proxiedPackageName、proxiedUid 指的是服务调用方的包名和 Uid：
步骤1：检查服务提供方有权限与否
步骤2：检查服务调用方有权限与否
可以发现，AppOps 要求服务提供方和调用方均要有权限才行，我们回到短信验证的过程中来看，如果权限验证没过的分支执行的函数rejectInsert：
public Uri rejectInsert(Uri uri, ContentValues values) {
// If not allowed, we need to return some reasonable URI. Maybe the
// content provider should be responsible for this, but for now we
// will just return the base URI with a dummy '0' tagged on to it.
// You shouldn't be able to read if you can't write, anyway, so it
// shouldn't matter much what is returned.
return uri.buildUpon().appendPath("0").build();
}
会发现并不会返回一个空或者直接报错，而是返回了一个 path 为 0 的合理 Uri。
2. AppOps
2.1 权限的存储
AppOps 是在 AMS 刚运行时开始初始化的，即它主要运行在 systemserver 进程：
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
...
public void systemReady(final Runnable goingCallback) {
...
mAppOpsService.systemReady();
mSystemReady = true;
}
...
}每个 Uid 对应一套权限，存储在一个 SparseArray 中：
final SparseArray<UidState> mUidStates = new SparseArray<>();
UidState 是包含了针对 Uid 的权限和针对该 UID 下的应用的权限：
private static final class UidState {
public final int uid;
public ArrayMap<String, Ops> pkgOps; //针对该 UID 下的应用的权限
public SparseIntArray opModes; //针对 Uid 的权限
...
}
每个包名对应一套权限，存储在 pkgOps 中，Key 是包名，Value 是对应的权限 Ops，Ops 是一个 SparseArray<Op>：
public final static class Ops extends SparseArray<Op> {
public final String packageName;
public final UidState uidState;
public final boolean isPrivileged;
......
}同时还会发现，Ops 类中也包含了 UidState，即拿到指定包名的权限，也能反查到该 Uid 的权限。Key 是权限对应的 Code，Value 就是该 code 对应的具体某一项权限，这里的 code 不是完全意义上的 opCode，而是 switchCode，它是 opCode 的子集，是压缩版的 opCode，原因是会出现一个权限开关能控制多种权限的现象，比如 OP_COARSE_LOCATION、OP_FINE_LOCATION、OP_GPS 三种权限实际上在设置权限的时候，先都会变成 OP_COARSE_LOCATION，即一个开关控制三种权限。
每当权限发生变化时，或者主动触发保存权限时，都会执行 AppOpsService.writeSate() 方法将权限写入 /data/system/appops.xml 中，举例如下：
<app-ops>
<pkg n="com.android.phone">
<uid n="1001" p="true">
<op n="4" t="1454047676885" />
<op n="11" t="1453514110695" />
<op n="14" t="1454050862950" />
<op n="15" m="0" t="1454050863238" />
<op n="23" t="1454047678100" />
<op n="40" t="1454052269904" d="4" />
<op n="45" t="1432781257792" d="2538" />
</uid>
</pkg>
</app-ops>这里记录了一个包名为 com.android.phone 的应用的权限，其中 op 标签中，n 表示该项权限的 opCode，t 表示时间戳（毫秒），m 表示权限值 mode，有三种：
public static final int MODE_ALLOWED = 0;
public static final int MODE_IGNORED = 1;
public static final int MODE_ERRORED = 2;
如果没有 m 值，则为默认值，每种权限都有一种对应默认值，在 AppOpsManager.sOpDefaultMode 数组中，这是一个 int 数组，下标代表 opCode，内容代表默认权限值。其他属性值大家可以参考 writeState 方法一一对应过去。
2.2 权限验证
在第一节中我们已经知道，AppOps 通过 noteOperationUnchecked 函数去检查服务提供方和服务调用方有没有权限，在这里展开该函数来看：
private int noteOperationUnchecked(int code, int uid, String packageName,
int proxyUid, String proxyPackageName) {
synchronized (this) {
Ops ops = getOpsLocked(uid, packageName, true);
if (ops == null) {
if (DEBUG) Log.d(TAG, "noteOperation: no op for code " + code + " uid " + uid
+ " package " + packageName);
return AppOpsManager.MODE_ERRORED;
}
Op op = getOpLocked(ops, code, true);
1. if (isOpRestricted(uid, code, packageName)) {
return AppOpsManager.MODE_IGNORED;
}
if (op.duration == -1) {
Slog.w(TAG, "Noting op not finished: uid " + uid + " pkg " + packageName
+ " code " + code + " time=" + op.time + " duration=" + op.duration);
}
op.duration = 0;
final int switchCode = AppOpsManager.opToSwitch(code);
UidState uidState = ops.uidState;
if (uidState.opModes != null) {
final int uidMode = uidState.opModes.get(switchCode);
2. if (uidMode != AppOpsManager.MODE_ALLOWED) {
if (DEBUG) Log.d(TAG, "noteOperation: reject #" + op.mode + " for code "
+ switchCode + " (" + code + ") uid " + uid + " package "
+ packageName);
op.rejectTime = System.currentTimeMillis();
return uidMode;
}
}
final Op switchOp = switchCode != code ? getOpLocked(ops, switchCode, true) : op;
3. if (switchOp.mode != AppOpsManager.MODE_ALLOWED) {
if (DEBUG) Log.d(TAG, "noteOperation: reject #" + op.mode + " for code "
+ switchCode + " (" + code + ") uid " + uid + " package " + packageName);
op.rejectTime = System.currentTimeMillis();
return switchOp.mode;
}
if (DEBUG) Log.d(TAG, "noteOperation: allowing code " + code + " uid " + uid
+ " package " + packageName);
op.time = System.currentTimeMillis();
op.rejectTime = 0;
op.proxyUid = proxyUid;
op.proxyPackageName = proxyPackageName;
return AppOpsManager.MODE_ALLOWED;
}
}
步骤1：判断是否有其他用户限制，用在多用户账号切换场景上；
步骤2：判断 Uid 对应的指定权限；
步骤3：判断包对应的指定权限；
2.3 修改权限
2.3.1 举例：设置默认短信应用
既然 AppOps 做了种种权限限制，那么系统是如何管理、如何修改权限的呢？第三方能不能主动修改权限呢？在这里我们拿设置默认短信应用来举例。
在做修改、删除、管理短信相关的功能时，经常遇到一个权限问题，就是在 4.4 及以上的系统，由于 AppOps 的出现，“默认没有修改短信权限”的设定让这类功能瘫痪了，但同时发现设置了默认短信应用之后则功能又恢复有效了，这是为何呢？
经研究发现，在设置默认短信时，直接调用的实际上是 SmsApplication.setDefaultApplication() 方法：
public static void setDefaultApplication(String packageName, Context context) {
TelephonyManager tm = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
if (!tm.isSmsCapable()) {
// No phone, no SMS
return;
}
final int userId = getIncomingUserId(context);
final long token = Binder.clearCallingIdentity();
try {
* setDefaultApplicationInternal(packageName, context, userId);
} finally {
Binder.restoreCallingIdentity(token);
}
}
展开 setDefaultApplicationInternal：
private static void setDefaultApplicationInternal(String packageName, Context context,
int userId) {
// Get old package name
String oldPackageName = Settings.Secure.getStringForUser(context.getContentResolver(),
Settings.Secure.SMS_DEFAULT_APPLICATION, userId);
if (packageName != null && oldPackageName != null && packageName.equals(oldPackageName)) {
// No change
return;
}
// We only make the change if the new package is valid
PackageManager packageManager = context.getPackageManager();
Collection<SmsApplicationData> applications = getApplicationCollection(context);
SmsApplicationData applicationData = getApplicationForPackage(applications, packageName);
if (applicationData != null) {
// Ignore OP_WRITE_SMS for the previously configured default SMS app.
AppOpsManager appOps = (AppOpsManager)context.getSystemService(Context.APP_OPS_SERVICE);
if (oldPackageName != null) {
try {
PackageInfo info = packageManager.getPackageInfo(oldPackageName,
PackageManager.GET_UNINSTALLED_PACKAGES);
1. appOps.setMode(AppOpsManager.OP_WRITE_SMS, info.applicationInfo.uid,
oldPackageName, AppOpsManager.MODE_IGNORED);
} catch (NameNotFoundException e) {
Rlog.w(LOG_TAG, "Old SMS package not found: " + oldPackageName);
}
}
// Update the secure setting.
Settings.Secure.putStringForUser(context.getContentResolver(),
Settings.Secure.SMS_DEFAULT_APPLICATION, applicationData.mPackageName,
userId);
// Configure this as the preferred activity for SENDTO sms/mms intents
configurePreferredActivity(packageManager, new ComponentName(
applicationData.mPackageName, applicationData.mSendToClass), userId);
// Allow OP_WRITE_SMS for the newly configured default SMS app.
2. appOps.setMode(AppOpsManager.OP_WRITE_SMS, applicationData.mUid,
applicationData.mPackageName, AppOpsManager.MODE_ALLOWED);
// Assign permission to special system apps
assignWriteSmsPermissionToSystemApp(context, packageManager, appOps,
PHONE_PACKAGE_NAME);
assignWriteSmsPermissionToSystemApp(context, packageManager, appOps,
BLUETOOTH_PACKAGE_NAME);
assignWriteSmsPermissionToSystemApp(context, packageManager, appOps,
MMS_SERVICE_PACKAGE_NAME);
assignWriteSmsPermissionToSystemApp(context, packageManager, appOps,
TELEPHONY_PROVIDER_PACKAGE_NAME);
}
}
步骤1：通过 setMode 函数将前一个默认短信应用的 OP_WRITE_SMS 权限设为 MODE_IGNORED；
步骤2：通过 setMode 函数将当前要设置的默认短信应用的 OP_WRITE_SMS 权限设为 MODE_ALLOWED；
可见，设置为默认短信应用之后就可以修改短信的原因在于 AppOps 权限的修改。
2.3.2 Android5.0 及以上设置权限
那么我们可否自己执行这个 setMode 函数呢？这里要分 Android 版本了（上文的代码均出自 6.0）我们先来看 5.0 - 6.0 （都一样）上的源码（AppOpsService.setMode是服务端实现，我们直接转到这里）：
public void setMode(int code, int uid, String packageName, int mode) {
* if (Binder.getCallingPid() != Process.myPid()) {
mContext.enforcePermission(android.Manifest.permission.UPDATE_APP_OPS_STATS,
Binder.getCallingPid(), Binder.getCallingUid(), null);
}
verifyIncomingOp(code);
......
}
只看星号那一行即可，如果判断调用 setMode 的客户端不是本进程的话，则必须验证有 android.Manifest.permission.UPDATE_APP_OPS_STATS 权限，即非 systemserver 进程内部调用必须验证该权限：
<permission android:name="android.permission.UPDATE_APP_OPS_STATS"
android:protectionLevel="signature|privileged|installer" />这是签名验证的权限啊，所以第三方应用是无法添加该权限的~~~即6.0上第三方应用改 AppOps 就别想了。
2.3.3 Android 4.3 及 Android 4.4 上设置权限
同样来看4.3和4.4的 setMode 函数：
public void setMode(int code, int uid, String packageName, int mode) {
verifyIncomingUid(uid);
verifyIncomingOp(code);
......
}
private void verifyIncomingUid(int uid) {
* if (uid == Binder.getCallingUid()) {
return;
}
if (Binder.getCallingPid() == Process.myPid()) {
return;
}
mContext.enforcePermission(android.Manifest.permission.UPDATE_APP_OPS_STATS,
Binder.getCallingPid(), Binder.getCallingUid(), null);
}
注意带星的一行，只要传入的 uid 和调用者一致即可，明显就是直接可以调用了呀，这算是漏洞咩？
所以大家可以在自己的工程中加入如下代码：
if ( 19 >= Build.VERSION.SDK_INT) {
try {
AppOpsManager appOpsManager = (AppOpsManager) sContext.getSystemService("appops");
appOpsManager.setMode(15, android.os.Process.myUid(), packageName, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
就能解决一部分没有深度定制的 rom 以及官方 rom 上修改短信没权限的问题。
3. 小结
本文基于短信修改权限对 AppOps 作了一定深度上的分析，并基于4.3、4.4的源码对这个直接修改AppOps的“漏网之鱼”作了介绍。
在这里感谢师弟@张晓的支持~~~~