有关快速重启wpa_supplicant时延时消息处理而引起的问题 - 草稿

先大概列一下android L上wifi打开流程:

应用可以通过wifiManager.setWifiEnabled(boolean)接口来控制wifi的开关,wifiManager是系统提供给应用的客户端接口,其通过aidl调用了服务端接口wifiServiceImpl.setWifiEnabled,这里会做一些简单的判断,如果符合条件,就会发一个CMD_WIFI_TOGGLED的消息给wifiController对象。wifiController与WifiStateMachine一样,也是一个状态机,也会有不同的state专门处理各种不同的消息。

在StaDisabledWithScanState和ApStaDisabledState状态下,因为涉及到快速切换wpa_supplicant状态的问题,原生系统上,在此做了一个workaround,通过预留mReEnableDelayMillis=500ms以保证wpa_supplicant成功打开后再处理接收到的消息。当然这个时间也是可以通过wifiController的常量WIFI_REENABLE_DELAY_MS定制的。

这里需要说明一下,从热点模式切换为wlan模式,cp2都需要shut down再restart,所以wpa_supplicant也会先关闭再打开。热点关闭时WifiController会enter到ApStaDisabledState状态,然后再收到WifiServiceImpl发来的CMD_WIFI_TOGGLED消息,由该状态来处理这条消息。在其enter()方法里,wifiController设置了三个变量:mDisabledTimestamp用来记录当前切换到本状态的时间;mDeferredEnableSerialNumber是一个计数器;mHaveDeferredEnable是一个标志位。具体用法下面讲。

enter()方法里会先stop supplicant。收到消息CMD_WIFI_TOGGLED后,会做如下处理:先判断Settings.Global.WIFI_ON值是否为1(这里涉及到wifiSettingsStore,详细流程不作分析),然后判断当前收到的消息是否需要defer。这里其实就是判断收到消息的时间与mDisabledTimestamp的时间间隔,是否大于mReEnableDelayMillis这500毫秒的时间。如果是,则返回false,该消息会被立即处理,状态机会切换为mDeviceActiveState,并且调用wifiStateMachine的接口去启动driver;否则就会重新打包一个CMD_DEFERRED_TOGGLE的消息,并将mDeferredEnableSerialNumber自增1作为arg1放到msg里,将原来的msg作为新msg.obj放到这条消息里。然后delay一段时间(保证能满足500ms的判断条件)再发给ApStaDisabledState。ApStaDisabledState收到该deffered的消息,需要判断arg1的值是否与当前的mDeferredEnableSerialNumber值相等,如若不等,则不会处理这条消息,wlan不会被打开。

目前的项目的新feature未考虑到这种机制,所以带来了一个问题:通过二维码分享相册里的图片,会生成一个随机ssid的热点并打开,此时若通过快捷菜单或者其它入口去打开wlan,会导致wlan无法成功打开。ShareService有一个策略是,在创建热点前会保存当前wlan的状态,在关闭热点分享后,恢复之前的wlan状态(特指打开的情况)。如果之前是打开的,当它收到热点断开的消息后,就去调用wifiManager.setWifiEnabled(true)打开wlan。但在此这前,快捷菜单或设置已经调用了一次该接口。所以现在情况变成了,在500ms内,同时收到了两条WifiServiceImpl发来的CMD_DEFERRED_TOGGLE消息,doDeferEnable中分别打包两条deffered的消息,参数值分别是50和51(只是举例)。第二次收到toggle消息时,mDeferredEnableSerialNumber会额外自增1,变为52.结果,就导致在处理deffered消息时,不能满足判断条件,wlan始终不会被打开。

class ApStaDisabledState extends State {

private int mDeferredEnableSerialNumber = 0;

private boolean mHaveDeferredEnable = false;

private long mDisabledTimestamp;

@Override

public void enter() {

mWifiStateMachine.setSupplicantRunning(false); // 停止supplicant

// Supplicant can't restart right away, so not the time we switched off  

mDisabledTimestamp = SystemClock.elapsedRealtime();

mDeferredEnableSerialNumber++;  //每次enter时都会自增1

mHaveDeferredEnable = false;   //初始为false,在收到第一条消息后置为true

}

@Override

public boolean processMessage(Message msg) {

switch (msg.what) {

case CMD_WIFI_TOGGLED:

case CMD_AIRPLANE_TOGGLED:

if (mSettingsStore.isWifiToggleEnabled()) {     //此时为true

if (doDeferEnable(msg)) {

if (mHaveDeferredEnable) {

//  have 2 toggles now, inc serial number an ignore both

mDeferredEnableSerialNumber++;

}

mHaveDeferredEnable = !mHaveDeferredEnable;

break;

}

if (mDeviceIdle == false) {

transitionTo(mDeviceActiveState);

} else {

checkLocksAndTransitionWhenDeviceIdle();

}

///M: check scan always avaliable only when ipo change from ipo on to off or airplane mode with no  ipo off

} else if ( mSettingsStore.isScanAlwaysAvailable() ) {

transitionTo(mStaDisabledWithScanState);

}

break;

……

case CMD_DEFERRED_TOGGLE:

if (msg.arg1 != mDeferredEnableSerialNumber) {

log("DEFERRED_TOGGLE ignored due to serial mismatch");

break;

}

log("DEFERRED_TOGGLE handled");

sendMessage((Message)(msg.obj));

break;

default:

return NOT_HANDLED;

}

return HANDLED;

}

private boolean doDeferEnable(Message msg) {

long delaySoFar = SystemClock.elapsedRealtime() - mDisabledTimestamp;

if (delaySoFar >= mReEnableDelayMillis) {

return false;

}

log("WifiController msg " + msg + " deferred for " +

(mReEnableDelayMillis - delaySoFar) + "ms");

// need to defer this action.

Message deferredMsg = obtainMessage(CMD_DEFERRED_TOGGLE);

deferredMsg.obj = Message.obtain(msg);

deferredMsg.arg1 = ++mDeferredEnableSerialNumber;

sendMessageDelayed(deferredMsg, mReEnableDelayMillis - delaySoFar + DEFER_MARGIN_MS);  

                                                                                                  //确保与enter的时间间隔大于500ms

return true;

}

}

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,036评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,046评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,411评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,622评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,661评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,521评论 1 304
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,288评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,200评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,644评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,837评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,953评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,673评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,281评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,889评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,011评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,119评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,901评论 2 355

推荐阅读更多精彩内容