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
This trigger was used on FDE devices to bring down the minimal
framework, and worked by shutting down the 'main' service class.
With APEX being introduced, we want to restart all services that were
started after the tmpfs /data was mounted, as those are the services
that haven't been able to use updated APEXes in the (real) /data.
In order to do this, we need to reset more classes; that in turn
made the 'shutdown_main' trigger pretty much similar to the
previously existing 'trigger_shutdown_framework' trigger; so instead
of keeping two duplicate triggers, use only the
'trigger_shutdown_framework' one.
Bug: 118485723
Test: Taimen configured as FDE boots, Taimen configured as FBE boots
Change-Id: I0d80ef2528bd70870b063a2c580cd00a03de9961
This trigger was used on FDE devices to bring down the minimal
framework, and worked by shutting down the 'main' service class.
With APEX being introduced, we want to restart all services that were
started after the tmpfs /data was mounted, as those are the services
that haven't been able to use updated APEXes in the (real) /data.
In order to do this, we need to reset more classes; that in turn
made the 'shutdown_main' trigger pretty much similar to the
previously existing 'trigger_shutdown_framework' trigger; so instead
of keeping two duplicate triggers, use only the
'trigger_shutdown_framework' one.
Bug: 118485723
Test: Taimen configured as FDE boots, Taimen configured as FBE boots
Change-Id: I0d80ef2528bd70870b063a2c580cd00a03de9961
