libRootJava – Integrating root with application development

Libraries are great. No, I’m not talking about the buildings full of books (although those are pretty great too). This is a tech site so I’m talking about Android libraries. If you’ve ever developed an app before, you’ve probably used a library. In this context, a library is a sort of plugin for an app that basically does something for you, so you don’t have to bother. It’s a big time-saver since you can just hook into its functions instead of making your own. material-intro is an example of a library. You can use that in your app to implement a nice introduction for your users. We actually use a slightly modified version in our Navigation Gestures app.

Chainfire‘s libRootJava library is the one I’m going to be talking about in this post, and it’s pretty cool.

I’m pretty confident when I say that most people reading this at least know what root is, and at least half have rooted a device at some point. Some of you have probably even run commands as root.

Believe it or not, a lot of apps also run root commands. Root gives you basically unlimited access to the system, and some apps need that, like Substratum or Xposed (remember Xposed?). Running root commands from Java/Kotlin (the programming languages most commonly used for Android development) is a little clunky, though. You have to translate your Java/Kotlin logic to text, then translate the text result back to Java/Kotlin… it can get tedious.

An alternative to commands would be to use what’s known as native code, which is C++ in Android’s case. Android isn’t all written in Java, and many features are actually built on a combination of Java and C++. This is another method developers have used for root functions, but it can also get pretty complicated in the end.

This is where libRootJava comes in. The point of this library is basically to make it so you don’t have to run shell commands or integrate C++. All your code is contained in Java. If you use the provided binder IPC logic (think of it as a bridge between two separate components of an app), it’s incredibly easy to run your root functions.

One use for libRootJava would be a file manager. You could always use root commands and mess with parsing output text and such, or you could use some native code. It’d be so much easier to just have everything in Java or Kotlin, though, and libRootJava lets that happen.

Implementing libRootJava gets pretty technical, so I’ll leave the explanation up to the documentation. I followed the documentation myself and wound up with a simple little app that turns the screen off with the press of a button. You can check it out if you’re curious. Obviously, this is a pretty basic thing. It would take less effort to just run a root command:

su -c "input keyevent 26"

Even at this scale, libRootJava has an advantage: turning the screen off happens instantly using my app, while the command can take up to a second. If I were working on a set of root-exclusive functions for Navigation Gestures (hint, hint), each gesture taking up to a second to actually do something would be pretty annoying. At this scale (lots of possible functions), libRootJava starts to make a lot of sense.

Obviously, you can do more with libRootJava than send KeyEvents. That’s just the function I happened to explore. You could use it to replace…

pm grant com.xda.nobar android.permission.WRITE_SECURE_SETTINGS

…with actual Java/Kotlin code, using the Android SDK. Or you could replace the abrupt behavior of…

reboot

…with the standard Android reboot process, shutdown animation and all.

For most people, everything I just said probably doesn’t mean that much. But if you’re an app developer who relies on root functions, you should definitely give libRootJava a try. You’ll probably have a much easier time