This CL adds a trigger and a service so that Systrace can be used
for tracing events during boot.
persist.debug.atrace.boottrace property is used for switching on
and off tracing during boot. /data/misc/boottrace/categories
file is used for specifying the categories to be traced.
These property and file are rewritten by Systrace when the newly
added option --boot is specified.
Here is an example of tracing events of am and wm catetories
during boot.
$ external/chromium-trace/systrace am wm --boot
This command will cause the device to reboot. Once the device has
booted up, the trace report is created by hitting Ctrl+C.
As written in readme.txt, this mechanism relies on persistent
property, so tracing events that are emitted before that are not
recorded. This is enough for tracing events after zygote is
launched though.
This only works on userdebug or eng build for security reason.
BUG: 21739901
Change-Id: I03f2963d77a678f47eab5e3e29fc7e91bc9ca3a4
Ensure that /data/anr always exists. This allows us to eliminate
some code in system_server and dumpstate. In addition, this change
solves a common problem where people would create the directory
manually but fail to set the SELinux label, which would cause
subsequent failures when they used the directory for ANRs.
Bug: 22385254
Change-Id: I29eb3deb21a0504aed07570fee3c2f87e41f53a0
Required by logd on devices with USE_CPUSETS defined.
Make /dev/cpuset/background, /dev/cpuset/foreground and
/dev/cpuset/task writeable by system gid. Add logd to system
group for writing to cpuset files and to root group to avoid
regressions. When dropping privs, also drop supplementary groups.
Bug: 22699101
Change-Id: Icc01769b18b5e1f1649623da8325a8bfabc3a3f0
The cfs tunables auto-scale with the number of active cpus by default. Given
that the tunable settings are in device-independent code and it's not
known how many cores are currently active when the init.rc file runs,
the cfs tunables can vary pretty significantly across devices depending
on the state at boot. Disable scaling of the the tunables so that we
can get more consistent behavior of cfs across devices. If we want to
do per-device tuning of these values, we can override what's written
here in device specific files.
Bug: 22634118
Change-Id: Id19b24ef819fef762521e75af55e6d4378cfc949
system.img may contain the root directory as well. In that case, we
need to create some folders init.rc would during the build.
Change-Id: I312104ff926fb08d98ac8256b76d01b0a90ea5e5
* commit 'ee923139c346e6751203fc7d2a341388e01c7b19':
Set up user directory crypto in init.
logd: switch to unordered_map from BasicHashtable
rootdir: make sure the /oem mountpoint is always available
Folders in the root directory are now created during the build,
as we may be building without a ramdisk, and when we do that,
the root directory will be read-only. With those changes,
these mkdirs will never need to run.
Change-Id: I49c63e8bfc71d28e3f938ed41f81d108359fa57a
system.img may contain the root directory as well. In that case, we
need to create some folders init.rc would during the build.
Change-Id: I157ccbebf36bee9916f3f584551704ec481ae1d1
File level encryption must get the key between mounting userdata and
calling post_fs_data when the directories are created. This requires
access to keymaster, which in turn is found from a system property.
Split property loaded into system and data, and load in right order.
Bug: 22233063
gatekeeperd depends on having /data to determine whether
to call setup routines for qcom HALs.
Bug: 22298552
Change-Id: I6c552016dc863bbb04bd5a949a2317a720c8263f
File level encryption must get the key between mounting userdata and
calling post_fs_data when the directories are created. This requires
access to keymaster, which in turn is found from a system property.
Split property loaded into system and data, and load in right order.
Bug: 22233063
Change-Id: I8a6c40d44e17de386417a443c9dfc3b4e7fe59a5
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I5a016f0958a92fd390c02b5ae159f8008bd4f4b7
