Android服务启动机制、自定义启动命令及mediadrmserver的valgrind运行咨询

Great question—let’s break this down step by step since you’re digging into low-level Android service management and profiling with Valgrind.

1. How Android System Services Start (Focus on init-managed services like mediadrmserver) #

Android’s core system services are controlled by the init process—the first user-space process that boots after the kernel. Here’s the key flow for services defined in .rc files like mediadrmserver.rc:

• The init process parses all .rc files in /etc/init/, /system/etc/init/, etc., during boot. It reads service blocks (e.g., service mediadrmserver /system/bin/mediadrmserver) and stores their configuration.
• When a service is marked as class main or another trigger class, init starts it automatically during the corresponding boot phase.
• If you modify the .rc file after boot, init doesn’t automatically reparse it—so your changes won’t take effect unless you force init to reload or restart the service in a way that picks up the new config.
• As for why the service still started despite errors in mediadrmserver.rc: init is resilient to minor syntax errors. It might skip invalid lines but still execute the core exec command to launch the service binary if that part remains intact.

2. How to Start Services with Custom Commands #

There are two main ways to manually control init-managed services like mediadrmserver:

Using init’s control properties (standard method) #

• Start the service: setprop ctl.start mediadrmserver
• Stop the service: setprop ctl.stop mediadrmserver
• This uses the original configuration from the .rc file, so if you want custom arguments, you’ll need to launch the binary directly instead.

Launching the service binary directly (for custom args/profiling) #

Since mediadrmserver runs as the media user by default, you need to switch to that user first to avoid permission issues:

1. Stop the running service first:

   setprop ctl.stop mediadrmserver
   

2. Launch the binary with your custom command (e.g., adding flags or profiling tools):

   su media -c "/system/bin/mediadrmserver --your-custom-flag"
   

   The su media -c ensures the service runs with the correct user permissions, matching what init would do.

3. Running Valgrind on mediadrmserver #

Following the spirit of the Using Valgrind guide, here’s a step-by-step approach tailored to mediadrmserver:

Prerequisites #

• Ensure Valgrind is installed on your emulator/device. You’ll need a build compatible with your Android architecture (ARM32/ARM64/x86). If your emulator doesn’t have it, cross-compile Valgrind and push it to /system/bin/ (you’ll need a rooted emulator for this).

Step-by-Step Execution #

1. Stop the existing mediadrmserver instance:

   setprop ctl.stop mediadrmserver
   

2. Launch mediadrmserver under Valgrind:
   Use su media to run it as the correct user, and redirect logs to a writable location like /sdcard/ (since /system/ is usually read-only):

   su media -c "valgrind --leak-check=full --log-file=/sdcard/valgrind_mediadrm.log /system/bin/mediadrmserver"
   

   • --leak-check=full enables detailed leak detection (adjust flags based on your needs from the Valgrind guide).
   • The log file will capture all Valgrind output for later analysis.

Troubleshooting Tips #

• SELinux Issues: If Valgrind can’t attach or run the service, temporarily disable SELinux (for testing only):

  setenforce 0
  

• Memory Limits: Valgrind uses extra memory—increase your emulator’s RAM (in AVD Manager) to avoid crashes.
• Architecture Mismatch: Make sure you’re using a Valgrind build that matches your emulator’s architecture (e.g., ARM64 Valgrind for an ARM64 emulator).

内容的提问来源于stack exchange，提问作者Kushal Ramkumar