Use C code instead of commands

[EmmanuelMess]

The idea would be to make the methods in RootUtils native and work them from C.

[VishalNehra]

What good would it do? Plus, there's no super su library for C.

[EmmanuelMess]

Instead of parsing commands we'd call functions, it isn't that important, but could be done for more deterministic results (what a command prints is intended to be read by a human, therefore there might exist cases where a command would return something unexpected, causing difficult to trace crashes).
Why would we need a Super su lib for C? What function could it contain?

[Alexander--]

This is definitely doable. I have created an extremely primitive file manager, that uses JNI + IPC to native daemon, and it was working well under my limited testing.

There are two caveats:

1. Increased size of crossplatform apk. This can be countered by using apk splits and compressing native code with upx (upx has recently gotten support for arm/x86 library compression in addition to executable compresssion).
2. Making a lot of wrappers for every method. You will have to maintain at least one JNI wrapper for every system call: stat, chown, readdir, readlink etc. Some may be tricky to write.

A bit of knowledge of SELinux and Android security architecture might be necessary (not much).

[EmmanuelMess]

Crossplataform? You mean that different architectures would need different functions or that different API versions will need different functions? How so?
Wrappers? You only need to reference the function from java as 'native' and have a function of the same signature in C, how much more?

[Alexander--]

@EmmanuelMess API functions are the same everywhere. But each CPU architecture (x86/x64/arm/arm64/mips/mips64) needs separate .so library file. So you would need libamaze-x86.so, libamaze-arm.so ...). 64-bit architectures can be skipped (they accept 32-bit libraries).

You have a choice: either put a version of each library (x86 .so + arm .so + ...) in the same apk (very bad idea, huge apk size) or distribute multiple apk files: one for arm, another for x86... mips is irrelevant, but serving third apk won't hurt much when you already serve two. The "fat" apk vs split apks setup is covered well in official Android docs.

Wrappers? You only need to reference the function from java as 'native' and have a function of the same signature in C, how much more?

A bit more, depending on your goal.

You will most certainly need a C/C++ file (example: https://github.com/chdir/fdutil/blob/master/fdlib/src/main/cpp/native-lib.cpp#L319). You can write it manually (this is actually simple to do) or use an automated tool to generate it from Java method or C headers (the quality of generated code will be meh).

New versions of Gradle/IntelliJ can compile native code automatically with single Gradle block, so there is no longer a need for complicated Gradle setup.

[EmmanuelMess]

Related #513

[EmmanuelMess]

This has already started being implemented to fix issues with parsing ls.