Obsolete
Status Update
Comments
ry...@gmail.com <ry...@gmail.com> #2
I agree, allowing applications to field incoming wifi direct connection requests (rather than having to wait for user input) would be an excellent addition to the current API. Adding a new permission to the manifest that allows this and is displayed to the user upon download would take care of privacy concerns.
ke...@gmail.com <ke...@gmail.com> #3
I am pro this feature as it gives a much needed flexibility to the app developers. Such a manifest in the android would be great !
al...@gmail.com <al...@gmail.com> #4
I agree, allowing applications send and receive data without users accepts. The good option to configuration an authentication through manifest.
ru...@gmail.com <ru...@gmail.com> #5
Yes, I do need the same requirement. I can see the users having both smartphone and nexus 7 tablet more and more in near future. So, they do not need the user level authorization for their own devices (between android smartphone and tablet). And we can always make the connection providing certification between two devices if we are more concern about security issue. One device can share the certification to another so that in future the other device connection request to the one will be established automatically. And also these feature will add the number of possibilities for the application developer.
mr...@gmail.com <mr...@gmail.com> #6
This would be enormously helpful. I created a game that uses WiFi Direct, and right now the host needs to deal with up to 8 of these pop-ups before each short game. This and many other uses for WiFi Direct on Android that I can imagine are seriously hindered by a total lack of auto-accept.
I assume for security reasons this would somehow be limited, maybe by only auto-accepting from applications that have the same application signature or storing a certificate, but there really should be at least some avenue that doesn't require user intervention on each and every connection.
I assume for security reasons this would somehow be limited, maybe by only auto-accepting from applications that have the same application signature or storing a certificate, but there really should be at least some avenue that doesn't require user intervention on each and every connection.
sg...@gmail.com <sg...@gmail.com> #7
I also would like to have such manifest option. This is very useful in using the proximity based application to avoid such authorization from user and application can field such values.
mo...@gmail.com <mo...@gmail.com> #8
I would like this as well! To negate security issues the phone could prompt the first time the app attempts to do this (regardless of endpoint) and then offer the options to "Always Allow", "Allow for X minutes", "Deny" (like the old Java permissions on S60 phones)?
yo...@gmail.com <yo...@gmail.com> #9
There is the hidden API to handle the pop-up dialog by your application from Android JB.
See setDialogListener() in WifiP2pManager.java. However, it is NOT supported officially because it's a hidden. This API can be used in the foreground application due to security issue.
See setDialogListener() in WifiP2pManager.java. However, it is NOT supported officially because it's a hidden. This API can be used in the foreground application due to security issue.
sm...@gmail.com <sm...@gmail.com> #10
Does anyone know if a foreground service is capable of doing what @yoshihik...@gmail.com mentioned?
I've managed to override the functionality using an Activity but not a foreground service.
I've managed to override the functionality using an Activity but not a foreground service.
ej...@gmail.com <ej...@gmail.com> #11
This feature would be really useful for my app as well. I have two device that need to connect over wifi direct. I will not have easy access to one, as it will be mounted somewhere, just need to send 1 command to the device, without any user interaction.
cd...@gmail.com <cd...@gmail.com> #12
If there is a safe way to add this functionality, it would be extremely useful. I liked the ideas about application certificates or a special manifest registration.
mg...@gmail.com <mg...@gmail.com> #13
This would be very useful for developers. The only way to change it to write your own rom currently which is well out of the scope of nearly all devs. Perhaps a notification saying a Wifi direct connection has occured would be helpful.
ro...@gmail.com <ro...@gmail.com> #14
In order for wifi direct to be useful for anything further than a rudimentary file transfer service Android has to take these steps. This function has so much potential but the permissions stuff makes it too cumbersome to use for any serious development. Im sure that Google has invested a lot of dough into this feature, hoping that it will separate them from the Iphone pack, but why do all that to develop a feature that is half-baked? Google- go the last mile and make it something we can use!!!
ne...@gmail.com <ne...@gmail.com> #15
I am wireless network researcher and I agree that this feature is sorely needed. We need it so that we can form ad-hoc networks on the fly. With ad-hoc mobility, its difficult for the user to keep accepting connections manually.
jv...@gmail.com <jv...@gmail.com> #16
nd...@gmail.com <nd...@gmail.com> #17
I have an app that is a remote control for another WiFi direct enabled device. When I start the app I'd like it to be able to silently connect to the device it is controlling without user interaction. The two devices authenticate anyway once the wifi direct link is up. Both the product and the app will be produced by us.
I don't want to use a standard AP in our product as it has no internet connection and a standard AP/Station arrangement would cause the mobile device to lose it's 3G connection. I don't want to use an AP in the mobile device because that's even more effort for the user than accepting a pop-up. WiFi direct is the optimal solution, point-to-point with no routing, mobile device stays connected to an AP or 3G and retains its internet connection. I just need to be able to re-connect silently once the devices have been connected for the first time.
I don't want to use a standard AP in our product as it has no internet connection and a standard AP/Station arrangement would cause the mobile device to lose it's 3G connection. I don't want to use an AP in the mobile device because that's even more effort for the user than accepting a pop-up. WiFi direct is the optimal solution, point-to-point with no routing, mobile device stays connected to an AP or 3G and retains its internet connection. I just need to be able to re-connect silently once the devices have been connected for the first time.
ma...@gmail.com <ma...@gmail.com> #18
Some valid points raised on utilising the API's for Wifi Direct. I would like to see more comments; especially from Google on this.
As developers we know where this technology is going. Sorry apple, not keeping up(IMO).
A few points I would like to address:
1. Why not implement a key or a unique identifier embedded in the code between devices running the same application?
2. Users with a common interest to have the same Android application installed on their device should not have to connect with a prompt and press accept(AndroidManifest.xml?).
3. Utilising this where there is a common application doesn't pose any threats because the user has agreed to the permissions on the Google Play Store. If an app says what it does then it should without being malicious. Simple as that.
I hope to hear some more comments on this.
Kind Regards,
ALK.
As developers we know where this technology is going. Sorry apple, not keeping up(IMO).
A few points I would like to address:
1. Why not implement a key or a unique identifier embedded in the code between devices running the same application?
2. Users with a common interest to have the same Android application installed on their device should not have to connect with a prompt and press accept(AndroidManifest.xml?).
3. Utilising this where there is a common application doesn't pose any threats because the user has agreed to the permissions on the Google Play Store. If an app says what it does then it should without being malicious. Simple as that.
I hope to hear some more comments on this.
Kind Regards,
ALK.
ne...@gmail.com <ne...@gmail.com> #19
Disclaimer:
1. The following only works on devices running AOSP or CyanogenMod. This is not going to work for those who does not want to recompile your own ROM.
2. I am not a developer, but a researcher who is fine with a quick and dirty hack to make my prototypes work. So I can't and don't know how (yet) to "develop an app" to easily rid the dialog box.
3. This probably won't help you at all if you are not familiar with the below. Best to wait for Google to address this.
The popup dialog that asks for the user to accept/reject a WiFi Direct connection is stored in "<aosp source>/frameworks/base/wifi/java/android/net/wifi/p2p/WifiP2pService.java"
Find the function called "private void notifyInvitationReceived()". Modify it to look like this,
private void notifyInvitationReceived() {
/*
comment away all existing code
*/
/* The following line is added to auto-accept any connections */
sendMessage(PEER_CONNECTION_USER_ACCEPT);
}
Recompile AOSP with this modification and flash your device. I believe only Google Nexus devices run AOSP natively. I verified that this modification works with a trio of tilapias (Asus Nexus 7 3G). WiFi Direct connections are auto-accepted.
Open-source ROMs based on AOSP should have this file as well. However, the last time I tried to run CyanogenMod on a pair of GT-P3100 with a GT-I9100, WiFi Direct does not work at all. I believe it was CyanogenMod 10.1, not sure if any recent releases fixed it.
1. The following only works on devices running AOSP or CyanogenMod. This is not going to work for those who does not want to recompile your own ROM.
2. I am not a developer, but a researcher who is fine with a quick and dirty hack to make my prototypes work. So I can't and don't know how (yet) to "develop an app" to easily rid the dialog box.
3. This probably won't help you at all if you are not familiar with the below. Best to wait for Google to address this.
The popup dialog that asks for the user to accept/reject a WiFi Direct connection is stored in "<aosp source>/frameworks/base/wifi/java/android/net/wifi/p2p/WifiP2pService.java"
Find the function called "private void notifyInvitationReceived()". Modify it to look like this,
private void notifyInvitationReceived() {
/*
comment away all existing code
*/
/* The following line is added to auto-accept any connections */
sendMessage(PEER_CONNECTION_USER_ACCEPT);
}
Recompile AOSP with this modification and flash your device. I believe only Google Nexus devices run AOSP natively. I verified that this modification works with a trio of tilapias (Asus Nexus 7 3G). WiFi Direct connections are auto-accepted.
Open-source ROMs based on AOSP should have this file as well. However, the last time I tried to run CyanogenMod on a pair of GT-P3100 with a GT-I9100, WiFi Direct does not work at all. I believe it was CyanogenMod 10.1, not sure if any recent releases fixed it.
ma...@gmail.com <ma...@gmail.com> #20
Hi neverwal...@gmail.com,
Thank you for your input. Its nice to know it's possible but unfortunately in the real world most users won't know how to update, let alone know that CyanogenMod exists. Doesn't work for my app unfortunately.
I am running a GT-I9100 but the rest of the world isn't. So I guess we will have to wait and see what google is going to do on this wifi direct issue. However, thank you very much for your input. Cheers :)
Thank you for your input. Its nice to know it's possible but unfortunately in the real world most users won't know how to update, let alone know that CyanogenMod exists. Doesn't work for my app unfortunately.
I am running a GT-I9100 but the rest of the world isn't. So I guess we will have to wait and see what google is going to do on this wifi direct issue. However, thank you very much for your input. Cheers :)
lm...@gmail.com <lm...@gmail.com> #21
I'd also like to see a solution to this. Could we not have a feature whereby if the signature of the app (or some kind of shared key in the app) matches then the prompt does not show? To properly implement a P2P mesh network we need the connections to happen silently in background processes.
Is this not how AllJoyn currently works with the Wifi Direct option enabled, or does that result in a prompt too?
Is this not how AllJoyn currently works with the Wifi Direct option enabled, or does that result in a prompt too?
lm...@gmail.com <lm...@gmail.com> #22
Edit: On a side note, is there any way to "forget" an existing connection to a device to force the prompt again (for testing)?
ma...@gmail.com <ma...@gmail.com> #23
With Android 4.2.2 there is the possibility to remember the previous
groups. If a previous group has to formed, pop-up window is not shown
groups. If a previous group has to formed, pop-up window is not shown
lm...@gmail.com <lm...@gmail.com> #24
@Mario: This is true, but it's still a pain to have to accept all connections in the first place. While that's fine for quick file transfers between two devices, it defeats the object of having such a powerful P2P library.
ma...@gmail.com <ma...@gmail.com> #25
Interesting, however a common key or unique identifier that an app uses would be more suitable as previously mentioned. For my purposes, this would be suitable because x number of users are running the app therefore they are "trusted" elimating the need to deal with a dialogue prompt to allow connection. If the devices connect once they may not necessarily connect ever again or they may.
It is trusting the developer to do the right thing. For me this would work because I take the approach that many users are running the app, therefore it should be trusted. Wifi direct would be perfect for this because I don't need Internet connectivity. Cheers.
It is trusting the developer to do the right thing. For me this would work because I take the approach that many users are running the app, therefore it should be trusted. Wifi direct would be perfect for this because I don't need Internet connectivity. Cheers.
lm...@gmail.com <lm...@gmail.com> #26
@mail Yes, it would probably require a new manifest permission, such as "Automatically allow Wifi Direct connections from other users of this app" so users are aware that other people will be connecting without warning.
at...@gmail.com <at...@gmail.com> #27
Would love to see this implemented! I think it's badly needed.
ma...@gmail.com <ma...@gmail.com> #28
Yes atrauzzi,
Badly needed and presenting users with a dialogue box takes the "fun" factor out of say a game for instance.
Badly needed and presenting users with a dialogue box takes the "fun" factor out of say a game for instance.
gh...@gmail.com <gh...@gmail.com> #29
Android 4.3 removed setDialogListener.
This is a step backwards. WiFi Direct needs an auto-acceptance API.
This is a step backwards. WiFi Direct needs an auto-acceptance API.
st...@gmail.com <st...@gmail.com> #30
The removal of setDialogListener is a set back for the implementation of seemless networking between services. If a user trusts an application and is aware of the networking permissions required and the reasons for the use of P2P connectivity at the application level, then I personally fail to see why the dialogs are required.
If it is now policy for Wi-Fi Direct to not be used for applications such as application-level networking or multiplayer gaming beyond small numbers, then I think this should be made clear to the development community.
If there must be a dialog prompt, perhaps have a mechanism that requires the user to supress all future dialog prompts in a session with an "accept all" option.
A step backwards is putting it mildly.
If it is now policy for Wi-Fi Direct to not be used for applications such as application-level networking or multiplayer gaming beyond small numbers, then I think this should be made clear to the development community.
If there must be a dialog prompt, perhaps have a mechanism that requires the user to supress all future dialog prompts in a session with an "accept all" option.
A step backwards is putting it mildly.
fe...@gmail.com <fe...@gmail.com> #31
Needed so bad.
ra...@gmail.com <ra...@gmail.com> #32
This could become a very good alternative for Apps to share application data.
no...@gmail.com <no...@gmail.com> #33
#9 smileymc...@gmail.com
Hey smileymc...@gmail.com. how did you override the functionality of setDialogListener()in your Activity.
Hey smileymc...@gmail.com. how did you override the functionality of setDialogListener()in your Activity.
ma...@movilok.com <ma...@movilok.com> #34
Not requiring user confirmation for Wifi Direct connections opens the door to use this technology in M2M applications, otherwise it is hardly possible.
Security concerns are always important, but a balance must be reached between security and usability. Modern mobile OS no longer prompt the user to confirm an HTTP connection as old J2ME devices used to do. In Android this was moved to the Manifest.xml file and permission declarations, why not doing something like that for wifi p2p?
Security concerns are always important, but a balance must be reached between security and usability. Modern mobile OS no longer prompt the user to confirm an HTTP connection as old J2ME devices used to do. In Android this was moved to the Manifest.xml file and permission declarations, why not doing something like that for wifi p2p?
du...@gmail.com <du...@gmail.com> #35
I am shocked that this issue has been open for so long. This feature is needed badly. Are there any workarounds?
re...@gmail.com <re...@gmail.com> #36
be...@gmail.com <be...@gmail.com> #37
Why this issue is still opened after a year ? Such functionality is strongly required to enable M2M opportunistic networks using smartphones.
pe...@gmail.com <pe...@gmail.com> #38
I agree. This functionality would bring many advances in mobile network developing.
ti...@gmail.com <ti...@gmail.com> #39
I also support this, as i need it. give it a special permission to make it transparent to the user and then make it possible, please.
Thnaks
Thnaks
da...@gmail.com <da...@gmail.com> #40
Come on google do not lets us down and this to your API's
gu...@gmail.com <gu...@gmail.com> #41
indeed where are they?
seems they smell the cash over that part ....
seems they smell the cash over that part ....
ya...@gmail.com <ya...@gmail.com> #42
I work on an open source project called Thali [1] which provides a framework to allow apps to securely communicate directly between devices. We were hoping to use Wi-Fi Direct to support ad-hoc connectivity in places like under served areas, disaster zones and even festivals, offices and conferences.
Thali is built using the CouchDB protocol and so uses a synch based model. Therefore we would want to be able to support devices opportunistically connecting over Wi-Fi Direct and automatically exchanging information without user intervention in cases where the other party is authenticated as having permission to send/receive data.
But, Wi-Fi Direct as now implemented by Google would create an experience where the user would spend all of their time being harassed by their phone as it constantly asked for permission to allow someone to connect. So unfortunately Wi-Fi direct as currently implemented is not workable.
Please Google, make Wi-Fi Direct useful, give us a permission or other mechanism that lets an app accept Wi-Fi Direct connections programmatically.
[1]https://github.com/thaliproject/thali
Thali is built using the CouchDB protocol and so uses a synch based model. Therefore we would want to be able to support devices opportunistically connecting over Wi-Fi Direct and automatically exchanging information without user intervention in cases where the other party is authenticated as having permission to send/receive data.
But, Wi-Fi Direct as now implemented by Google would create an experience where the user would spend all of their time being harassed by their phone as it constantly asked for permission to allow someone to connect. So unfortunately Wi-Fi direct as currently implemented is not workable.
Please Google, make Wi-Fi Direct useful, give us a permission or other mechanism that lets an app accept Wi-Fi Direct connections programmatically.
[1]
sh...@gmail.com <sh...@gmail.com> #43
Its been two years since this issue was reported. I am working on an application related to disaster management and p2p connectivity without user manually permitting the app is a big hinderance for me. Apple is way ahead when it comes to p2p connectivity as it already allows multi-peer connectivity from iOS7+ .
Lets hope GOOGLE addresses this issues soon as well.
Lets hope GOOGLE addresses this issues soon as well.
vl...@gmail.com <vl...@gmail.com> #44
Same problem here. I'm doing my PhD on P2P mobile systems and I would love to have this feature in place. Google should really do something about it.
13...@gmail.com <13...@gmail.com> #45
I'm developing p2p mobile system that uses wi-fi direct for automatically exchange messages between peers. Ability of auto-receive is, in fact, essential for my developments. Please add new manifest permission. Great potential of Wi-Fi direct and ad-hoc connectivity is wasted on those pop-ups.
Many enthusiasts and researchers would benefit with such feature.
Many enthusiasts and researchers would benefit with such feature.
mi...@gmail.com <mi...@gmail.com> #46
We seriously need a comment from Google on this. The best case scenario, I think, would be to allow the app to override the default behavior. Sometimes, for instance, it isn't even about "auto-accepting" p2p connections, it is about having a smoother, more integrated dialog to accept or decline.
en...@google.com <en...@google.com>
gh...@gmail.com <gh...@gmail.com> #47
Not obsolete. Feature requests still applies to Android 5.0
lo...@gmail.com <lo...@gmail.com> #48
That feature is missing and seriously needed by the research community, along with the support of issue 36904180 https://code.google.com/p/android/issues/detail?id=82
ma...@gmail.com <ma...@gmail.com> #49
This is not obsolete ! Always waiting !
bo...@gmail.com <bo...@gmail.com> #50
We are developing an app which requires devices to exchange data using wifidirect in background after forming an adhoc network. It would be a great advantage for everyone with similar issues to get this done. (add new manifest permission)
na...@gmail.com <na...@gmail.com> #51
What do you mean when you say it's obsolete? Has it been implemented now?
li...@gmail.com <li...@gmail.com> #52
This is a real issue for use cases involving forming ad-hoc mesh networks.
ma...@gmail.com <ma...@gmail.com> #53
Our research group would love to use this for Data Offloading from conventional networks to D2D links. WiFi Direct is the only available option for this currently. Having to have users accept popups every time they change links is not really a feasible way of communication. This still seems like an issue that could use proper solving (as suggested: add a new entry to the manifest)
na...@gmail.com <na...@gmail.com> #54
I am scratching my head over this pop up issue for long time. As far as I can see google does not have plans to fix this :(.
Does anybody have solved this with routed devices, and how ?
p.s @google how hard is for 3 years to add an new manifest permission ?
Thanks
Does anybody have solved this with routed devices, and how ?
p.s @google how hard is for 3 years to add an new manifest permission ?
Thanks
[Deleted User] <[Deleted User]> #55
[Comment deleted]
le...@gmail.com <le...@gmail.com> #56
has this been fixed/implemented yet?
to...@gmail.com <to...@gmail.com> #57
My team and I have been working with Android P2P API's for about six months. The devices connect but we get this connect approval pop up every 1 out of 10 connections or so. Google has to do something about this.
cs...@gmail.com <cs...@gmail.com> #58
This issue has lingered so long. I can understand security concern on one hand. On the other hand, it's undeniable that it has serious adverse effect on usability. We need a balanced approach. I propose the following fixes:
1. At the moment, if a mobile phone is in standby (i.e. screen off), a user won't be able to know there is a WiFi connection acceptance popup dialog waiting for acknowledgement. So, a WiFi connection acceptance process should behave similar to a phone call that will ring/vibrate/wake up screen based on the user's setting.
2. Secondly, record used in creating WifiP2pDnsSdServiceInfo may play a role in providing basic security for automatically accepting a connection if pairing devices configure the same user level 'match code' just as I did in my app where I added a random generated match code (e.g. ZX45E8R) to as part of a record for WifiP2pDnsSdServiceInfo.newInstance on both mobiles for service discovery. I use this for service handshake. Android could integrate a similar approach. For example, it may extend WifiP2pConfig to have a security code field for a user to specify a code for wifiP2pManager.connect. The WiFi P2P network infrastructure/dialog can then examine if the code has a match in WifiP2pDnsSdServiceInfo's record of the target device and to decide whether or not to pop up the dialog.
Whatever solution, we application developers need an automatic acceptance.
1. At the moment, if a mobile phone is in standby (i.e. screen off), a user won't be able to know there is a WiFi connection acceptance popup dialog waiting for acknowledgement. So, a WiFi connection acceptance process should behave similar to a phone call that will ring/vibrate/wake up screen based on the user's setting.
2. Secondly, record used in creating WifiP2pDnsSdServiceInfo may play a role in providing basic security for automatically accepting a connection if pairing devices configure the same user level 'match code' just as I did in my app where I added a random generated match code (e.g. ZX45E8R) to as part of a record for WifiP2pDnsSdServiceInfo.newInstance on both mobiles for service discovery. I use this for service handshake. Android could integrate a similar approach. For example, it may extend WifiP2pConfig to have a security code field for a user to specify a code for wifiP2pManager.connect. The WiFi P2P network infrastructure/dialog can then examine if the code has a match in WifiP2pDnsSdServiceInfo's record of the target device and to decide whether or not to pop up the dialog.
Whatever solution, we application developers need an automatic acceptance.
zh...@gmail.com <zh...@gmail.com> #59
OBSOLETE????
na...@gmail.com <na...@gmail.com> #60
[Comment deleted]
na...@gmail.com <na...@gmail.com> #61
Please allow me to connect wifi-direct without user approval.
ha...@gmail.com <ha...@gmail.com> #62
Not Obsolete. This issue really affects the usability of P2P connectivity based applications. IOS seems to be streets ahead in this.
al...@gmail.com <al...@gmail.com> #63
Please make this feature available guys, or give us an alternative at least!
This is getting so frustrating!
This is getting so frustrating!
xr...@gmail.com <xr...@gmail.com> #64
Why can't they really do something about it? Why is the solution with new PERMISSION and auto-accept not good? I really don't get it.
vi...@gmail.com <vi...@gmail.com> #65
Greetings.
I’ve developed mesh networking library for Android that uses Bluetooth in such way that it doesn’t need Discoverable confirmation from the user each 5 minutes. It also allows background connection between devices thus allowing true seamless mesh networking.
You can try it here:http://underdark.io
I’ve developed mesh networking library for Android that uses Bluetooth in such way that it doesn’t need Discoverable confirmation from the user each 5 minutes. It also allows background connection between devices thus allowing true seamless mesh networking.
You can try it here:
st...@gmail.com <st...@gmail.com> #66
Why obsolete? This feature can be very useful.
do...@gmail.com <do...@gmail.com> #67
[Comment deleted]
do...@gmail.com <do...@gmail.com> #68
I wish there is an insecure API for Wifi direct just as Bluetooth.
sa...@gmail.com <sa...@gmail.com> #69
Hurray Google ! Fuck all users !
Close the issue without the explanation !
Close the issue without the explanation !
st...@gmail.com <st...@gmail.com> #70
[Comment deleted]
in...@gmail.com <in...@gmail.com> #71
This feature would be very useful and needed. It seems reasonable a manifest permission.
[Deleted User] <[Deleted User]> #72
Please reopen this issue. A lot more people would use Wi-Fi Direct if there were promptless connections. This is definitely not obsolete.
ro...@gmail.com <ro...@gmail.com> #73
Marking it as absolute without an explanation is a disservice to the Android project and goes against the open-source philosophy. Why is Bluetooth allowed to operate under a permission set and not WiFi-Direct?
sa...@gmail.com <sa...@gmail.com> #74
The Google developers reason that simply setting permission in the app brakes the security is completely valid.
Here is my proposal, which may be called temporary permission.
Somewhere in the Android Setting add section Allow temporary Wi-Fi Direct accept ion (from other devices).
Here also may be defined for how long this may stay valid, from several hours to several days.
Then , with the first request accepted, for the time set all the consequent requests are satisfied without pop-up
Here is my proposal, which may be called temporary permission.
Somewhere in the Android Setting add section Allow temporary Wi-Fi Direct accept ion (from other devices).
Here also may be defined for how long this may stay valid, from several hours to several days.
Then , with the first request accepted, for the time set all the consequent requests are satisfied without pop-up
in...@gmail.com <in...@gmail.com> #75
Hi,
I had the chance to delve into the matter these days, and i discovered some pretty interesting stuff. First of all, as I understood (but i could be wrong) the reason why there's the annoying popup is because is required by the wifi direct standard. In fact, the wifi direct prescribes an authentication with wps [Supported WPS configuration methods (PIN, or PushButton)], which is a pin or a push button. You can find a very detailed description here:
http://www.thinktube.com/tech/android/wifi-direct
The other interesting point is the wifi direct (as explained on that link) is not the best way to realise a distributed mesh network. The best way to obtain that result, is to use the ad hoc method. Ad hoc is pretty old, and it doesn't only allow a connection point 2 point between 2 devices, but also a multiple connection with multiple devices. To cut it short (because everything is explained on the link), google blocked the ad hoc connection on Android and refused to explain why (see Issue 36904180 ). Just to say that this feature could be very important in case of natural disasters, but it's clear that google doesn't care to save human lives, preferring maybe to safeguard some obscure commercial interests.
I had the chance to delve into the matter these days, and i discovered some pretty interesting stuff. First of all, as I understood (but i could be wrong) the reason why there's the annoying popup is because is required by the wifi direct standard. In fact, the wifi direct prescribes an authentication with wps [Supported WPS configuration methods (PIN, or PushButton)], which is a pin or a push button. You can find a very detailed description here:
The other interesting point is the wifi direct (as explained on that link) is not the best way to realise a distributed mesh network. The best way to obtain that result, is to use the ad hoc method. Ad hoc is pretty old, and it doesn't only allow a connection point 2 point between 2 devices, but also a multiple connection with multiple devices. To cut it short (because everything is explained on the link), google blocked the ad hoc connection on Android and refused to explain why (see
fa...@gmail.com <fa...@gmail.com> #76
Hi,
It's probably pointless to complain to the Google devs, they simply implement the Wi-Fi Direct spec as it should be.
There are several companies involved in the writing of those specs, and the Android platform devs can't do whatever they want, they have to stick to the spec if you want it to be called Wi-Fi Direct.
The Wi-Fi Alliance is responsible for writing the specs, so it's this organisation which has to be contacted. Or you can get the membership and take part into the writing of the specs ($$$) :)
The current spec can be found here:
http://www.wi-fi.org/file/wi-fi-peer-to-peer-services-technical-specification-package-v12
It's probably pointless to complain to the Google devs, they simply implement the Wi-Fi Direct spec as it should be.
There are several companies involved in the writing of those specs, and the Android platform devs can't do whatever they want, they have to stick to the spec if you want it to be called Wi-Fi Direct.
The Wi-Fi Alliance is responsible for writing the specs, so it's this organisation which has to be contacted. Or you can get the membership and take part into the writing of the specs ($$$) :)
The current spec can be found here:
vi...@gmail.com <vi...@gmail.com> #77
No, the problem is that Google doesn't care about quality of Wi-Fi or Bluetooth implementation.
Because Bluetooth on Android do allow connection without confirmation (basically ad-hoc mode), but Bluetooth stack itself is buggy as hell.
So it's not a conspiracy — it's the buggy and careless software implementation from advertisement company (Google).
Because Bluetooth on Android do allow connection without confirmation (basically ad-hoc mode), but Bluetooth stack itself is buggy as hell.
So it's not a conspiracy — it's the buggy and careless software implementation from advertisement company (Google).
in...@gmail.com <in...@gmail.com> #78
I think everybody interested in Wifi direct without popups is basically interested in having ad hoc mode on Android. I opened an Issue 36949180 to request it. Please join me if interested. I'm sure they will close it as Issue 36904180 though. Actually i'm thinking to start a campaign on change.org . By the way, there is a subtle difference between ad hoc and wifi direct, wifi direct is basically a star configuration, while ad hoc is truly p2p. this has a huge impact for mobile devices. {see http://www.thinktube.com/tech/android/wifi-direct for topologies considerations)
vi...@gmail.com <vi...@gmail.com> #79
#78 Great cause!
But I think more realistic today (and in short term) is to start a campaign about Google fixing the buggy Bluetooth implementation on Android, because it basically allows the same thing as Wi-Fi Direct / AdHoc, but supported already on most devices (it's just buggy).
See my library that uses it:http://underdark.io
But I think more realistic today (and in short term) is to start a campaign about Google fixing the buggy Bluetooth implementation on Android, because it basically allows the same thing as Wi-Fi Direct / AdHoc, but supported already on most devices (it's just buggy).
See my library that uses it:
da...@gmail.com <da...@gmail.com> #80
Hi , i want to develop an android app for communicating 2 android devices in a local network without internet. I need a bidirectional communication between the devices and without pops ups of confirmation... its an application for a restaurant , sending customers menus directly to restaurant kitchen to be cooked ... what can u recommend me? im a bit new on android and learning a lot of this.. thanks!!
na...@makkiya.ca <na...@makkiya.ca> #81
It is not obsolete, people still want this, come on Google
mi...@naprvyraz.sk <mi...@naprvyraz.sk> #82
The closest thing to have Wi-Fi Direct features without prompt I've managed is to use Service Discovery combined with legacy mode, i.e. when the connection is supposed to happen, you don't use WifiP2pManager.connect() but WifiManager.enableNetwork() instead.
I'm the author of a very simple P2P stack which automates all the magic, you can check out an example onhttps://github.com/croconaut/wifon-mini to see how well/bad it works (plus some documentation).
I'm the author of a very simple P2P stack which automates all the magic, you can check out an example on
pu...@gmail.com <pu...@gmail.com> #83
This is not obsolete or any out dated feature. It helps to connect with people. Please anyone let me know if you found any fix for this.
do...@anyfi.io.c-035vjy74.appstempdomain.goog <do...@anyfi.io.c-035vjy74.appstempdomain.goog> #84
ra...@gmail.com <ra...@gmail.com> #85
there must be an option to directly connect without asking from users, I am developing an offline social media for cruise ships, etc. where user can connect offline to other when there is no internet connection, chat with them using wifi direct, the problem is if a user scans the device list then it asks for confirmation to accept and reject which is very weird.
read the complete details here:https://www.skydevelopers.net/blog
read the complete details here:
in...@gmail.com <in...@gmail.com> #86
is it possible to use "play-to" for P2P?
da...@gmail.com <da...@gmail.com> #87
This would be a good addition to the wifimanager api's
sa...@gmail.com <sa...@gmail.com> #89
This would be a great feature for people like me who are trying to build ad-hoc communication apps. User could give the permission at the lunch of the app for asking for permission on each connection is hindering from craeting an app which relies on wifi direct to pass data to other neighboring devices.
ch...@gmail.com <ch...@gmail.com> #90
The fact that this is still open after almost 10 years is discouraging
bl...@gmail.com <bl...@gmail.com> #91
Google definitely aren't going to do anything towards it at this point. I've had this article as an open tab for a while now, not sure if it's a good alternative or what's happening with it though: https://www.tomsguide.com/amp/news/google-just-made-wi-fi-way-better-than-bluetooth-heres-how
Description
I am trying to write an application that accepts wifi direct connection request, transfers data using sockets once the connection is setup and then disconnects it.
The current API requires the user to accept the connection manually.
If there is a workaround for that or an API for accepting P2P WiFi connection requests could become a feature for the next versions for android, that would be great.
Thank you.