| commit | 2bf110d691053353d6cb06ad2bbd1b78fef60f19 | |
| author | Tor Lillqvist <tlillqvist@suse.com> | |
| Mon, 14 Nov 2011 23:41:57 +0000 (15 01:41 +0200) | ||
| committer | Tor Lillqvist <tlillqvist@suse.com> | |
| Mon, 14 Nov 2011 23:54:49 +0000 (15 01:54 +0200) | ||
| tree | 159fcfed4e1d335f65a1e17802a2445a7cfe2487 | treesnapshot (tar.gz zip) |
| parent | d14416463a0e62cf624cf66e8a599abac5694cd2 | commitdiff |
Rework the bootstrap mechanism of a LO program on Android
Do use NativeActivity and android_native_app_glue after all.
I hope this enables us to have a "message pump" (a loop that typically
would call ALooper_pollAll()) inside the LO "program" being run, as
expected by LO code.
(On Android, a "program", even one mostly implemented in native code,
is actually a shared library loaded by the main Java code of an app.)
The android_native_app_glue code and the android_main() it calls
belongs in the bootstrap library, though. Not in SAL_MAIN_IMPL.
The earlier idea, having a "normal" Java Activity subclass, would mean
events come in as method calls to that class. To then turn those into
something the LO code can "get", we would have effectively had to
re-implement what android_native_app_glue does anyway.
Do use NativeActivity and android_native_app_glue after all.
I hope this enables us to have a "message pump" (a loop that typically
would call ALooper_pollAll()) inside the LO "program" being run, as
expected by LO code.
(On Android, a "program", even one mostly implemented in native code,
is actually a shared library loaded by the main Java code of an app.)
The android_native_app_glue code and the android_main() it calls
belongs in the bootstrap library, though. Not in SAL_MAIN_IMPL.
The earlier idea, having a "normal" Java Activity subclass, would mean
events come in as method calls to that class. To then turn those into
something the LO code can "get", we would have effectively had to
re-implement what android_native_app_glue does anyway.