Does AOSP include an initialisation system (equivalent to SystemD)?

I see [stackoverflow.com/revisions/20060853/1](https://stackoverflow.com/revisions/20060853/1) (paraphrased unmdermentioned), which appears to answer a similar question, although the answer that it provides causes me to believe that the services are *hardcoded* inside a user-inaccessible (even with standard adb access) POSIX Shell Script:

The statement "Service declarations only serve to describe services, they do not actually start anything" is correct. The native daemons are actually started in init.rc by lines 371-372 in [android.googlesource.com/platform/system/core/+/master/rootdir/init.rc](https://android.googlesource.com/platform/system/core/+/master/rootdir/init.rc) : - class_start core - class_start main ...where all daemons that belong to class *core* and class *main* are started respectively.

[Another answer, from *this* forum](https://android.stackexchange.com/revisions/6559/1#:~:text=/data/init.sh%20runs%20at%20boot%2C%20if%20you%20have%20root%20you%20can%20edit%20it%20as%20you%20like.) , to a similar question, mentions a near-duplicate file that acts identically (although it doesn't elaborate much – it, too, is paraphrased undermentioned): > /data/init.sh runs at boot. If you have root, you can edit it as you like. Inherently, their formats don't render them application-unmodifiable, but the sole alternative example of a user-modifiable shell script configuration file that I've seen is GRUB2's /etc/default/grub, which I was under the impression was a *singularly* exceptional circumstance, especially because modifying it necessitates superuser permissions. Relevantly, the security reduction that would arise from permitting applications to add arbitrary shell commands to that script would be obvious enough that I do not envisage this being the method by which services are added and configured. Consequently, does AOSP include an initialisation system that applications can add to? ##### Rationale The reason I ask here is because I'm asking as a user instead of a developer. That may appear nonsensical, but hopefully situations like [github.com/TacoTheDank/Scoop/issues/65#issuecomment-2571309312](https://github.com/TacoTheDank/Scoop/issues/65#issuecomment-2571309312) , in which users must utilize development tools to bypass platform restrictions, provide adequate rationale.