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?
Related
there is an app from pioneer for controlling my AV receiver. Unfortunately it is no longer working on Android 11 or even 10.
It is called iControlAV5.
Now I have the idea, to check why the app freezes. Therefore I downloaded the app and loaded it to Android Studio.
Unfortunately I only reach the freezing point when the app has found the receiver in my local network...
How do I configure Android Studio so that I will be able to access my local network?
Any ideas?
Regards,
Dodger
I'm using libVLC in my Android app to stream video over rtsp from the camera that I'm connected to over WiFi.
In general, streaming works fine, but there seems to be streaming problem if I'm connected do the camera by WiFi (that provides no internet) and also have got mobile data turned on. I use bindProcessToNetwork to make sure that the streaming is done via my WiFi network. On some devices (like Huawei Mate 10 with Android 9) the streaming works ok (it seems to use WiFi and ignore having mobile data on), but on other devices (like Samsung Note 10 with Android 10) when I use new networking API it seems that VLC is trying to connect via the mobile data, and only after some time when it fails it decides to use my camera's WiFi (despite the fact that I used bindProcessToNetwork).
I get an error log
VLC-std: Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0
Suprisingly, it works fine if I connect to my WiFi from the system settings...
I found some comments that media streaming is done in a separate process, and it ignores calling to bindProcessToNetwork but on some devices (and Android versions) is seems to work and on others it does not.
I already asked this question on the Videolan forum, but with no luck.
Is there a way to force libVLC to stream using a specified network?
I don't think LibVLC can do this, and it's a bit out of scope of a multimedia framework.
I would handle this on the app side if I were you, using something like How do I connect to a specific Wi-Fi network in Android programmatically?
so my original goal was to install an external GPS module to a single board computer running android and be able to run navigation apps using the GPS data from the GPS module. I first tried using a raspberry pi 3 running android things. I bought a GPS hat for it and found this appropriate driver
https://github.com/androidthings/drivers-samples/tree/master/gps
However, after installing android things I decided that it wasn't exactly what I was expecting and wanted a full-fledged version of android along with access to the google play store. I am currently debating buying a Odroid single board computer and installing Android on it, not android things. My question is, would the driver above work with Android and my GPS module? The Odroid I am looking at has the same 40 pin layout as the pi so the GPS hat should connect properly.
This drivers use the Android thing peripheral IO library, which is not available on standard Android.
So, in short: No.
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!
(originally asked on GoogleGroup support)
If you are experiencing an issue please mention the full platform your issue applies to:
IDE: NetBeans
Desktop OS: Mac
Simulator: none, due to Bluetooth usage which is not available on Simulator
Device: Android phone
Bluetooth device: pedometer
It seems BLE support is unreliable. I turn on my Bluetooth device that I'm trying to connect to (a pedometer), then on the phone I start scanning for the device, and sometimes it picks up, sometimes not. If it does pick up, I try to connect using the address, and I get a "Could not connect to device". (incidentally, if I use isConnected(), it throws an exception saying it was never connected. I assumed it would just return false)
I'm trying to duplicate a native iOS app, which has no issue connecting to the pedometer every time.
I've been searching for a "best practices" on BLE comms, but can not find anything substantial. The link the Cordova docs are cumbersome due to requiring translation into the Codename One lib.
As you mentioned in the https://groups.google.com/d/msgid/codenameone-discussions/b2b022e0-47e3-4a4c-9c33-4998ce2ef65e%40googlegroups.com[thread in the discussion forum] the API is callback based and expects you to wait for a response from the device asynchronously.
This is because we ported a Cordova plugin to implement this functionality in a stable way. Since JavaScript doesn't support synchronous calls those weren't added.
We thought about extending the implementation but we also wanted to keep it as close as possible to the original so changes there can be brought in quickly.