cancel
Showing results for 
Search instead for 
Did you mean: 

Native activity crashes on input event

Anonymous
Not applicable
Hi!

I have a android native activity which uses native_app_glue. Everything works fine, except when I am debugging it and vr mode is activated. In that case for a simple touch event the application crashes at AInputQueue_preDispatchEvent (in android_native_app_glue.c, process_input function) with "SIGILL (illegal instruction)".

I have no clue what might cause it. I use Android Studio and when a start the same debuggable application without the debugger attached, it works as expected.

What am I missing?
11 REPLIES 11

Anonymous
Not applicable


Hi,

Welcome to the Oculus Forums.

Which Oculus engine integration or Oculus SDK are you using?

Is there anything helpful in this thread regarding this issue?



Hi!

I am using the VrApi 1.0.4 (build: 298951).
Debugging is working normally, nothing crashes when vrapi_EnterVrMode is not called. (I did not find any useful information in the thread regarding the issue.)

Anonymous
Not applicable
Hey guys,
 Any chance on a resolution here?  We have the same issue (using VRApi 1.5.0).  In order to get vrapi_EnterVrMode() (and vrapi_SubmitFrame()) happy, we had to "update" the Java portion of the ovrFrameParms structure to be what the current context for JNI is at the time of calling.

  Since this is a NativeActivity as well, I'm sensing that the "normal" usage from Google is to use the NativeActivity glue layer with the separate thread for input events, etc.  Your guys' examples do the main loop "right there" in the same thread.

  Since I have a severe lack of sleep, I'm not seeing what I need to do in order to get this working with the set-up that (most) devs will use (e.g., see the NativeActivity glue layer to see how the queuing of events is done).  Does someone have a quick "You need to do X" answer?

Matt

Anonymous
Not applicable
Ah, as a quick follow-up, it looks like this happens when the GearVR controller gets input....

rosebud_the_sle
Expert Protege
Hi folks,

I guess I'm not understanding your use case.  Most folks doing this follow the pattern described in MobileSDK/Samples/Native/VrTemplate, which just polls the current keys in the Frame() method.  It's also useful to take a look at Samples/Native/VrController/src/VrController.cpp around line 353 to see how to pull button state from the controller itself.  

Though the Gear VR Controller reports normal Android key events, you shouldn't consume these for your app.  They go through a filtering pass to allow the Gear VR Controller to be used with legacy (pre-controller) applications.  For contemporary apps, you should read input directly from vrapi (e.g. via vrapi_GetCurrentInputState), both for the controller and for the HMD trackpad + back button.  This will give you unfiltered, lower latency input data.

Chris

Anonymous
Not applicable
Hey Chris,
  If you look at the standard code that Google recommends developers using NativeActivity use, you'll see that there is a custom looper set-up to handle events from the UI thread (which is NOT where the "main" game loop is running... it's a separate thread).

  The problem is that the example you guys are referring to don't line up with the "low-level" nature we need, e.g., the VRController example uses the middle layer (VRFrameworks, etc.); we don't want to use that - you mention Frame() method... that framework is way outside what we want for our engine.

  Can you give us an example in the VrCubeWorld_NativeActivity context?  ~NOTE~ that the issue with THIS demo is that it does NOT used the default, threaded input queue that just about 99% of all NativeActivity devs are going to be using.  What I mean is this:

/**
 * Process the next input event.
 */
static int32_t app_handle_input( struct android_app * app, AInputEvent * event )
{
ovrApp * appState = (ovrApp *)app->userData;
const int type = AInputEvent_getType( event );
if ( type == AINPUT_EVENT_TYPE_KEY )
{
const int keyCode = AKeyEvent_getKeyCode( event );
const int action = AKeyEvent_getAction( event );
return ovrApp_HandleKeyEvent( appState, keyCode, action );
}
else if ( type == AINPUT_EVENT_TYPE_MOTION )
{
const int source = AInputEvent_getSource( event );
// Events with source == AINPUT_SOURCE_TOUCHSCREEN come from the phone's builtin touch screen.
// Events with source == AINPUT_SOURCE_MOUSE come from the trackpad on the right side of the GearVR.
if ( source == AINPUT_SOURCE_TOUCHSCREEN || source == AINPUT_SOURCE_MOUSE )
{
const int action = AKeyEvent_getAction( event ) & AMOTION_EVENT_ACTION_MASK;
const float x = AMotionEvent_getRawX( event, 0 );
const float y = AMotionEvent_getRawY( event, 0 );
return ovrApp_HandleTouchEvent( appState, action, x, y );
}
}
return 0;
}

.... the VrCubeWorld_NativeActivity is "saving time" by showing a trivial input handling method.  The normal way this is done (at least for us) is to start from the sample that Google gives (which is nice for decoupling input from the UI thread and batching it up for the game/rendering thread).  It all stems from this native_app_glue code:

(er, I can't attach files, so if you look up android_native_app_glue.c and android_native_app_glue.h in any of the recent NDK releases, i.e. android-ndk-r15b-windows-x86.zip\android-ndk-r15b\sources\android\native_app_glue\ you should find what I am talking about).

  Also, we ARE using the input directly from vrapi_GetCurrentInputState() calls.  We're worried about removing our default input handling in case the system will interpret the actions for us (returning false in these calls can cause the system to shut-down the app unexpectedly... or at least at a point you didn't want (try hitting back without handling it)).

  If you guys say that it's kosher to remove input or handle it a different way, please let us know!

Matt

PS - TL;DR -> Two issues -> One, the examples you have use two different systems (pure native vs. VrFramework) AND the input of the pure native does NOT match what most devs will use for input (see native glue).

madefireengr
Explorer
I see this issue on SDK version 1.5.0. I cannot debug because I see the "SIGILL (illegal instruction)". Has this issue been resolved in 1.7.0? Is there anything I can do?

diegurrio
Explorer
I still see this issue. It makes debugging almost impossible. Has anyone found a way around this problem?

NelnoTheAmoeba
Explorer
Hi, all,

Sorry you've been hitting this issue and for the delay in figuring out what you were seeing.

Long story short, because we don't own the OS on all platforms (i.e. Gear VR), we hook into some internal Android APIs  (within the application process only) so that we get first crack at some of the system inputs. The way we do this is by intentionally writing an illegal instruction at the top of a function and installing a signal handler to route us to the correct place. 

When the Android Studio debugger is attached it will by default install its own signal handler that will stop execution when it encounters this dummy instruction. To fix this, you will need to disable the SIGILL handler in LLDB:

- Open your application in Android Studio
- Go to Run -> Edit Configurations.
- while your app is selected in the left pane, click on the Debugger tab in the right pane.
- Below that click on the "LLDB Post Attach Commands" tab.
- Click on the + to the right and add the following command.
process handle --pass true --stop false --notify true SIGILL
Let us know if this works. It was our oversight that we appear to not have added these instructions to our SDK documentation, but we will for the next release.

-Jonathan

NelnoTheAmoeba
Explorer
ECSGuy, to answer your questions about input as it relates to VrAppFramework vs. VrCubeWorld_NativeActivity.

For all Oculus controllers, the headset buttons and trackpad, and (since 1.14, I think) gamepads, apps should use vrapi_ input methods to query input from those devices.

The latest version of VrCubeWorld_NativeActivity has been updated to use the vrapi_ input paths. This handling is done in a function called directly from the frame loop in main(). app_handle_input() is gone completely, and the app->onInputEvent callback is left unassigned.

Since VrApi hooks back and home keys, there shouldn't be any need to handle the normal Android paths for these events.

If you want to do something like handle Bluetooth keyboard events, then you'll still need the handle normal Android input events as before.