ActivityManagerService对于app缺少运行时权限而crash的一种友好处理方法
我们都知道runtime权限是google在android上权限管理的又一大重要改变，在应用程序安装过程中，只会grant install部分的基本权限，而对于dangerous的权限，应用程序需要在运行时主动申请，并动态的由用户来确认是否需要给予对应的权限。
当然，google在开发者文档中也详细的介绍了关于新的权限申请机制，也给app开发人员带来了新的机遇与挑战，但是对于很多旧版本的app或者说一些初出茅庐的开发者开发的应用，并没有按照google的要求去设计兼容性很强的app时，这些应用一旦跑起来，去访问需要运行时给予权限的操作而导致应用的crash，这些用户就会看到一个很不想看到的结果，应用直接crash了，如果不懂开发的用户用到，他根本不知道发生了什么，只见眼前一黑，应用闪退了。。。。Unfortunately， Your application has stopped！！
这真让人绝望啊。
既然app开发者没有做好这件事情，我作为一个系统开发工程师（虽然对于给应用擦屁股这种事我是极度拒绝的），但是，对于系统机制的探索使我对这一问题产生了浓厚的兴趣，以便可以为该问题提供一个系统级的友好解决方案。于是，顺着AMS的源码，我们今天就为那些不友好的app开发者捏着鼻子擦一次屁股吧。
我们知道，zygote启动时，会为应用程序主线程注册一个UncaughtHandler，当应用程序发生异常时，会触发RuntimeInit的UncaughtHandler的uncaughtException方法：
01-02 13:06:40.072 2688-2688/linhui.skysoft.com.permissiontest E/AndroidRuntime: FATAL EXCEPTION: main
Process: linhui.skysoft.com.permissiontest, PID: 2688
java.lang.RuntimeException: Unable to resume activity {linhui.skysoft.com.permissiontest/linhui.skysoft.com.permissiontest.MainActivity}: java.lang.SecurityException: Permission Denial: opening provider com.android.providers.contacts.ContactsProvider2 from ProcessRecord{b19ead7 2688:linhui.skysoft.com.permissiontest/u0a79} (pid=2688, uid=10079) requires android.permission.READ_CONTACTS or android.permission.WRITE_CONTACTS
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3103)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3134)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2481)
at android.app.ActivityThread.access$900(ActivityThread.java:150)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1344)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Caused by: java.lang.SecurityException: Permission Denial: opening provider com.android.providers.contacts.ContactsProvider2 from ProcessRecord{b19ead7 2688:linhui.skysoft.com.permissiontest/u0a79} (pid=2688, uid=10079) requires android.permission.READ_CONTACTS or android.permission.WRITE_CONTACTS
at android.os.Parcel.readException(Parcel.java:1620)
at android.os.Parcel.readException(Parcel.java:1573)
at android.app.ActivityManagerProxy.getContentProvider(ActivityManagerNative.java:3550)
at android.app.ActivityThread.acquireProvider(ActivityThread.java:4778)
at android.app.ContextImpl$ApplicationContentResolver.acquireProvider(ContextImpl.java:1999)
at android.content.ContentResolver.acquireProvider(ContentResolver.java:1455)
at android.content.ContentResolver.acquireContentProviderClient(ContentResolver.java:1520)
at android.content.ContentResolver.applyBatch(ContentResolver.java:1268)
at linhui.skysoft.com.permissiontest.MainActivity.insertDummyContact(MainActivity.java:157)
at linhui.skysoft.com.permissiontest.MainActivity.onResume(MainActivity.java:46)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1259)
at android.app.Activity.performResume(Activity.java:6361)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3092)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3134)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2481)
at android.app.ActivityThread.access$900(ActivityThread.java:150)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1344)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) 这个方法会调用ActivityManagerNative的如下方法继而由ActivityManagerService来对其进行处理：
ActivityManagerNative.getDefault().handleApplicationCrash(
mApplicationObject, new ApplicationErrorReport.CrashInfo(e));ActivityManagerNative.getDefault()获取到的是IActivityManagerProxy的binder代理,
static public IActivityManager getDefault() {
return gDefault.get();
}
private static final Singleton gDefault = new Singleton() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
}; 因此，接下来通过binder驱动，将会唤醒AMS的handleApplicationCrash来处理此次crash。
public void handleApplicationCrash(IBinder app, ApplicationErrorReport.CrashInfo crashInfo) {
ProcessRecord r = findAppProcess(app, "Crash");
final String processName = app == null ? "system_server"
: (r == null ? "unknown" : r.processName);
handleApplicationCrashInner("crash", r, processName, crashInfo);
}
/* Native crash reporting uses this inner version because it needs to be somewhat
* decoupled from the AM-managed cleanup lifecycle
*/
void handleApplicationCrashInner(String eventType, ProcessRecord r, String processName,
ApplicationErrorReport.CrashInfo crashInfo) {
EventLog.writeEvent(EventLogTags.AM_CRASH, Binder.getCallingPid(),
UserHandle.getUserId(Binder.getCallingUid()), processName,
r == null ? -1 : r.info.flags,
crashInfo.exceptionClassName,
crashInfo.exceptionMessage,
crashInfo.throwFileName,
crashInfo.throwLineNumber);
addErrorToDropBox(eventType, r, processName, null, null, null, null, null, crashInfo);
crashApplication(r, crashInfo);
}这里通过层层封装调用，最终会调用到crashApplication方法中。这里的r为进程的信息，类型为ProcessRecord，而crashinfo中则包含了crash原因以及调用栈。
我们既然拿到了crash信息以及crash调用栈， 就可以根据crash信息处理特殊的因为权限而导致的异常了。
crashApplication方法主要是构造一个AppErrorResult信息，并封装一个SHOW_ERR_MSG的消息到UIHandler中去处理。
private void crashApplication(ProcessRecord r, ApplicationErrorReport.CrashInfo crashInfo) {
long timeMillis = System.currentTimeMillis();
String shortMsg = crashInfo.exceptionClassName;
String longMsg = crashInfo.exceptionMessage;
String stackTrace = crashInfo.stackTrace;
if (shortMsg != null && longMsg != null) {
longMsg = shortMsg + ": " + longMsg;
} else if (shortMsg != null) {
longMsg = shortMsg;
}
Slog.i(TAG,"crashApplication ==>",new Throwable());
Slog.i(TAG,"crashApplication, shortMsg:"+shortMsg+" longMsg:"+longMsg);
AppErrorResult result = new AppErrorResult();
synchronized (this) {
if (mController != null) {
try {
String name = r != null ? r.processName : null;
int pid = r != null ? r.pid : Binder.getCallingPid();
int uid = r != null ? r.info.uid : Binder.getCallingUid();
if (!mController.appCrashed(name, pid,
shortMsg, longMsg, timeMillis, crashInfo.stackTrace)) {
if ("1".equals(SystemProperties.get(SYSTEM_DEBUGGABLE, "0"))
&& "Native crash".equals(crashInfo.exceptionClassName)) {
Slog.w(TAG, "Skip killing native crashed app " + name
+ "(" + pid + ") during testing");
} else {
Slog.w(TAG, "Force-killing crashed app " + name
+ " at watcher's request");
if (r != null) {
r.kill("crash", true);
} else {
// Huh.
Process.killProcess(pid);
killProcessGroup(uid, pid);
}
}
return;
}
} catch (RemoteException e) {
mController = null;
Watchdog.getInstance().setActivityController(null);
}
}
final long origId = Binder.clearCallingIdentity();
// If this process is running instrumentation, finish it.
if (r != null && r.instrumentationClass != null) {
Slog.w(TAG, "Error in app " + r.processName
+ " running instrumentation " + r.instrumentationClass + ":");
if (shortMsg != null) Slog.w(TAG, " " + shortMsg);
if (longMsg != null) Slog.w(TAG, " " + longMsg);
Bundle info = new Bundle();
info.putString("shortMsg", shortMsg);
info.putString("longMsg", longMsg);
finishInstrumentationLocked(r, Activity.RESULT_CANCELED, info);
Binder.restoreCallingIdentity(origId);
return;
}
// Log crash in battery stats.
if (r != null) {
mBatteryStatsService.noteProcessCrash(r.processName, r.uid);
}
// If we can't identify the process or it's already exceeded its crash quota,
// quit right away without showing a crash dialog.
if (r == null || !makeAppCrashingLocked(r, shortMsg, longMsg, stackTrace)) {
Binder.restoreCallingIdentity(origId);
return;
}
/// linhui:Permission exception dialog, @{
result.setExceptionMsg(longMsg);
/// @}
Message msg = Message.obtain();
msg.what = SHOW_ERROR_MSG;
HashMap data = new HashMap();
data.put("result", result);
data.put("app", r);
msg.obj = data;
mUiHandler.sendMessage(msg);
Binder.restoreCallingIdentity(origId);
}在UIHandler的handlemessage中，则会显示我们app crash的dialog。
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case SHOW_ERROR_MSG: {
.......
if (mShowDialogs && !mSleeping && !mShuttingDown) {
Dialog d = new AppErrorDialog(mContext,
ActivityManagerService.this, res, proc);
d.show();
proc.crashDialog = d;
} else {
.......
}
}
}
} break;所以到达这里后，我们可以通过定制AppErrorDialog的消息框，来达到友好的目的。这里是通过获取到调用栈，解析SecurityException的信息，解析出权限所属组，对于 dialog的选项框重定向到应用的权限管理设置中，提醒用户打开对应的权限再启动该app，以实现较好的用户体验。
我们在crashApplication中，构造AppErrorResult的时候设置其crash原因(即解析的crash字串)，再由AppErrorDialog去解析，将解析的结果在dialog中友好的显示出来，最后，如果解析发现是由于Permission Denial导致的，则启动权限管理的intent到达app权限管理设置中去，以便提醒用户手动开启应用需要的权限。
具体的实践过程如下：
1. 在AppErrorResult中新增字符串mExceptionMsg，该字符串中保存的是crashinfo的longMsg，通过这个消息，我们基本上可以确定crash的app，以及具体的crash原因，如下所示：
longMsg:java.lang.SecurityException: Permission Denial: opening provider com.android.providers.contacts.ContactsProvider2 from ProcessRecord{6e38cac 2733:linhui.skysoft.com.permissiontest/u0a79} (pid=2733, uid=10079) requires android.permission.READ_CONTACTS or android.permission.WRITE_CONTACTS
--- a/services/core/java/com/android/server/am/AppErrorResult.java
+++ b/services/core/java/com/android/server/am/AppErrorResult.java
@@ -37,6 +37,20 @@ final class AppErrorResult {
return mResult;
}
+ /// linhui:Permission exception dialog, @{
+ public synchronized void setExceptionMsg(String msg) {
+ mExceptionMsg = msg;
+ }
+
+ public synchronized String getExceptionMsg() {
+ return mExceptionMsg;
+ }
+
+ String mExceptionMsg = null;
+ /// @}
+
2. 然后再构造AppErrorDialog中去解析上面的crash信息，得到具体的appname，permission等。
下面这段代码主要是解析mExceptionMsg各个字段。
int crashByMustHavePermission = CRASH_BY_PERMISSION_NONE;
+ String permissionTitled = null;
+ if (mExceptionMsg != null
+ && mExceptionMsg.contains(SECURITY_EXCEPTION)) {
+ if (DEBUG_PERMISSION) {
+ Slog.v(TAG, "AppErrorDialog mExceptionMsg = " + mExceptionMsg);
+ }
+ if (mExceptionMsg.contains(SECURITY_SUB_PERMISSION_DENIAL)) {
+ int startIndex = mExceptionMsg.indexOf(SECURITY_SUB_REQUIRES)
+ + SECURITY_SUB_REQUIRES.length();
+ String parseResult = mExceptionMsg.substring(startIndex, mExceptionMsg.length());
+ if (parseResult.contains(SECURITY_SUB_OR)) {
+ startIndex = parseResult.indexOf(SECURITY_SUB_OR) +
+ SECURITY_SUB_OR.length();
+ parseResult = parseResult.substring(startIndex, parseResult.length());
+ }
+
+ permissionTitled = getPermissionTitle(context.getPackageManager(),
+ parseResult);
+
+ if (DEBUG_PERMISSION) {
+ Slog.v(TAG, "AppErrorDialog parseResult = " + parseResult +
+ " and permissionTitled = " + permissionTitled);
+ }
+ if (permissionTitled != null) {
+ crashByMustHavePermission = CRASH_BY_PERMISSION_DETAIL;
+ }
+ }
+ if (crashByMustHavePermission == CRASH_BY_PERMISSION_NONE) {
+ crashByMustHavePermission = CRASH_BY_PERMISSION_TRY;
+ }
+ }
3. 通过封装对应的message将消息发给handler去处理，这里新建了一个专门处理PERMISSION_SETTINGS的消息：
if (crashByMustHavePermission != CRASH_BY_PERMISSION_NONE) {
setButton(DialogInterface.BUTTON_POSITIVE,
res.getText(com.android.internal.R.string.force_close),
mHandler.obtainMessage(PERMISSION_SETTINGS, app.info.packageName));
} else {
setButton(DialogInterface.BUTTON_POSITIVE,
res.getText(com.android.internal.R.string.force_close),
mHandler.obtainMessage(FORCE_QUIT));
}
}
.........
public void handleMessage(Message msg) {
/// linhui:Permission exception dialog, @{
if (msg.what == PERMISSION_SETTINGS) {
Intent mIntent = new Intent(Intent.ACTION_MANAGE_APP_PERMISSIONS);
mIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
mIntent.putExtra(Intent.EXTRA_PACKAGE_NAME, (String) msg.obj);
mContext.startActivity(mIntent);
}
最后，在handleMessage中对PERMISSION_SETTINGS的消息定向到app的权限管理界面中，提醒用户打开具体所缺的权限。
这样app再因为缺少对应的权限而crash的情况得到了友好的解决。
具体效果如下：
可以看到，我们定制后的dialog中会友好的提示，PermissionTest应用由于缺少访问Contacts的权限而死掉，现在通过OK按钮，我们便可直接达到应用权限管理界面打开对应的权限，保证app的正常运行。
怎么样，是不是很简单？虽然如此，我们还是强烈建议app开发者们遵循google的设计原则主动申请应用的运行时权限，以便开发出兼容性超强的app，做一个合格的Developer！
关于应用权限申请的部分，可以参考我的另一篇博文：
Android M PackageManager应用程序权限管理源码剖析及runtime permission实战