Native Activity input? android/input.h

[shadowmint]

Can someone point me in the direction of a sample where they have input working in a native activity app?

I had a look at the native activity sample in the NDK, but it only touches on sensor data, not on actual input.

Specifically, I'm trying to figure out how to call the functions in input.h

Seems like I need to do something along these lines: 

struct AInputQueue queue;

struct AInputEvent events[1]; // ??

struct AInputEvent event;

AInputQueue_attachLooper(&queue, ...);

while (AInputQueue_hasEvents(&queue) {

  AInputQueue_getEvent(&queue, &events);

  event = events[0]; // ??

  if (AInputQueue_preDispatchEvent(&queue, &event)) {

    appContextProcessEvent(&event); // Actually process event for application

    AInputQueue_finishEvent(&queue, &event, 1);

  }

}

...but I can't get it to work, and I can't find an example that actually _does_ work.

Anyone managed to do this?

[Dianne Hackborn]

The native activity sample also processes touch input to change the color shown on screen.  This function retrieves the touch data:

/**

 * Process the next input event.

 */

static int32_t engine_handle_input(struct android_app* app, AInputEvent* event) {

    struct engine* engine = (struct engine*)app->userData;

    if (AInputEvent_getType(event) == AINPUT_EVENT_TYPE_MOTION) {

        engine->animating = 1;

        engine->state.x = AMotionEvent_getX(event, 0);

        engine->state.y = AMotionEvent_getY(event, 0);

        return 1;

    }

    return 0;

}

And it is set as the input callback when initializing:

void android_main(struct android_app* state) {

    struct engine engine;

    // Make sure glue isn't stripped.

    app_dummy();

    memset(&engine, 0, sizeof(engine));

    state->userData = &engine;

    state->onAppCmd = engine_handle_cmd;

    state->onInputEvent = engine_handle_input;

    engine.app = state;

    ...

}

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[shadowmint]

oic, I missed that sorry. 

Hm... I can't see anything specifically that does this in android_native_app_glue.c, but does the mutex locking going on mean the events are processed in a separate thread?

~

Doug.

[Dianne Hackborn]

Events are processed in the thread running the event loop.  The standard glue makes a separate thread that your main loop is running in (not the main thread of the process) so it can entirely drive that event loop however it wants.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Tim Wright]

Is there any way to access these events without using the
NativeActivity class?

On Mar 9, 3:24 am, Dianne Hackborn <hack...@android.com> wrote:
> Events are processed in the thread running the event loop.  The standard
> glue makes a separate thread that your main loop is running in (not the main
> thread of the process) so it can entirely drive that event loop however it
> wants.
>
>
>
> On Tue, Mar 8, 2011 at 6:59 PM, shadowmint <douglas.lin...@gmail.com> wrote:
> > oic, I missed that sorry.
>
> > Hm... I can't see anything specifically that does this in
> > android_native_app_glue.c, but does the mutex locking going on mean the
> > events are processed in a separate thread?
>
> > ~
> > Doug.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-ndk...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-ndk?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

Um.  The Java APIs?

Not sure what you mean besides that.

hac...@android.com

[Dia]

I think he wants to say if you can access input events in another way than using Native Activity. I assume he has a Java code as I do and needs to get only the input from native code (the xperia touchpad events can only be accessed in native code) and leave the normal SDK application with normal View and Activity as it is .

This is my problem. Please correct me if I am wrong. Also is there another way?

 Diana Loredana Radu
 Email: diana.lor...@gmail.com
 Phone: 0747.11.30.27

" Fii schimbarea pe care vrei să o vezi în lume! " Gandhi :)

[Dianne Hackborn]

You can only get them with NativeActivity.  A trick you can use if you don't want NativeActivity to give the native code ownership of your window's surface is to call getWindow().takeSurface(null).

2011/3/9 Dia <loryd...@gmail.com>

[shadowmint]

If what you mean is, "Can your native code poll for events if it isn't a native activity application?", the answer is definite 'maybe'.

You absolutely cannot do it with an API level < 9:

per-ms006:platforms douglasl$ ls

android-3 android-4 android-5 android-8 android-9

per-ms006:platforms douglasl$ du -a |grep android/input.h

56 ./android-9/arch-arm/usr/include/android/input.h

per-ms006:platforms douglasl$

The native event code for input, audio, etc. simply does not exist on earlier platforms. So that is absolutely a no go.

The question about, can you poll for events using api level 9+ and not a native activity is more complicated.

Technically, the answer is yes. The code supports this; Practically, you'd have to disect:

sources/android/native_app_glue/android_native_app_glue.c 

And if you look closely at that file, you'll see that polling for events depends on the "ALooper" instance that is attached to the android_app struct magically before we get passed the object in android_main(). 

If you can get access to /create an equivalent object in native code, you could technically poll for events without using the native activity. 

However, it'd be pretty tough to get working. There's certainly no easy way to do it.

~

Doug.

[Dianne Hackborn]

Sorry, no you can't.  Event dispatching is pretty complicated (needing to interact with the IME and such), and the NativeActivity's JNI glue code takes care of this.

As I said, though, if you want a NativeActivity that doesn't give the native code ownership of the window's surface, you can use getWindow().takeSurface(null).

~

Doug.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[shadowmint]

Just out of curiosity, if I want to find the source to libandroid.so and see how this was actually done, where can I find it?

Hunted around on the gitorious archive, but it looks like platforms/android-9/arch-arm/usr/lib/libandroid.so gets build externally somewhere and then added:

http://gitorious.com/0xdroid/development/commit/3ec1cec3b7cfaacee5db2d738e02e49b30319ac0

Part of the kernel tree?

~

Doug.

[Dia]

Thank you a lot. This really helped. 

Now I have one more problem:

Xperia Play is 480x854. But the getwidth() and getheight() return 320x569 if I use the NativeActivity. 

Thank you again for your answer.

[Dia]

Oh this is because the application is scaled. No problem here. The problem comes from the fact that the returned x, y from the Motion Event in native code is not scaled, they represent the actual screen pixels. 

Is there any configuration to make this work as in normal Activity?

[Dianne Hackborn]

Turn off compatibility mode.  Seriously.  You are using API level 8, and compatibility mode is for apps that were written before API *4*.

Generally if you are using NativeActivity, you must be setting your minSdkVersion to 8, since that is the first API it appears in.  If you are doing the work of also maintaining compatibility with older platforms, at least set targetSdkVersion to 8.

[Dia]

I used the NativeActivity with takeSurface(null). But now I have a problem when I try to override the Menu button. The application freezes.

This is the used code:

 public boolean OnNativeKeyDown(int keyCode){

     Log.i("TouchpadNAJava", "Received native key DOWN event! (" + keyCode + " zz)");

     if(keyCode==KeyEvent.KEYCODE_MENU)

     {

     openOptionsMenu() ;

     return true;

     }

         else

        return mainPanel.doKeyAction(keyCode, true);

    }

For all other keys the application works fine. I think it is also a surface problem. Can you get me a hint please on this ?

Thank you.

[Dianne Hackborn]

What is your code doing in the debugger when it freezes?  I doubt this has anything to do with a surface; what that call does is make it behave the same as if you aren't using NativeActivity for drawing.

[Dia]

That is the problem. No exception is thrown in the debugger. It just freezes. And after a while the phone closes the application.

PS: sorry for the private. I just clicked Reply and not Reply to all.

[Dianne Hackborn]

So the first question to answer: what is your app doing while it is hung?  Attach the debugger and look at where the threads, especially the main thread, are.

Also "phone closes the application" is not informative.  What does that mean?  Is there an ANR dialog?  Does the process get killed?  Something else?  What is printed in the log when this happens?