Android L无法接听/拒接来电现象的分析与解决（文末对比Android M）

问题描述

卡2收到来电，上滑选择短信拒接，仅停留在界面不选择短信，
此时卡2上的来电被对方取消，卡1收到来电
此时无法接听或拒接卡1上的来电

分析问题

假设对于卡1上的来电可以成功下发answer和decline的命令，那么界面上应该会有正常的响应，所以这个问题很可能出现在InCallUI内；
找到answer和decline的代码，查看是否有可疑之处，必要时打断点debug。

关键代码接听：

 	public void onAnswer(int videoState, Context context) {
        int phoneId = getActivePhoneId();
        Log.i(this, "onAnswer  mCallId:" + mCallId + "phoneId:" + phoneId + " videoState="
                + videoState);
        if (mCallId == null || phoneId == -1) {
            return;
        }
		...
    }

拒接：

	/**
     * TODO: We are using reject and decline interchangeably. We should settle on
     * reject since it seems to be more prevalent.
     */
    public void onDecline(Context context) {
        int phoneId = getActivePhoneId();
        Log.i(this, "onDecline mCallId:" + mCallId + "phoneId:" + phoneId);
        if (mCall[phoneId].getSessionModificationState()
                == Call.SessionModificationState.RECEIVED_UPGRADE_TO_VIDEO_REQUEST) {
            InCallPresenter.getInstance().declineUpgradeRequest(context);
        } else {
            TelecomAdapter.getInstance().rejectCall(mCall[phoneId].getId(), false, null);
        }
    }

看到这两个方法里都有log打印出来，那么我分别打印正常和异常的log做比较看能都发现异常。

//按照上面步骤操作得到的异常log：
05-02 14:04:11.318 7643-7643/com.android.incallui I/InCall: AnswerPresenter - onDecline mCallId:[Ljava.lang.String;@1734d9f8phoneId:1
05-02 14:04:13.603 7643-7643/com.android.incallui I/InCall: AnswerPresenter - onAnswer  mCallId:[Ljava.lang.String;@1734d9f8phoneId:1 videoState=0
//只有卡1有一个来电的拒接操作：
05-02 14:05:47.048 7643-7643/com.android.incallui I/InCall: AnswerPresenter - onDecline mCallId:[Ljava.lang.String;@15b5b6e1phoneId:0

注意到虽然两次操作都是针对卡1上的来电，但是输出的phoneId却不一样，可以理解为出现异常的时候，我们打算对卡1的来电进行操作，实际上是对卡2上的电话的操作，但是实际上卡2的来电不是已经断开了么？而且卡2上的call断开以后其状态很可能已经变为IDLE，状态的为IDLE的call如何被接听？为什么会出现这种情况呢？我们继续分析。

从前面的代码段中可以看到phoneId是getActivePhoneId()的返回值，那么可以的地方就是这个方法了。

	// get active phoneId, for which call is visible to user
    private int getActivePhoneId() {
        int phoneId = -1;
        if (CallList.getInstance().isDsdaEnabled()) {
            int subId = CallList.getInstance().getActiveSubscription();
            phoneId = CallList.getInstance().getPhoneId(subId);
        } else {
            for (int i = 0; i < mCall.length; i++) {
                if (mCall[i] != null) {
                    phoneId = i;//phoneId的值
                }
            }
        }
        return phoneId;
    }

乍一看这个方法似乎没有问题，但真的没问题么？按照常理，这个方法写在AnswerPresenter.java里，那么可供操作的对象一定是INCOMING或者CALL_WAITING的call，因为来电界面一旦消失，那么这两种状态的call的状态也会立即跟着转变（我们假设当初写这个方法的作者也是这样想的），但是实际情况是，当停留在短信拒接的选择界面时，AnswerFragment的生命被延长了，即使call已经断开，界面没有消失，那么对应的call也就存留了下来。也就导致getActivePhoneId()方法有可能返回IDLE的call。

问题解法

方法一

其实这个方法的意图是返回一个有可“操作”的call的SIM卡对应的phoneId。那如果我们认定IDLE是不可操作的，那么我们把这个状态过滤掉就好了。改写判断条件：

	if ((mCall[i] != null) && (mCall[i].getState() != Call.State.IDLE)) {
        phoneId = i;
    }

但是实质上，更深入的想一下，这里想要获得是一个INCOMING或者CALL_WAITING的call所对应的phoneId，可修改条件为:

	if ((mCall[i] != null) && ((mCall[i].getState() == Call.State.INCOMING)
                || (mCall[i].getState() == Call.State.CALL_WAITING))) {
		phoneId = i;
		break;
    }

这样的话每次这个方法每次返回的phoneId对应的都是有来电的那张卡（修改已提交给CM http://review.cyanogenmod.org/#/c/109759/）。

方法二：

换个思路，问题复现的一个必要步骤是，在第一次来电的时候上滑停留在短信拒接选择短信的界面，之后来电断开，在之后问题复现。那么如果我们在来电断开后就立刻dismiss掉选择拒接短信的Dialog，这个问题也可以被解决（OPPO就是这么做的）。这么修改似乎都可以说的过去，但是，短信拒接的界面还提供了另一个选项“自定义短信回复”，如果用户正在编辑一串短信，而这个Dialog突然就随着来电的断开就dismiss掉的话，有点不合常理不近人情的感觉。所以我个人建议还是保留Dialog的显示。

其他

Q&A

有人可能会问，为什么在call disconnect以后call没有被清理掉？下面就是原因：

    @Override
    public void onDisconnect(Call call) {
        // no-op
    }

因为onDisconnect()里面什么都没有做、、

附加问题

在处理这个问题的过程中，我发现只要我们停留在短信拒接选择短信的界面，对方挂断来电，那么之后本机再选择短信都是发不出去的。 之前的原因是getActivePhoneId()返回了的phoneId对应IDLE的call，加入修改后getActivePhoneId()返回-1，不对应任何call。无论哪种原因，都是发不出去短信的。那么我们保存最后Incoming的call，另外开辟一条发送短信的路就是了，具体方法不写出来了。

对比Android M

在M上有人发现了不能接听/拒接来电的问题（好像M上复现起来更容易，步骤更简单），于是他在onDisconnect()方法里将mCall = null了(http://review.cyanogenmod.org/#/c/124087/)。这样修改可以解决这个问题，但是我上面提到的来电断开后不能成功发送短信的问题还是存在的（Mokee开发群里就有人发现了这个问题，本以为这个问题几乎不会有人发现，后来我还是改了一下提交到Mokee了，解法与L类似。）

总结

call的状态的变化有时候并不如我们预料的那样，CallList里面不存在的call不一定在其他地方不存在，有可能因为其他原因call的生命被延长了。