Android ndk pure C ++ development (1)

Android ndk now supports pure C ++ development and can also develop programs with activity.

There are two ways to develop a C ++-only Android program: native_activity.h and android_native_app_glue.h. Of course, it is essentially the same. android_native_app_glue.h is an encapsulation of native_activity.h. Therefore, it is clear that the recommended method is android_native_app_glue.h.

In the <ndk>/sources/Android \ native_app_glue folder, there are implementation codes of android_native_app_glue.h and android_native_app_glue.c. as users, we do not need to understand the implementation of handler, you only need to pay attention to the interfaces provided in android_native_app_glue.h and how to use them. Open android_native_app_glue.h and you can see the related explanations in the comments section, I don't want to study the meaning of each sentence accurately ):

/**
* The native activity interface provided by <Android/native_activity.h>
* Is based on a set of application-provided callbacks that will be called
* By the activity's main thread when certain events occur.

The native activity interface provided by <Android/native_activity.h> is implemented based on the callback functions provided by a series of applications. These callback functions are implemented in the event (events) it is called by the main thread of the activity.
*
* This means that each one of this callbacks _ shoshould _ not _ block, or they
* Risk having the system force-close the application. This programming
* Model is direct, lightweight, but constraining.
*

This means that these callback functions should not be blocked. Otherwise, the system may forcibly close the application. This programming model is straightforward and lightweight, but it is too restrictive.
* The 'threaded _ native_app 'static library is used to provide a different
* Execution model where the application can implement its own main event
* Loop in a different thread instead. Here's how it works:

The "threaded_native_ap" static library is used to provide a different execution model. An application can implement its own main event loop in a different thread. Below is how it works:
*
* 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.

1. the application must provide a function named "android_main ()", which will be called when the activity is created, it is in a new thread that is different from the main thread of Activiy.
*
* 2/android_main () receives a pointer to a valid "android_app" Structure
* That contains references to other important objects, e.g.
* Anativeactivity obejct instance the application is running in.

2. android_main () accepts a pointer to the "android_app" struct, including references to some important objects. For example, the anativieactity object represents an instance of the running application.
*
* 3/The "android_app" object holds an alow.instance that already
* Listens to two important things:

3. The "android_app" object stores a alogue instance, which has listened to two important tasks:
*
*-Activity lifecycle events (e.g. "pause", "resume"). See app_pai_xxx
* Declarations below.

For activity lifecycle events (such as "pause" and "resume"), see the Declaration of app_lifecycle _xxx.
*
*-Input events coming from the ainputqueue attached to the activity.

The input event from the ainputqueue appended to the activity.
*
* Each of these correspond to an alow.identifier returned
* Alooper_pollonce with values of looper_id_main and looper_id_input,
* Respectively.

Each event corresponds to a aloop identifier returned by alooper_pollonce, and its values correspond to looper_id_main or looper_id_input.
*
* Your application can use the same alow.listen to additional
* File-descriptors. They can either be callback based, or with return
* Identifiers starting with looper_id_user.

Your application can use the same alogue to listen for additional file identifiers. They can be both callback-based functions and looper_id_user-based identifiers.
*
* 4/whenever you receive a looper_id_main or looper_id_input event,
* The returned data will point to an android_poll_source structure. You
* Can call the process () function on it, and fill in android_app-> onappcmd
* And android_app-> oninputevent to be called for your own Processing
* Of the event.

When you receive a looper_id_main or looper_id_input event, the returned data points to an android_poll_source struct, and you can call the process () function on it, and fill in android_app-> onappcmd and android_app-> oninputevent to give your own event processing functions.
*
* Alternatively, you can call the low-level functions to read and Process
* The data directly... Look at the process_cmd () and process_input ()
* Implementations in the glue to see how to do this.

In addition, you can call the underlying functions to directly read and process data... you can refer to the implementation of process_cmd () and process_input () in glue to learn how to implement it.
*
* See the sample named "Native-activity" that comes with the ndk with
* Full usage example. also look at the javadoc of nativeactivity.

Refer to the "Native-activity" example in ndk to learn all the examples. You can also refer to the javadoc of nativeactiviy.
*/