I have recently had to change my work Android phone to an HTC Incredible S to use for Android NDK debugging. Unfortunately, the ndk-gdb script fails to attach the debugger, coming up with the error run-as: Package my.package has corrupt installation. I have tried all the usual fixes - uninstalling and reinstalling the apk, cleaning and rebuilding in Eclipse - several times, but to no avail. Also, I know the project is set up properly for debugging as I have been doing so successfully for a few weeks on a Nexus S.
Has anyone had any success with Android NDK on the Incredible S? And if so, did you have to do anything particular? I realise it may be necessary to root the phone and change the permissions of /data/data, but I want to avoid this if at all possible.
Thanks
EDIT: Okay, I've also tried the HTC Desire S, with similar results. Could anyone tell me of a phone they've used successfully for NDK multi-threaded debugging without rooting that's not the Nexus S? I've tried the Galaxy S II - the debugger connected but none of the breakpoints were hit - I think this is down to the Tegra chip at its core.
From my research with various phones, it seems that HTC Sense (or something that HTC add) changes something deep within Android that makes run-as fail (as it is so picky about the filesystem due to its SUID bit - fair enough). So if this helps anyone else - I would avoid trying to use an HTC for debugging (rooting might help, but I haven't tested it).
Phones that I have had success with are:
Google Nexus S and the Google Nexus One (I'm thinking any Google-branded phone with stock Android on will work).
Sony Xperia Play.
Related
Part 1 - Description of the problem
I have the DK2 and I am working on a VR project. This project uses FirefoxNightly. I've downloaded it and installed the WebVR Enabler Add-On
Got this from http://mozvr.com/downloads/
I have also downloaded and installed the latest SDK and Runtime for Windows from https://developer.oculus.com/downloads/
I am also getting this on the Oculus Configuration Utility (while the oculus is plugged in):
However, I have gone on another computer with windows.. installed everything just like on this windows computer and it clearly shows the Oculus Rift connected properly but the head tracking still not working.
EDIT: I just tried connecting the oculus rift to this "second" pc ( dell laptop ) and now it doesn't even recognize the oculus rift. Still no head tracking.
EDIT 2: I tried installing everything on a third PC without success. I'm getting "service unavailable" on the Oculus Configuration Utility
My display mode is set as shown in the image.
Part 2 - Questions
What am I doing wrong? Is there a step I forgot to do? The weird thing is, I have the same project running on Mac without having any problems. Yes, on windows I can see the screen through the oculus rift but head detection is just not present.
Part 3 - list of possible fixes that did not work
This reddit post talks about the firewall issue however I tried the oculus rift with the firewall disactivated without success.
This reddit post talks about a possible fix by reinstalling everything and updating certain drivers.. however I have followed this fix step by step without success.
This oculus forum post talks about the issue and one person proposes a fix that worked for him/her. I followed the fix without success.
Part 4 - System info
If you require specific translations let me know. It is in French.
Part 5 - List of things I have tried that have been thought of
I have reinstalled everything. SDK (is not even needed in fact), runtime, firefoxnightly, webvr add-on multiple times
I have rebooted my computer multiple times
I have tried the different Rift Display Mode
Basic demos from mozvr.com and other webvr based projects work fine but head tracking does not work.
My Oculus is not broken (maybe for windows), it works fine for the Mac.
I've tried using different HDMI cables and Different minUSB-USB cables without success.
Part 6 - Quotes from the forum
First post
This sounds like the same issue a lot of us are having with the 0.5
and 0.6 versions. It's not something wrong with the cables, but with
the Runtime itself. Direct-mode works flawlessly and in Extended mode
the rift still displays a picture, altho without any tracking etc from
the runtime. Hoping it'll be fixed in the next update.
I've seen head tracking break in Firefox Nightly sometimes but I can usually solve it by restarting the browser once or twice, assuming that the hardware and Oculus side of things is working correctly.
Today, most games made for the Oculus Rift are based on specific versions of the Oculus Rift. I found this GUI desktop application that seems to solve most of those problems.
The idea is to install all Oculus Rift Runtime versions and then use the GUI to switch between each version.
The link above is to a reddit post that talks about how to install the application and the different runtimes.
You must install the runtimes from oldest to newest otherwise you'll run into some difficulties, like I unfortunately did. If I'm not mistaken runtime version 0.8 is very buggy and I never really got it to work.
Good luck.
This is what I did to get the Oculus DK2 working on my Windows 10 Laptop:
Create a windows restore point before you start this.
Download oculus_runtime_rev_1_sdk_0.4.4_win.exe from the Oculus downloads page.
Run the installer. Do not restart your computer when prompted.
Go to C:\Program Files (x86)\Oculus\Service folder, right click on OVRServer_x86.exe and go to properties.
In the compatibility tab, check Windows 8 mode, and Run As Administrator.
Run OVRServer_x86.exe
That's it.
The Good News
You should now be able to run direct to rift games. The HELIX rollercoaster app works well. So does the 6000 Moons demo. Most others do not. Depending on the game, you may need to go to your windows display settings, and fiddle with the screen resolution and rotation of the Oculus display.
The Bad News
Your computer may not restart. When I did the above, and later restarted, the computer hung on the windows loading page. I had to go into advanced start mode and load a system restore point. Definitely not the best user experience, but at least I got something working.
I want to make a Windows store application using the monogame libraries, but for this purpose, I need to install Windows 8.1. The installation fails and gives me the error
0xC1900101 - 0x40017
This error is quite large and alot of people have had or still have it. I made alot of research on it and it seems that this problem is caused by driver incompatibility. I tried the installation about 15 times now, every time updating some drivers, installing updates, etc.
On the installation, it stops at 84% on "Applying PC parameters" step.
So I believe that the problem is that one of my drivers in incompatible and I need to remove it so here are my specs/peripherals:
ASUS G75VW qs71 laptop (16GB RAM, i7 ivy bridge) (I don't think it is the problem, since my friend has the same and it worked for him)
- Logitech G930 Gaming Headset
- Razer Orochi Mouse (Not the 2013, but the 2012)
If some of these drivers are incompatible, please tell me how to remove them.
Thank you.
P.S. I'm not sure if this question is relevant for this site, but it is somewhat programming related and I need it to do programmation.
I have my app working to my satisfaction both in the simulator and on two devices when debugging through Xcode 4.3.2. I use OTA Ad-hoc distribution to send to my beta testers. After archiving, saving, and uploading my ipa and plist file to my website, I then download and successfully install the app on my phone.
Sounds good, right?
HOWEVER, I am using CoreAudio and CoreData, and low and behold suddenly there is no sound in my app. I delete and install OTA on the same devices I am debugging with, so I am at a loss to where the problem is occurring.
I have a feeling that there might be an underlying problem with my Core Data model (which feeds my sound) but checks upon checks seem to verify that it is working. It DOES work when I install from Xcode, unplug, close, and reopen the app on the device. Only the OTA install has this problem.
Has anyone encountered any differences in behavior like this? I checked my build settings and the only difference I see for AdHoc is using the Entitlements.plist, which only useful setting appears to be NO to debugging.
I have the tools installed for windows phone 7 development.
But, when I run the any of the sample apps I have to manually refresh my emulator's app window to see any changes.
Any ideas what I'm doing wrong? Or maybe a setting is wrong?
Thanks
I've got it on every machine I've tried- but they all have various Nvidia cards (desktop and mobile).
When I posted about this on the wp7 forums, they talked about wdm 1.1 (which I've got) and so far I have no fix.
My machines are all 64bit, so I'm wondering if this isn't some issue with them or the nvidia drivers- but I don't experience any other problems with the drivers outside of the emulator.
I think we're stuck for a while anyway...
I recently started creating applications for mobile devices and have successfully completed an application for the iPhone. I am now turning my attention to the Blackberry but haven't been able to find a convincing article or website that states that it can be done or a tutorial on how to do so. Can Blackberry apps be developed on Mac OS X? If yes, how do I go about doing so? Can anyone please point me in the right direction as I only have access to a Mac and really want to get this project on the road. Thanks in advance for your help.
UPDATE:
RIM has released a MacOS Eclipse plug-in for Blackberry Development: http://na.blackberry.com/eng/developers/javaappdev/macosx.jsp
While there is no built-in simulator, the plug-in DOES support USB tethered device debugging for the Torch 9800 handhelds. I plan to get one; they are ~$499 w/no contract. With a Torch and the new plug-in, Blackberry development is possible without using a VM. (Finally!)
PREVIOUS POST:
Building on MacOS works well once you set it up. I've had less luck with the simulator. On the whole though, being able to run Eclipse natively in MacOS and flip to a Windows VM only for debugging is a big win in my book.
You can get a MacOS version of preverify (see link below for details). I do my development with Eclipse on MacOS X and use Ant to build BB apps.
This blog is excellent and has many of the details to get you started:
http://www.azizuysal.com/2009/07/blackberry-development-on-mac-os-x.html (original link is dead. The "wayback machine" provides us with the original text content, but images and styling are lost to the sands of time. Still worth a read.)
The tricky part is getting the simulator to work. There is a Wine-based work-around, but on my computer, while the simulator was able to run under Wine, the LCD output was scrambled.
Currently, I build COD files from Mac, and my Ant build process drops them into a directory that is shared with a WinXP VM. I can run the simulator stand-alone in this VM. Debugging is also possible by installing Eclipse inside WinXP and pointing the debug configuration it at the source directories.
I've actually got a bit more magic. I enabled some of the Java 1.5 features by compiling against 1.5 and then translating the bytecode to 1.3 prior to the preverify script. (Blackberry only speaks a barbaric 1.3 java, flashback to circa 1992). It's not a silver bullet as some features still don't work, but it does cut down on the need to make everything an untyped Object reference.
Lately, I've been working on a x-platform framework to allow me to write app code once and build against both Android and Blackberry (both are Java). The Android part was easy. It's just a bitch to debug anything in Blackberry. Someone working at RIM decided that Blackberry didn't need to keep Exception stack traces unless there was a catch(Throwable), and then they could do something bizarre, non-standard, and undocumented (catching Throwable behaves weird). I've only kinda-sorta figured out a hack to get stack traces using JavaLoader.exe without breaking into the debugger, and it's barely worth it.
p.s., I now do x-platform development with a single code-base targeting Android, Blackberry, and Desktop. Desktop is great for testing app functionality, with very little Blackberry on-device testing needed once features work in the desktop 'simulator' (a Swing GUI built for debugging our games).
Even though certain components of the RIM development platform are java-based, such as the JDE - other components such as the preverifier and device simulators are implemented as native Windows executables.
Basically, the easiest way to do it is to install Windows on your Mac using Bootcamp or Parallels and run inside a real Windows environment on your Mac.
However, there are other "hackier" ways to do it using Wine, MacPorts, and a number of other tools - as an example see this blog post