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
Instead of having each view build and maintain its own tree
representing the underlying storage, switch to building a single tree
that each view augments with GID/mode specific behavior.
This has the nice property of a single file always having the same
node ID when presented across multiple views, giving us a firm handle
that we can use to invalidate kernel caches.
Specifically, when a file is deleted through one view, we now tell
the kernel to invalidate that file in the other two views.
Bug: 22477678, 22375891
Change-Id: I3ff041d549d41040839cde9773504719a508219f
We need to have partition.*.verified properties even when bootloader
is managing dm-verity mode, because we may have failed to set up the
verified partition and need a property to indicate this.
This means we still need to run fs_mgr_update_verity_state and walk
through all the partitions to verify the device mapper status, just
without updating verity mode.
Bug: 22489805
Bug: 22507568
Change-Id: Iaf28185adb8b80e5452447e54e1f4e4417a34168
(cherry picked from commit 2f42554f18)
Require gralloc accept flexible YUV when SW READ/WRITE usage is
set. Also decouple flexible YUV from camera usage flag.
Bug: 22379456
Change-Id: I5a82a8360b08036c31dc03cd639d449ba1e3ed01
Using a getenv('OUT') in such a deep down function is a wrong design
choice. Replacing with explicit parameter that may be NULL in case
device specific files can be accessed from /.
Since TARGET_COPY_OUT_SYSTEM may be defined to something different than
system we also ensure that we use a path relative to TARGET_OUT to
compute path to fs_config_* files.
Bug: 21989305
Bug: 22048934
Change-Id: Id91bc183b29beac7379d1117ad83bd3346e6897b
Signed-off-by: Thierry Strudel <tstrudel@google.com>
If verity state is managed by bootloader, it will pass the verity
mode to the kernel in the androidboot.veritymode command line
parameter. Init copies the value to the ro.boot.veritymode property.
Check for ro.boot.veritymode in fs_mgr and use the value to set
dm-verity mode. If this property is not set, store verity state in
metadata as before, if a storage location is specified in fstab.
Bug: 21605676
Change-Id: Ife3c978c133248432c302583d3b70e179605fe42
(cherry picked from commit ac5c1224cf)
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
Typical apps are restricted so they can only view shared storage
belonging to the user they're running as. However, a handful of
system components need access to shared storage across all users,
such as DefaultContainerService and SystemUI.
Since WRITE_MEDIA_STORAGE already offers this functionality by
bypassing any FUSE emulation, reuse it to grant the "sdcard_rw" GID
which is no longer handed out to third-party apps. Then we change
the FUSE daemon to allow the "sdcard_rw" GID to see shared storage
of all users.
Bug: 19995822
Change-Id: Id2fe846aefbf13fc050e9b00ddef120021e817f4
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
When someone force-unmounts our target endpoint, gracefully handle by
terminating, instead of looping on the same errno forever.
Bug: 22197797
Change-Id: I7e71632f69d47152ea78a94431c23ae69aba9b93
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
If a thread is created while the parent thread is "Background",
then the default timerslack value gets set to the current
timerslack value of the parent (40ms). The default value is
used when transitioning to "Foreground" -- so the effect is that
the timerslack value becomes 40ms regardless of foreground/background.
This does occur intermittently for systemui when creating its
render thread (pretty often on hammerhead and has been seen on
shamu). If this occurs, then some systemui animations like navbar
ripples can wait for up to 40ms to draw a frame when they intended
to wait 3ms -- jank.
This fix is to explicitly set the foreground timerslack to 50us.
A consequence of setting timerslack behind the process' back is
that any custom values for timerslack get lost whenever the thread
has transition between fg/bg.
See Bug: 19398120
Change-Id: Idc259717f62fa2255f8bafbbf88b68c0043f29cf
Adds the call to wakeup_callback when the write to the /sys/power/state
fails. This will help userspace account for the suspend aborts.
Bug: 17478088
Bug: 18179405
Change-Id: Icd1194cfbaf61044ca0b2fe63a10a4c52e1535bc
(cherry pick from commit ed777e9eec)
Quick low-risk to resolve possible hash table corruption.
Resolved an unlikely path memory leak.
ToDo: replace lock with nested lock so no lock
helpers are required.
Bug: 22068332
Change-Id: I303ab06608502c7d61d42f111a9c43366f184d0c
If the handle version is 0, there's no hardware_backed flag
meaning hardware backed handles will be attempted against
the soft impl. Ensure we don't try to read from hardware_backed
unless the version is > 0.
Bug: 21090356
Change-Id: I65f009c55538ea3c20eb486b580eb11ce93934fc
Jeff Vander Stoep