Chainfire/librootjava

Create a Service-like wrapper

Chainfire opened this issue · 1 comments

Some feel a Service-like wrapper that makes usage more transparent would be a good idea. This is certainly possible to create.

Currently, the following things are analogous between librootjava and Android Service:

  • (client) Use a su library to execute getLaunchScript() vs context.bindService()
  • (client) Use a RootIPCReceiver instead of a ServiceConnection
  • (server) Implement main method instead of a Service class

(this could probably go into the docs as well)

Creating a Service-class-like wrapper will likely hide some functionalities, but those are probably only relevant to the most advanced users.

Foreseen difficulties:

  • Create wrappers that work with both normal and daemon services. This would be tricky if the wrapper is an additional library, but easy if the wrappers are included in both existing libraries itself.
  • Execute the script as root without directly depending on libsuperuser, libsu, or whatever root library the user may be using. This will probably either need an additional library plugin per root library, optionally using reflection to support the base ones out-of-the-box.

Some feel a Service-like wrapper that makes usage more transparent would be a good idea. This is certainly possible to create.

Currently, the following things are analogous between librootjava and Android Service:

  • (client) Use a su library to execute getLaunchScript() vs context.bindService()
  • (client) Use a RootIPCReceiver instead of a ServiceConnection
  • (server) Implement main method instead of a Service class

(this could probably go into the docs as well)

Creating a Service-class-like wrapper will likely hide some functionalities, but those are probably only relevant to the most advanced users.

Foreseen difficulties:

  • Create wrappers that work with both normal and daemon services. This would be tricky if the wrapper is an additional library, but easy if the wrappers are included in both existing libraries itself.
  • Execute the script as root without directly depending on libsuperuser, libsu, or whatever root library the user may be using. This will probably either need an additional library plugin per root library, optionally using reflection to support the base ones out-of-the-box.