init: apexd is started in the current mount namespace
init starts services in "bootstrap" mount namespace until the "default"
mount namespace is ready even when init's current mount namespace is
"default".
apexd and linkerconfig are those processes to set up the mount
namespaces: apexd activates apexes and linkerconfig generates linker
configs.
Previously apexd is allowed to be started in the "current" namespace by
checking its "service name"(it should be "apexd"). But there can be a
certain environment apexd is started in a different way. For example, in
microdroid, apexd is started using "exec -- /system/bin/apexd --vm"
because it wants to run in a different execution mode.
So, instead of checking the service name, its executable's path is
checked against to allow apexd to be started in the current mount
namespace.
Bug: 179342589
Test: MicrodroidTestCase (microdroid boots)
Test: cuttlefish boots
Change-Id: I7c2490e15d481c28ddf382d2d3fdf58a78e467ec
diff --git a/init/service.cpp b/init/service.cpp
index 836dc47..c3069f5 100644
--- a/init/service.cpp
+++ b/init/service.cpp
@@ -460,7 +460,11 @@
scon = *result;
}
- if (!IsDefaultMountNamespaceReady() && name_ != "apexd") {
+ // APEXd is always started in the "current" namespace because it is the process to set up
+ // the current namespace.
+ const bool is_apexd = args_[0] == "/system/bin/apexd";
+
+ if (!IsDefaultMountNamespaceReady() && !is_apexd) {
// If this service is started before APEXes and corresponding linker configuration
// get available, mark it as pre-apexd one. Note that this marking is
// permanent. So for example, if the service is re-launched (e.g., due