Don't use the FDE flow to support metadata encryption; just provide a
vold service which directly mounts the volume and use that.
Bug: 63927601
Test: Boot Taimen to SUW with and without metadata encryption.
Change-Id: Ifc6a012c02c0ea66893020ed1d0da4cba6914aed
This CL changes vold from using a KM3 device directly to using the KM4
support wrapper from the KM4 support library, which supports both KM3
and KM4 devices (KM0, 1 and 2 devices are still supported as well,
because the default KM3 device is a wrapper that uses them).
In addition, I found myself getting confused about which "Keymaster"
types were locally-defined vold keymaster types and which were from
the KM4 HAL and support library, so I changd the approach to
referencing the latter, so all of them are qualified with the "km::"
namespace reference.
Test: Build & boot
Change-Id: I08ed5425641e7496f8597d5716cb3cd0cbd33a7f
shipping API version:
For devices shipped before Android P nothing changes, data
is stored under /data/system/users/<user-id>/fpdata/...
Devices shipped from now on will instead store
fingerprint data under /data/vendor_de/<user-id>/fpdata.
Support for /data/vendor_de and /data/vendor_ce has been added to vold.
Bug: 36997597
Change-Id: I615e90d1c9ab08e768a8713968fa043598a0a526
Test: manually
Unfortunately, static library dependency is not transitive (even if the
dependency is a shared library). So I am wrapping the libarcobbvolume's
dependency as libarcmounter shared library.
Bug: 64500663
Test: Compile
Change-Id: I12be7a9d885c7c1c043185bd134e0148d420c6fd
Several partners have been requesting exFAT support. Android doesn't
natively support exFAT, but we're at least willing to try mounting an
exFAT filesystem if we detect the Linux kernel supports it, and if
helper binaries are present.
This CL is simple scaffolding, and it provides no actual
implementation of exFAT.
Test: builds, boots
Bug: 67822822
Change-Id: Id4f8ec3967b32de6e1c0e3c4b47fe6e43a6291ab
Remove FIDTRIM support, which isn't meaningful on UFS-based flash
devices. Modern devices require FBE/FDE which gives us better
protection against trimmed data lingering around.
Bug: 67041047
Test: builds, boots
Change-Id: I38d7d6961edf2047592b87c74b2a0f5906fb54e2
Merged-In: I4fb194c5d5ef13f413c02acedfbaaf79c567582b
This new flag isolates each user on a multi-user device for security
reasons.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.ExternalStorageHostTest#testSecondaryUsersInaccessible
Bug: 64672411
Change-Id: I3db8dde597a7715ca680779ac57957fb12a92f8e
This is how we tell CTS if the device has reserved blocks set aside
for system critical services.
Test: builds, boots
Bug: 62024591
Change-Id: I7c8ec2294b246eed54668b5717df00e72f13887a
This GID extends the ability to use reserved disk space, giving the
system a chance to be usable enough for the user to free up disk
space used by apps.
Test: builds, boots
Bug: 62024591
Change-Id: I8bc47911a71e1f399616caae83678e2914781c7e
We've finished all the underlying work to support adoptable storage
on FBE devices, so remove the code that was disabling it by default.
To aid debugging, support blocking move commands (so that we log
the stdout) via a system property, so we don't have to recompile
end user devices stuck in funky states.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Bug: 29923055, 25861755, 33252673, 37289651
Change-Id: I6b781de7e196a1a50ba543843aca0caf74c3e282
Bug: 64766105
Test: FBE boots, forceencrypt boots, set pattern, reboots, encryptable
boots and can be encrypted
Change-Id: I8c6dc0acdc37c3a6f1bea28d5607ed8938a4eb0c
We've tried our best to protect against malicious storage devices
with limited SELinux domains, but let's be even more paranoid and
refuse to look at disks inserted while a secure keyguard is
showing. We'll gladly scan them right away once the user confirms
their credentials.
Test: builds, boots, manual testing
Bug: 68054513
Change-Id: I37fd6c25bbd6631fa4ba3f84e19384d746a22498
On FBE systems, adoptable storage uses both file-based encryption (for
per-user protection) and full disk encryption (for metadata
protection). For performance/battery reasons, we don't want to encrypt
the same data twice; to that end, ensure that the
allow_encrypt_override flag is sent to dm_crypt.
Bug: 25861755
Test: see ag/3247969
Change-Id: Ib0c5891ab2d2ee9007e27a50254d29fc867d7bc5
Put AIDL files into a filegroup so they can be imported as sources
for framework.jar.
Bug: 69917341
Test: m checkbuild
Change-Id: I22e765ccf88832b1b192b42b2161898d9a6e5b2c
