Can I use ALooper to temporarily take over the UI thread's main loop?

[Andreas Falkenhahn]

Let's suppose my Java code calls a C function named myTestFunc() via JNI on the UI thread. Can myTestFunc() now use the ALooper functions to run a temporary modal event loop before returning control to the Java side by making myTestFunc() return?

In other words, is it possible for myTestFunc() to enter into a modal loop that waits for some certain event on the Java side to happen before quitting the modal loop and returning control to the Java side?

Note that my app isn't a NativeActivity app but a normal Java app with some parts implemented in C.

--
Best regards,
Andreas Falkenhahn mailto:and...@falkenhahn.com

[Alex Cohn]

You can force some C++ code to run on UI thread, while it's not trivial. Much easier to cooperate with Java and post some Runnable to UI thread, which in turn calls your C++ code via JNI.

But you should not run a modal loop on UI thread: for the Android system, this would mean that you keep the UI thread too long, and will promptly trigger ANR.

BR,

Alex

[Andreas Falkenhahn]

On 14.08.2019 at 10:09 Alex Cohn wrote:

> But you should not run a modal loop on UI thread: for the Android system, this would mean that you keep the UI thread too long, and will promptly trigger ANR.

That's the question. The Android NDK has those ALooper APIs and my question is if those can be used to run a modal event loop on the C/C++ side so that there won't be an ANR.

AFAICS, the NativeActivity samples do exactly that. Their main loop is based on ALooper.

Now the question is if this is also possible for non-NativeActivity-based apps. That would be a nice workaround for the fact that it's impossible to run a modal loop on the Java side.

[Alex Cohn]

No, Native Activity does not 'appropriate' the main looper for its purposes. It does not have a modal loop. The Native Activity is actually a system Java class (so you don't have to include Java in your APK) which extends Activity and calls your custom C++ code for every system callback that your C++ subscribes to.

Here is how android_native_app_glue.h explains it:

* 1/ The application must provide a function named "android_main()" that

* will be called when the activity is created, in a new thread that is

* distinct from the activity's main thread.

Alex

[Andreas Falkenhahn]

Good observation, thanks. I thought android_main() was running on the UI thread. I guess it's safe to say that ALooper can't be used like I planned then.

[Alex Cohn]

On Wed, 14 Aug 2019, 17:11 Andreas Falkenhahn, <and...@falkenhahn.com> wrote:

Good observation, thanks. I thought android_main() was running on the UI thread. I guess it's safe to say that ALooper can't be used like I planned then.

I am afraid I still don't understand what exactly you wanted to achieve with such loop. Maybe a looper can help you, or some other multithreading construct.

BR,

Alex