am: 5890c72489 -s ours
am skip reason: change_id Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051 with SHA1 8cc5716ef1 is in history
Change-Id: I27daa9c7758bec8234a1dc41a5242309fe2e5c08
am: 288fca9266 -s ours
am skip reason: change_id Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051 with SHA1 8cc5716ef1 is in history
Change-Id: I7d9f111a30c196b86f84cdaa3fd1081733be789f
Don't delete keys in checkpointing mode. Instead wait until the
checkpoint has been committed.
Bug: 134631661
Test: Flash A with a working build. Flash B with a broken build. Test
that the device rolls back to A without getting sent to recovery.
Merged-In: Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051
Change-Id: Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051
Don't delete keys in checkpointing mode. Instead wait until the
checkpoint has been committed.
Bug: 134631661
Test: Flash A with a working build. Flash B with a broken build. Test
that the device rolls back to A without getting sent to recovery.
Change-Id: Ie5fc2d098355e2d095c53e9a95a6a8c7ab7ed051
In order for the build system to track updates to the header files
during incremental builds, always specify the src files using the same
path as the package for C++ compilations.
Bug: 112114177
Test: treehugger
Change-Id: I9a2d638cbde46f67e2d5761f5b5113cc7e068ec5
Bug: 131815738
Test: vdc checkpoint startCheckpoint 2 succeeds on blueline
It fails with a modified fstab with no checkpoint=fs flag
Change-Id: I6d55810a1f711a670f18fbd10d8779c15f4e3cba
When Android boots after file_contexts has changed, the boot process
walks the entire /data partition, updating any changed SELinux labels as
appropriate. However, credential encrypted ("ce") directories are
deliberately excluded from this early boot directory walk. Files within
ce directories have their filenames encrypted, and as a result, cannot
match the file_contexts entries. Only after the user has unlocked their
device are the unencrypted filenames available and a restorecon
appropriate.
Ensure that we do a post-unlock restorecon on /data/vendor_ce, like we
do for /data/system_ce and /data/misc_ce. This ensures the labels on
files within these directories are correct after the device has been
unlocked.
(cherrypicked from commit 6a3ef488e5)
Bug: 132349934
Test: See bug 132349934 comment #12 for test procedure
Change-Id: Ifcbef5fdfb236ec6dea418efa9d965db3a3b782f
When Android boots after file_contexts has changed, the boot process
walks the entire /data partition, updating any changed SELinux labels as
appropriate. However, credential encrypted ("ce") directories are
deliberately excluded from this early boot directory walk. Files within
ce directories have their filenames encrypted, and as a result, cannot
match the file_contexts entries. Only after the user has unlocked their
device are the unencrypted filenames available and a restorecon
appropriate.
Ensure that we do a post-unlock restorecon on /data/vendor_ce, like we
do for /data/system_ce and /data/misc_ce. This ensures the labels on
files within these directories are correct after the device has been
unlocked.
Bug: 132349934
Test: See bug 132349934 comment #12 for test procedure
Change-Id: Ifcbef5fdfb236ec6dea418efa9d965db3a3b782f
This mostly 1:1 replaces manual ioctls to device-mapper with calls to
libdm. There were two exceptions:
(1) There is a very old table-load-retry loop to workaround issues with
umount (b/7220345). This loop has been preserved, however, it now
includes DM_DEV_CREATE as well as DM_TABLE_LOAD.
(2) There was some ancient code to set DM_DEV_GEOMETRY for obb
dm-devices. This never did anything since geometry must be set after
loading a table. When setting it before (as vold was doing), the
subsequent DM_TABLE_LOAD will clear it.
Bug: 132206403
Test: FBE device boots
FBE device w/ metadata encryption boots
FDE device boots
atest StorageManagerIntegrationTest
Change-Id: Ib6db6b47329f093ac7084edaf604eddace8b9ac6
am: ebce4cc16b -s ours
am skip reason: change_id Ib3272a47a901ed106474039e72f123b11f5443ff with SHA1 5fceb48da1 is in history
Change-Id: I0d248b5b041118b318c36858882342d626fcb7b0
