IssueTracker

Same here. I have links in a local html file referencing file:///android_res/drawable/ and on all gradle build flavors using another applicationId (added suffix) the Webview only shows broken links.

This behaviour seems not to be connected solely to Android 5.0 since it occurs on Android 4.4.4 too (tested with current cyanogenmod 11 build).

As a hotfix I added the following code to the gradle buildscript, which generates an additional R.java with changed java package for every flavor. I don't like this solution though.

android.applicationVariants.all{ variant ->
  variant.javaCompile.doFirst{
   copy {
        from "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/R.java"
        into "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${variant.buildType.name}/"
    }
    File rFile = file("${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${variant.buildType.name}/R.java")
    String content = rFile.getText('UTF-8')
    String newPackageName = "com.example.application.${variant.buildType.name}";
    content = content.replaceAll(/com.example.application/, newPackageName)
    rFile.write(content, 'UTF-8')
  }
}

I've recenly encountered this issue and I must say it's quite a nuisance. Searched half of the Internet just to find out that the problem lies in Gradle's applicationIdSuffix :). I think this bug should be reported to Android SDK Build Tools devs, because only they can do something about it.

IMHO it's the case of Android platform problem. Resources are packed, WebView tries to load them from wrong place. It's not build tools that put them in wrong place.

And by the way it's very frustrating bug.

[Comment deleted]

[Comment deleted]

The applicationIdSuffix/packageName/etc seem to be a Gradle-specific concept that applies only at build time.

At runtime, the only way WebView has to identify your app is the actual package name of the APK, and that will be the full string with the suffix included. The package that was used at compile time when generating the R class is not stored in the APK, and there's not really any way for WebView to know what it was as far as I know.

[Comment deleted]

Isn't the package name attribute in the root node of the AndroidManifest preserved when an app is packaged? That would be the correct package to use when loading the R class

I don't think so. You could check what's actually in your packaged APK with "aapt dump xmltree <apkfilename> AndroidManifest.xml" - if it's not there, then WebView can't get to it at runtime either.

I haven't actually checked this as I don't have an android studio project handy currently (will try soon) but I suspect that Gradle passes the app name with the suffix appended to aapt with --package-name, which causes aapt to replace the name specified in your manifest with the one on the command line. The original name doesn't end up in the APK at all.

OK, I tried this out in Gradle to check what the terms that it uses really correspond to when building a package, and also read the docs at http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename

This has confirmed what I wrote in my previous comments, unfortunately. What Gradle calls the package name (the name of the package that your Java sources and R class are stored in) is *not* the APK's actual package name that gets set at build time, and is *not* stored anywhere at all or accessible at runtime whatsoever. The APK is solely identified by the application ID with the suffix added, and the original package name is overwritten in the manifest. Android itself does not have this concept of the package name and application ID being separate; it's just a build-time trick Gradle is doing for you.

So, unfortunately, it doesn't look like there is any way for WebView to reliably know where your R class is. We might be able to add an API for the app to specify this in a future version (though I'm not entirely sure how that would actually work; it'd probably have to be a static method on WebView?), but that won't help you for existing OS versions, we can't add new APIs retroactively.

I think your only short-term options are to not use applicationIdSuffix or to not use file:///android_res/ in WebView. You could instead use a different URL (one that isn't handled by WebView itself), intercept it with shouldInterceptRequest, and provide the data by reading it from your resources yourself. I understand that that's not very convenient, but it seems like the only actual option here that works right now.

One thing WebView could do which would work in *some* cases is to just try to strip off components from the package name if the R class isn't found, going up one package at a time until we find it. That would work if you've just added a suffix like ".debug" - we'd fail to find com.example.debug.R and then try com.example.R instead. That still wouldn't work for any case where the package name is totally different, though (which gradle permits you to do). I'll look into whether this is safe to do and if so we could maybe add this in a future webview update, but it still won't fix the problem for users of pre-Lollipop Android versions (who don't get WebView updates), or for users who just don't have the latest webview update installed, so you're going to have to work around this problem in your app anyway to continue supporting those devices. :/

I've filed http://crbug.com/599869 to track potentially handling the suffix case in the WebView code, but note that as I said, this will only fix it for users with the latest WebView on Android 5.0+ devices, and so you will need to still work around this in your application if you want it to work on any other devices.

#11 thanks for explanation

I think the whole scheme file:///android_res/ ideally should be deprecated in favor to android.content.ContentResolver.SCHEME_ANDROID_RESOURCE, which allows specify package and resId and used everywhere in Android except WebView.

http://androidbook.blogspot.ru/2009/08/referring-to-android-resources-using.html

http://stackoverflow.com/a/4855376/1430070

What do you think?

Perhaps, but again, we can't add that for existing users without updatable WebView versions, so even if we did add it, it wouldn't really solve the problem for your apps since ~2/3 of the android device population doesn't get webview updates yet: http://developer.android.com/about/dashboards/index.html

WebView 53 and onward will attempt to strip package name components from the app package name until it finds an R class, which will deal with the simplest cases here (applicationIdSuffix appending a suffix to the base name), but not other cases where the package name is unrelated to the R class name.

This won't fix it for users with pre-L android versions, or who don't upgrade to at least WebView 53 once it's released, though, so you will not be able to rely on this as a full workaround :/

Awesome! That updatable webview is one of the best thing you guys have done is the last couple of years!

Well, this doesn't really solve your actual problem (for years yet), as I said, since there's still a significant population of pre-L devices that you probably want to keep supporting, and not all L+ devices will ever get upgraded to a sufficiently recent WebView, but yes, the fact that we can do this at all is useful :)

Well I my problem was with dev build, and I do most of the development on
L+ devices so, it might not solve the real issue, but it is sufficient for
me :)

[Comment deleted]

The fix that had been applied is not working anymore.

There's regression caused by https://chromium.googlesource.com/chromium/src.git/+/95d6e720c235f105aa3182e2a1b2f826cfaa483f%5E%21/#F1
I've left a comment on https://bugs.chromium.org/p/chromium/issues/detail?id=599869#c12

I'm fixing this upstream on https://crbug.com/599869.

I'm going to close this bug as we aren't planning to do anything further to address this issue beyond the change made some time ago in #16 (and fixing it again after it broke in a more recent version)

Needed so bad.

This could become a very good alternative for Apps to share application data.

#9 smileymc...@gmail.com

Hey smileymc...@gmail.com. how did you override the functionality of setDialogListener()in your Activity.

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?

I am shocked that this issue has been open for so long. This feature is needed badly. Are there any workarounds?

#34 Dusted...@gmail.com:

As far as I know there is currently no workaround for non-rooted devices.

Why this issue is still opened after a year ? Such functionality is strongly required to enable M2M opportunistic networks using smartphones.

I agree. This functionality would bring many advances in mobile network developing.

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

Come on google do not lets us down and this to your API's

indeed where are they?
seems they smell the cash over that part ....

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

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.

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.

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.

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.

Not obsolete. Feature requests still applies to Android 5.0

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 

This is not obsolete ! Always waiting !

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)

What do you mean when you say it's obsolete? Has it been implemented now?

This is a real issue for use cases involving forming ad-hoc mesh networks.

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)

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

[Comment deleted]

has this been fixed/implemented yet?

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.

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.

OBSOLETE????

[Comment deleted]

Please allow me to connect wifi-direct without user approval.

Not Obsolete. This issue really affects the usability of P2P connectivity based applications. IOS seems to be streets ahead in this.

Please make this feature available guys, or give us an alternative at least!
This is getting so frustrating!

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.

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

Why obsolete? This feature can be very useful.

[Comment deleted]

I wish there is an insecure API for Wifi direct just as Bluetooth.

Hurray Google ! Fuck all users !

Close the issue without the explanation !

[Comment deleted]

This feature would be very useful and needed. It seems reasonable a manifest permission.

Please reopen this issue. A lot more people would use Wi-Fi Direct if there were promptless connections. This is definitely not obsolete.

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?  

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

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.

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

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).

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)

#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

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!!

It is not obsolete, people still want this, come on Google

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 on https://github.com/croconaut/wifon-mini to see how well/bad it works (plus some documentation).

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.

https://play.google.com/store/apps/details?id=io.anyfi.cosmos 

This app does what you are looking for. Connections happen automatically.

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

is it possible to use "play-to" for P2P?

This would be a good addition to the wifimanager api's

this app(https://play.google.com/store/apps/details?id=io.anyfi.cosmos) can not use in realme x2, keep in luancher

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.  

The fact that this is still open after almost 10 years is discouraging

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