IssueTracker

Can you eloborate further on how you are creating the group here ?

I tried out the negotiation path (from wifi direct settings) on two phones running MR0 & MR1 and did not see a persistent group created.

Are you creating an auto GO  ? We only support persistent auto GO on MR1. I can see how inviting an MR0 device from the auto GO will cause issues.

Now that I have had more time to experiment, I see that the problem occurs if JB MR0 or older device becomes a client.

The issue is due to a bug we had in JB MR0 device where we had supplicant create a persistent group even though the framework did not support it.

The only work around right now is to choose a higher intent value on JB MR0 or older device from the application.

I think this issue also affects ICS. Or at least, it is related.

Two bugs that are ruining my app:

Bug 36903750: ICS, receive invitation to connect, and device reboots. I heard you fixed a bug related to this (but I didn't see the change) but it gives me the stack trace:
01-26 14:37:12.520: E/AndroidRuntime(481): *** FATAL EXCEPTION IN SYSTEM PROCESS: WifiP2pService
01-26 14:37:12.520: E/AndroidRuntime(481): java.lang.NullPointerException
01-26 14:37:12.520: E/AndroidRuntime(481):  at android.net.wifi.p2p.WifiP2pService$P2pStateMachine.notifyP2pInvitationReceived(WifiP2pService.java:2331)
01-26 14:37:12.520: E/AndroidRuntime(481):  at android.net.wifi.p2p.WifiP2pService$P2pStateMachine.access$8000(WifiP2pService.java:444)
01-26 14:37:12.520: E/AndroidRuntime(481):  at android.net.wifi.p2p.WifiP2pService$P2pStateMachine$InactiveState.processMessage(WifiP2pService.java:1368)
01-26 14:37:12.520: E/AndroidRuntime(481):  at com.android.internal.util.StateMachine$SmHandler.processMsg(StateMachine.java:881)
01-26 14:37:12.520: E/AndroidRuntime(481):  at com.android.internal.util.StateMachine$SmHandler.handleMessage(StateMachine.java:741)
01-26 14:37:12.520: E/AndroidRuntime(481):  at android.os.Handler.dispatchMessage(Handler.java:99)
01-26 14:37:12.520: E/AndroidRuntime(481):  at android.os.Looper.loop(Looper.java:137)
01-26 14:37:12.520: E/AndroidRuntime(481):  at android.os.HandlerThread.run(HandlerThread.java:60)

That is from Android 4.0.4 on invitation from Android 4.2.1.

Bug 36903751:
Try reversal of bug 36903750: Android 4.0.4 sends request to 4.2.1.  The invitation pops up - But only if you go into the Wifi Direct menu first since the other device will never find you as a peer it seems. It is incredibly unpredictable.

As soon as I press accept, it hangs the system. I have attached the bug report. I wish there could be updates to the older versions so perhaps they actually would get an update. I know a lot of devices aren't going to see JB MR0 much less MR1 with the filesystem change. Using wifi direct in my application has been one headache after another after another. I do not know if this is why invitation requests don't always arrive on 4.1/4.2 devices when it's done from within an app.

Follow up note: Killing the system process and having ti restart will make Wifi direct invitations fail to work at all for what appears to be several minutes. I have an LG Mach on 4.0.4 and a Galaxy nexus on 4.1.2 and my Nexus 7 on 4.2.1. The nexus 7 hung (as I just mentioned in the previous post) and I removed all the groups. I had the LG Mach try to connect to my N7. It hung my N7 so I killed system. I then invited the LG Mach which was still waiting to connect. It did not reboot the LG Mach (surprisingly) but never finished even after about 2 minutes. I invited my Galaxy Nexus and it stated 'couldn't connect' (Should have its grammar fixed too).

Galaxy Nexus never saw an invite. After about 2 minutes I sent an invite to my N7 from my Galaxy Nexus and it did not open anything on my Nexus 7. My nexus 7 later auto-connected to the LG Mach that it had invited about 4 minutes before without having an invitation show up on the LG Mach.

So I really have no idea what's going on anymore.

I attached my N7 screenshot when the ICS invite came in and hung it.

A couple of suggestions here:

- Target your Wifi Direct application to JB and above. ICS had several issues unfortunately (from wifi driver perspective) and dealing with persistence (which did not exist at the time).

- For JB MR0,  Your best bet is to increase the "intent" if the device is lower than MR1 so that the MR0 device becomes a Group Owner for group formation.

If a MR0 device becomes group owner with a MR1 device, persistence will not get used and things should work.

If you have two MR1 devices, persistence will kick in.

How would you choose group owner intent if your device doesn't know anything about the other one? My app uses another method (not wifi direct) to transfer it's mac address to another device so they can set up a wifi direct application automatically. I could transfer it's version information, but then there's no way to reliably get the other device's IP address if you're the group owner (since there's no built in methods to get a client IP address). After I set up wifi direct I have to set up sockets so I've tried to design my app to have the one transmitting be the group owner and the other one be the 'client' so it's easy to find the IP address of the owner, given that the group owner intent works (which sometimes it doesn't it seems)

I've tried looking it up in ARP but it seems to clear itself really fast out of ARP.

I might just have to build in warnings that ICS Wifi Direct is broken. Kind of hard to target a ~10% marketshare...

You do not need other device's info to choose group owner intent. Just choose a higher value (lets say 10) if you detect your current platform version is less than JB MR1. The default value is 7 if you do not specify.

Are there any plans to add methods in the framework that will allow the host to find client IP addresses? If I can't set who the host is (since it would depending on the SDK_INT instead of who starts setting up the connection because their SDK_INTs may differ), depending on what I am doing I have to do a real hack job to get client IP addresses. Like if I am transferring a file, I have to have the file host's IP so a socket can connect. If I have multiple clients there is no reliable way to find the ip address of connected clients.

Since your application has control over both client & GO role, can you initiate the TCP connection setup from client always and use that connection ?

We will add API to fetch client IPs at some point, but right now you either have to do service discovery on top or just initiate connection from client.

I totally spaced that a socket can handle sending and receiving data as long as it is not simultaneous. Thanks for reminding me, that saved me a ton of extra work.

Still hoping for those new methods.

So essentially you can't invite a JB (any version) device from ICS. About 75% of the time it just forces the supplicant to restart on my JB phone/tablet.

Sigh.

Can you pull logs from JB MR1 if it is showing bad behavior on a invite ?

I'll try to get them when I can. I've had both it say 'you must disconnect from wifi' as well as it hanging, rebooting (kind of rare now) and the driver just rebooting. It's obvious since it throws the P2p state changed and cancels whatever my app is doing.

Also, please eloborate on what is happening. Only on a invite from a ICS device, JB MR1 has issues ? What device is this ?

Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO.