1.) Android 9/10 restricts access to JNI and Jave reflection API's.

This adds additional checks.

Commented out an possible optimization, which could be assumed to
works, but does not for me so far.  Please leave this comment in, so
we recall before we wonder why and try over and over again.  Once in a
while we should ponder if it still does not work or why.

2.) Clear Java exceptions.

This enables to continue to run when an exception occured during a JNI
call.  (Future versions shall forward this as an exception in Gambit.)

3.) Avoid some JNI calls and provide more information about the
Java/Android environment to Scheme.

This is required for (upcoming) tricks to still call embedded dynamic
libraries as subprocesses.

It also enables to figure out a sane path to store app-private data
instead of the deprecated hard coding of the publicly accessible path
`/sdcard`.

4.) Add support to switch the apps content view to Java and back.

An upcoming module `webview` will need this.

Any not-so-time-critical Android API/Java Method - except those
restricted Android itself may be called without adding JNI code.

Co-authored-by: Matthias Görges <[email protected]>

Remove use of length, repeated list traversals and combinations of apply+append.

Apps that use FileProvider to pass URIs to activities must include ANDROID_xml_services and xml/file_paths.xml. 

Also fixes build-binary to locate the support.v4 library needed for FileProvider. Finally, use onRequestPermissionsResult to bootstrap.java.in to fix permission requests hanging.

An upcoming module webview will need this.

Avoid some JNI calls and provide more information about the Java/Android environment to Scheme.

Co-authored-by: Matthias Görges <[email protected]>

1) Android 9/10 restricts access to JNI and Jave reflection API's. This adds additional checks. Commented out an possible optimization, which could be assumed to works, but does not for me so far.  Please leave this comment in, so we recall before we wonder why and try over and over again.  Once in a while we should ponder if it still does not work or why.
2) Clear Java exceptions. This enables to continue to run when an exception occured during a JNI call.  (Future versions shall forward this as an exception in Gambit.)

Problem stems from conversion of apply to case-based approach
which didn't consider that colors in glCore:TextureDrawUnClipped
is now a list of lists. Also patched glCore:TextureDrawClipped

1.) Android 9/10 restricts access to JNI and Jave reflection API's.

This adds additional checks.

Commented out an possible optimization, which could be assumed to
works, but does not for me so far.  Please leave this comment in, so
we recall before we wonder why and try over and over again.  Once in a
while we should ponder if it still does not work or why.

2.) Clear Java exceptions.

This enables to continue to run when an exception occured during a JNI
call.  (Future versions shall forward this as an exception in Gambit.)

3.) Avoid some JNI calls and provide more information about the
Java/Android environment to Scheme.

This is required for (upcoming) tricks to still call embedded dynamic
libraries as subprocesses.

It also enables to figure out a sane path to store app-private data
instead of the deprecated hard coding of the publicly accessible path
`/sdcard`.

4.) Add support to switch the apps content view to Java and back.

An upcoming module `webview` will need this.

Any not-so-time-critical Android API/Java Method - except those
restricted Android itself may be called without adding JNI code.

…into pr-module-lnjscheme

Calling setContentView between permission requests would cause some apps to hang. This problem was previously addressed by adding a shell override function for onRequestPermissionResult, which is no longer needed and is removed in this commit

- #defines LAMBDANATIVE_JNI_VERSION to JNI_VERSION_1_4
- uses `jint` as if it was an opaque type
- checks via GetEnv before attaching a thread
  (there are claims on the Internet that this may save some overhead)
- use AttachCurrentThreadAsDaemon instead of AttachCurrentThread for
  gut feeling

This appears to be the correct way and seems to actually solve the
issue observed and not fixed by da86a5160 ff.

This reverts commit 5dfe4cc.