I am trying to use gwt-mobile-webkit, particularly its location api. It works well with iPhone (both device and simulator) and Firefox and on G1 with 1.6 Android, however, it does not work on G2 with Android 1.5 on it. In result I am getting onFailure callback with Permission Denied error.
So it seems, that there is some geolocation API (gears or HTML5) in the browser available, but it just does not want to ask user for granting permissions.
Do you know if there is any workaround or just enable it somewhere in settings?
I had what sounds like a similar problem on G1. The fix for me was to do Factory Reset - a bit extreme, but it was the only solution I had at the time.
See http://groups.google.co.uk/group/android-discuss/browse_thread/thread/f9233991a1affbd5/3b318c6bed932790
I guess you have read the gears doc here on geolocation (android section):
http://code.google.com/p/geo-location-javascript/wiki/SupportedPlatforms#Google_Gears
Interesting that it says the permission is only asked once per site (see excerpt below).
"Gears is a javascript framework available for Android, Windows Mobile (IE Mobile, Opera Mobile), Mac (Firefox, Safari), Linux and Windows . One of its cores is the Geolocation API. On the mobile phone it asks the user once for permission per site and user, so not every session as in the iPhone OS 3.0."
I would try clearing the android browser cache and then re-visit the site to hopefully cause it to ask permission to enable geo location. - just a guess.
I know the support was flaky at best in 1.5 android.
Related
I have a very big problem and unfortunately I cannot find a solution. Help from some professionals would be really great. Thanks!
The little problem
I have a Angular Web App / Android App using Cordova. My app needs at least the Chrome Engine 50 to support all functions and looks right. Unfortunately I noticed that there are many devices that use a much older version. Also the devices do not use a common source for the Chrome Engine. Some use the Chrome Browser itself or the Android System WebView. In these two cases I can tell my testers, install the two things and then it works. Currently I check at the start of the app which version is installed and if it is less than 50 I show an info that users have to update ther apps / components particularly important here the two things (Chrome Browser itself or the Android System WebView). I rather say my users that they should update all ther apps because some hardware manufacturers have their own apps that include the Chrome Engine. That alone I find very unpleasant.
The biger problem
But it is worse with devices that have their own Chrome Engine built into the firmware. So one that you can not update at all via the apps update only just the hardware manufacturer of the phone can update them with firmware updates. So many cheap devices that don't get any more updates simply fall out and bring me possibly bad ratings.
What can you do?
Maybe someone has an idea? Because this way I can put my app in the store from Android 4.4 on but even 6.0 devices have older Chrome Engine versions in their firmwares. Can't I provide a chrome engine version or say I use it there from Chrome or from the Android system WebView? I'm really on the edge and need a clever solution.
I would be very happy about some help or exchange. Thanks a lot.
Best regards
Robi
I'm trying to port a web application to a native Android application using Cordova. It's fairly simple, primarily just sending Midi messages to a connected device. I know the WebMidi API is only supported on recent versions of Webkit on Android, and I have been testing on 5.1. I've managed to prove that the basics work by running the original web version on Chrome on the device, it works fine.
The problem when running in Cordova is the messages themselves are not sent for some reason, no error, just not getting there. I know the API is working, as a separate part of the application lists the connected devices and presents a dropdown list to choose from, this works fine, and recognises the connected Midi device. However, when I send messages they don't have the desired effect on the Midi device. They are SysEx messages, which I believe needs additional permissions, android.webkit.resource.MIDI_SYSEX, is it possible that this is enabled on Chrome but not on the Cordova application? I've tried adding this permission to the ./config.xml, and ./platform/android/AndroidManifest.xml but to no avail, it doesn't seem to have any effect, and doesn't even show as an additional permission when installed.
Based on various searches, I've also tried installing the Crosswalk plugin, but couldn't get that to work at all, not even the device listing.
Any thoughts welcome.
The problem you're facing is that you won't even be prompted for midi sysex permission unless you meet certain criteria. You either have to be accessing your web midi code via a localhost, OR on an https URL. Sysex is potentially harmful, so they have used this as a minimum security requirement.
I had it working on android by opening a URL on my to my dev PC (using a self signed SSL cert on wamp). It gives the security prompt for sysex and then works as expected, so chrome on android works for sure. Crosswalk Cordova however, I'm not so sure.
I've tried running a little webserver in my cordova app (on Android), starting the webserver on 127.0.0.1:8080 and then connected to it using chrome (separately on the same device). Feels tantalizingly close, but I need it to run in my app!
My attempts to run an iFrame with the webserver's URL (http://127.0.0.1:8080) have failed. it's just not found. No security error, so doesn't seem to be to do with white-listing, although I need to look into that further to be sure.
It seems that the webserver plugin is running successfully, but is not visible from within the app.
You should have a play with this, and see if it gets you anywhere...
Or perhaps you'll find another one that is visible from within the app itself.
The alternative approach is to use a socket server to connect to your computer, and have the midi devices connected to it. Not exactly portable though!
With physical web integration in new google chrome browser (still in beta), its possible to detect beacons that emit Eddystone Url frames.
source: http://www.blueupbeacons.com/index.php?page=/blog/physicalweb
I downloaded Chrome Beta, enabled physical web going to chrome://flags, gave the app access to location services, gave runtime permission for using location (I am using Marshmallow), but the browser still wasn't able to detect a beacon nearby. I tried using physical web app as well as Opera Labs version and both are able to detect the same beacon.
I am using RadBeacon USB by Radius Networks.
What am I missing here?
My first guess is that your URL is an HTTP URL. You have to be pointing to an HTTPS URL for Chrome to display it.
Chrome 50 will have a physical-web diagnostics page to show issues like this.
Now that Chrome 49 is out for Android, it's built in natively to the functionality but you still have to enable the physical web flag on your device (Chrome://flags#enable-physical-web). You will get prompted to restart the browser. Also, make sure your bluetooth is on and you allow Chrome to have access to your location which you will be prompted for. Now you should start to see Eddystone-URL broadcasts that are close to you. Make sure that your RadBeacon is Eddystone-URL compliant as I know that some of the usb beacons they released did not support eddy-url. I'm using a bkon beacon and it's working well. Make sure that your end destination site is https as well and you can do this for free using letsencrypt. Good luck!
Go to your chrome beta settings, then privacy and check if physical Web is on. Also, the broadcasting URL should be an https secured URL. Also, your browser location should be on.
Sometimes it takes time for your browser to detect for URL's. Try to lock your phone screen by pressing the power button and then unlock it. You should se physical web.
Repeat this activity several times.
Still if you are not able to see physical Web then try reinstalling chrome beta.
What's the first version/build of mobile Safari (on Droid & iPhone) which supports accessing the GPS fix by GeoLocation API?
I need to know exactly where the version break is - since elder version obviously do not support GPS fix, only WiFi estimation.
The ideal and for sure accepted answer would be user-agent strings of 2 consequent builds (of which one supports it while the other doesn't).
This is a re-post of a closed question, refined to match nicely into the Q&A scheme, hopefully.
Please do not post any hyperlinks to the W3C specs or similar Google top-hits for these keywords...
Merely the Safari & AppleWebKit tags are relevant - which have the build numbers.
This question is barely browser version/build related - built-in hardware GPS support is assumed -
It is also assumed, that GeoLocation API is enabled and that the user confirms the request.
You sound as if you just the answer you want to hear.
The actual answer is it's not that simple. You are making certain assumptions regarding hardware that aren't true.
Let's take the iPad for example. A second generation WiFi iPad and a 3G iPad have the same user agent. But only the 3G iPad has GPS. It's not the browser version that determines GPS, it's the hardware you're running on.
Furthermore, just because your device has GPS is no guarantee it will be used or available.
The 'ideal' answer that you're looking for simply doesn't exist: and even if it did, there would be thousands upon thousands of user agents you'd need, because it's dependent on many factors, including hardware and OS version.
I'm starting to develop an AR applcation and my development device is the one in the subject.
This target runs Android 3.1.
i covered all the steps needed to setup my environment and tried to run the Image Targets example that is supplied with the QCAR SDK but with no success.
Everything is complied and deployed successfully but when the application starts on the target i get an error:
"Network connection required to initialize camera settings.
Please check your connection and restart the application.
If you are still experiencing problems, then your device may not be currently supported."
While a network connection is present via Wi-fi to a local home network.
Anyone can suggest me what to do? I cannot replace my device and i must work with Quallcom's AR library.
Thank you very much
Soon apparently..
https://ar.qualcomm.at/qdevnet/forums
According to Qualcomm, the QCAR SDK now supports all android Eclair, Froyo, Gingerbread, and Honeycomb devices.
I found this thread, which lists four sanity checks:
Is your device connected to a wifi network with an internet connection?
Can you load a webpage using the Browser app?
Can you load an webpage at an https address?
Is the date and time on your device are set correctly?