Delay mounting encryptable but unencrypted volumes until we can
check the ro.vold.forceencrypt flag, then optionally encrypt.
Requires matching vold change from
https://googleplex-android-review.git.corp.google.com/#/c/615309/
Bug: 18764230
Change-Id: If22008be8de6a4f3216b349f81ace49be1730314
This reverts commit 152d2d4234.
Fixed build error, and also fixed memory leak spotted from warning.
(cherry-pick of bbb36319119edde9377fb80015235893c30d2bc9.)
Bug: 17691572
Change-Id: I23b5ba537f7b557432041d4338b38b9be434e981
If the encryptable partition is wiped (4KB worth of 0 or 0xff),
then reboot into recovery to format /data+/cache
This is while waiting for the Mac OS support to format f2fs.
The flashstation running on Mac OS will currently just erase userdata
and not format it with f2fs.
Bug: 15720406
Bug: 15747366
Change-Id: Ib7cca3e1701483a09573457a835750f34da71ee0
Move the code that attempts to mount alternative fstab entries
into its own function.
Clarify return codes.
Suggest wipe via recovery in error messages.
Bug: 15747366
Change-Id: I3634477cd4d1d73f974f3e906c53285f0d9e0eac
Signed-off-by: JP Abgrall <jpa@google.com>
Previous attempt was broken.
It would incorrectly be affected by mount failures.
This changes allows an fstab to contain multiple lines for a given
mount point.
The lines sharing a mount MUST be after each other.
The 1st matching line is the primary when it comes to mounting
and look ups for wiping.
Mounting based on a mount_point will attempt each dup in turn
until one succeeds.
The reported error will be that of the last failed attempt.
This is to allow quick experimentation between different FSes.
Bug: 15702546
Change-Id: I378d68ad13eb0098ec1ccb8dcf108b82acbe9ebb
Signed-off-by: JP Abgrall <jpa@google.com>
This is apparently breaking N5, so reverting for now.
This reverts commit a794f86522.
Bug: 15709256
Change-Id: I37a5160eead17e153e2c83fa94632ffa5d8553c2
This changes allows an fstab to contain multiple lines for a given
mount point.
The lines sharing a mount MUST be after each other.
The 1st matching line is the primary when it comes to mounting
and look ups for wiping.
Mounting based on a mount_point will attempt each dup in turn
until one succeeds.
This is to allow quick experimentations between different FSes.
It does not deal with checkfs yet, because the underlying invocation
of fs-type appropriate fsck does not handle the error code.
Only the primary FS (1st in the dups) is checked.
Change-Id: I8329737454b53e2681436fe85cd00a9bc522676b
Signed-off-by: JP Abgrall <jpa@google.com>
This change adds a "verify" fs_mgr flag specifying that
the device in question should be verified.
Devices marked with this flag are expected to have a
footer immediately after their data containing all
the information needed to set up a verity instance.
Change-Id: I10101f2c3240228ee0932e3767fe35e673d2e720
Instead of specifying in init what to mount, and having various hacks in init
itself to deal with encryption, use a filesystem manager library to do the
work, that can also be invoked by vold when mounting an encrypted volume.
Keep all the magic filesystem info an a device specific fstab file.
Change-Id: Ib988f1e4fb0638ba1d5fd98407fa6d8cf862aaca
