Once upon a time an AOSP native service could be started with arguments through the property ctl.start. Something like:
setprop ctl.start ppp:debug
The generic start of a service with arguments was:
setprop ctl.start service:arg1 arg2 arg3..
This feature was introduced by commit f24e252903ca0f71c7fbfb135cf17e83e0c2ea90 but got lost after the heavy refactoring applied to init (probably also due to security concerns).
Since I needed that feature again, I took a quick look at the init code, to see if it was possible to patch the code for adding arguments support, but it was not trivial, so I took the lazy path: the idea is to wrap the service in a shell script in which arguments are given through android properties.
Defining an AOSP native service
Let’s suppose we would like to have a generic dhcp client service in which we want to dynamically specify the network interface; we can define the following service:
service dhcpcd_generic /system/vendor/bin/dhcpcd_generic_script group shell radio dhcp disabled oneshot
dhcpcd_generic_script is a script with the following content:
#!/system/bin/sh # generic dhcpcd script interface=$(getprop service.interface.dhcpcd) /system/bin/dhcpcd-6.8.2 -dABKL $interface
The argument of the command is taken from property
service.interface.dhcpcd
that should be set before starting the AOSP native service with the line
setprop ctl.start dhcpcd_generic
Note that a few more steps are needed for making this to work properly:
Copy the script in the filesystem during the platform build: this can be done by adding the proper directive to the PRODUCT_COPY_FILES variable in the device makefile, e.g.
PRODUCT_COPY_FILES += vendor/services/script/dhcpcd_generic_script:system/vendor/ bin/dhcpcd_generic_script
Configure seLinux policies:
dhcpcd_generic.te
# dhcpcd_generic service type dhcpcd_generic, domain; type dhcpcd_generic_exec, exec_type, file_type; init_daemon_domain(dhcpcd_generic)
Add in file_contexts the line
/system/vendor/bin/dhcpcd_generic_script u:object_r:dhcpcd_generic_ exec:s0
NOTE: those policies are not meant for security. In a production system they should be customized for not leaving holes.
You are now ready to use your AOSP native service with arguments.