I noticed that the zygote64 and zygote64_32 files
had gotten slightly out of sync as a result of change
I3aad4b4b1d2f54db9e7ba86db8a655d8552bad0a. Merge the zygote64_32 changes
into zygote64, and to prevent this from happening again, replace the
64-bit zygote declaration in zygote64_32 with an import from zygote64.
Change-Id: I7fcceeb22b722c2164b9acf0b517a32ce34731fd
The critical services can now using the interface `critical
[window=<fatal crash window mins>] [target=<fatal reboot target>]` to
setup the timing window that when there are more than 4 crashes in it,
the init will regard it as a fatal system error and reboot the system.
Config `window=${zygote.critical_window.minute:-off}' and
`target=zygote-fatal' for all system-server services, so platform that
configures ro.boot.zygote_critical_window can escape the system-server
crash-loop via init fatal handler.
Bug: 146818493
Change-Id: Ib2dc253616be6935ab9ab52184a1b6394665e813
Improve app startup performance before the new app is in the top-app
cpuset.
Test: boots, zygote64 in top-app stune group
Bug: 159201879
Change-Id: I3aad4b4b1d2f54db9e7ba86db8a655d8552bad0a
The FUSE filesystem is implemented by a Zygote child. If Zygote dies,
all of its children die along with it, including the FUSE daemon. The
FUSE filesystem is cleaned up automatically whenever the /dev/fuse file
descriptor of the FUSE daemon is closed. However, due to the way the
binder driver holds on to the 'struct files' of processes in the kernel,
the closing of FDs of all of Zygote's children is serialized.
That in turn means that, if a process has a file with dirty pages on
FUSE, and that FD is closed *before* the FUSE FD, the FUSE kernel driver
will happily issue a request to the FUSE daemon to serve that request.
But since the FUSE userspace daemon is already dead, it will never get
served. And because the closing of all FDs is serialized, we will never
close the FUSE fd to unblock this request.
Solve this particular case by manually aborting the FUSE filesystem when
Zygote restarts. Because we now explicitly close the FUSE fd, the FUSE
filesystem will be cleaned up, all outstanding requests to it will be
cancelled, and new ones will be skipped.
Bug: 153411204
Test: kill zygote manually
Change-Id: I2cb6c1a03cc1a932461ff33558894a428ff35180
Removing 'updatable' from zygote as zygote is started after apexd. All
APEXes are guaranteed to be activated at the moment.
Sequence of actions:
1) /data mounted. post-fs-data is triggered.
2) apexd starts. APEXes are activated. Init does not execute more
commands until the activation finishes.
3) all post-fs-data sections from other *.rc are executed.
4) zygote-start is triggered.
Bug: 123404717
Bug: 126555629
Bug: 125549215
Test: device boots
Test: no following message on the logcat log
Could not restart 'zygote': Cannot start an updatable service 'zygote' before configs from APEXes are all loaded. Queued for execution.
Change-Id: Ib4d0716ed5225b6ade3adaa247ff6140a9b2b9d5
This change adds new socket declarations to the init scripts for the
Zygote processes. This socket is used for communication between the
System Server and the Blastula pool.
Bug: 68253328
Change-Id: I5dbb87770b1a3100c6c122bb39ca854006bb0b0d
Topic: zygote-prefork
Test: build image; flash device; launch apps
It depends on libdexfile_external, libnative{bridge,helper,loader} and
libart(d), which are provided by the Runtime APEX.
Test: flash & boot
Test: atest CtsJdwpTestCases
Bug: 113373927
Change-Id: I0df99f444e892c47a5f06bd1bcf5d184defb4517
We recently created a new GID that can be granted to critical system
processes, so that the system is usable enough for the user to free
up disk space used by abusive apps.
Test: builds, boots
Bug: 62024591
Change-Id: Ia5af7535cc05a214f8720ac08c594c6db888597a
Parts of this change were accidentally reverted by an incorrect
manual merge conflict resolution.
Bug: 35306127
Test: manual
Change-Id: I8e6d6b07dcaa548775213dd42ba9def7431c62d3
This reverts commit e5aee79e9c.
Given recent improvements to boot timing, and higher paralellization,
the lazy preloading of zygote resources makes boot time slightly slower
by ~100-250ms. Therefore, the change is being reverted until we can do
it properly and defer it to a later point in the boot process. This work
is being tracked by b/34810190
BEFORE
------
successive-online : 17290.0,17633.0,17329.0,17655.0,16802.0,16888.0,17645.0,17369.0,17572.0,16932.0,
successive-online_avg : 17311.5
successive-boot : 24834.0,25119.0,25122.0,25091.0,25617.0,25535.0,25047.0,27462.0,25088.0,25648.0,
successive-boot_avg : 25456.3
AFTER
-----
successive-online : 16973.0,16530.0,17015.0,17953.0,17367.0,17098.0,16887.0,17377.0,18039.0,16742.0,
successive-online_avg : 17198.1
successive-boot : 24921.0,25622.0,25781.0,25449.0,25128.0,24774.0,24554.0,25029.0,24544.0,25809.0,
successive-boot_avg : 25161.1
Test: Boot timings collected with tradefed harness.
Bug: 34810190
Change-Id: I9a6dd5ce31bda067e74fc088b057711fa4a7a0fb
This helps to avoid tearDownInterfaces call from WiFiStateMachine's
constructor.
Bug: 33752168
Test: on device
(cherry picked from commit 0db195d0757e36c73b9da5a95d9b9986386f0f2e)
Change-Id: I55f56dd8daa5089073ff8dd424e92d09326c7d00
This helps to avoid tearDownInterfaces call from WiFiStateMachine's
constructor.
Bug: 33752168
Test: on device
Change-Id: I44527ee39700c5ac3259bba3a007dde6979170ff
In zygote wrapping mode, ZygoteConnection does a check to see if the pid
reported by the wrapped process is either child process that was
forked, or a decendent of it. This requires read access to other
processes /proc files. Grant zygote AID_READPROC to allow this access.
Bug: 32610632
Test: manual inspection of /proc files to verify group.
Test: manual inspection of zygote's children to make sure they do not
inherit AID_READPROC
Change-Id: I3619a9ae33c8077e068e8024f7c7d44cfca6fb76
When using EAS, the foreground tasks were all getting boosted
during touchboosts. Limit it to top-app tasks.
BUG: 28378389
Change-Id: I72b7158a614bfd9b6c61024774e408ceba61fc9c
Move foreground tasks to /sys/fs/cgroup/stune/boost/tasks (boosted
weight in EAS scheduler). Move background tasks to
/sys/fs/cgroup/stune/tasks (default weight). For services started
with init, set "foreground" services to boosted.
Change-Id: I0e489fad9510727c13e6754dabaf311c2391f395
Move foreground tasks to /sys/fs/cgroup/stune/boost/tasks (boosted
weight in EAS scheduler). Move background tasks to
/sys/fs/cgroup/stune/tasks (default weight). For services started
with init, set "foreground" services to boosted.
Change-Id: I0e489fad9510727c13e6754dabaf311c2391f395