Ryan ZHENG的专栏

com.android.internal.util.AsyncChannel类的介绍与使用

手机作为AP时，关闭移动网络流量开关，STA端出现断开重连的现象

Android P WiFi扫描请求发起、扫描结果返回流程流程串联。

Android P WiFi扫描结果返回流程

Android P WiFi扫描请求发起流程

DHCP与ARP

[Android][WIFI]关闭WLAN耗时分析前言基于Android P(9) 分析流程梳理详见：[Android]Android P(9) WIFI学习笔记 - Framework (2)和[Android]Android P(9) WIFI学习笔记 - HAL (2)背景引发这个思考，是由于一个现象：在热点打开的时候，关闭WLAN耗时约为1s；在热点关闭后，再关闭WLAN，耗时在2s以上；这么一个一致性很差的现象，确实很难让人理解，于是翻开之前的流程图，开始了梳理之路；梳理

背景老规矩，先交代背景。现状是这样：wifi-ext-service.jar是我们开发的wifi的扩展接口的实现；wifi-service.jar与wifi-ext-service.jar均在编译时将代码混淆；wifi-ext-service.jar依赖wifi-service.jar；AOSP原生编译规则中，wifi-service.jar会静态依赖android.hardware.wifi-V1.0-java；一切都相安无事，直到现在有个开发需求，需要wifi-ext-service.

目录前文回顾前言入口WifiNativeIWifiChipIWifiCond`IWificond.disableSupplicant()``IWificond.tearDownInterfaces()`小结下一步计划：前文回顾WIFI学习笔记 - Framework (1)WIFI学习笔记 - Framework (2)WIFI学习笔记 - HAL (1)前言基于Android P源码学习；代码片为了方便阅读段经过删、裁减，请以实际源码为准；本篇旨在补全WIFI学习笔记 - HAL

WIFI学习笔记 - Framework (2)前言更多细节详见上一篇；基于Android P源码学习；代码片为了方便阅读段经过删、裁减，请以实际源码为准；调用栈 - 关闭WIFI与WIFI开启的调用入口一致，只是参数不同：开启：WifiManager.setWifiEnabled(true)关闭：WifiManager.setWifiEnabled(false)因此从App调用到WifiServiceImpl这一部分链路是完全一致的；从WifiController开始，两者执

背景事情起因是我在学习WIFI Hal部分时，发现一个比较困惑的地方：代码路径：hardware/interfaces/wifi/1.2/default/wifi_legacy_hal.cpp:wifi_error WifiLegacyHal::QcAddInterface(const std::string& iface_name, const std::string& new_ifname,

WIFI学习笔记Framework初始化流程SystemServer在调用到startOtherServices时，会通过mSystemServiceManager.startService(WIFI_SERVICE_CLASS);启动WIFI的SystemService，对应类为：com.android.server.wifi.WifiService构造WifiService时会同时构造出WifiServiceImpl： public WifiService(Contex

在上一篇中，我简单介绍了一下StateMachine的工作原理，并尝试用示意图的方式描述其运行机制。这一篇会从源码入手，对StateMachine进行一个详细的拆解；注意，如下所有代码片段均非源代码直接截取，而是经过了各种删减的，删减部分包括但不限于日志输出部分、不影响代码逻辑分析的分支判断等；同时，为了方便阅读、理解，对原有的英文注释也进行了删减，并添加了部分中文的，基于个人的理解；因此请勿直接使用；类与内部类State首先需要介绍一下State这个类；前面提到，StateMachine是处理

StateMachine介绍StateMachine,中文名状态机。顾名思义，是用于记录、切换状态的。除此之外，StateMachine还可以通过预定义执行的方法，使其在状态切换开始前、过程中、结束后分别执行不同的逻辑；接下来就对StateMachine进行一个简单的拆解；注意，如下所有代码片段均不是源代码截取，而是经过了各种删减的，删减包括但不限于日志输出部分、不影响代码逻辑分析的分支判断等；同时，为了方便阅读、理解，对原有的英文注释也进行了删减，并添加了部分中文的，基于个人的理解；因此请勿直接使

目录前文回顾前言入口WifiNative初始化打开WIFIIWifiChip前文回顾WIFI学习笔记 - Framework (1)WIFI学习笔记 - Framework (2)前言基于Android P源码学习；代码片为了方便阅读段经过删、裁减，请以实际源码为准；入口根据前两篇的分析结果，调用栈都汇聚到了WifiNative：打开Wifi：mWifiNative.setupInterfaceForClientMode(false, mWifiNativeInterfaceCa

前文回顾[Android]StateMachine介绍（一）——概览[Android]StateMachine介绍（二）——拆解这一篇会进一步介绍一些高级应用场景；State的层级关系State切换时的调用时序根据之前的了解，我们知道在State切入时会调用其enter()方法，在退出时会调用其exit()方法；但是那都是基于评级关系而言的，当State存在层级关系的时候，enter()/exit()的调用时序是否会存在差异呢？为了探究这点，我们先假设有如下State层级关系的状态机：

背景今天接到做WIFI以后的第一个问题分析，现象如下：复现步骤：机器连接某个特定WIFI （办公场所提供，无法登陆后台确认设置信息）机器再打开热点（即桥接模式）手机连接热点期望结果：手机可以正常连接实际结果：手机无法连接，始终停留在“正在获取IP地址”；这个问题比较“神奇”的地方在于：只有当机器连接某个特定WIFI时出现问题；连接该特定WIFI时稳定复现；连接其他WIFI时稳定不复现；出于直觉，这个问题很大概率上是这个WIFI设置与机器出现了不兼容的情况；但是仍然