I'm seeing some devices (with broadcom's btld) in which the radio services (RIL) use the service. namespace to pass or store data... Conflicts: init/property_service.c Change-Id: I6e3177689a12b0925064e615408bc1e0f175bcf3
The older (GB) blobs used with AUDIO_LEGACY do not support the new enums. Change-Id: If80539060dbef53e984ca3d52d65cac6a499e8dd
…ined in arbitrary /system/addon.d/*.sh scripts." into ics
… arbitrary /system/addon.d/*.sh scripts. Set permissions on /system/addon.d/ and files within. Patch Series ============ http://review.cyanogenmod.com/#change,13265 CyanogenMod/android_build * edify generator http://review.cyanogenmod.com/#change,13266 CyanogenMod/android_system_core * permissions on /system/addon.d http://review.cyanogenmod.com/#change,13267 CyanogenMod/android_vendor_cm * 50-cm.sh reference backup script * modular backuptool.sh * support backuptool.functions used by /system/addon.d/*.sh scripts Change-Id: I4f1464ea8d55f45d47ba760a7a448036a46feb00
When the chown program fails it prints out an error message and is describing itself as chmod. This has been corrected. Change-Id: I2c489975f09343bdf66acbf7df6e7183c2daff78 Signed-off-by: christian bejram <firstname.lastname@example.org>
The waitpid call in do_exec may return early with EINTR when init receives a signal, e.g., a SIGCHLD from an exiting service process. do_exec should check waitpid for an EINTR "error", to ensure that it returns only after waiting on its child process.
A stopping service now remains in SVC_RUNNING state until its exiting process has been reaped by waitpid. This prevents a "stop, start" sequence from spawning a second service process before resources held by the first are released. However, a "stop, start" pair _will_ restart the service after exit (unless critical or oneshot). This scenario was originally special-cased by the SVC_RESTART state used by the restart command. However, we have observed instances where services are, unintentionally, stopped and started "too quickly," and so simultaneous processes for the same service should never be allowed. Note the SVC_RESTART state (and restart) command is still useful to explicitly restart critical and oneshot services, for which the "stop, start" procedure is not intended.
This is needed by new CPU Settings in CMParts Change-Id: I0ec4e0b1705670034a433df549b2895985c476af
…em/bin/sysinit" This reverts commit 9c83c76.
…ysinit Change-Id: Ic691c646558ddf842856f97236d055f5664b65f7
At present, service restarts exhibit a race condition whereby the new (restarting) service process is often spawned before the old (stopping) process has terminated. This may result in the new service process failing to acquire a limited resource (file lock, socket bind, etc.) that the old process has not yet released. The new method preforms a safe service restart by stopping the service, waiting for the old service process to terminate, and (only then) start the new service process. In the event of "restarting" an already stopped service, the previous behavior is maintained whereby the service is simply started.
some of these are required by proprietary binary apps and tools like lsof which report errors on unknown user 9000 A lot of projects use this android_filesystem_config.h, so a global CFLAGS is better to handle this in BoardConfig.mk Added latest ones for OSH (webtop) and whisper (used in pds) Change-Id: I7e92bacfcac418cd9f21e67543a5789a292137a3
liblog is not usable, because stderr and stdout are redirected to /dev/null to control the android log output. Only forked processes are able to write to the android logs... Note: accept parameters: log [-t topic] [-p level] <message> limit : strings beginning with "--" are not handled Change-Id: I2fbf7422e0085d4cdf1bba6511413d1f796d4555