This reverts commit 8ed81fd9ca.
Reason for revert: Let me try one last time more carefully. According to https://googleplex-android-review.git.corp.google.com/q/%2522customize+stubvolume%2522 - this CL will flow to aosp branches (without vendor images) and 2 branches with vendor images. I have submitted the vendor CL for both branches now (ag/13366009 and ag/13371672). This should not break anything now.
Change-Id: I69aacceabfb70053387a3c156b49e06be65fe6e4
This reverts commit 0cf77b025d.
Reason for revert: The requird libarcvolume has been submitted to master (ag/13366009)
Change-Id: I86fada53aad2ec5faa497a9bcbce5435c35d040e
This allow ARC to customize StubVolume implementation in vendor
partition.
Bug: 132796154
Test: Customize the implementation of StubVolume and check on device.
Ignore-AOSP-First: Will cherry-pick to AOSP.
Change-Id: I626a7ed4113b6132bb456b3258ee4a93b4f8a72e
destroyDsuMetadataKey() / destroy_dsu_metadata_key() calls
android::gsi::GetDsuMetadataKeyDir() to query the DSU metadata
encryption key dir and destroy the key.
This releases the resource and allows consecutive DSU installations to
use the same key *directory*, but not the same key *blob*.
Bug: 168571434
Test: 1. Install a DSU system.
2. Boot the DSU system and reboot back to the host system.
3. Wipe the DSU installation.
4. DSU metadata key dir /metadata/vold/metadata_encryption/dsu/dsu is
destroyed.
Change-Id: Ib851177315a5a266807f46ccfd446de1848232cf
The interface which is imported by an unstable interface is 'unstable'
as well. Until now, the ODR violation checker in aidl has omitted an
interface imported, but it will be checked, accordingly, fix the current
problem
Bug: 146436251
Test: m nothing
Change-Id: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Merged-In: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Exempt-From-Owner-Approval: cp from internal
Regression introduced by
commit 7ebcc2bcfd
("Revert "[Vold] Conditional dependency to ARC++ ObbVolume"")
errantly removed the product_variables support for
-D__ANDROID_DEBUGGABLE__ when built for userdebug builds.
Restore stanza.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: adb-remount-test no longer reports a problem
Change-Id: Ia7e55d1174fa7fac2d934d4aac06d15e8be388af
This reverts commit aedae617fe.
Reason for revert: ArcObbVolume is not needed by ARCVM R and above.
Bug: 157885448
Test: trybot
Change-Id: I16395ac8b6902cedea263f51e306b297d719043f
This reverts commit dcbd4fcad2.
Reason for revert: ARC is migrating to ARCVM on R, which doesn't use AppFuse any more.
Change-Id: Ifd0bf92a79c0ff25d782bea44dd593f9502f1959
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
Merged-In: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
This can be used to fixup application directories in case they have been
created by some other entity besides vold; the main use case for this
API right now is OBB directories, which can be created by installers
outside of vold; on devices without sdcardfs, such directories and the
files contained therein are not setup correctly. This API will make sure
everything is setup the way it needs to be setup.
Bug: 146419093
Test: inspect OBB dir after install
Change-Id: I2e35b7ac2992dbb21cc950e53651ffc07cfca907
The dm-crypt solution requires a kernel patch that won't be present in
the GKI kernel, while the new metadata encryption system in the GKI
kernel solves this problem in a much cleaner way.
Test: create private volume on Cuttlefish, setting property both ways.
Bug: 147814592
Change-Id: Ie02bd647c38d8101af2bbc47637f65845d312cea
More consistency between MetadataCrypt and cryptfs, and steps towards
supporting Adiantum properly in MetadataCrypt.
Test: create private volume on Cuttlefish
Bug: 147814592
Change-Id: Ic3993c1fde11b4f5a9e6cc8ee588a7d92241c6ab
This CL updates vold to use the Keymaster 4.1 interface, but does not
yet call any of the new methods.
Test: Boot the device
Change-Id: I4574a2f6eead3b71d1e89488b496b734694620c7
Merged-In: I4574a2f6eead3b71d1e89488b496b734694620c7
This CL updates vold to use the Keymaster 4.1 interface, but does not
yet call any of the new methods.
Test: Boot the device
Change-Id: I4574a2f6eead3b71d1e89488b496b734694620c7
AIDL import path should point to a root directory where relative path to
an AIDL file encodes the fully qualified name of the type in the file.
Since libvold_binder imports types like
android.os.incremental.IncrementalFileSystemControlParcel which are
under frameworks/base/core/java, the import path should set to the path,
not to the sub directory that directly has the AIDL files.
Bug: 147918827
Test: m
Change-Id: Ic4941578813eced5a7eb59a0656c10b76e902515
We want to be sure we're not allocating memory, holding locks
or otherwise preventing the child process from making progress.
This is a temporary fix of limited scope. In the medium term, it
would be preferable to exec a binary that performs this work for us
as soon as we fork.
Test: manual
Bug: 141678467
Change-Id: I57dbd9b3c887aa27e2dd609abf0ad43c66f4ef2a
Mounting a FUSE path needs two steps:
1. Mounting the filesystem
2. Starting the FUSE session in the FUSE daemon
The second part requires retriving an fd from (1) and the mount paths
and passing it to the FUSE daemon.
Previously, we'd return from the Vold mount call and mark the volume
as mounted while we scramble to do (2). This means there's a time
period where the Volume is marked as MOUNTED but not actually ready
and any IO access on the paths will hang forever. This could also be
misleading when interpreting bug reports.
Now, we block the Vold mount call until the FUSE session is started
Test: atest AdoptableHostTest
Bug: 144275217
Change-Id: I45238a31df71286f67ef1c65c711d0085d72e97f
Now that we include libfscrypt in libfs_mgr via whole_static_libs we
should not reference it directly.
Bug: 143307095
Test: treehugger
Change-Id: I4cd138b50131ec8ce7835d9604c89c99cae53212
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I890b572d537d66ecb49effd8efc782279c52956e
Objects derived from RefBase should always be owned by sp rather then
unique_ptr or other smart pointer implementations.
Bug: 79474587
Change-Id: I6a3ca04b3a3bab74c6114643ffdaeac537188d12
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
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
Motivation:
Early processes launched before the runtime APEX - that hosts the bionic
libs - is activated can't use the bionic libs from the APEX, but from the
system partition (which we call the bootstrap bionic). Other processes
after the APEX activation should use the bionic libs from the APEX.
In order to let both types of processes to access the bionic libs via
the same standard paths /system/lib/{libc|libdl|libm}.so, some mount
namespace magic is used.
To be specific, when the device boots, the init initially bind-mounts
the bootstrap bionic libs to the standard paths with MS_PRIVATE. Early
processes are then executed with their own mount namespaces (via
unshare(CLONE_NEWNS)). After the runtime APEX is activated, init
bind-mounts the bionic libs in the APEX to the same standard paths.
Processes launched thereafter use the bionic libs from the APEX (which
can be updated.)
Important thing is that, since the propagation type of the mount points
(the standard paths) is 'private', the new bind-mount events for the
updated bionic libs should not affect the early processes. Otherwise,
they would experience sudden change of bionic libs at runtime. However,
other mount/unmounts events outside of the private mount points are
still shared across early/late processes as before. This is made possible
because the propagation type of / is 'shared' .
Problem:
vold uses the equality of the mount namespace to filter-out processes
that share the global mount namespace (the namespace of the init). However,
due to the aforementioned change, the early processes are not filtered
out because they have different mount namespaces. As a result,
umount2("/storage/") is executed on them and this unmount event
becomes visible to the global mount namespace (because as mentioned before /
is 'shared').
Solution:
Fiter-out the early processes by skipping a native (non-Java) process
whose UID is < AID_APP. The former condition is because all early
processes are native ones; i.e., zygote is started after the runtime
APEX is activated. The latter condition is to not filter-out native
processes created locally by apps.
Bug: 120266448
Test: m; device boots
Change-Id: I054deedc4af8421854cf35be84e14995523a259a
cryptfs.cpp and MetadataCrypt.cpp can use android::vold::sFsckContext directly.
hash.h is unuseful.
Test: make
Change-Id: I7acdac97d6ed1c9b2a5dc367fcea8aa2942192e8
This library doesn't actually exist outside of ARC specific branches,
so it will break any ARC product builds.
Test: None
Change-Id: Ic73f470c93ea7d3590dc2b273624988291612344
