Brand new Termux API concept?

[twaik]

Now Termux has termux-api package which helps us with using Android's API's without writing Java code. But it has restrictions:

1. Termux should be in foreground or have Draw over apps permission. ([Bug]: am reports ActivityManager.START_SUCCESS but activity is not launched TermuxAm#7). Pay attention that it is imposibe to check if we in foreground or check if we have this permission.
2. User should install Termux::API application from Google Play or F-Droid.
3. Termux::API and Termux applications should be signed with the same key.

I propose the following scheme:
0. Make termux-api service a part of termux-app to fix termux/TermuxAm#7.

1. Use some IPC/RPC with code generation, resource management. That will allow us use API without writing it manually.
2. Start service in separated thread (with simple fork) and keep it to work with unix socket in $PREFIX/var/run as long as Termux's services are alive.

I prefer to use libwayland as IPC because:
0. We can use our IPC as C/C++ library so we can let C/C++ programs to use Android API's (or bindings) without using termux-api or other bash scripts.

1. It has resource management so resources created by clients will be alive as long as clients themselves are alive.
2. It has text, non-binary protocol with version control. In the case of protocol version mismatch we can tell the user that his termux-app version is outdated.
3. It can send and receive file descriptors so we can i.e. patch libusb to use it. Device enumerating and other stuff will work.
4. There is a Java scanner. We can use this as gradle task which generates protocol implementation in java and use it without writing code in C/C++. This way we do not need to write C bindings to java code.
5. Server side will have access to real Context so we can check/ask all the permissions at package installation time (it can be asynchronously, no need to wait while pkg is working) and in runtime (in target program).
6. termux-gui also can be reimplemented here...

What do you think about this?

[twaik]

@fornwall @Grimler91 @wmcbtech30 @agnostic-apollo

[twaik]

Looks like invoking Java code from C++ programs is possible. We can link to nativehelper (which dlopens art or dalvik, load art/dalvik with JniInvocationInit and then use JNI_CreateJavaVm. This will invoke all stuff we need.

[twaik]

@agnostic-apollo ?

[agnostic-apollo]

That "may" work, would have to test it on older devices 5,6,7 specially. JNI_CreateJavaVM apparently wasn't exported on older NDKs but it is now. There may be runtime restrictions for app user to do such stuff, loading system libraries is prohibited in new Android versions. Otherwise, app can load dex/jar files with DexClassLoader to get modified classloader and load required classes and execute functions. Execution should be possible in native code as well, should be possible to pass Context as well. Not sure how one would handle parameters and return calls though.

https://calebfenton.github.io/2017/04/05/creating_java_vm_from_android_native_code/

https://calebfenton.github.io/2017/04/14/calling_jni_functions_with_java_object_arguments_from_the_command_line/

https://github.com/rednaga/native-shim

[twaik]

Wow. Did not see those links. But it looks like event if we load Java code it would not be possible to use Android APIs without initializing them. Android registers them right after creating VM and then starts binder thread. So anyway we should use libandroid-runtime. Somehow.
I do not think porting it to termux-packages would be complicated. If I am not wrong it uses String8 and String16 classes which have the only storage field containing pointer to char array, it uses Vector which has 4 fields we can easily emulate with struct. We can emulate them or simply port old android's libutils. They should be compatible with modern versions.

But anyway if we port this it will be slow. Creating vm in every process using termux api will consume a lot of resources. Now I am trying to create minimal Wayland java bindings that will save resources in termux-app/termux-x11 applications and will let us use Java code with wayland without writing any JNI code.

[agnostic-apollo]

Invoking jvms is definitely slow, so should be avoided if it can be. Portingmay require aosp source tree to be included and behaviour would be different on different android versions and even vendors.

Not sure which String usage you are referring to but android native String handling, specially for binder parcels is complicated and different on different android versions.

Better way is service binders if just for termux-x11. If random code, then dex way would probably work too, custom objects may have issues, but gson could be used. I actually plan to look into that in future for service call commands to call android service interfaces, but not anytime soon.