I believed that any change in the list of peers (the inclusion or exclusion of a peer in the Wifi Direct range) could trigger the BroadcastReceiver.
Yes, I think this should happen.
In my app, when a new peer is found, its name is correctly included in a ListView, but if the peer leaves the wireless range (or if I turn off its Wi-Fi interface), the BroadcastReceiver is not invoked (more specifically, the WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION event is not triggered), and the peer name remains in the ListView.
We can try to dig through the source code and see if we can explain this behavior.
Note: I don't have a solution to offer. But, the following research might help you understand the 'issue' better.
We'll start here: WifiP2pSettings Link
This is the fragment you see when you go to Settings > Wifi > Wifi-Direct. If you go through the code, you'll notice that the implementation is quite similar to WifiDirectDemo project - the BroadcastReceiver listens for the same four actions (and two more - one for UI update). The reason why we're looking at this fragment is to check if the demo itself is flawed. But, it looks like the demo is alright.
Moving on - let's see who's broadcasting the action WIFI_P2P_PEERS_CHANGED_ACTION - ultimately, we're interested in finding out why this isn't happening as soon as a device goes offline/out of range. This takes us to WifiP2pService Link.
The method WifiP2pService # sendPeersChangedBroadcast() issues the broadcast:
private void sendPeersChangedBroadcast() {
final Intent intent = new Intent(WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION);
intent.putExtra(WifiP2pManager.EXTRA_P2P_DEVICE_LIST, new WifiP2pDeviceList(mPeers));
intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT);
mContext.sendBroadcastAsUser(intent, UserHandle.ALL);
}
From looking at WifiP2pService, you can tell that sendPeersChangedBroadcast() is called in response to several events. We're interested in this one: WifiMonitor.P2P_DEVICE_LOST_EVENT Link:
....
case WifiMonitor.P2P_DEVICE_LOST_EVENT:
device = (WifiP2pDevice) message.obj;
// Gets current details for the one removed
device = mPeers.remove(device.deviceAddress);
if (device != null) {
sendPeersChangedBroadcast();
}
break;
....
WifiMonitor # handleP2pEvents(String) is responsible for sending the message that lands in the above-mentioned case. Go up the chain to find MonitorThread - a static inner class in WifiMonitor. MonitorThread # dispatchEvent(String) calls the handleP2pEvents(String) method.
Finally, something interesting. Look at the run() method of MonitorThread:
private static class MonitorThread extends Thread {
....
public void run() {
//noinspection InfiniteLoopStatement
for (;;) {
String eventStr = mWifiNative.waitForEvent();
....
}
}
....
}
- first, we're inside an infinite-loop.
- second,
mWifiNative.waitForEvent() tells me that its probably a blocking call.
These two points put together indicate to me that I am not going to get a prompt response out of this - well, definitely nothing 'instant-like'. The method that we reached by going up the chain - MonitorThread # dispatchEvent(String) - is called from inside this infinite loop.
Let's check if something can support our educated guess:
Take a look at WifiNative class Link, especially the method setScanInterval(int). This method is called from class WifiStateMachine Link. Go through the method processMessage(Message):
....
case WifiP2pService.P2P_CONNECTION_CHANGED:
NetworkInfo info = (NetworkInfo) message.obj;
mP2pConnected.set(info.isConnected());
if (mP2pConnected.get()) {
int defaultInterval = mContext.getResources().getInteger(
R.integer.config_wifi_scan_interval_p2p_connected);
long scanIntervalMs = Settings.Global.getLong(mContext.getContentResolver(),
Settings.Global.WIFI_SCAN_INTERVAL_WHEN_P2P_CONNECTED_MS,
defaultInterval);
// ====>> Interval defined here
mWifiNative.setScanInterval((int) scanIntervalMs/1000);
} else if (mWifiConfigStore.getConfiguredNetworks().size() == 0) {
if (DBG) log("Turn on scanning after p2p disconnected");
sendMessageDelayed(obtainMessage(CMD_NO_NETWORKS_PERIODIC_SCAN,
++mPeriodicScanToken, 0), mSupplicantScanIntervalMs);
}
....
Notice the defaultInterval in the first if block. It's requesting R.integer.config_wifi_scan_interval_p2p_connected which is defined in config.xml Link as:
<!-- Integer indicating wpa_supplicant scan interval when p2p is connected in milliseconds -->
<integer translatable="false" name="config_wifi_scan_interval_p2p_connected">60000</integer>
60000 ms. That's 1 minute. So, if Settings.Global.WIFI_SCAN_INTERVAL_WHEN_P2P_CONNECTED_MS is not set, the scans will be spaced 1 minute apart.
Since, WIFI_SCAN_INTERVAL_WHEN_P2P_CONNECTED_MS is placed under global settings, we cannot change it. In fact, it can't even be read. Meaning, the only guarantee we have here is that the list of peers will be refreshed in under a minute. The interval can of course vary from brand to brand.
To verify this, I ran the demo on an asus tablet and a dell tablet. Like you said, device coming online was noticed fairly quickly (during the discovery phase). On switching wifi off, I clocked the response. The offline device was taken off the list automatically - with a substantial delay. The dell tablet took close to 60 seconds to notice that asus is offline. Asus on the other hand took 45 seconds.
To me, this seems like a limitation enforced by android. I cannot tell why. I hope that someone here can offer you a solution - possibly take this research and explore further. But I wouldn't be surprised if a solution did not exist (at present).
