We are having issues with one of our two tango devices.
With one device it's really easy to create adf files and re localize. With the other it's very hard (same room, and scanning area).
Furthermore we are developing a multiplayer game by sharing the adf file. And the device who connects to the first one always has a offset in the y-axis.
Another experiment showed a quite strange behavior:
We placed the two devices in the docking stations right next to each other, closed all apps and rebooted both devices. Then we opened the explorer app on both devices and displayed the point cloud. Oddly enough the horizon line one device is much higher than on the other. Is this normal or is on of our devices miss-calibrated/broken.
Here are the two screenshots:
Even if these two tablets are physically at the same height level. They haven't the same Z because their initialization at 0 happens at the start of the service. You can check this with full diagnostic menu entry.
Related
Hello and thanks in advance for the help.
I am working on an app which provides range bearing to a particular spot based on GPS and compass.
From time to time (every week or so) I have noticed that the compass orientation freezes. I have installed a different compass app and, it doesn't freeze, but it is clearly giving a very wrong reading (for example, north indicated directly to the sun).
Similarly, Google Maps is showing the wrong reading. I am sure the bearing are wrong because if the sun was in the north we'd be really screwed :). Plus I have another compass on my watch, and it is OK, so I know where north really is.
I suspect the reason my app is frozen, and the other app is not frozen, is just because of the different animation approaches. The root cause appears to be that the sensor is "jammed" even though it is in a solid state.
I have tried recalibrating (maybe 40 times), shutting off the phone, resetting the phone, clear the app's memory, stopping the app, etc..
What I noticed today is that if I place my phone on its magnetic mount, all of a sudden the compass started working again once I remove it from the mount. So, to be clear, I am out in the woods many kilometers away from my magnetic mount when it is jammed but when I return to my car and put it on/remove it from the mount everything works fine again for a few days.
I have never had an electronic compass behave like this. Unfortunately google searches invariably point me to suggestions to recalibrate.
If it matters, the phone is a OnePlus 6T with Android 11, Oxygen OS 11.1.1.1
Thanks
Interestingly enough, I noticed that when developing, I can choose to run a Wear app on the phone instead of a Wear device. It looks the same--just huge, of course.
Based on https://plus.google.com/+AndroidDevelopers/posts/QhWQArNDfS3, I gather I could use ADB to make the phone screen small enough to do a fair imitation of a rectangular smartwatch...
But what about testing for round Android Wear devices? Is there something I can do to the phone (or a rectangular Android Wear device, for that matter) to make it show as a circle (and even better, identify as a round device to Android Wear) in order to test the round interfaces?
Yes, there's always cutting a round hole out of a page and holding that over the device, but that's obviously far from ideal.
You can test your app on a round emulator. Here are instructions how to do this: https://developer.android.com/training/wearables/apps/creating.html
EDIT:
About round and forcing round on a square device: you can try to pretend that the device is round, but it's a little hacky and ugly.
In your Activity you need to implement inset listener and then use reflection to change WindowInsets.mRound field. Then dispatch the insets further down the hierarchy. This will trick your views to think that the device is round.
Check this article about handling square and round: http://gruszczy.blogspot.com/2015/03/handling-round-screens-using.html It describes how insets with the information about device display type are delivered.
I want to run one app on two phones, and then display what these apps show onto the same tablet. Is this possible?
So for example show what phone #1 shows in the bottom left corner of the tablet screen and show what phone #2 shows in the bottom right corner.
All related answers are appreciated!
What you want to do is mirroring both phones screens, I know you can do it to your pc, not sure about tablets.
you can read more about this here
But from my experience, mirroring not working so good- in most of the solution you have to root the devices first, and it's probably be bit slow and not smooth.
I would recommend you just to put those 2 phones next to each other and make a video with the tablet.
I am driving some experiments with a pair of a-JAYS Four headphones (having 3 buttons on its wired remote/mic) plugged onto a Galaxy Nexus (ICS 4.0.2).
My issue is that only the middle button is 'recognised' by a test app I have written, i.e. triggering both Intent.ACTION_MEDIA_BUTTON and/or Activity.onKeyDown callback with KeyCode 79 when it is pressed.
Pressing the two other buttons don't trigger any of the previous methods. For info, those headphones and its 3 buttons work on Apple iPhones and Apple computers (at least a MacBookPro 2011), as advertised on the box...
Firstly I thought Android or my device could simply not handle more than one button on a wired jack remote (even if that sounds weird...) but then I had a try with a pair of headphones from HTC (the ones coming with one of their Desire device) having 3 buttons. Middle button would react the same way as my a-JAYS, but the two other buttons are also recognised with KeyCodes 87 and 88, respectively Play Previous and Play Next media keys.
So it seems that either the device or the low levels layers of Android are simply not able to catch certain headphones buttons signals :/ (at least those which are not 87 and 88)
Any idea anyone about how to make Android able to recognise other buttons/signals from such headphones as Apple compatible ones? Would it imply low levels drivers writing for ICS or am I missing something really obvious?
Any help would be much appreciated. Can post my test-app code if needed.
Cheers
The signals/ resistance from the volume control buttons (1.525-1.495 V for volume down, and 1.619-1.587 V for volume up) are currently unable to be recognized through the android framework's software. I believe this has to do with Apple having a patent on the designated volume controls and so Google won't release to developers how the framework recognizes particular signals through the fourth connector on the headphone jack. The center/mic/action buttons on headsets generally work, it shorts the path from ~2V to ~0V and Apple does not own the patent for that. If someone could figure out how to interact with the inputs on their own that would be huge. I am tempted to learn app development and find a workaround.
The problem is more complicated that it seems: http://david.carne.ca/shuffle_hax/shuffle_remote.html .
I have to emphasize that I am no expert on this topic, but from what I have read and tried so far I conclude that it is not impossible to have an Android phone respond to an iPhone headphone's volume buttons, but for some reason the performance is poor/lagging.
There are some apps trying to do the magic, but they are too unreliable for everyday use. I suppose the problem is that triggering the signal may have to be implemented at a lower OS level than most regular apps have access too.
The solution could probably be some kind of a ROM mod...
If you can implement this, I am sure it would be a big deal for the Android community, and maybe a good biz for you.
Kind Regards, your fellow Hungarian
Gergő
You have to press and hold the middle button while plugging the headphones to the jack. That will make the microphone work on an Android. It works on my HTC Thunderbolt.
I believe it's a hardware issue (at least in regards to Apple headphones). If you look at the plug on those they have four contacts instead of the normal three. I'm willing to bet they run their button signals through that extra contact. AFAIK, there is no Android equipment wth jacks to match that.
So, ultimately I don't believe you can make apple earphones with buttons work for android (as far as button functions go).
You have to hold the middle the whole time for it to work. If you let go and not playin music it says accsessary not supported but if u play music and let go it simply stops the music until you hold it again. Maybe tape the middle button shut really tight?
If you look at the four contacts, tip-ring-ring-sleeve (TRRS), and know that MOST headphone sets are:
tip: left
ring 1: right
ring 2: ground
sleeve: mic
(1/4 inch pro audio stereo plugs are known as TRS - tip-ring-sleeve)
although some reverse the ground and mic contacts, what you need to know as far as how the device recognizes the different buttons you have, is that those buttons are making a short between the ground and mic contacts.
(before IR, old school WIRED remotes for VCRs used resistance for different functions)
Now your homework to find out what is going on is:
measure the resistance between ring 2 and the sleeve for each one of your buttons
find out if it is a momentary short, or constant
if you have some other headphone/mic device that works correctly, measure those impedance (resistance) too
I don't know how into this you want to get, but you can buy resistors with the correct impedance to get the functions you want out of the Android device, the question is, do you know what functions the device is capable of, and what those impedances are that trigger that function.
daniel#destinypatrolsoftware.com
I installed the accelerometer sample app from the android SDK 2.3 om the device (Nexus s). I get several balls falling towards one side of the screen and nothing changes their position.
Is there any place in which the expected behavior of this application is described?
Does anyone here knows the expected behavior?
I suspects it exposed a problem with the hardware operation.
Thanks,
Yoav
Just ran it on a Nexus One... you hold the phone flat w.r.t. the ground. Tilting it slightly will cause the balls to fall towards the downmost edge of the screen, i.e. as if they were under the influence of real gravity.