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
Put AIDL files into a filegroup so they can be imported as sources
for framework.jar.
Bug: 69917341
Test: m checkbuild
Change-Id: I22e765ccf88832b1b192b42b2161898d9a6e5b2c
Correctly handle a key upgrade error from keymaster by upgrading the
FDE RSA key and writing the new key blob to disk.
Bug: 69792304
Test: Roll back PLATFORM_SECURITY_PATCH a month, wipe and reboot, roll
forwards again, check logs with and without this patch.
Change-Id: I220d2dd4e3d791f636e9bc5f063064cecbf1b88a
This patch formats f2fs paritition with proper flags.
Change-Id: Ie5ded1f2ceb3869771b2eaf9bea3b0966cab18c5
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
runIdleMaint is equivalent with:
1. echo 1 > /sys/fs/f2fs/sdX/gc_urgent
2. wait until /sys/fs/f2fs/sdX/dirty_segments
<= threshold or timeout
3. echo 0 > /sys/fs/f2fs/sdX/gc_urgent
4. fstrim
abortIdleMaint forces the wait loop above to exit and
skips fstrim. However, if fstrim is already running,
abortIdleMaint will just leave it run to completion.
Test: adb shell sm idle-maint [run|abort]
Bug: 67776637
Change-Id: I4adff8d9b6bbd63bce41368cea55dc9e9b117eb6
This is temporary. Keystore is in the process of being upgraded to use
the new Keymaster 4.0 HAL, and I want to leave vold alone, using
Keymaster 3.0 for the moment. This CL just copies relevant bits of
keystore support utilities into vold, so it can stop depending on the
copies from keystore.
After the keystore update is complete, vold will be changed either to
use Keymaster 4.0 or -- more likely -- to use keystore rather than
talking to Keymaster directly. At that point the files added by this CL
will be deleted.
Test: Device boots and successfully decrypts /data
Change-Id: I73f6d4cc4c5e20d89d7ac37d29d025bf279f9e12
A typical storage device finishes the benchmark in under 10 seconds,
but some extremely slow devices can take minutes, resulting in a
confusing UX that looks like we've frozen. Even worse, we keep
churning through all that I/O even though we know the device will
blow past our user-warning threshold.
So periodically check if we've timed out, and also use that to report
progress up into the Settings UI.
Test: manual
Bug: 62201209, 65639764, 67055204
Change-Id: I321397bcff230976f034cede0947d4a5a1f3e8a7